Re: The Demise of Simple Assurance?

caseyat_private

Crispin Cowan wrote:

> I believe it to be completely infeasible to ever consider moving the kernel
> security logic into a module.  In-kernel security logic ("DAC" for short :-) is
> deeply intertwined with lots of other non-security code.  Teasing it apart
> would be a Herculean task (complete with shoveling loads of crap :-) and is
> fraught with error.  As a result, the kernel group is highly likely to reject
> such a proposal.

Let us not forget our real-time embedded friends,
who want the null security policy. For them, leaving
the DAC code as is is clearly the wrong solution,
as the "capable always returns true" scheme gains
them nothing, while a DAC module which does no
checks but always returns success speeds them up.

We also have the impending NFSv4 crisis, with it's
bizillon and six unpleasant DAC attributes to deal with,
and the DAC policy enforcement will not be 100% file
system specific. If DAC isn't in a security module
for that, it's gonna get ugly.

> So no, moving the in-kernel/DAC logic to a module was not what I was proposing,
> and it is unlikely to ever be considered.  That's not a dictatorial rule, but
> IMHO, it is practical advice.

While I understand this position, I cannot condone it.
How can I change the DAC policy if it's not in the module?
How can I make Privileged Ports a DAC policy if I want?
How can I implement Hovan ACLs instead of POSIX ACLs?
In short, I can't. There is no way I can change the DAC
policy using LSM if the hooks are not authoritative or
do not include the DAC enforcement. I'm, as you say,
back to square one, requesting my own changes be applied
because LSM wasn't good enough for my evil purposes.

-- 

Casey Schaufler				Manager, Trust Technology, SGI
caseyat_private				voice: 650.933.1634
casey_pat_private			Pager: 888.220.0607

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module