Re: will bash honor the suid bit or not?

[Richard Troy <rtroy at sciencetools dot com>]

Thank you for your reply, Larry.

You're right when you say that the requirement to give these permissions
would defeat the whole purpose. In short, the purpose of the application
itself is security-related. The information contained in the config. files
is sensitive. The user needs to have the benefit of the data - through
action of the program - but should not have access to the data itself.
Giving out extensive privileges is exactly contray to this purpose.

And you were right to guess that I already set ntsec in CYGWIN - it was my
first move. That, and to put the definition in the systems env. vars, so
other users who log in without Administrator privilege can't change it.

I am apparently ignorant of how to handle a case like this on NT/2000, nor
do I even know where to look. This problem must be solved for many uses
already. I would think that a great many services have this same problem.
It's an exceptionally common need to have a non-privileged user run a
program and get privileged results. ...I'm a skilled, experienced
programmer, but am _completely_ ignorant of the NT/2000 world - I don't
even know where to look for answers! Worse, I'm very short on time.
Yesterday, for example, I put in 19 hours of work. ...Working tired sure
doesn't help. -sigh-

>From where I sit, it sure looks like this problem should be solved for the
BASH shell. Perhaps it should become a service? I dunno!

It'd be great to hear from more of you: Anyone else care to confirm
Larry's suggestion that giving privileges to users is the solution in this
case?

Thanks for your input,
Richard

-- 
Richard Troy, Chief Scientist
Science Tools Corporation
rtroy@ScienceTools.com, 510-567-9957, http://ScienceTools.com/

On Wed, 17 Apr 2002, Larry Hall (RFK Partners, Inc) wrote:

> Date: Wed, 17 Apr 2002 22:34:29 -0400
> From: "Larry Hall (RFK Partners, Inc)" <lhall@rfk.com>
> To: Richard Troy <rtroy@sciencetools.com>, cygwin@cygwin.com
> Subject: Re: will bash honor the suid bit or not?
>
> 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/