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

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

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.


Unsubscribe info:
Problem reports:

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