Vista + cygwin basics

Vista + cygwin basics

[Charles Wilson]

So, I'm taking the plunge...but I have a few questions.  Here's what 
I've done so far:

(1) using setup-2.588 snapshot

(2) Ran as Administrator. Note that I was logged in as my normal user 
account, which is NOT a member of the Administrators group. So, I 
right-clicked on setup-2.588.exe, and chose 'Run as Administrator'. This 
gave me the UAC popup, with my choice of Administrative accounts:
   a) the regular ComputerOwner account that was pre-configured on my 
comptuer, and is a member of the Administrators group
   b) the hidden "real" Administrator account
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9015738&pageNumber=2

(I chose to use the real 'Administrator' account)

(3) selected my favorite packages
(4) installed.

There are a few things I noticed that were/are odd.

(1) The installation reported an error

2008/04/13 03:08:21 mbox note: Can't open 
file://C:\Users\cwilson\Desktop\cygwin-local/http%3a%2f%2fmirrors.xmission.com%2fcygwin/release/GNOME/glib2/glib2-runtime/glib2-runtime-2.10.3-1.tar.bz2 
for reading: Invalid or unsupported tar format

This seems related to this:
http://cygwin.com/ml/cygwin-apps/2008-04/msg00104.html
but I thought these were all fixed
http://cygwin.com/ml/cygwin-apps/2008-04/msg00105.html

And besides, my copy of glib2-runtime-2.10.3-1.tar.bz2 IS 46 bytes, and 
'tar tvjf' doesn't seem to have a problem with it.

(2) Many of the installed files look like this:

$ ls -l aatest.exe
----r-x---+ 1 Administrator Users   6144 Mar 20 13:53 aatest.exe

$ getfacl aatest.exe
# file: aatest.exe
# owner: Administrator
# group: Users
user::---
group::r-x
group:SYSTEM:rwx
group:Administrators:rwx
mask:rwx
other:---

Compare this to my XP machine, in which I typically run setup.exe under 
my normal user account (which is a member of the Administrators group):

$ ls -l aatest.exe
-rwxr-x---+ 1 cwilson Users 6144 Mar 20 13:53 aatest.exe

$ getfacl aatest.exe
# file: aatest.exe
# owner: cwilson
# group: Users
user::rwx
group::r-x
group:SYSTEM:rwx
group:Administrators:rwx
mask:rwx
other:---

What puzzles me here is that the nominal owner on Vista, 'Administrator' 
  does not appear to have the user permission bits/ACL entry.


(3) Symlinks look like this:

$ ls -l aclocal
lrwxrwxrwx 1 Administrator None 25 Apr 13 03:19 aclocal -> 
/etc/alternatives/aclocal

$ getfacl aclocal
# file: aclocal
# owner: Administrator
# group: Users
user::---
group::r-x
group:SYSTEM:rwx
group:Administrators:rwx
mask:rwx
other:---

By way of comparison, on XP:

$ ls -l aclocal
lrwxrwxrwx 1 cwilson Users 25 Aug 20  2005 aclocal -> 
/etc/alternatives/aclocal*

$ getfacl aclocal
# file: aclocal
# owner: cwilson
# group: Users
user::rwx
group::r-x
group:SYSTEM:rwx
group:Administrators:rwx
mask:rwx
other:---

Once again, it seems odd that on Vista, the nominal owner has no 'user' 
permissions in the ACL list (even though symlinks are always 'ls -l'ed 
as lrwxrwxrwx)


(4) and directories look like this:

$ ls -ld etc
d---r-x---+ 20 Administrator Users 12288 Apr 13 03:25 etc

$ getfacl etc
# file: etc
# owner: Administrator
# group: Users
user::---
group::r-x
group:SYSTEM:rwx
group:Administrators:rwx
mask:rwx
other:---
default:group:SYSTEM:rwx
default:group:Administrators:rwx
default:group:Users:r-x
default:mask:rwx

Again, by comparison on XP:
$ ls -ld etc
drwxrwxr-x+ 25 cwilson Users 0 Apr 13 00:28 etc/

$ getfacl etc
# file: etc
# owner: cwilson
# group: Users
user::rwx
group::rwx
group:SYSTEM:rwx
group:Administrators:rwx
mask:rwx
other:r-x
default:user::rwx
default:group:SYSTEM:rwx
default:group:Administrators:rwx
default:group:Users:rwx
default:mask:rwx


So, are these differences expected?  Have I messed up the installation 
by doing 'Run as Administrator' -- some posts around the web seem to 
recommned turning off UAC when running setup.exe, or running it in 'XP 
Compatibility Mode'.

What is the official recommendation for installing cygwin on Vista?

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

Re: Vista + cygwin basics

[Brian Dessent]

Charles Wilson wrote:

> So, are these differences expected?  Have I messed up the installation
> by doing 'Run as Administrator' -- some posts around the web seem to
> recommned turning off UAC when running setup.exe, or running it in 'XP
> Compatibility Mode'.

Yes I would expect differences, given that Vista has very different
defaults.  No they shouldn't matter -- unless you're saying that
something doesn't work.  I don't think UAC should really matter, in that
its heuristics are going to ask for permission to run it as
administrator anyway (or at least, it should if it was named setup.exe;
don't know about setup-n.exe.)  It might be a different situation at
runtime though, i.e. there still could be packages that don't yet have
foo.exe.manifest-like workarounds discovered and implemented.

Setup doesn't do anything with permissions, so the resulting ones are
the defaults as inherited from the directory containing the location you
chose to install.  If you installed in c:\cygwin, they should have
inherited from the default ACL in c:\, whatever Vista chose for that. 
The striking difference could be due to this, i.e. MS tightended down
the root dir default ACLs since you don't typically install things there
but instead in Program Files.  If you want them different, simply create
the root dir with the desired permissions before installing.

I'll look at that empty glib2-runtime package and see what the deal
there is.

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/

Re: Vista + cygwin basics

[Brian Dessent]

Brian Dessent wrote:

> Setup doesn't do anything with permissions, so the resulting ones are

Correction - it doesn't try to do anything with the permissions as
stated in the tarball.  At startup it does try to set a DACL in the
process token that contains Everyone:full.  However, as I understand it,
the DACL only applies to files created in situations where they would
not otherwise inherit an ACL, so if the Vista default for C:\ contains
inheritable settings (as I would imagine it has to) then this wouldn't
apply.

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/

Re: Vista + cygwin basics

[Charles Wilson]

Brian Dessent wrote:
> Correction - it doesn't try to do anything with the permissions as
> stated in the tarball.  At startup it does try to set a DACL in the
> process token that contains Everyone:full.  However, as I understand it,
> the DACL only applies to files created in situations where they would
> not otherwise inherit an ACL, so if the Vista default for C:\ contains
> inheritable settings (as I would imagine it has to) then this wouldn't
> apply.

I used the Windows Properties dialog on C:\cygwin to add 
'Administrator:Full Control' on my existing cygwin installation (since I 
had done very little personalization, there were no "private" files 
belonging to my unprivileged self to worry about).

This propagated down to all contained objects.

Now the perms/ACLs look a bit more sane.

$ ls -l aatest.exe
-rwxr-x---+ 1 Administrator Users 6144 Mar 20 13:53 aatest.exe

$ getfacl aatest.exe
# file: aatest.exe
# owner: Administrator
# group: Users
user::rwx
group::r-x
group:SYSTEM:rwx
group:Administrators:rwx
mask:rwx
other:---

It's not that anything was noticeably broken -- it's just that things 
looked so WEIRD I didn't really try to DO anything; afraid that I might 
have to wipe out any customizations and start over.  Now, I've been 
involved with cygwin for a long time, but Vista+cygwin gives me the 
creeping heebie-jeebies...or maybe I'm just over-thinking it.

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

Re: Vista + cygwin basics

[Charles Wilson]

One odd thing I've noticed. (well, two, really, but I suspect they are 
related).

Here is the output of 'ps -eaf' from a regular user (not a member of 
Administrators):

$ ps -eaf
      UID     PID    PPID TTY     STIME COMMAND
       ME    5408       1   ?  01:44:16 /usr/bin/ssh-agent
       ME    5712       1 con  10:05:24 /usr/bin/rxvt
       ME    2144    5712   0  10:05:24 /usr/bin/bash
       ME    1172    2144   0  10:08:28 /usr/bin/ssh
       ME    3180       1 con  13:24:19 /usr/bin/rxvt
       ME    5160    3180   1  13:24:19 /usr/bin/bash
       ME    3060    5160   1  14:17:08 /usr/bin/ps

Here is a *simultaneous* result, on the same machine, but from a shell 
that was launched via 'run as administrator'

$ 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   ?  01:09:40 /usr/bin/ssh-agent
       ME    2420       1   ?  14:00:38 /usr/bin/ssh-agent
Administ    4764       1 con  14:17:20 /usr/bin/rxvt
Administ    3836    4764   0  14:17:21 /usr/bin/bash
Administ    1076    3836   0  14:17:27 /usr/bin/ps

Note that these two program lists (which should both list ALL cygwin 
programs run by ANY user, and should be identical) are actually 
completely disjoint. There is no PID that appears in both lists.

The other issue is related, I think.  I'm using keychain from my 
~/.bashrc, so it should start an ssh-agent if none is running, and then 
save that PID to a file.  Then any new shell can check for the PID in 
that file, contact the exising ssh-agent, and continue.

Notice in the above lists I have multiple ssh-agents running. This is 
because as long as I have one window owned by ME open, I can open other 
windows and they will continue to access the same ssh-agent, just as 
expected. However, if I close all windows owned by ME, then if I open a 
new window, it somehow can't contact the original ssh-agent, and starts 
another one. (But note: I do NOT stop ALL cygwin processes between these 
two events: obviously the old ssh-agent is still running, and the 
various daemons are running under cyg_server and SYSTEM, and the 
'administrator' bash shell is still running)

It seems like there is some issue with the various processes 
communicating with each other.  Both the Administrator user, and the 
   ME user, have 'server' in their CYGWIN variables. There is no global 
CYGWIN variable setting.

cygserver is running under SYSTEM, not a special privileged user.

Does anybody know what's going on here?

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

Re: Vista + cygwin basics

[Brian Dessent]

Charles Wilson 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.  If you use process explorer you can
enable this column to be viewed.  By default, everything gets created
with medium IL.  When a process elevates, it gets bumped to high. 
Services run as system, and IE runs as low.

The IL is their workaround for the following problem: They want users to
run as "administrators who have dropped privileges."  This gives the
desired effect of inability (or less-ability) to cause harm, yet they
can still elevate to administrator to do all those common things that
require admin privileges by just clicking "Yes" or "Okay", as opposed to
being a real non-admin user which would require entering credentials to
elevate to admin.

In XP this was done simply by creating a new process token and removing
the membership from the administrators group, as well as any dangerous
privileges.  This in theory would allow sandboxing things like the
browser, while letting the user remain an admin so that they can still
install software or whatnot.  But there's a huge gaping hole in this
strategy: the "sandboxed" process can still escape its sandbox because
the default security model allows full access to all objects you own. 
So the sandboxed process could simply OpenProcess any other process
running as that same user and inject a new thread to execute arbitrary
code, or it could inject simulated mouse/KB into Explorer, or a million
other leaks.  This is not a real sandbox.

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.

(They also implemented a form of window message filtering called User
Interface Privilege Isolation (UIPI) which is a similar set of
restrictions that is supposed to prevent the a process from being able
to send window messages to a process of higher IL -- this is to prevent
the "inject virtual keystrokes" style of attack.)

But the sad thing is this is all nonsense, it is not an actual security
barrier but more of a deterrance.  The fact is that a user that is an
administrator that has dropped privileges (i.e. what 99% of vista users
are) is still an administrator at heart, no matter what IL or UIPI may
prevent.  There will always be cracks and ways to get out and elevate,
see <http://blogs.zdnet.com/security/?p=175>.

For example, MS was the butt of a lot of jokes when it was first
revealed that the OS uses a number of heuristics (such as "filename is
setup.exe") to automatically prompt to elevate.  Some people said "oh
look, huge security hole, just rename your badware to setup.exe and
you're instantly an admin as long as the user just clicks 'okay'."  What
these people are missing is that, yes, this is one particularly
laughable example, but it does not represent a real security hole at
all.  The whole UAC/"pretend I'm not an admin but I really am one" thing
is just training wheels to try to encourage developers make software
that does not require admin privileges.  That you can bust the training
wheels does not indicate a security breach, it just means that you were
always an admin anyway and that it's impossible to "partially" drop
admin privileges.  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.  

Some good background:
http://technet.microsoft.com/en-us/magazine/cc138019.aspx
http://technet.microsoft.com/en-us/magazine/cc162494.aspx
http://technet.microsoft.com/en-us/magazine/cc162480.aspx
http://technet.microsoft.com/en-us/magazine/cc162458.aspx
http://blogs.technet.com/markrussinovich/archive/2007/02/12/638372.aspx
...and pretty much anything else Mark has written.

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/

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

Re: Vista + cygwin basics

[Brian Dessent]

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/

Re: Vista + cygwin basics

[Corinna Vinschen]

On Apr 21 00:36, Brian Dessent wrote:
> 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.

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.  You can find more details about this privilege which, IMHO, is
obscurity rather than security, for instance here:
http://msdn2.microsoft.com/en-us/library/aa366537.aspx

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

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


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/

Re: Vista + cygwin basics

[Brian Dessent]

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,

Right, I wasn't trying to imply that the location of the shared section
had anything to do with IL, just explaining why his elevated shell in
session 1 could see the processes of services in session 0 (i.e. because
the elevated session 1 could create the shared section in the global
namespace and read the cygwin process table.)

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/

Re: Vista + cygwin basics

[Brian Dessent]

Brian Dessent wrote:

> Right, I wasn't trying to imply that the location of the shared section
> had anything to do with IL, just explaining why his elevated shell in
> session 1 could see the processes of services in session 0 (i.e. because
> the elevated session 1 could create the shared section in the global
> namespace and read the cygwin process table.)

Oh wait, I think I see what you're saying: that regardless of IL, the
output of 'ps' depends solely on the Cygwin shared process table and not
being able to open a process object.

But then, ps -W would depend on IL, since that includes non-Cygwin
processes that aren't included in the Cygwin pid table, right?

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/

Re: Vista + cygwin basics

[Corinna Vinschen]

On Apr 21 02:17, Brian Dessent wrote:
> Brian Dessent wrote:
> 
> > Right, I wasn't trying to imply that the location of the shared section
> > had anything to do with IL, just explaining why his elevated shell in
> > session 1 could see the processes of services in session 0 (i.e. because
> > the elevated session 1 could create the shared section in the global
> > namespace and read the cygwin process table.)
> 
> Oh wait, I think I see what you're saying: that regardless of IL, the
> output of 'ps' depends solely on the Cygwin shared process table and not
> being able to open a process object.

Yep.  The problem is that there isn't one process table, but one
process table per session.

> But then, ps -W would depend on IL, since that includes non-Cygwin
> processes that aren't included in the Cygwin pid table, right?

Not IL, afaik.  It's all about session isolation.  Non-privileged users
can't see processes outside of their session.  That's also already the
case since at least Windows 2K3.


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/

Re: Vista + cygwin basics

[Charles Wilson]

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/

Re: Vista + cygwin basics

[Thorsten Kampe]

* Charles Wilson (Sat, 19 Apr 2008 14:34:52 -0400)
> The other issue is related, I think.  I'm using keychain from my 
> ~/.bashrc, so it should start an ssh-agent if none is running, and then 
> save that PID to a file.  Then any new shell can check for the PID in 
> that file, contact the exising ssh-agent, and continue.

I had exactly the same issue: in my .zshrc/.bashrc I run keychain if 
there is also an ssh agent running under my account. I noticed that 
under Vista I had to manually run keychain. The line in question is:

    pgrep -u $(id -un) ssh-agent && sshagent

where sshagent is
sshagent()
    { keychain id_dsa
      source ~/.keychain/$(uname -n)-sh;}

The problem was that "pgrep -u $(id -un) ssh-agent" didn't show my 
running ssh agent although I could see it in ps.

The good news is that now it works (maybe with the Cygwin update from 
last week?). Maybe it'll work for you, too, if you update.


Thorsten


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

Re: Vista + cygwin basics

[Corinna Vinschen]

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/

RE: Vista + cygwin basics

[Karl M]

Hi Chuck...

> The other issue is related, I think. I'm using keychain from my
> ~/.bashrc, so it should start an ssh-agent if none is running, and then
> save that PID to a file. Then any new shell can check for the PID in
> that file, contact the exising ssh-agent, and continue.
>
Just a comment...keychain is pretty heavy for what you get in Cygwin. I had problems a long time ago with a slow laptop running XP SP2 with Cygwin windows taking a long time to open if I kicked off several at once, particularly at boot time.

My solution was to launch ssh-agent as a service (one for each user that wants it). That service spawns the agent and updates the user environment in the registry so that other processes can find the ssh-agent process/socket. The advantages are that it is fast and the agent survives a logout (only rekey for a reboot is desired).

I had thought about offering it as a package, but there was insufficient interest. Your are welcome to it if you are interested. It has been rock solid for years.

:.)

...Karl
_________________________________________________________________
Express yourself wherever you are. Mobilize!
http://www.gowindowslive.com/Mobile/Landing/Messenger/Default.aspx?Locale=en-US?ocid=TAG_APRIL

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

RE: Vista + cygwin basics

[Mark Moriarty]

I'd be interested in it :) 

-----Original Message-----
From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com] On Behalf Of
Karl M
Sent: Tuesday, April 22, 2008 2:09 PM
To: cygwin@cygwin.com
Subject: RE: Vista + cygwin basics


Hi Chuck...

> The other issue is related, I think. I'm using keychain from my 
> ~/.bashrc, so it should start an ssh-agent if none is running, and 
> then save that PID to a file. Then any new shell can check for the PID 
> in that file, contact the exising ssh-agent, and continue.
>
Just a comment...keychain is pretty heavy for what you get in Cygwin. I had
problems a long time ago with a slow laptop running XP SP2 with Cygwin
windows taking a long time to open if I kicked off several at once,
particularly at boot time.

My solution was to launch ssh-agent as a service (one for each user that
wants it). That service spawns the agent and updates the user environment in
the registry so that other processes can find the ssh-agent process/socket.
The advantages are that it is fast and the agent survives a logout (only
rekey for a reboot is desired).

I had thought about offering it as a package, but there was insufficient
interest. Your are welcome to it if you are interested. It has been rock
solid for years.

:.)

...Karl
_________________________________________________________________
Express yourself wherever you are. Mobilize!
http://www.gowindowslive.com/Mobile/Landing/Messenger/Default.aspx?Locale=en
-US?ocid=TAG_APRIL

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




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

Re: Vista + cygwin basics

[David Rothenberger]

On 4/22/2008 4:25 PM, Mark Moriarty wrote:
> On 4/22/2008 2:09 PM, Karl M wrote:
>> My solution was to launch ssh-agent as a service (one for each user that
>> wants it). That service spawns the agent and updates the user environment in
>> the registry so that other processes can find the ssh-agent process/socket.
>> The advantages are that it is fast and the agent survives a logout (only
>> rekey for a reboot is desired).
>> 
>> I had thought about offering it as a package, but there was insufficient
>> interest. Your are welcome to it if you are interested. It has been rock
>> solid for years.
>
> I'd be interested in it :) 

Me, too.

-- 
David Rothenberger  ----  daveroth@acm.org

And that's the way it is...
                 -- Walter Cronkite


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

Re: Vista + cygwin basics

[Charles Wilson]

Karl M wrote:
> Just a comment...keychain is pretty heavy for what you get in Cygwin. I had problems a long time ago with a slow laptop running XP SP2 with Cygwin windows taking a long time to open if I kicked off several at once, particularly at boot time.
> 
> My solution was to launch ssh-agent as a service (one for each user that wants it). That service spawns the agent and updates the user environment in the registry so that other processes can find the ssh-agent process/socket. The advantages are that it is fast and the agent survives a logout (only rekey for a reboot is desired).
> 
> I had thought about offering it as a package, but there was insufficient interest. Your are welcome to it if you are interested. It has been rock solid for years.

That sounds like a useful alternative.

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

RE: Vista + cygwin basics

[Karl M]

[-- Attachment #1: Type: text/plain, Size: 1721 bytes --]


Charles Wilson wrote:
> Karl M wrote:
>> Just a comment...keychain is pretty heavy for what you get in Cygwin. I had problems a long time ago with a slow laptop running XP SP2 with Cygwin windows taking a long time to open if I kicked off several at once, particularly at boot time.
>>
>> My solution was to launch ssh-agent as a service (one for each user that wants it). That service spawns the agent and updates the user environment in the registry so that other processes can find the ssh-agent process/socket. The advantages are that it is fast and the agent survives a logout (only rekey for a reboot is desired).
>>
>> I had thought about offering it as a package, but there was insufficient interest. Your are welcome to it if you are interested. It has been rock solid for years.
>
> That sounds like a useful alternative.
>
It is three bash script files and one C program (just compile it with gcc). The shell scripts (1) install the service, (2) are the service under cygrunsrv and (3) is the commands to add to your bash_profile. If you use a different shell, they will need syntax tweaking. The C program provides access to sending a Windows API call to broadcast a message for WM_SETTINGCHANGE. This is needed because the user can log in before the service is started in XP. I think that this all worked on WIN2k when last I tried it, but it has been a long time since I touched a WIN2k box. I have no experience with Vista :.).

Overall, it is fast and simple.

Enjoy,

...Karl

_________________________________________________________________
Express yourself wherever you are. Mobilize!
http://www.gowindowslive.com/Mobile/Landing/Messenger/Default.aspx?Locale=en-US?ocid=TAG_APRIL

[-- Attachment #2: secret-agent-service-install --]
[-- Type: text/plain, Size: 685 bytes --]

#!/bin/bash
# secret-agent-service-install service-name user-name

if [ "~$1" = "~" ]; then
  echo A service name is required.
  exit 1
fi

if [ "~$2" = "~" ]; then
  echo A user name is required.
  exit 1
fi

echo Uninstalling the secret-agent service, $1.
cygrunsrv --remove $1

echo Adding the \"Log on as a Service\" right for $2.
editrights -a SeServiceLogonRight -u "$2"

echo Installing the secret-agent service, $1.
cygrunsrv --install $1 \
  --args '/bin/secret-agent-service' \
  --disp "Secret Agent $2" \
  --desc "Creates an ssh-agent process for $2." \
  --path '/bin/bash' \
  --shutdown \
  --user "$2"

echo Starting the secret-agent service, $1.
cygrunsrv --start $1

[-- Attachment #3: secret-agent-service --]
[-- Type: text/plain, Size: 854 bytes --]

#!/bin/bash
# Launch the ssh-agent from a service so it survives logoff.

# When the service stops, kill the ssh-agent.
trap "ssh-agent -k;
  exit 0" TERM

# Clean up old files that may be left behind after a crash.
#   The file permissions make this safe to do in a multi-user
#   environment, but "/tmp" must be local to this host.
rm -rf /tmp/ssh-*

# Launch the ssh-agent.
eval $(ssh-agent)

# Provide the ssh-agent socket ID via the registry and broadcast
#   the change in case the user is logged before we finish.
#   Do not provide the ssh-agent PID to minimize the risk of
#   accidentally killing the ssh-agent.
regtool -s set /HKEY_CURRENT_USER/Environment/SSH_AUTH_SOCK $SSH_AUTH_SOCK
regtool remove /HKEY_CURRENT_USER/Environment/SSH_AGENT_PID
sendchenv

# Wait quietly until the service is stopped.
while true; do
  sleep 24h &
  wait
done

[-- Attachment #4: bash_profile_addition --]
[-- Type: text/plain, Size: 62 bytes --]

ssh-add -l >/dev/null 2>&1
if [ $? -eq 1 ]; then
  ssh-add
fi

[-- Attachment #5: sendchenv.c --]
[-- Type: text/plain, Size: 299 bytes --]

// Notify all windows that environment variables may have changed.

#include <windows.h>

int main()
{
  DWORD dwReturnValue;
  
  if (SendMessageTimeout(HWND_BROADCAST, WM_SETTINGCHANGE, 0,
      (LPARAM) "Environment", SMTO_ABORTIFHUNG, 5000, &dwReturnValue))
    return 0;
  else
    return 1;
}

[-- Attachment #6: Type: text/plain, Size: 218 bytes --]

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