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


Hi Achim,

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.

I am fully aware that I am touching a very sensitive subject here. I shouldn't have
mentioned the word 'Capabilities'. But I sense something deeper here. Correct me if
I'm wrong, but do you really love Unix? I think not. There is no such thing as a
"classical" Unix system. There is only Unix. Prove to me that you really love Unix.

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

I will remove the term from my hints file.

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

No root at all?? You're stuck on words. Root is a type of super-user and SYSTEM is
also. Don't be tight. Prove to me that you really love Unix.

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

Nope. They will not use administrative rights. The opposite is true. You, as a
member of the Admin group, need those extra rights so procmail can deliver as an
*unprivileged* user. If procmail or sendmail 'see' that they have been started by a
non-super-user, they will refuse to switch to the unprivileged user and deliver
e-mail.

> 
> > 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.
> 
> > 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.  But for the moment I
> think you'd better patch that into sendmail and procmail gnulib-style.

Proper license? Please explain.

Sincerely,
Daniel


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