On Sun, Feb 24, 2008 at 09:34:27PM +0200, Elad Efrat wrote: > Hi, > > At the moment, secmodel_bsd44's default return value, unless the > operation is allowed, is "deny". This works okay as long as we don't > try to do interesting things. :) > > I'm thinking about changing the default to "defer": if the operation > isn't allowed, don't block it, but rather say "let someone else decide". > By default, since there will be nobody else to decide, it will end up > being a "deny". > > The rationale behind the "deny" was that if other kernel code listening > on some scopes decides to allow everything, we don't lose with our defer > policy -- the secmodel can't be weakened. I think this would be a good change. Any security module that's supposed to be usable as a module not at the end of the chain would have to do this. > Now I'm thinking, though, that this might not be necessary. To get code > in the kernel (conventionally) you'd have to either write to /dev/kmem > or load a module. If you can do that, you have the permissions and > ability to do plenty other stuff, too, so kauth should not try to > supposedly protect itself in such situations. I'd say don't let this arguement talk you out of making this change. A default answer of "defer" is more-correct that what happens now. Making this change strikes me as the right thing to do. It also will serve as a good example for future module-authors. Also, the fact that root was able to load modules at boot doesn't mean that root can load modules (and thus kmem is writable) later. :-) Isn't that the reason we talked about securelevel and capabilities and the inability to re-enable "capabilities" that we disable towards the end of boot? Take care, Bill
Attachment:
pgpva1rLZIkiH.pgp
Description: PGP signature