Re: will bash honor the suid bit or not?

["Larry Hall (RFK Partners, Inc)" <lhall at rfk dot com>]

At 09:56 PM 4/17/2002, Richard Troy wrote:

>Hi All,
>
>I've got an application I'm trying to port from Unix to cygwin on Windows
>NT/2000 using NTFS.
>
>The application consists of an executable and a few configuration files.
>To work correctly, the executable and configuration files need to be owned
>by any ole user which is _not_ the user who wishes to run the application.
>Root/Administrator privileges are _not_ required, or desireable. The
>config files and executable are then secured from the user being able to
>change them, or view the configuration files. The suid bit of the
>executable is set in the file system. When the user runs the program,
>bash, or whatever shell, should then note the suid bit and run the program
>in the user context of the file owner, not the user who executes the
>program. The application thereby has access to the config files that the
>user does not ordinarily have.
>
>The program does not call, and does not need to call setuid(), nor any
>other flavor of such a call.
>
>The program works just fine on every Unix and Linux system upon which it
>has so far been tried. Now for Windows NT/2000! In setting it up and
>testing, I found that it runs properly for the user who owns the
>executable and configuration files. However, if another user tries to run
>it, it fails.
>
>In reading up, there's talk of the cygwin dll having a setuid() function,
>so I don't understand why the cygwin bash shell doesn't honor the setuid
>bit. I also observe that the file system _appears_ to honor the concept of
>the setuid bit. That is to say, you can $ chmod u+s <file>, and
>$ls -l <file> also shows the bit being set (or cleared as the case may
>be). ...SO... If the cygwin bash doesn't honor the bit, why bother having
>it available? (I didn't see this on the "to do" list.)
>
>It occurrs to me that there's a section in the User's Guide, which I
>didn't quite understand, that talks about "special permissions." In
>particular, it states:
>
>    "NT uses so called `access tokens' to identify a user and it's
>    permissions. To switch the user context the application has to request
>    such an `access token'. This is typically done by calling the NT API
>    function LogonUser. The access token is returned and either used in
>    ImpersonateLoggedOnUser to change user context of the current process
>    or in CreateProcessAsUser to change user context of a spawned child
>    process. An important restriction is that the application
>    using LogonUser must have special permissions"
>
>How to set these special permissions is not discussed, and it merely
>begins describing how to write a setuid call - or, rather, replace it?
>...Either way, it's my (barely educated) view that BASH should recognize
>that the suid bit is set for the about-to-be-executed image and should
>place the call to CreateProcessAsUser on our behalf... This would avoid
>-any- coding changes whatsoever. It would be _very_ useful, too!
>
>So... Do I merely have to set special permissions on the application
>program somehow? If so, pray-tell how? Or, is there no solution today? If
>there's no solution, since I _have_ to solve this, should I take it upon
>myself to contribute a tiny piece of code that implements this that could
>later be rolled into the cygwin-bash? (Please note that I don't really
>feel competent to write such code! I have _never_ written _any_ "Windows"
>application code!)
>
>Inquiring minds - and creative and demanding hackers - need to know!
>
>...Thanks in advance for your time!


You've hit on the key aspect of the issue that's keeping you from doing what
you want to do.  Specifically, you quoted the important paragraph from the 
User's Guide.  It sounds like you may have missed the other important tidbits 
that are sprinkled through the email archives and various READMEs in 
/usr/doc/Cygwin.  The first thing you need is to set 'ntsec' in your CYGWIN 
environment variable.  You may already have this but you didn't mention it so 
I thought I'd better state it for completeness.  This needs to be set before 
cygwin1.dll is loaded.  Now, to the bigger issue.  NT permissions don't give 
user's the permissions by default to change user context.  So, while the good 
news is that it should be possible to get things to work as you need them, 
the bad news is that you won't be able to do it without making changes to the 
user's rights.  These rights are:

"Act as part of the operating system"
"Replace process level token"
"Increase quotas"

These rights, plus "Logon as a service", are given by default to the 
SYSTEM user but no others.  The reason is that these are very powerful 
permissions.  To give them to any user other than SYSTEM makes the system
very insecure.  So, while this should make things work for you, you'll be
stuck with having to add these rights for any user you wish to have run 
the program and you'll be compromising security along the way.  If this is
OK for your purposes, then I think you have your answer.  Given that the 
process you describe seeks to limit the user's ability to make modifications
(at least to the files used by your program), I'm guessing the need to add
these rights to all users of the program is going to be defeating the purpose.
I could be wrong.

The rights I listed above are from /usr/doc/Cygwin/openssh*.REEADME and
/usr/doc/Cygwin/inetutils*.README.  There's some discussion there about other
requirements and concerns as well, although much of it is in the context of 
services, which can change user contexts without making the system insecure.

Obviously, I'm only applying what I know of NT's restrictions on changing 
user contexts (thanks Corinna! :-) ) to the description of the requirements
you gave for your application and drawing conclusions based on that.  It's
possible that I've missed some key aspect of NT rights management or your
application needs that would allow you to get things working with no 
additional changes to your program.  If changes are needed and they can 
be accomplished outside of your application, I believe that the first target
for the changes should be the Cygwin DLL.  If that's not possible, then 
perhaps a Cygwin specific change to bash is appropriate.  I would submit,
however, that a similar change would need to be made for other shells to 
be robust.  Of course, the robustness concept breaks down when one considers
shells that aren't provided by Cygwin so I'm dubious about this approach in
general.

Good luck,


Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
838 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/