Re: Securelevel bitmap patch

Harald Koenig (koenig@tat.physik.uni-tuebingen.de)
Mon, 30 Mar 1998 14:41:53 +0200


On Mar 30, Richard Gooch wrote:

> Why is the capabilities mask for children needed at all? I would
> assume that the init binary (for example) would be changed to do:
> fork ();
> /* Child */
> rip_out_capabilities ();
>
> As things stand now, any trusted binary (i.e. suid-root) does much the
> same thing if needed (such as /bin/login), by calling setuid (),
> seteuid (). We don't have a child process
> "uid,euid,gid,egid,gid-saved-set" table either. So why do we need the
> child capabilities mask?

maybe just don't call it `child capabilities' but `maximum capabilities'.

I know these priviledge bitmaps from good old VAX/VMS times and it was
pretty handy that you have been allowed to remove all those authorized
priviledges for your own process jsut for now, and later on you can
enable those priviledges back again (but only those which have been
marked in your `maximum capabilities' or (VMS style) "authorized privs".

the same is true for nice levels (VMS: process priorities).
sometimes it was convenient to be allowed to lower the oen priority (slow down)
for a while, but being allowed to increase it later again up to the normal
nice level sometimes makes it more conveniant and more likely to `be nice'
for at least some time.

IMHO both `capabilities' and nice levels etc. are proces resources just
like (data/stack segment size, cpu time limit, and so on) where it's sometimes
nice to be able to limit oneself _for_now_ (and not needing to exit and
log in again to gain old (previously allowed) resource limits).

Harald

PS: just one warning from my last bits of memories of VMS-days:
it's pretty important that priviledges are some sort of orthogonal
and don't have (too much) unexpected side effects in allowing
other operations too. I remember that e.g. just the signle "READALL" priviledge
(allowed to read-only access all files, pretty handy for operator's processes
running disk backups) was sufficient to be misused to get all other privildges
you'd like to have (first get CMEXEC or CMKRNL, then SETPRIV, then everything else;
or some simiar sequence...).

--
All SCSI disks will from now on                     ___       _____
be required to send an email notice                0--,|    /OOOOOOO\
24 hours prior to complete hardware failure!      <_/  /  /OOOOOOOOOOO\
                                                    \  \/OOOOOOOOOOOOOOO\
                                                      \ OOOOOOOOOOOOOOOOO|//
Harald Koenig,                                         \/\/\/\/\/\/\/\/\/
Inst.f.Theoret.Astrophysik                              //  /     \\  \
koenig@tat.physik.uni-tuebingen.de                     ^^^^^       ^^^^^

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu