This is the mail archive of the
mailing list for the Cygwin project.
Re: Vista + cygwin basics
Brian Dessent 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.
But wait: somehow syslogd works. If all services are at the highest IL,
then no lower IL should be able to use syslog()? But I (a lowly,
unprivileged user) can run logger.exe -- presumably with 'medium' IL --
and my message DOES get logged.
So somehow this barrier is crossed. (If this were a real OS, instead of
cygwin-dll-on-top-of-windows, I say "aha! system call exception!")
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.
Well that's one mystery. Another is why, as admin, my 'ps' can see the
services? As an unelevated process, it is also at 'medium IL'.
But let's talk implementation. The (cygwin) process list is managed by
(the one, single copy of) the cygwin1.dll in memory, using a global
(that is, non-login-session-based) named shared memory area, right?
"Since processes running at different integrities are sharing the same
desktop they share the same “session”. Each user logon results in a new
session in which the processes of the user execute. The session also
defines a local namespace through which the user’s processes can
communicate via shared objects like synchronization objects and shared
But that really doesn't say anything about the two mysteries above --
because the various processes involved are running in different login
sessions, under different accounts: Administrator, cyg_server, SYSTEM,
and ME. Now, perhaps there are some additional rules in this "security"
model that allow shared memory between processes running in different
sessions [I thought using the global namespace would do that] AND
different ILs...but those aren't explained in Mark's blog.
...and what about cygserver? Seems like Vista's scheme would completely
break it -- at least with regards to communication between these various
not-really-sandboxes. </me needs to go experiment with
Worse, it seems that any technique we might develop to restore "normal"
behavior would be (a) the same kind of thing that malware would do, (b)
be detected as such by AV software, and (c) "fixed" -- e.g. eliminated
-- in the next SP or OS.
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.
Yes, my normal user is not an Administrator, and that's exactly what
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html