Re: linux-security-module digest, Vol 1 #175 - 9 msgs

dwheelerat_private

KRAMER,STEVEN (HP-USA,ex1)" <steven_kramerat_private>:
>Why is it that MAC and DAC both must return the same error messages?
>I can easily envision a MAC policy that returns more errno values
>than the access errors.

Hmm, looks like we have two groups, one who want hooks BEFORE the DAC
checks, and another who wants the hooks AFTER the DAC checks.
In particular, it looks like there is a _semantic_ difference
(not just an elimination of covert channels) that would drive
different placements.

Out of curiosity, what would be the implications of having
_both_ "pre" and "post" hooks?  Obviously, this would add more hooks
(maintenance pain) and potentially impact performance (slightly?).
How many hooks?  Would that be a solution?

I'd like to see this "third approach" considered.
One advantage of having "pre" and "post" hooks is that the "default"
behavior is still in the kernel (not requiring separate libraries or
anything else, for which there's always the danger of not calling them
correctly).

dawat_private (David Wagner) wrote:
>No.  The whole covert channel model---you give some untrusted code access
>to confidential data, and then you try to prevent that code from spilling
>the beans---is fundamentally broken, in my view, because you're doomed
>to failure.  Getting rid of all the covert channels is a Herculean task.

To be fair, nobody requires getting rid of "all" covert channels;
even Orange Book A1 systems have covert channels.  Those who worry about
covert channels don't eliminate them - their goal is to lower their bandwidth.

>A better model: Just don't give that untrusted code access to the
>confidential data in the first place, and voila!, no more worries about
>covert channels.

Great idea.  Please write the program that can tell if arbitrary code
will send confidential information where it shouldn't go.
Turing would have been interested to see it :-).
As you know, the problem is that some code is trusted, but isn't worthy
of that trust.  Ideally, you'd like to limit the amount of trust you
give applications as much as practical.

>In any case, even if you don't buy my argument and still worry about
>covert channels, the most compelling argument is that Linux is unlikely
>to be the right base to build on.  It is extremely hard to retrofit
>legacy systems to reliably remove all covert channels.

Here I agree; I think it would be VERY hard to eliminate covert channels
with the current Linux kernel.  Let's be fair, though: the only way to
build a system to defend against covert channels is to start with
an existing base.  "Starting from scratch" just doesn't work, it's too
expensive to start over (rewriting device drivers, etc.).

Anyway, this is all a side-topic.  I don't think covert channel issues
are particularly an issue now.  If solutions are equal & one would
be better for covert channels (if that were to be supported later),
by all means choose the more flexible
approach.  I do _NOT_ think inhibiting covert channels is
anywhere near as important as flexible access rights & auditing.

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