search

mellon85 / shellinabox

Automatically exported from code.google.com/p/shellinabox
Other
0 stars 0 forks source link

dropping privileges doesn't actually drop privileges #48

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago 
When I run into a daemon that offers me options to change my uid and gid, my 
expectation is 
that it will totally drop its root privileges as soon as possible. I was 
therefore surprised and 
concerned to notice that shellinaboxd actually leaves the saved set-user-ID 
value set to root in 
the launcher process. Furthermore, dropping the real and effective UIDs to 
nobody but leaving 
the saved set-user-ID is somewhat deceptive in that it lulls people into 
thinking that the 
daemon is running totally unprivileged.

I think a better solution would be roughly as follows:
 - If shellinabox is started as root, and a uid or gid is specified, unconditionally drop privileges. If 
this breaks the LOGIN service, that will affect fewer people then having 
shellinaboxd 
unconditionally hold on to privileges.
 - If neither a uid or gid is specified, look at the service map. If the LOGIN service is in the service 
map, do not drop privileges at all - run the daemon as root
 - If neither a uid or gid is specified, and the LOGIN service is not in the service map, drop 
privileges to nobody/nogroup

Original issue reported on code.google.com by evan.broder@gmail.com on 1 Feb 2010 at 10:06

GoogleCodeExporter commented 8 years ago 
I'm more than happy to try and write a patch to fix this, but I'd prefer some 
confirmation that my proposed 
solution is acceptable before I dive too far into code.

Original comment by evan.broder@gmail.com on 1 Feb 2010 at 10:06

GoogleCodeExporter commented 8 years ago 
I think that the concern is valid. I wonder if we can make a simple requirement 
that completely dropping privileges requires that an SSH login be used instead 
of LOGIN.  It should be simple enough to make a switch, say, 
--no-root-privileges, that requires an SSH service.  If the user asks for LOGIN 
it won't run.  In this way, it is explicitly privilege free and the user knows 
it.

OK?

Comments and/or a patch welcome.

Original comment by beewoo...@gmail.com on 31 Mar 2012 at 7:37

GoogleCodeExporter commented 8 years ago 
That sounds reasonable. It'll make documentation a little more difficult. But 
it shouldn't confuse the manual page too much.

Original comment by zod...@gmail.com on 31 Mar 2012 at 8:24