This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: suid bit on executables?


On Tue, 23 Mar 2004, Richard Troy wrote:

> > Richard,
> >
> > FYI, Cygwin implements /dev/conin and /dev/conout, so, perhaps, the
> > approach suggested in <http://cygwin.com/ml/cygwin/2004-03/msg00259.html>
> > would be helpful (or something along those lines).
>
> Hi Igor,
>
> I tried man and apropos, and found nothing for conin or conout,

Technically, you should have been able to look at
<http://cygwin.com/cygwin-ug-net/using-specialnames.html> instead...  The
Cygwin User's Guide makes for wonderful and exciting bed-time reading. ;-)
However, the above document is strangely silent on the topic of
conin/conout...  As things stand now, looking at the Cygwin source is
probably your best bet.

> but if I understand what you're suggesting, you're saying I should try
> something like the following:
>
> The original command to use as a template (I take it this worked?):
>
> cygrunsrv --install fetchmail --path /usr/bin/su.exe --args "-p -c
> '/usr/bin/fetchmail --daemon 300 --nodetach </dev/conin 2>/dev/conout'
> domain\\user" --env HOME=/home/user --termsig TERM --shutdown --type
> manual --interactive
>
> My interpretation of the above:
>
> cygrunsrv --install <my_program> --path /usr/bin/su.exe --args
> "-p -c '<path_to_my_program> <my_programs_args> </dev/conin 2>/dev/conout'
> <my_domain>\\<privileged_user>" --env <my_progs_env_vars> --termsig TERM
> --shutdown --type manual --interactive

Yes, except you'd probably need to redirect the stdout to /dev/conout as
well.  The idea is that you essentially run "su" in an interactive
service (which will pop up a console) running as SYSTEM, and that you
switch the context to that of the specified user.  The "--termsig" and
"--shutdown" parameters are optional.

> Hmmm... Yes, this _seems_to_me_ to be exactly what I was hinting at when
> Corinna suggested ssh instead. ... The above would be both better and
> easier because there's no need for keys and no encryption overhead. Do I
> understand that conin and conout redirect std-in and std-out to/from the
> installed service to the caller of the service?

conin/conout will let the process access the console that cygrunsrv pops
up, rather than the stdout/stderr file descriptors, which are redirected
to files in /var/log...

> Also, you said:
>
> > OTOH, once cygserver is in place, we'll have a working "su" (which is
> > exactly what you want, right?).
>
> But in the above cygrunsrv you call su! Yes, I know the executable is
> there - in at least this example, does it work?

Quoting the part of my message that you snipped out:
>>>> And before people ask: yes, you really *can* use "su" from a
>>>> system-owned process.

> Also, since there's an ability to specify the user, maybe use the user
> flag, specify it explicitly and ignore the su.exe?

Yes, cygrunsrv allows services running explicitly as some user, with two
caveats: they can't be interactive, and you'd need to enter a password for
that user.  The above method will let you switch the context with no
password, thus emulating the "suid" functionality.

> Thanks for all your keystrokes!

On Tue, 23 Mar 2004, Richard Troy wrote:

> Igor,
>
> one of us is confused! ...NOT referring to Cygwin, but Unix in general:
> 'su' requires the caller to either already be root, or have the password
> of the account they want to "become". In contrast, there's no checking of
> passwords at all when a program is launched that has the suid bit set: It
> simply starts in the context of the files owner. The user may well be
> unaware, even, that a different user id is involved - not at all the case
> with su, where it's explicit.

All the password checking, etc, is superficial.  The point is that there
exists functionality that lets any user, no matter how unprivileged, to
switch the context to that of any other user, as long as the appropriate
permissions are verified (e.g., the user knows the root password).
Programs like "sudo" make use of this functionality all the time.

> BTW, tnx for the pointer to ntsec, but that's old hat for me: I have for
> many years been aware of this issue, though I'm far from a guru. As for
> those "security holes" - that's what we're trying to work through in this
> dialogue: I have a legitimate need, we can see the "right" answer is to
> have cygwin1.dll perform execs that honor suid - perhaps with the aid of
> cygserver, and that at the moment we are discussing a workaround for the
> interrim! -smile-  ...And _THANK_YOU_VERY_MUCH_ for your participation in
> this dialogue!

I didn't say that having this functionality is a security hole, I just
said that in Windows, a user context switch is not possible from all user
accounts unless special privileges are assigned to all user accounts,
which *would* open a security hole.  That's exactly what the cygserver
approach tries to avoid -- cygserver will be running as a service as the
one user that does have enough privileges (i.e., SYSTEM), and thus will
allow context switches without assigning those privileges to all users.

> Anyway, back to my question you neatly avoided! -smile- If the program
> were installed with cygrunsrv and the user flag specified the right user,
> can conin and conout be used to get the "command line" access to the
> running program?

Using conin and conout will get you access to the interactive console.

> I gathered that's what your example using conin and conout were really
> all about, not su.exe - we _know_ that's "broken!"

"su" is not broken, "su" simply doesn't work the same as in Unix.  It will
work correctly from a system-owned process (which cygrunsrv provides).
"su" is needed to run the program as a particular user, not as SYSTEM.  If
the user you want to run the process as (the owner of the file) is SYSTEM,
the "su" invocation may be omitted.
HTH,
	Igor

> Maybe take a second look at my post on my interpretation of your
> suggestion and see if I've gotten it right?
>
> Regards, and thanks again,
> Richard
>
> > > No, what I need is _very_ different. The requirement is for a program that
> > > runs as a different user without that user having any special privileges
> > > themselves and without the ability to log in, or run other programs as
> > > that other user. On Unix (and Unix clones), there's a concept of the "suid
> > > bit" which is set in the file system and associated with executable
> > > programs (and on many implementations, executable shell scripts too). When
> > > any user, including root, executes a program with the suid bit set, the
> > > program runs just like any other program except that it runs in the user
> > > context of the file's owner, NOT as the user who called the program. In
> > > contrast, su requires that the caller have the password of the account in
> > > question...
> > >
> > > That said, a "working su" program _should_ be able to be used as the
> > > foundation of an implementation of an exec call where the suid bit is set.
> > > Corinna hinted that W2003 makes things harder and I haven't any idea why,
> > > but it figures that Windows would try very hard to ensure that nothing
> > > else is compatible with Windows. -frown-
> > >
> > > Regards,
> > > Richard
> >
> > Richard,
> >
> > The functionality of "su" and the "suid bit" is the same.  Aside from
> > privilege checking, both require the ability to have any user set its
> > effective user id to that of another user.  This is currently not possible
> > in Windows without opening a whole set of security holes.  By default, the
> > only account able to switch user contexts is SYSTEM.  Reading
> > <http://cygwin.com/cygwin-ug-net/ntsec.html> should provide some insights.
> > Win2003 makes it harder because the appropriate privileges aren't assigned
> > to SYSTEM by default, as they were in the previous versions of Windows.
> > HTH,
> >       Igor

-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]