Brett Lymn writes: > > Ugh no - this would be a major lose as the idea of the flags was in > part to make files immutable at certain security levels such that > _even_root_ could not modify them. The idea being you could trojan > proof your binaries by making them immutable (don't forget the > directories themselves, kiddies). If you allow root to stomp an > immutable file then you lose part of the value of chflags. > > Then again you could just rig the system to check your binaries > against an md5 signature before running them which stops the trojans :-) > > No, it seems everybody needs this explained. The issue is over the UF_IMMUTABLE and UF_APPEND flags, not their SF_ counterparts. USER flags may be added or removed at any time by either the user or root, therefore their protection in most circumstances could only be construed as advisory. The only caveat of letting root disregard these flags is that root loses the ability to temporarily mark a file as immutable while the system is running secure. IMHO no great loss. Again, user immutability and append only are for protecting users from each other, it's the system flags that are for protecting the system from root. Allowing users to trip root up this way just causes unexpected behaviour in code that assumes that if something failed, it was because root wanted it to. /Hugh
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:55:25 PDT