Re: Vista + cygwin basics

[Brian Dessent <brian at dessent dot net>]

Charles Wilson wrote:

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

As far as I know, syslog listens on both a UDP port and /dev/kmsg
(implemented as a mailslot.)  Those are both file objects, which are
distinct from process objects, and this whole IL business has per-object
level granularity.  A medium IL process mightn't be able to read a
process object of higher IL, but perfectly able to read a file object of
higher IL, and it's only process objects and thread objects that have
the no-read-up policy.  And I'm sure somewhere in the default policies
there is the allowance for the fact that the file object representing a
port that a service is listening on should be readable/writable by any
IL, since otherwise the service would be useless.

> 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!")

It's not a "you can't see any aspect of this process" barrier, it's much
more fine grained.

> 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 it was elevated, since you did "run as administrator".  The only way
to have a process with admin privileges that is not elevated is to
disable UAC.  However this does not explain why it can see the services
that are running at IL of System.  I think that is because it's getting
the info from the Cygwin shared memory area, not from opening the
process object and reading its command line there.

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

You can clear this all up with process explorer:

Unelevated bash shell:
- user 'brian'
- IL medium
- session 1
- shared memory area \Sessions\1\BaseNamedObjects\cygwin1S4.shared.4

Elevated bash shell
- user 'brian'
- IL high
- session 1
- shared memory area \BaseNamedObjects\cygwin1S4.shared.4

syslog-ng service
- user 'NT AUTHORITY\SYSTEM'
- IL System
- session 0
- shared memory area \BaseNamedObjects\cygwin1S4.shared.4

So as you can see, Cygwin tries to create its shared section in the
global namespace, but doing this requires administrator privileges, so
it can only do it if elevated (or UAC disabled.)  This explains I think
everything that you saw.

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

AFAIK the cygserver daemon listens on a named pipe ("cygwin_lpc") which
is the same category as above with a daemon listening on a port.  I
tried shmtool and it worked fine from both a regular account and an
elevated account.

Brian

--
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/