On Sun, 25 Jun 2000, Gregory Maxwell wrote:
> On Sun, 25 Jun 2000, Igmar Palsenberg wrote:
>
> > > > Root is already privileged to set/unset those bits on any file regardless
> > > > of ownership. It does not follow that this would change if users could
> > > > set those bits on their own files.
> > >
> > > In the original implementation (pre 2.0) that wasn't the case when secure
> > > level was > 0. securelevel was dropped later because it was broken.
> > > The root restriction is a leftover.
> >
> > It is mainly used here (on BSDI) to protect system programs (login,
> > etc). Kills the possibility of a rootkit.
>
> Amusingly, other then own my own paranoid-fortresses-of-doom systems, the
> only place I've seen Immutiable files is AFTER the install of the rootkit
> (i.e. the hacker chattrs to confuse clueless sysadms)..
> :)
Erm... Folks, let me fill in a detail that seems to be missing here. Dunno
about BSDI, but 4.4BSD as it had been released (and {Free,Net,Open}BSD)
have more elaborate scheme - they have immutable and user-immutable.
Rules looks so: immutable is subject to securelevel limitations,
user-immutable is a normal attribute (can be set/reset the same way it is
for any other permission bit). Either of them prevents modification/unlinking/
renaming/creating a link to. That way one can have the security-enforcing
behaviour (normal immutable) _and_ normal users can use it as protection
on their files. Root can override the user-immutable (as every other
permission bit). Same goes for append-only. That makes sense - there are
times when you want to protect against your own screwups and be able to
do/undo that without su. If we add that we may restore the securelevel-type
scheme for strong variants of these (useful for enforced security) and let
users have the weaker variant.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jun 26 2000 - 21:00:06 EST