[rsbac] Re: Thoughts on the "No Linux Security Modules framework" old claims

Casey Schaufler casey at schaufler-ca.com
Wed Feb 16 17:07:10 CET 2005

--- Lorenzo Hernández García-Hierro <lorenzo at gnu.org>

> ... but think it's main
> shortcoming is that it cuts
> performance

Ya'know, I keep hearing this assertion, but
the evidence of actual system implementations
that have been measured to determine this
"performance impact" is that there is no
difference except in contrived cases. In
contrived cases the performance is better
if you do the "special" checks first.

> and adds further overlapping to the DAC
> checks, that should
> be the first ones being called (as most times they
> do) and then apply
> the LSM basis, so, post-processing will be only
> required if the DAC
> checks get in override or passed, without adding
> too-much overhead to
> the current behavior.

No. There are a number of reasons, including
audit and nearline storage issues that make it
important to do the special checks first. Some
access control schemes may not work if the
Classic DAC check is done first.

> So, I just agree partially, but yes, maybe modifying
> the DAC checks
> themselves and add what-ever-else helper function to
> handle by-default
> auditing in certain operations could be interesting.

I remain a advocate of authoritative hooks.

> I think it could be worthy to have a roadmap in a
> wiki or even talk
> about a one, trying to write it, so, we all could
> know what needs to be
> improved and done, getting a higher percentage of
> mainline-accepted
> approaches.


Casey Schaufler
casey at schaufler-ca.com

Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

More information about the rsbac mailing list