> -----Original Message-----
> From: owner-linux-kernel@vger.rutgers.edu
> [mailto:owner-linux-kernel@vger.rutgers.edu]On Behalf Of Alexander Viro
>
> 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).
--- This makes alot of sense.I would guess (?) that an accidental 'rm -fr' by root wouldn't remove normal 'immutable' files -- but that they would still be required to remove the immutable bit first? If not, root couldn't use user-level immutable w/o being afraid that they or a root level program wouldn't accidently remove the file same as today...
> 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. --- If I understood Andi, securelevel isn't currently implemented? If that is so, maybe the current bits should be allowed to normal users and the "sec_immutable" and "sec_append_only" would be allocated in the future should secure level come back into existance?
In order to protect against programs including code to 'override' user-immutable, I could see 'chattr' being enhanced to be a security-enforcing program (like passwd) that would allow users (except root) to only change bits on their own files but would also be 'suid' so that setting +i and +a bits is still a privileged operation that can't be simply overridden by user-level programs. When and if the secure-level feature is added back in, the new bit flags in the same program could be "+/-I" and "+/-A".
Just a thought... -l
-- Linda A Walsh | Trust Technology, Core Linux, SGI law@sgi.com | Voice: (650) 933-5338
- 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:07 EST