On Tue, Jun 05, 2007 at 10:26:20AM +0200, Casper.Dik at Sun.COM wrote: > >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)
Ah, ALL privs instead of a special priv to clear, make sense, but see below. > 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". But what we don't provide that BSD run-levels do, is an administrative way to make sure that the system has entered such a "secure run-level." In Solaris that would be done by making sure that no process has (and therefore can't get) some privilege in its L/P/E sets, no? But we don't have an SMF service, say, that we could enable, that would allow this. Now, suppose that we had such a service. Then we could have a system running without any process with PRIV_FILE_FLAG_SET in any priv set, but now operations that normally need all privs cannot be done, and if the intent in dropping PRIV_FILE_FLAG_SET was only to make sure that certain files were immutable until the next boot then dropping that priv will have accomplished more than that. I'm thinking of writing to files owned by UID 0, which requires all privs, not just PRIV_FILE_DAC_WRITE. OTOH, perhaps that should be the intent in dropping PRIV_FILE_FLAG_SET: to prevent not just writes to immutable files and so on but also to prevent all operations which would require the caller have all privs. Nico --
