tech-security archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Secmodel_bsd44: default to "defer", not "deny"?



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: pgpCKDT_09301.pgp
Description: PGP signature



Home | Main Index | Thread Index | Old Index