This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Vista + cygwin basics

Charles Wilson wrote:

> Does anybody know what's going on here?

Vista introduces a new state on every object, the Integrity Level (IL):
low, medium, high, and system.  If you use process explorer you can
enable this column to be viewed.  By default, everything gets created
with medium IL.  When a process elevates, it gets bumped to high. 
Services run as system, and IE runs as low.

The IL is their workaround for the following problem: They want users to
run as "administrators who have dropped privileges."  This gives the
desired effect of inability (or less-ability) to cause harm, yet they
can still elevate to administrator to do all those common things that
require admin privileges by just clicking "Yes" or "Okay", as opposed to
being a real non-admin user which would require entering credentials to
elevate to admin.

In XP this was done simply by creating a new process token and removing
the membership from the administrators group, as well as any dangerous
privileges.  This in theory would allow sandboxing things like the
browser, while letting the user remain an admin so that they can still
install software or whatnot.  But there's a huge gaping hole in this
strategy: the "sandboxed" process can still escape its sandbox because
the default security model allows full access to all objects you own. 
So the sandboxed process could simply OpenProcess any other process
running as that same user and inject a new thread to execute arbitrary
code, or it could inject simulated mouse/KB into Explorer, or a million
other leaks.  This is not a real sandbox.

Redmond still wanted the ease of easy elevation, but with better
sandboxing, so they came up with this Integrity Level junk.  Along with
the four levels are three policies: No-Write-Up, No-Read-Up, and
No-Execute-Up which describe what an object of lower IL is allowed to do
to one of higher IL.  The default policy for everything but threads and
processes is No-Write-Up, but for those it's No-Read-Up and
No-Write-Up.  Thus, a process cannot read or write another process if
that process has higher IL, even if both processes are owned by the same
user.  This is so that the browser can run at low IL and a rogue ActiveX
control wouldn't be able to use one of the many code injection
techniques to break out of the "sandbox" (still not a real sandbox.) 
But it also means that when you are simply running as a normal process
at medium you cannot read elevated processes at high, which means they
won't show up in a "ps" listing.  I don't know why the high IL process
doesn't include the medium/low IL processes in its ps.

(They also implemented a form of window message filtering called User
Interface Privilege Isolation (UIPI) which is a similar set of
restrictions that is supposed to prevent the a process from being able
to send window messages to a process of higher IL -- this is to prevent
the "inject virtual keystrokes" style of attack.)

But the sad thing is this is all nonsense, it is not an actual security
barrier but more of a deterrance.  The fact is that a user that is an
administrator that has dropped privileges (i.e. what 99% of vista users
are) is still an administrator at heart, no matter what IL or UIPI may
prevent.  There will always be cracks and ways to get out and elevate,
see <>.

For example, MS was the butt of a lot of jokes when it was first
revealed that the OS uses a number of heuristics (such as "filename is
setup.exe") to automatically prompt to elevate.  Some people said "oh
look, huge security hole, just rename your badware to setup.exe and
you're instantly an admin as long as the user just clicks 'okay'."  What
these people are missing is that, yes, this is one particularly
laughable example, but it does not represent a real security hole at
all.  The whole UAC/"pretend I'm not an admin but I really am one" thing
is just training wheels to try to encourage developers make software
that does not require admin privileges.  That you can bust the training
wheels does not indicate a security breach, it just means that you were
always an admin anyway and that it's impossible to "partially" drop
admin privileges.  If you actually made your user account a normal user
account then clicking on "setup.exe" would require entering a root
password to do any damage, just like on Linux or OS X.  

Some good background:
...and pretty much anything else Mark has written.


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]