Mail Archives: cygwin/2008/04/21/23:36:58
Corinna Vinschen wrote:
> Sorry Brian, but this has only marginally to do with integrity levels.
> The real reason for this is the SeCreateGlobalPrivilege introduced with
> Windows 2003. Only administrative users hold this privilege by default,
> as well as any process running in terminal server session 0. Not having
> this privile means, you are not allowed to create named shared memory in
> the global namespace. That means, the global shared memory used by
> Cygwin can not be created by a non-admin user running in another session
> than 0.
This explains another detail I noticed. I have sshd running as a
service, under the cyg_server user. As Corinna explains, because it is a
service it is running in session 0. If I ssh *in* to the machine and log
in as my unprivileged self ME, and type ps...
$ ps -eaf
UID PID PPID TTY STIME COMMAND
SYSTEM 5392 1 ? Apr 18 /usr/bin/cygrunsrv
SYSTEM 6108 5392 ? Apr 18 /usr/sbin/cygserver
SYSTEM 2460 1 ? Apr 18 /usr/bin/cygrunsrv
SYSTEM 4780 2460 ? Apr 18 /usr/sbin/syslog-ng
cyg_serv 2948 1 ? Apr 18 /usr/bin/cygrunsrv
cyg_serv 3772 2948 ? Apr 18 /usr/sbin/inetd
cyg_serv 4500 1 ? Apr 18 /usr/bin/cygrunsrv
cyg_serv 5036 4500 ? Apr 18 /usr/sbin/sshd
ME 3804 1 ? Apr 19 /usr/bin/ssh-agent
ME 2420 1 ? Apr 19 /usr/bin/ssh-agent
ME 6856 1 ? Apr 20 /usr/bin/ssh-agent
cyg_serv 2260 5036 ? 23:01:57 /usr/sbin/sshd
ME 1304 2260 0 23:01:59 /usr/bin/bash
ME 6664 1 ? 23:02:04 /usr/bin/ssh-agent
ME 7932 1304 0 23:02:07 /usr/bin/ps
even my unprivileged self can see the services -- because as a remotely
logged-in user, I inherit the session of the service: 0.
As confirmed by Process Explorer.
However, the bash shell for the remote login is running at the Untrusted
IL in session 0, unlike the bash shell for the current at-the-keyboard
login, which is running at the Medium IL in session 1.
I'm not sure that's what I'd want...I think I'd want my remote user to
be Medium, to, otherwise all kinds of odd sandboxing/virtualization
things happen, right?
> Up to and including Windows 2003, all console users and all services are
> running in TS session 0. Beginning with Vista, even the console logon
> is running in a session != 0 and only the services are running in
> session 0.
Right. That's what I see -- except for the remote users authenticated by
those services in session 0. They don't get a session of their own, but
remain in session 0.
Hmmm. I wonder if they SHOULD get a session of their own (which might
alleviate any concerns with IL medium processes controlled by a remote
user running in session 0 with the services). How would
sshd/rlogind/telnetd do that?
Oh, and I now have an explanation for why there are so many ssh-agents
running. When I log in remotely, I'm in session 0. I read the .keychain
file and get the PID of the current ssh-agent, which is running in
session for the at-the-keyboard logon. However, I can't contact it --
it's in a different session. So, keychain starts a new ssh-agent -- AND
overwrites the ~/.keychain/${host}-sh file!
Now, while the remote user is still logged in, suppose the desktop
starts a new bash --login shell. Well, my ~/.bash_login runs keychain,
and sees the PID for the *remote* user's ssh-agent in session 0. Since
he's in session 1, he can't contact it, and starts a new ssh-agent --
AND overwrites the ~/.keychain/${host}-sh file AGAIN.
And now I have three different ssh-agents: one for the remote user, and
two for the various shells used by the at-the-keyboard user.
Rinse and repeat.
I think I need to teach keychain to use separate files in ~/.keychain/
for different sessions on the same host. Is there a command line tool
that I can use to get the session number #if Vista?
> With UAC enabled, an administrative user running a normal
> shell is running it "non-elevated". For an admin user that means, she
> doesn't hold the SeCreateGlobalPrivilege privilege and the user token
> contains the administrators group as "deny only". An elevated shell
> ("run as administrator") contains the SeCreateGlobalPrivilege privilege.
But I was logged in as a unprivileged user (non Administrator), so when
I selected "run-as-administrator" to launch a bash shell, I had to type
in the Administrator's password, and therefore the new shell was elevated.
> However, that problem will be fixed in 1.7.0 by using something along
> the lines of the Vista/Longhorn "Private Namespaces". So, with 1.7.0
> you will see all Cygwin processes again. Unless, of course, Microsoft
> decides to break my new solution with the next Windows version...
You naughty malware author...
--
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/
- Raw text -