>On Mon, Jun 04, 2007 at 10:36:26PM -0700, Scott Rotondo wrote: >> >> > In order to ease the porting of ZFS to BSD and MacOS X the following >> > "system" attributes will be supported in ZFS. Setting these >> > attributes requires PRIV_FILE_FLAG_SET. Clearing the attribute >> > requires a process to have PRIV_FILE_FLAG_CLEAR >> >> You're requiring two different privileges, depending on whether the >> attribute is set or cleared? That's contrary to the way other Solaris >> privileges work, where a single privilege lets you set a given attribute >> (say, file permission bits) regardless of the value being set. > >I seem to recall a conversation on #onnv about how one could implement >the BSD notion of security run levels: make sure that no process remains >or can be started with PRIV_FILE_FLAG_CLEAR and IMMUTABLE or APPEND ONLY >files truly are, until next boot. Mark enough files IMMUTABLE or APPEND >ONLY and drop PRIV_FILE_FLAG_CLEAR early enough at boot and you're set.
We should not implement a BSD notion of secure levels based on a single privilege. That is BROKEN beyond believe. A single privilege must not be allowed to side step the main protection mechanism. If the flags should not be clearable, which is something I can understand, then you should require ALL privileges (available in the current zone) >Now, one thing is that PRIV_FILE_FLAG_CLEAR should be possible to drop >and yet one should still be able to perform some operations that >currently require all privs (e.g., non-destructive DTrace scripts that >use the fbt provider, or mdb -k, but not mdb -kw), just not operations >that require all privileges and let the user work around these file >attributes. The fbt provider does not require all privileges neither does mdb -k. We already have secure levels; but they are per-process and they are called the limit set. >Of course, that may be more difficult to work out than it may at first >seem: one would have to be able to mark certain SMF services as >IMMUTABLE, but one could not mark the repository that way without >causing all SMF services to become IMMUTABLE. But at least having the >split privileges now should make it easier to work this out later. Considering the amount of destruction possible by allowing files to be marked immutable incorrectly, I think we need to do some serious thinking on this matter. There is a reason why Solaris privileges require all privileges for certain operations: it's because those operations are allow sidestepping the security levels; it's our form of "secure-levels". Casper
