On Fri, 3 Aug 2001, David Wheeler wrote:
> It appears to me that there's increasing unrest with the restrictive
> hook approach, with a number of problems being noted about it.
>
> However, many seem to believe that removing _all_ existing DAC checks
> from the kernel isn't allowable.
For anybody listening, some think it's not allowable, some think it would
be allowable, but might be so much effort that it will break the camel's
back at this point... so I'm looking for a strategy that allows it later
without backtracking significantly, if the Cassandra's are correct (hrm,
Cassandra... Casey... coincidence (j/k, late friday, my brain does that)).
>And although various arguments have
> been made, in my mind the major _advantage_ of restrictive hooks is their
> ease of verifiability.
>
> Let's examine a form we've looked at before:
>
> retval = (current-DAC-check);
> if (hook(retval, ...)) ...
>
> This has several advantages:
> 1. The DAC check is still in the kernel code. That way, the "default"
> is clearly stated, and there's not problem with duplicate code that tries
> to emulate what the kernel "usually does".
> 2. In many cases, this won't require many changes from what's done now,
> so I don't think it'd be too hard to switch from what's here now.
> 3. Verification of security modules is the main advantage of restrictive
> hooks, though as noted, it turns out to be fairly easy to unintentionally
> mess things up anyway. However, if all hooks start like this in a module:
>
> if (retval) return retval;
>
> Then you have a "restrictive-only" module. This is trivial to verify
> by hand; at most, you need to check ~140 entries for a sophisticated
> security module.
>
> This could even be checked automatically. Yes, this is something that
> needs checking, but hopefully no one is going to insert
> unchecked security modules into critical systems :-).
I agree on all four points, and add
4. Authoritative that allows in-kernel ("DAC", when convenient) to be
reported to the module and potentially overridden begins to acknowledge
that in-kernel MAY be something that should be moved out to a module. By
having it this way, it enables statistics to be gathered and considered
with regard to how many modules actually ignore it, how many respect it
restrictively, and how many might find other uses for having the kernel
opinion, and how they do in the market. This is the "forward/alternative
path" acknowledgement I've been trying to argue that we need for weeks,
but gotten nowhere with.
Furthermore, SGI or DACOUT(fictitious group) could work on the
LSM-to-this-ideal patch and PRESERVE LSM as a viable group/authority,
letting others deal with the "not easily placed" case and come to LSM with
any modifications to the interface that may be essential. Simply pass "no
opinion" to our authoritative hooks and rip out the in-kernel checks, it
becomes an idea somebody else can argue without arguing AGAINST the
validity of LSM.
Dr. Wagner's "do you have proof/statistics" question can be answered this
way without completely blocking us now.
>
> Perhaps there are places in the code where it makes little sense to
> permit a DAC override. In which case, don't pass a "ret", and the
> hook is restrictive (instead of authoritative). That means that you'll
> need to know, for each hook, if it's restrictive or authoritative,
> which can be determined from its prototype.
>
> This _does_ mean that, performance-wise, DAC checks always execute first.
> However, the kernel developers will want the COMMON case ("no fancy
> security module") to be fast, and paying for a few more cycles isn't
> likely to be a problem on systems worrying about advanced security
> mechanisms. Indeed, on most processors, the function call
> will almost certainly swamp any other performance payment you make.
> For the case of "the DAC security values are on tape", perhaps such
> DAC values should be implemented via a stackable security module instead
> the filesystem.
I'm not, personally, sure that the performance hit is a strong argument
either way... that data is not yet "in". The "flexability" is more dear
to me... processors get faster and more efficient all the time, and
concerns that want "high" security will have to decide if they want to pay
for it individually.
While ripping EVERYTHING out of the kernel now and allowing "return
permission" authoritative modules might certainly help the embedded
community, I don't yet have statistics that say it doesn't impose far
greater cost on the community at large. Authoritative after in-kernel
*wherever possible* moves us all toward getting that data and possibly
working out a solution *later*.
Sincerely,
J. Melvin Jones
|>------------------------------------------------------
|| J. MELVIN JONES jmjonesat_private
|>------------------------------------------------------
|| Microcomputer Systems Consultant
|| Software Developer
|| Web Site Design, Hosting, and Administration
|| Network and Systems Administration
|>------------------------------------------------------
|| http://www.jmjones.com/
|>------------------------------------------------------
_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Fri Aug 03 2001 - 13:57:04 PDT