[ITP] libsuexec 1.0

[ITP] libsuexec 1.0

[D. Boland]

Hi group,

This is not an existing package, but a spin-off project from porting Sendmail and
Procmail to Cygwin. These programs, as you may or may not know, rely heavily on the
setuid  mechanism (impersonating as another user).
More formally, this is called 'running as an unprivileged user' in Linux and
'privilege separation' in OpenBSD. In Cygwin, this mechanism is already implemented
in the ssh daemon.

Sendmail takes this idea to the extreme. It starts up as the root user and waits for
connections. On connection, it starts the 'queue runner' program as an unprivileged
user called 'smmsp', which handles the conversation with the remote e-mail client. 

If the incoming e-mail has to be delivered locally (stored on disk), the queue
runner starts the procmail program, which in turn switches to the actual user the
e-mail is meant for and stores it in the user's inbox.

So, for instance sending an e-mail to myself involves switching through three users:
root -> smmsp -> daniel

The problem
-----------
Up to WinXP and Win2002, porting source code for Cygwin which performed this
switching of users, wasn't a big problem.

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.

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.

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.

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

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.

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.

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/

All GTG's are welcome...

Cincerely,
Daniel

Re: [ITP] libsuexec 1.0

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 5512 bytes --]

On Aug 16 10:05, D. Boland wrote:
> Hi group,
> 
> This is not an existing package, but a spin-off project from porting
> Sendmail and Procmail to Cygwin. These programs, as you may or may not
> know, rely heavily on the setuid  mechanism (impersonating as another
> user).  More formally, this is called 'running as an unprivileged
> user' in Linux and 'privilege separation' in OpenBSD. In Cygwin, this
> mechanism is already implemented in the ssh daemon.
> 
> Sendmail takes this idea to the extreme. It starts up as the root user
> and waits for connections. On connection, it starts the 'queue runner'
> program as an unprivileged user called 'smmsp', which handles the
> conversation with the remote e-mail client. 
> 
> If the incoming e-mail has to be delivered locally (stored on disk),
> the queue runner starts the procmail program, which in turn switches
> to the actual user the e-mail is meant for and stores it in the user's
> inbox.
> 
> So, for instance sending an e-mail to myself involves switching
> through three users: root -> smmsp -> daniel
> 
> The problem ----------- Up to WinXP and Win2002, porting source code
> for Cygwin which performed this switching of users, wasn't a big
> problem.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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'.

Now I *finally* understand what you mean with "multi-root".  Duh.

> 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.
> 
> 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.
> 
> 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/
> 
> All GTG's are welcome...

This looks neat.  It doesn't cover the acl(2) family of functions,
but these are seldom used anyway.

I have just a few small nits.

- suexec.h neglects to declare most of the su_* functions.  This doesn't
  seem much of a problem at first, but it is when using this from C++,
  or when running a build with -Werror.  May I suggest to declare all
  su_* functions in suexec.h?

- The expression "multi-root" doesn't have a known meaning.  The
  description text in setup.hint doesn't help a lot either.  In a way it
  claims that setuid/setgid isn't available without this package, which
  is wrong, and it uses the expression "multi-root" by way of explaining
  it.  Along these lines...

- ... it would be much more helpful if you could explain what the
  package is doing, basically the full content of this mail of yours I'm
  just replying to, in a README file under /usr/share/doc/suexec/.  Keep
  in mind that the description text in setup.hint is (still) not visible
  from setup-<arch>.exe, thus almost nobody will read it.  Also, to
  understand what you mean by "multi-root", such a longer description in
  a proposed README file is really necessary.

Does that make sense?


Thanks,
Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ITP] libsuexec 1.0

[Achim Gratz]

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

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

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

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


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

Re: [ITP] libsuexec 1.0

[Marco Atzeri]

On 16/08/2014 11:28, Achim Gratz wrote:

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

suexec is the upstream name.
http://httpd.apache.org/docs/2.2/suexec.html

Marco

Re: [ITP] libsuexec 1.0

[D. Boland]

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

Re: [ITP] libsuexec 1.0

[Achim Gratz]

D. Boland writes:
>> 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.

It appears you want to license under some version of the GPL.  No
license document is actually included that spells out what that means.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: [ITP] libsuexec 1.0

[Achim Gratz]

Marco Atzeri writes:
> suexec is the upstream name.
> http://httpd.apache.org/docs/2.2/suexec.html

I fail to see the relation, APache suexec seems to do quite different
things.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: [ITP] libsuexec 1.0

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 5681 bytes --]

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 #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ITP] libsuexec 1.0

[Achim Gratz]

Corinna Vinschen writes:
>> 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.

Good, I haven't checked the sources so I'll believe it.  Actually I've
been thinking before that maybe it was a good idea to map group 544 to
euid 0 (so that shells would be showing # as prompt without extra
nudging), but I came to the conclusion that it probably makes more
trouble than it's worth.  Maybe I revisit that question some time…

But anyway, I stick to my earlier assessment that this functionality
should be incorporated into applications that need it on the source
level, gnulib-style.  That shim is small emough so that the resulting
duplication doesn't matter.  I can't think of a good reason to have that
as a DLL on the other hand (other than if you'd wanted to shim at
runtime, which is IMHO a bad idea).

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

The idea of exposing that server to the world doesn't sound exactly
appealing to me.  But yes, choice is good.  :-)


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: [ITP] libsuexec 1.0

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 3084 bytes --]

On Aug 16 12:50, Achim Gratz wrote:
> Corinna Vinschen writes:
> >> 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.
> 
> Good, I haven't checked the sources so I'll believe it.  Actually I've
> been thinking before that maybe it was a good idea to map group 544 to
> euid 0 (so that shells would be showing # as prompt without extra
> nudging), but I came to the conclusion that it probably makes more
> trouble than it's worth.  Maybe I revisit that question some time…

uid/gid == 0 is *only* used by applications which are in the server
and switch-user-context business.

It's kind of a bad idea anyway, and I'm constantly puzzled why there
are so many applications out there using this test.  Applications *not*
running with certain privileges will not be able to use certain functions
anyway.  The inability to use certain function is in 99% of the cases
indication enough that the application is running in a low-privilege
context and not running as a system-wide service.

So, while it's kind of nice from a compatibility POV to use uid/gid 0 in
certain scenarios, it doesn't make much sense most of the time.
Especially not on a system which *is* capabiliy based rather than
uid/gid==0 based.  This is a problem on other sytems as well.  Even on
Linux capabilities are getting more and more important and the uid/gid
loses its meaning.

> But anyway, I stick to my earlier assessment that this functionality
> should be incorporated into applications that need it on the source
> level, gnulib-style.  That shim is small emough so that the resulting
> duplication doesn't matter.  I can't think of a good reason to have that
> as a DLL on the other hand (other than if you'd wanted to shim at
> runtime, which is IMHO a bad idea).

Point taken.  Maybe it should be provided as a static lib only.  The
size added to the executable is, in fact, negligible.

> > 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.
> 
> The idea of exposing that server to the world doesn't sound exactly
> appealing to me.

Heh :)  So you're going to provide a postfix port really soon now?


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ITP] libsuexec 1.0

[D. Boland]

Hi group,

Thanks for all the critiques and suggestions regarding this new library. I have made
changes accordingly.

* The term 'capabilities' has been removed from the hints file, since that is not
what the library is about or for.

* Also the term 'multi-root' has been removed from the hints file. I think the new
description in the hints file now accurately covers what the library does.

* Not all functions in the library were declared. They are now.

* I added a readme file.

* I removed the dynamic library. This library will be static only.

* I put the license under the 'Open Source Definition' license and added a reference
to the complete license text.

http://cygwin.boland.nl/x86/release/libsuexec/

GTS's are welcome.

Daniel

Re: [ITP] libsuexec 1.0

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1549 bytes --]

Hi Daniel,

On Aug 17 21:22, D. Boland wrote:
> Hi group,
> 
> Thanks for all the critiques and suggestions regarding this new
> library. I have made changes accordingly.
> 
> * The term 'capabilities' has been removed from the hints file, since
> that is not what the library is about or for.
> 
> * Also the term 'multi-root' has been removed from the hints file. I
> think the new description in the hints file now accurately covers what
> the library does.
> 
> * Not all functions in the library were declared. They are now.
> 
> * I added a readme file.
> 
> * I removed the dynamic library. This library will be static only.
> 
> * I put the license under the 'Open Source Definition' license and
> added a reference to the complete license text.

Uh, that's a bit of a problem.

The text under http://opensource.org/docs/osd/ does *not* constitute a
license by itself.  It just describes what a license has to define to
become an OSS license.  For blessed OSS licenses, see
http://opensource.org/licenses/.  For a simple lib like this I'd suggest
http://opensource.org/licenses/BSD-2-Clause or
http://opensource.org/licenses/LGPL-3.0

> http://cygwin.boland.nl/x86/release/libsuexec/

A LICENSE file parallel to usr/share/doc/README containing the license
text would be nice.

Other than that licensing issue, the package is GTG.


Thanks,
Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ITP] libsuexec 1.0

[D. Boland]

Hi Corinna,

Corinna Vinschen wrote:
> 
> > * I put the license under the 'Open Source Definition' license and
> > added a reference to the complete license text.
> 
> Uh, that's a bit of a problem.
> 
> The text under http://opensource.org/docs/osd/ does *not* constitute a
> license by itself.  It just describes what a license has to define to
> become an OSS license.  For blessed OSS licenses, see
> http://opensource.org/licenses/.  For a simple lib like this I'd suggest
> http://opensource.org/licenses/BSD-2-Clause or
> http://opensource.org/licenses/LGPL-3.0
> 
> > http://cygwin.boland.nl/x86/release/libsuexec/
> 
> A LICENSE file parallel to usr/share/doc/README containing the license
> text would be nice.

I changed the license to LGPL 2.1. It has the nice short text to paste in my sources
:-).

I also updated the procmail package. It has Cygwin version 14 now.

Finally, I sent my public key, so now I will wait for activation.

Thanks,
Daniel

Re: [ITP] libsuexec 1.0

[Achim Gratz]

D. Boland writes:
> Thanks for all the critiques and suggestions regarding this new library. I have made
> changes accordingly.

I still think you should name it differently.  Marco has already mixed
it up with Apache suexec…


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: [ITP] libsuexec 1.0

[D. Boland]

Hi Achim,

Achim Gratz wrote:
> 
> D. Boland writes:
> > Thanks for all the critiques and suggestions regarding this new library. I have made
> > changes accordingly.
> 
> I still think you should name it differently.  Marco has already mixed
> it up with Apache suexec…

The idea kind of was to mix it up, so people will know what it does. I noticed that
you and other people already declare the user switching technique half dead. It's a
brilliant idea, you know. Because of its simplicity. It's even patented. By
referring to the Apache executable I give the technique the glory and attention it
deserves.

So most people are thinking 'Capabilities' nowadays... Sigh. This will only steer
admins away from finding out how user switching works and applying it. Instead they
will just run entire server processes as admin-users.

Sincerely,
Daniel

Re: [ITP] libsuexec 1.0

[Yaakov Selkowitz]

On 2014-08-18 13:20, D. Boland wrote:
> Achim Gratz wrote:
>> I still think you should name it differently.  Marco has already mixed
>> it up with Apache suexec
>
> The idea kind of was to mix it up, so people will know what it does.

Deliberately inciting confusion isn't a good thing.  If this was "Apache 
suexec turned into a library" this might make sense, but this clearly 
isn't.  Let's find another name for it, please.


Yaakov

Re: [ITP] libsuexec 1.0

[Achim Gratz]

D. Boland writes:
>> I still think you should name it differently.  Marco has already mixed
>> it up with Apache suexec…
>
> The idea kind of was to mix it up, so people will know what it does.

Apache suexec is concerned with running new processes as a different
user, so both the "su" and the "exec" part of the name make sense.

Your library is concerned with inserting itself into certain calls to
swap uid/gid so programs expecting a fixed mapping of some uid/gid to
certain capabilities (roughly associated with the concept of a root
user) work without the actual source getting patched on a system where
those assumptions aren't true.  Looks like different thing to me and
giving it a different name surely wouldn't hurt.

> I noticed that you and other people already declare the user switching
> technique half dead. It's a brilliant idea, you know. Because of its
> simplicity.

I did nothing of that sort.  I said that the assumptions some of those
programs make aren't true on many systems and have not been for a long
time.

> It's even patented. By referring to the Apache executable
> I give the technique the glory and attention it deserves.

Attaching to unrelated projects' names for glory is a surefire way to
rile those projects up and sow confusion among users on both sides.

> So most people are thinking 'Capabilities' nowadays... Sigh. This will
> only steer admins away from finding out how user switching works and
> applying it. Instead they will just run entire server processes as
> admin-users.

Again, running applications with the least privileges needed for a given
task is a tried and valid concept.  SWitching uid/gid to achieve that is
an implementation detail that is not relevant to all systems.  Give
SELinux a spin and then come back to me.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

DIY Stuff:
http://Synth.Stromeko.net/DIY.html

Re: [ITP] libsuexec 1.0

[D. Boland]

Hi Achim,

Achim Gratz wrote:
> 
> D. Boland writes:
> >> I still think you should name it differently.  Marco has already mixed
> >> it up with Apache suexec…
> >
> > The idea kind of was to mix it up, so people will know what it does.
> 
> Apache suexec is concerned with running new processes as a different
> user, so both the "su" and the "exec" part of the name make sense.
> 
> Your library is concerned with inserting itself into certain calls to
> swap uid/gid so programs expecting a fixed mapping of some uid/gid to
> certain capabilities (roughly associated with the concept of a root
> user) work without the actual source getting patched on a system where
> those assumptions aren't true.  Looks like different thing to me and
> giving it a different name surely wouldn't hurt.
> 

Ok, got the point. But the "su" part must stay. Because it's the super-user who
needs to be simulated.

Soo:

susim?
simsu?
fakesu?

Suggestions are welcome...

D.

Re: [ITP] libsuexec 1.0

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 609 bytes --]

On 08/21/2014 06:19 AM, D. Boland wrote:

>> Your library is concerned with inserting itself into certain calls to
>> swap uid/gid so programs expecting a fixed mapping of some uid/gid to
>> certain capabilities (roughly associated with the concept of a root
>> user) work without the actual source getting patched on a system where
>> those assumptions aren't true.  Looks like different thing to me and
>> giving it a different name surely wouldn't hurt.

> fakesu?

I like this one.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 539 bytes --]

Re: [ITP] libsuexec 1.0

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 731 bytes --]

On Aug 21 06:20, Eric Blake wrote:
> On 08/21/2014 06:19 AM, D. Boland wrote:
> 
> >> Your library is concerned with inserting itself into certain calls to
> >> swap uid/gid so programs expecting a fixed mapping of some uid/gid to
> >> certain capabilities (roughly associated with the concept of a root
> >> user) work without the actual source getting patched on a system where
> >> those assumptions aren't true.  Looks like different thing to me and
> >> giving it a different name surely wouldn't hurt.
> 
> > fakesu?
> 
> I like this one.

Ditto.


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ITP] libsuexec 1.0

[Pavel Fedin]

Hello, D..

Thursday, August 21, 2014, 16:19:00 you wrote:

> susim?
> simsu?
> fakesu?

> Suggestions are welcome...

 cygsu
 cygroot

Just 'cyg' somehow sounds better IMHO. But it's really just MHO.

-- 
Kind regards,
 Pavel

Re: [ITP] libsuexec 1.0

[Achim Gratz]

D. Boland writes:
> fakesu?

I'd go with "fakeid" personally.  But that's a joke that's probably too
hard to get… so fakesu is also good.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

Re: [ITP] libsuexec 1.0

[D. Boland]

Achim Gratz wrote:
> 
> D. Boland writes:
> > fakesu?
> 
> I'd go with "fakeid" personally.  But that's a joke that's probably too
> hard to get… so fakesu is also good.
> 
> Regards,
> Achim.
> --
> +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
> 
> Samples for the Waldorf Blofeld:
> http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

So it's settled. I will roll with fakesu. I'll re-post. Anyone know why my
upload-key activation is taking so long? Or were y'all waiting for me to change my
mind...

Daniel

Re: [ITP] libsuexec 1.0

[Yaakov Selkowitz]

On 2014-08-22 00:39, D. Boland wrote:
> So it's settled. I will roll with fakesu. I'll re-post. Anyone know why my
> upload-key activation is taking so long? Or were y'all waiting for me to change my
> mind...

Sorry, issue on our end.  Your key has been activated.


Yaakov

[ITP] libsuexec 1.0

[D. Boland]

Hi group,

This is not an existing package, but a spin-off project from porting Sendmail and
Procmail to Cygwin. These programs, as you may or may not know, rely heavily on the
setuid  mechanism (impersonating as another user).
More formally, this is called 'running as an unprivileged user' in Linux and
'privilege separation' in OpenBSD. In Cygwin, this mechanism is already implemented
in the ssh daemon.

Sendmail takes this idea to the extreme. It starts up as the root user and waits for
connections. On connection, it starts the 'queue runner' program as an unprivileged
user called 'smmsp', which handles the conversation with the remote e-mail client. 

If the incoming e-mail has to be delivered locally (stored on disk), the queue
runner starts the procmail program, which in turn switches to the actual user the
e-mail is meant for and stores it in the user's inbox.

So, for instance sending an e-mail to myself involves switching through three users:
root -> smmsp -> daniel

The problem
-----------
Up to WinXP and Win2002, porting source code for Cygwin which performed this
switching of users, wasn't a big problem.

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.

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.

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.

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

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.

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.

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/

All GTG's are welcome...

Cincerely,
Daniel