Hi, in Windows Vista Microsoft plans to introduce a security concept they call "Mandatory integrity control" (MIC) which is described here: [1] http://blogs.technet.com/steriley/archive/2006/07/21/442870.aspx As this sounds like a promising feature I did some testing with Vista RC1 that gave interesting results. I posted them to that blog asking for clarification and will post them here as the technology and discussion may be of interest for some bugtraq readers. ================ 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... 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 Copyright (C) 2006 Mark Russinovich 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 correctly 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 by Mark Minasi (c) 2006 www.minasi.com "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 Copyright (C) 2006 Mark Russinovich 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 not 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 -- Enno Rey ERNW Enno Rey Netzwerke GmbH - Breslauer Str. 28 - 69124 Heidelberg Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 www.ernw.de - PGP 055F B3F3 FE9D 71DD C0D5 444E C611 033E 3296 1CC1
