unowned processes and who controls them (was: Re: passwd entry for uid -1
On Tue, Jun 05, 2001 at 05:57:17PM +0200, Oystein Viggen wrote:
> Quoth Marcus Brinkmann:
>
> > Will the following scenario work?
> >
> > glibc is changed, so that "setuid(-1)" means: Drop all (effective?) user ids.
> > Change the nobody entry in the passwd file so that it lists -1 as uid.
> >
> > This will make Unix programs which conventionally switch to user nobody very
> > safe (because they will run without any privileges).
>
> Would this make it possible to run both the apache-threads and bind as
> "nobody", and still have a person who cracks your bind _not_ being able
> to fiddle with your apache? Would services using more than one process
> still be able to work normally?
I am not sure. As far as I can see from
glances at the code in proc/, you can only frob processes that have no
owner if they are in your login collection (check_owner in proc/proc.h).
There seem to be a couple of issues, though (the setlogin interface
is called to be there "for historic reasons", and we "are not expected
to understand" it (process.defs).
Anyway, the code is there, but processes started at boot time are not in
different login groups, I think. You would want them to be there, though.
In fact, I think you would loose all security at the login shell if there
were processes without owner started at boot time, as login groups are only
created after a login.
It's not clear to me how tihs stuff works from just reading a couple of
minutes. We should probably ask Thomas.
> If we could get some kind of compartmentalizing for setuid(-1), so that
> the apache threads would have access to each other, but not to bind or
> the ftpd, and soforth, it could work, but this would again be totally
> incompatible with all other systems.
If you put them in a login group, this could work out right now. I am not
sure what you mean with compatible here.
You can actually try this out. Create a few users (we need them just for
the login group). Login, use rmauth to drop all uids, and then run some
programs. You should not be able to kill programs in one login group from
another one. Also try this at the login shell as another "login group", and
with programs run at boot time. You can use getlogin to query the login
group.
> Am I totally off here? I'm not sure how you would combine "no
> privileges" with "actually being able to do something useful". I'm
> quite Unixified in my knowledge, so perhaps it is only a question of
> unlearning a bit more ;)
The programs can access the filesystems through the fourth set of access
bits. By default, they are the same as the bits for "other". This way, you
can actually do something useful. However, the point of who controls who
for unowned processes is an important one. There is some code for this
there, but I am not sure how good it is.
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann GNU http://www.gnu.org marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de
Reply to: