Mandatory integrity control in Windows Vista

re: Mandatory integrity control in Windows Vista

Mike — Mon, 24 Jul 2006 01:46:23 GMT

Wow. This sounds great! Have you run into any major application compatibility problems because of it?

re: Mandatory integrity control in Windows Vista

blogCZSK — Mon, 24 Jul 2006 12:00:29 GMT

I really like the concept of MIC, however I am missing one (I think quite important) thing - visual differential between applications in different MIC modes. Dont you know about something like explorer extensions, that will enable this???

HTTP over HTTP

spatie25 — Wed, 26 Jul 2006 22:47:13 GMT

I was reading the blog by Keith Combs covering the new ‘HTTP over HTTP’ feature on ISA2006. (http://blogs.technet.com/keithcombs/archive/2006/07/08/440752.aspx)

This got me back to a brain breaker I am struggling for some time now. I am very concerned about the way things are moving with remote communication in all its aspects. It shows over the last few years that more and more vendors are adopting the approach to encapsulating all sorts of protocols in HTTP. Of course this is a very tempting solution, as HTTP in many cases is about the only protocol that is allowed to travel across a company’s firewall.

I remember a presentation on security, hosted by MS employees, were it was stated bluntly : don’t use VPN, it is a hole in your firewall, which is quite fair to me.

Now, I wonder what the advice would be from the MS security experts on protocols that are ported over HTTP. I try to understand what the risks could be, or why I should be rest assured that this is under control. The way I understand it is that there is no defence against malicious code, encapsulated in an HTTP protocol other than a very performant firewall with state of the art statefull inspection and even then, I am told, it still is risky business. On the why’s, I get various explanations that do not always comply with one another.

Now, I understand that this IPsec solution, offered by ISA2006, is pretty nice in terms of setting up a secure P2P connection without the hassle of a VPN client. But this is not the discussion. What to think about an employee, trying to access the OWA servers from a public computer : no VPN, no IPsec, just a certificate and a password. Once compromised, you can only but imagine what could go wrong. And in this case we are ‘talking’ HTTP, plain simple (for the firewall that is).
What if that employee tries to do RDP over HTTP or whatever other traffic that could be routed over HTTP. I am making to much fuzz out of nothing, or should we be careful in how we ‘adopt’ these new features?

re: Mandatory integrity control in Windows Vista

SomeDude — Fri, 04 Aug 2006 02:13:59 GMT

Great article!

What GUI and command-line tools can be used to see or edit the labels on sucurable objects? WHOAMI.EXE shows my SAT's label, but I don't see anything different in REGEDIT, Windows Explorer, etc.

Thanks!

re: Mandatory integrity control in Windows Vista

Bryan — Fri, 04 Aug 2006 04:27:52 GMT

Very interesting - but I feel a nagging dread as well.

What tools will administrators have, so that they can see and edit the intergrity level of an object?

What errors will mismatched integrity levels generate?

What documentation exists- explaining exactly how integrity levels are assigned by the OS and/or installer programs? Does written data always inherit the integrity level of the user whose process wrote it? (Given the IEPM example it seems not?)

This could be an excellent feature, but it's going to need extensive documentation! Anything on MSDN yet?

re: Mandatory integrity control in Windows Vista

Multician — Mon, 28 Aug 2006 19:57:54 GMT

Multics had it, back in the day. And of course it was an option for almost every Unix vendor back in the 80's.

Mandatory Integrity Control in Vista

Mike Taulty's Blog — Wed, 06 Sep 2006 03:25:26 GMT

I picked up this post on Vista's new Mandatory Integrity Control feature by way of Steve's blog. The...

Ah, the joys of speaking about pre-release software!

Steve Riley on Security — Wed, 06 Sep 2006 06:21:47 GMT

Two weeks ago I delivered my Windows Vista System Integrity presentation at the TechEds in New Zealand...

COM activation change in Windows Vista

Junfeng Zhang's .Net Framework Notes — Wed, 06 Sep 2006 08:50:51 GMT

In Windows Vista, COM will read HKLM\Software\Classes when the process has a integrity level &gt; MEDIUM,...

re: Mandatory integrity control in Windows Vista

KJK::Hyperion — Fri, 08 Sep 2006 13:26:17 GMT

I wonder, why didn't you implement the "no read down" policy? not even as an optional flag for labels?

Ah, the joys of speaking about pre-release software!

Steve Riley on Security — Sat, 09 Sep 2006 06:29:09 GMT

Two weeks ago I delivered my Windows Vista System Integrity presentation at the TechEds in New Zealand...

re: Mandatory integrity control in Windows Vista

Steve Riley — Mon, 11 Sep 2006 00:18:52 GMT

MIKE: No, I'm not aware of any app compat issues that MIC has caused.

SPATIE25: A long time ago, I had the same lament as you. "It's a bastardization of HTTP to make it into the univseral transport," I claimed. But I've changed my thinking there. Look for a blog post soon about why I think the trend is good.

SOMEDUDE: Some SysInternals (www.sysinternals.com) now display integrity levels: AccessChk and Process Explorer.

BRYAN: MIC is automatic and doesn't really require user or administrator tinkering. There's information on MSDN about MIC; one interesting document describes how IEPM uses MIC (http://msdn.microsoft.com/library/en-us/IETechCol/dnwebgen/ProtectedMode.asp).

KJK: We want to keep MIC's purpose simple: to control writes. "No read down" is more of a privacy control. You can implement something very similar by putting deny ACLs on resources -- deny access to any principal whose integrity level is lower than the level of the resource.

re: Mandatory integrity control in Windows Vista

Rob — Mon, 11 Sep 2006 14:52:13 GMT

Please, please do not confuse the mandatory ACCESS controls as described by Bell and LaPadula with the mandatory INTEGRITY controls as described by Biba. They are fundamentally different in the way they are working and in the way they allow and disallow access.

Also, your statement on Vista being the first commercial OS to implement them is dead wrong. It may be the first consumer OS, but it most definitely is not the first commercial OS.

re: Mandatory integrity control in Windows Vista

Steve Riley — Mon, 11 Sep 2006 17:37:15 GMT

ROB: Hmm, I'm not exactly sure why you think I have confused them? I certainly understand the difference -- and my post even includes links to Wikipedia articles describing the two models.

Note that I mention MIC as a *form* of Biba. While MIC does enforce Biba's no write-up restriction, it doesn't enforce the model's no read-down restriction. To do so is impractical for computer integrity controls. Consider that you, as a medium integrity user, would never be able to read data written by IE protected mode if MIC implemented no read-down.

Plus, understand that Bell-LaPadula can't be directly compared to access controls. If you were to do that, then you could never write data that principals with a lower access level could read. In other words, you could never create information that's readable by, say, everyone.

re: Mandatory integrity control in Windows Vista

Rob — Tue, 12 Sep 2006 10:05:34 GMT

Steve,

You should reverse the matter, the Biba model is a form of MIC. Comparing the MIC as implemented to Biba is pointless, since, as you point out, Biba describes no read down as a restriction, which the MIC implementation in Vista does not do.

I find it a very puzzling implementation, why did Microsoft decide to have the operating system files unlabeled? (thus essentially sticking them at the same level as the user is?). It would have been no problem to have them at a higher integrity level... lower-level processes can still read from them.

Regarding Bell-LaPadula, you bet they can be compared to access controls, ssince they *are* access controls. Just not the ordinary discretionary ones you have gotten used to. You got the point behing Bell-LaPadula right, the fact that principals with a lower access level can't read data with a higher level is what you *want* in the situation for which Bell-LaPadula was designed (namely a military organisation).

I have worked with operating systems implementing the full Bell-LaPadula and the full Biba model, and those operating systems provide mechanisms to circumvent those models in certain, wel known and audited places. Working on such a system can be pain, but the assurance that processes are strictly separated is in some cases worth that pain.

re: Mandatory integrity control in Windows Vista

Steve Riley — Wed, 13 Sep 2006 01:03:53 GMT

I guess we have different interpretations of the function of a model. To me, a model is a guideline, something to base a design on, not to constrain. Biba and Bell-LaPadula describe idealized functionality -- functionality which can be fully implemented if necessary, as you mention. But in the more common cases of integrity and access control, certain elements of the models must be relaxed in order for the controls to be broadly useful.

It's a good question about the OS files being unlabeled. Essentially, you've got two choices for protecting the files: label them system integrity (higher than admins) or ACL them read-only for everyone except the trusted installer. Neither approach will stop malicious admins or malware running as admin: in the former, the admin or malware can directly modify the master file table and remove the integrity labels on the files; in the latter, the admin or malware can take ownership of the files and change the ACLs. This reinforces the point that administrators must be people you trust.

There's one advantage to the approach we finally took. Setting the ACL to trusted-installer:full-control, everyone-else:read-execute-only makes very obvious the intention of the security policy. A system integrity level wouldn't be so clear. Generally, it's best to think of integrity checks as a compliment to access control, not a replacement.

re: Mandatory integrity control in Windows Vista

Rob — Wed, 13 Sep 2006 11:56:05 GMT

Steve, in your last paragraph you are (again) mixing up access controls with integrity controls.

The whole point behind mandatory controls is exactly that, they are mandatory. File ownership, access and integrity are no longer at the discretion of the system administrator, they are enforced by the policy inspection mechanism according to the label they carry. And that means *everything* on the system has to have a label. It also means that an administrator might not be able to touch stuff on the system. In that case you no longer need to rely on trust in the administrator. This is a *fundamentally different* way of thinking about both access and integrity.

And that is the issue here. You are not *enforcing* mandatory integrity. You are not enforcing anything. You are providing an extra integrity checking mechanism. The fact that it is provided is a good thing. The fact that it is labeled by your marketing department as "mandatory integrity controls", which it is clearly *not*, is confusing at best. There is no such thing as mandatory integrity on Vista if I as administrator can still alter the master file table.

re: Mandatory integrity control in Windows Vista

Steve Riley — Wed, 13 Sep 2006 18:16:10 GMT

Rob, I'm not sure we'll come to agreement here. I disagree with your assertion that I am "mixing up" access controls with integrity controls. I certainly understand the differences, the definitions of idealized implementations, and the reality of applying the computer science principles they embody to the real-world implementations that derive from them.

Integrity controls in Windows Vista *are*, in fact, mandatory. Any object that has a security descriptor is evaluated against integrity controls, even if the object itself is unlabeled. In the case of unlabeled objects, the operating system assumes a label of medium.

One of the fundamental laws of computer security states that if a bad guy can get software to run on your computer, then it isn't your computer anymore. In my description of how an administrator might alter labels, I'm simply being honest about how locally-executed malicious code can cause damage. Every computer system in the world, regardless of operating system, can be owned by a sufficiently-motivated attacker.

re: Mandatory integrity control in Windows Vista

Mark Minasi — Mon, 18 Sep 2006 14:18:48 GMT

Hi --

I noted that several of you wanted a tool that would let you examine and change integrity levels on objects in Vista. icacls does it, but it's still broken and a bit limited, so I wrote a tool that may be useful. It's at http://www.minasi.com/vista/chml.htm and it's a command-line tool that lets you see an object's IL, change it via either SDDL (ugly but flexible) or with some simpler options. I hope this helps someone!
-- Mark

Phew ... I can come up for air now.

James O'Neill's blog — Mon, 18 Sep 2006 16:58:01 GMT

I have finally got my outlook unread messages down to zero. There are 1229 Messages in my deleted Items...

re: Mandatory integrity control in Windows Vista

Walter — Fri, 29 Sep 2006 01:21:19 GMT

In prior Vista betas, Process Explorer used to show a SID flag named "DesktopIntegrity" in the SAT of a process. The "Integrity" flag is still around, but what happened to "DesktopIntegrity"?

I assume that "DesktopIntegrity" was for User Interface Privilege Isolation (UIPI), so does this mean MIC is no longer being used for UIPI just like Windows Resource Protection no longer uses MIC?

Any other MIC changes in build 5728 to know about?

Thanks again for the blog, it's hard to find this information!

Ah, the joys of speaking about pre-release software!

Steve Riley on Security — Wed, 04 Oct 2006 01:52:06 GMT

Two weeks ago I delivered my Windows Vista System Integrity presentation at the TechEds in New Zealand

re: Mandatory integrity control in Windows Vista

Enno Rey — Fri, 06 Oct 2006 12:04:09 GMT

Steve,

at first thanks for your blog and the valuable insight it provides. After reading your post on MIC I decided to have a look on it, given I've done some research on multi level security systems lately. I stumbled across some obscurities though which I'd like to clarify here. Please note that this was my first installation of Win Vista ever so maybe there are some misunderstandings of concepts on my side...

So this is what I did in detail:

- default installation of RC1 (build 5600)

- creation of first and single user (here 'erey')

- logged in as erey, with restricted token and the following privs

PRIVILEGES INFORMATION

----------------------

Privilege Name Description State

============================= ==================================== ========

SeShutdownPrivilege Shut down the system Enabled

SeChangeNotifyPrivilege Bypass traverse checking Enabled

SeUndockPrivilege Remove computer from docking station Disabled

SeIncreaseWorkingSetPrivilege Increase a process working set Disabled

SeTimeZonePrivilege Change the time zone Disabled

- creation of c:\tools directory and download of tools to it (Sysinternals: accesschk, ProcessExplorer and Mark Minasi's chml)

=== Integrity level of files

I then checked the integrity levels of the files just downloaded and here comes the first surprise (or just personal misunderstanding):

AccessChk v2.0 - Check account access of files, registry keys or services

Sysinternals - www.sysinternals.com

C:\tools\accesschk.zip

Medium Mandatory Level (Default)

RW BUILTIN\Administrators

RW NT AUTHORITY\SYSTEM

R BUILTIN\Users

RW NT AUTHORITY\Authenticated Users

C:\tools\chml.exe

Medium Mandatory Level (Default)

RW BUILTIN\Administrators

RW NT AUTHORITY\SYSTEM

R BUILTIN\Users

RW NT AUTHORITY\Authenticated Users

I had naively expected that these files had an integrity level of 'low' given their origin (internet) and the process that wrote them to disk (IE, supposedly running with 'low' integrity).

Question: why do these files have an integrity level of 'medium'? Lack of intlevel assigning capability in IE in current state?

Or the other way round: what the hell will ever get intlevel 'low' if not such files (executables downloaded from the internet, restricted user, by means of IE, from untrusted sources)?

[one could argue that the Sysinternal stuff is signed, but at least the Minasi stuff isn't].

=== Integrity level of processes

Looking at the integrity level of processes I noticed the following:

1) Restricted token user 'erey' invokes procexp.exe (medium) => process integrity: medium

2) (Run as) Administrator 'erey' invokes procexp.exe (medium) => process integrity: high

This is consistent to your description (or at least my understanding of it ;-):

"when a user invokes a file whose integrity level is higher than low the resulting process will run with the integrity level of the user"

[which contrasts to the Biba model where the lower level of subject (user) and object (file) is chosen, but as you correcty say a model is just a basis...].

This again rises the question: if a user runs an internet-downloaded executable with admin privileges (and this will happen rather often, think of all the little helper tools available from the internet, requiring admin privs for whatever reason), the resulting process will run with intlevel 'high'. Where's the protection benefit then?

I understand the behaviour is consistent (however I'm not sure if or why the variation from Biba is a good idea here) and I understand that maybe the process needs a 'high' intlevel (to perform it's functions correctly) - and yes UAC came into place and asked me when invoking procexp as an admin - but I'm a bit sceptic about the use then. My previous understanding of "in Vista we're running IE with low privs to protect you from all that bad stuff coming from the internet" was a bit different...

=== Modifying intlevel of files and the results

Time for a change of the integrity level of an executable now...

Trying that gave the following:

- created a copy of procexp.exe

1) - tried (as 'erey' with restricted token) to modify intlevel by

C:\tools>chml procexp_mod.exe -i:l

=> did not work ("Access is denied").

2) I then gave the user 'erey' the privilege "Modify an object label" by gpedit (+ gpupdate).

After logging out and in again I noticed I did not even (seem to) have it when running cmd.exe as admin:

PRIVILEGES INFORMATION

----------------------

Privilege Name Description State

=============================== ========================================= ========

...

SeCreateGlobalPrivilege Create global objects Enabled

SeRelabelPrivilege Modify an object label Disabled

SeIncreaseWorkingSetPrivilege Increase a process working set Disabled

But now chml worked:

C:\tools>chml procexp_mod.exe -i:l

chml v1.010 -- Change Windows Integrity Level

"chml -?" for syntax, examples and notes.

Integrity level of procexp_mod.exe successfully set to low.

C:\tools>accesschk.exe -i procexp_mod.exe

AccessChk v2.0 - Check account access of files, registry keys or services

Sysinternals - www.sysinternals.com

C:\tools\procexp_mod.exe

Low Mandatory Level (!!!)

RW BUILTIN\Administrators

RW NT AUTHORITY\SYSTEM

R BUILTIN\Users

RW NT AUTHORITY\Authenticated Users

3) Invoking the procexp_mod.exe with intlevel 'low' gave the following:

invoking as restricted user 'erey' => process integrity: 'low' (as indicated by ProcessExplorer)

invoking as admin => process integrity 'high'

BIG surprise! what's going on here? High integrity user runs low integrity executable and resulting process runs on 'high' integrity!?!

Questions:

a) Looking at the "Explain" text in gpedit:

"Modify an object label

This privilege determines which user accounts can modify the integrity label of objects, such as files, registry keys, or processes owned by other users. Processes running under a user account can modify the label of an object owned by that user to a lower level without this privilege."

... I do not understand why 1) didn't work. I invoked a process cmd.exe (supposedly running with intlevel 'medium' given the user was restricted) and tried to modify a file I owned. The observed behaviour seems to contrast the 'help text' but seems consistent to Mark Minasi's comments in the manpage of chml.

b) why did user 'erey' seemingly not dispose of SeRelabelPrivilege after assigning it to him directly and logging out+in, neither as restricted user nor as admin? or at least: why did 'whoami' indicate that? Problem of privilege enumeration in 'whoami'?

c) please explain scenario 3 mentioned above! ;-))

This seems to contradict fully your explanation (or I got it totally wrong).

There seems to be a different behaviour as for the process intlevel, depending on the level of the invoking user.

And: is this a good idea? Biba wouldn't have liked that a lot. And neither do I ;-)

Concluding my observations mean:

User downloads executable from internet, saves file to hard disk and this file has intlevel 'medium': maybe no a good idea.

[maybe resulting from IE currently not assigning intlevels to files it writes]

User running with admin_privs (most windows users will still sometimes do ;-) invokes this executable resulting in a process running with intlevel 'high': debatable...

Security aware user labels some executables down to 'low' but invokes them as admin, process is running with intlevel 'high': what can I say here? ;-)

These are some observations from a guy with some background on "Mandatory" security models, running Vista for the first time.

Thanks in advance for your answer, I appreciate your efforts.

thanks,

Enno

re: Mandatory integrity control in Windows Vista

Milan — Sat, 07 Oct 2006 21:38:19 GMT

I believe that Trusted Solaris by Sun was the first commercial implementation of Mandatory Access Control. I always thought this was a great feature and oddly neglected by the media. I guess that now M$ does something, everyone will get excited...

re: Mandatory integrity control in Windows Vista

Dominick — Sun, 08 Oct 2006 12:36:11 GMT

Hi Steve,

Enno posted very interested observations.

Is there already some documentation that describes the behavior and scenarios of MIC?

Or - alternatively - could you comment on Enno's findings as they look like a complete description of the current behavior.

thanks!

MB’s Windows Security » Blog Archive » Why doesn’t IE7 protected mode mark downloaded files as low integrity?

Tue, 13 Mar 2007 07:05:21 GMT

PingBack from http://xato.net/bl/2007/03/12/why-doesnt-ie7-protected-mode-mark-downloaded-files-as-low-integrity/

Wes' Blog : Failure creating an Outlook application object on Vista

Wes' Blog : Failure creating an Outlook application object on Vista — Mon, 05 Nov 2007 08:57:12 GMT

PingBack from http://puzzleware.net/blogs/archive/2007/11/04/Failure-creating-an-Outlook-application-object-on-Vista.aspx