This is the mail archive of the cygwin-apps 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: [ITP] libsuexec 1.0


On Aug 16 11:28, Achim Gratz wrote:
> > In Windows, it is the 'SYSTEM' user which starts up most services, thus in effect
> > acting as the Unix 'root' user. The difference is that SYSTEM has uid '18', while
> > root has uid '0' in Unix.
> 
> No, there are much larger differences between a capability based system
> and this.  With capabilities, whatever you call a "root" user might not
> even exist and if it does, it might not have the capabilities you're
> associating with "root" on a classical UNIX system.

Good point.  A README file should perhaps refrain from calling what
sendmail does a capability model.  It's just a typical old-style Unix
service expecting uid 0 is something special.  This isn't simply a
Cygwin problem.

> > So, if porting from Unix to Cygwin one could just look for all occurances of uid '0'
> > and replace them with '18'. Actually, this technique has been used to create the
> > current Cygwin port of the Procmail program.
> 
> That's a long winded way of saying that these programs are not capability-aware.
> 
> > As of Win7 and Win2003 this will no longer work. For security reasons, the privilege
> > needed to impersonate another user (called 'SeCreateTokenPrivilege') has been
> > removed from the SYSTEM user.
> >
> > Services (daemons) who need impersonation now have to be started by non-SYSTEM
> > users, which have been put in the 'Administrators' group and granted the
> > SeCreateTokenPrivilege. This works for most suid software, like the Apache
> > webserver, but not for Sendmail and Procmail.
> >
> > Both programs *enforce* what is called the Capabilities model. This means that both
> > programs actually check if they are ran by root and if not, refuse to deliver
> > e-mail. So, simply replacing '0' with '18' in the source code has no effect.
> 
> No, actually they have no idea what a capability is and use the UID as a
> proxy for certain capabilities.  Which is wrong when actual capabilities
> come into play.
> 
> > The solution
> > ------------ 
> > The solution to this problem turns out to be very simple and elegant: *tell*
> > Sendmail and Procmail who is the root user by overriding functions which involve
> > getting or setting user id's. 
> >
> > For instance: make the getuid() function return '0' when the actual user id is '18'
> > and make the setuid() function change to uid '18' if the requested uid is '0'. Take
> > this idea one step further and Sendmail and Procmail become 'multi-root aware'.
> 
> Except that SYSTEM is not "root".  Depending on what capabilities those
> programs actually expect from "root" it may or may not have them.  And I
> wish you'd stop talking about "multi-root", there is no such thing and
> never will be, since there is no "root" at all.

Good point.  The "multi-root" expression puzzles me, too.  Before this
mail I vaguely thought about some multi-user ability.  I'm not claiming
that my misunderstanding is a role model, but the expression certainly
*is* misleading.

> > I created this library to do exacly that. On startup it assumes the root user id is
> > '18' (SYSTEM) and the root group id is '544' (Administrators). It overrides the
> > original getuid(), getgid(), etc. functions to return '0' if the actual uid/gid are
> > '18' or '544'.
> >
> > The library makes its program 'multi-root aware' by checking if the non-SYSTEM user
> > is a member of the 'Administrators' group and if so, simply replacing *its* uid and
> > gid to be '0'. This totally satisfies Sendmail and Procmail.
> 
> So if I'm a member of the administrators group those programs will use
> administrative rights while delivering mail to my inbox even though they
> don't need to?  That doesn't sound desirable to me in any way.

No, they won't.  The lib just converts the uid of the current user to 0
within the application to keep it blissfully ignorant.  This allows to
run applications claiming uid 0 is something special from SYSTEM or
cyg_server as service, without the need to patch the sources.  It's
not exactly a bad idea for such services if it makes them work, I think.

> > More importantly: I didn't have to change a single line in their source code (which
> > would have been an awful lot), because the library is doing the swapping of
> > uids/gids in the background.
> 
> As much as I had to patch it up in a time long ago I'd rather have
> sendmail die as it's way past its "best-before-use date", but then I
> wasn't planning on using it anyway.

Postfix for Cygwin would be *so* nice.  Sigh.  It would also be nice to
get Exim running on 64 bit.  But either way, sendmail is still kind of a
de-facto standard, so it's not bad to get it into the distro, just as
Fedora comes with sendmail, postfix, exim, etc.  Choice is good.

> > To use this library, put '#include <suexec.h>' and '-lsuexec' at a strategic
> > location in your source code and Makefile. To make your program 'multi-root' aware
> > and even do suid and/or sugid, place a call to 'suexec(argv[0])' in your 'main'
> > function and set the suid and/or sgid bits on the resulting binary.
> >
> > http://cygwin.boland.nl/x86/release/libsuexec/
> 
> This library doesn't do anything su-like or exec, so I think it is misnamed.
> 
> > All GTG's are welcome...
> 
> At the very least you're missing a proper license.

Another good point.  Actually, we need this to be under some OSS license
compatible with http://opensource.org/docs/osd/


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: pgpmz8jNC5yFs.pgp
Description: PGP signature


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