Re: MAC before DAC vs DAC before MAC

dawat_private

Casey Schaufler  wrote:
>You are argueing that I ought to compromise my security
>policy (MAC before DAC) because [...]

Well, now I'm surely confused.  That's not what I was suggesting.  I was
criticizing some performance arguments that didn't look to me like an
adequate basis for altering the LSM architecture.  And I'm surprised to
hear you think that I was suggesting you compromise your security policy.
That wasn't my intent.

Maybe I should explain why I was raising questions on this subject.
My point wasn't to suggest that some policy goals are more important than
others.  Rather, I heard someone suggest doing in-module checks before
in-kernel checks, and when asked for justification, I heard two answers:
 - audit
 - performance [*]
Others have questioned the audit part, but I was questioning the
performance justifications.

I'm not suggesting that you abandon your policy goals.  But I still don't
see what policy goals would force us to prefer one ordering over another.
I suspect we can all agree that the ordering of checks is not a policy
goal in and of itself, although it may be a way to achieve some such goal.
What policy goals are incompatible with the current ordering?

(Well, let me qualify my above remarks with two caveats.  If the goal is
to avoid covert timing channels, then the ordering matters, but I'm not
sure that the LSM project is prepared to take on this goal, and I think
it would take a lot more than just changes to LSM to immunize Linux
against covert timing channels.  Likewise, if the goal is audit, then
ordering may matter, but others have said that we should wait on audit.
What does that leave?)

Footnote [*]:
  The only argument I heard for performance went along these lines:
  the performance issue only comes up for denied syscalls, but we need
  to optimize even denied accesses, because there are some cases where
  the kernel's checks might take a lot longer than the module's checks,
  and it is important to shortcut those checks and return an error to
  the user as quickly as possible.  That's the performance justification
  I heard, anyway.

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