Re: unowned processes and who controls them (was: Re: passwd entry for uid -1
(This ended up horribly long.. I'm sorry :)
Quoth Marcus Brinkmann:
> 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.
>
> 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.
Hey, this is cool ;)
It also seems that root is still god and can do whatever he wants, also
killing these processes, but two different rmauth'ed oysteivi's can not
frob each others processes.
There seems to be some fun to be had in the filesystem part of things,
though: When I log in as oysteivi and rmauth oysteivi, I can not, as
expected, do anything with "my" home directory (which is no longer
mine), but I can create files in /tmp, also as expected.
The strangeness kicks in when the files are created in /tmp. No matter
who I rmauthed from, the files will appear owned by user and group root
with the default umask. This means that I can 'cat > /tmp/somefile',
and actually get what I want in there, but I will not be able to open
this file for writing again, as it is now writable only for root.
It seems to me that implementing this in the filesystem would really be
a PITA, as you need to add the concept of files owned by the nameless
non-user while still taking care of the login groups.
Combined with some kind of capabilities support, this could prove quite
a versatile (and did I mention cool ;) security feature for the hurd,
though.
> The programs can access the filesystems through the fourth set of access
> bits. By default, they are the same as the bits for "other".
Are these supported in the current ext2fs implementation, or do we need
to fix both that and the user space tools?
> This way, you can actually do something useful.
I'd argue that without the option of keeping some privileges, much like
capabilities in linux, this would be of limited use for things like
network servers.
If, on the other hand, you were able to preserve a "capability" that
makes you able to open port 20 for outgoing connections, you could have
a nicely secured anonymous ftp server by using this feature. (I'm only
talking concept here, not necessarily implying that the current
implementation is secure.)
I've had xntpd on linux running as user ntp with the ability/privileges
(capabilities) to open low ports and set the system clock, but this
removal-of-uid is a bit more versatile, as you don't have to preallocate
uids.
> 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.
Well, after finally having understood some of it, I believe that the
_concept_ in itself is quite solid and can be useful in many cases.
A last note: I could not find the program getlogin anywhere. It's not
in the hurd package at least. Is there any other way to list process
groups or any place where I can get this program?
Oystein
--
This message was generated by a horde of attack elephants armed with PRNGs.
Reply to: