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

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.

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.

What do others think?

Thanks,

-e.

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

Bill Stouder-Studenmund wrote:

> 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?

Right.

I'll wait a couple of days and change it.

Thanks,

-e.