Vista + cygwin basics

[Charles Wilson]

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?

Well, kinda:
"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 
memory."
http://blogs.technet.com/markrussinovich/archive/2007/02/12/638372.aspx

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 
msgtool/semtool/shmtool...>

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 
happens.

--
Chuck

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/