On Apr 21 23:36, Charles Wilson wrote: > 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?
The solution for the future is "cyglsa", the special DLL which will be part of the 1.7 release. A script /bin/cyglsa-config plus a reboot will install it. After that, your IL will be Medium for a normal user and High for an admin user when logging in through ssh/telnet/etc. Other than that, I also added code to the create_token function which is used for passwordless login, if the cyglsa DLL hasn't been installed. It adds a IL SID to the create token, matching the user: Medium level for normal users, High level for admins, System level for SYSTEM. However, that will also only work starting with 1.7. > 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? How should that work? We're talking about terminal server sessions. The most important fact is that a ssh/telnet/whatever login is NOT a TS session. Also, workstation systems (XP, Vista) don't support more than one TS session at a time. Creating a TS session for the ssh/telnet/whatever login would result in logging out the locally logged on user... *iff* the local user agrees to be logged out. > [...] > 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. That should work as expected with 1.7 as well. >> 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... I'm using whatever is allowed from user space... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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/
