Re: State of Audit Proposal ?

sarnoldat_private

On Mon, Jul 23, 2001 at 06:17:55AM -0700, KRAMER,STEVEN (HP-USA,ex1) wrote:
> 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.  Given that it is a possibility to have
> different MAC and DAC return codes, it becomes an issue of storage 
> channels, not only timing channels.

Simply that many syscalls are expected to return one of -EPERM or
-EACCES if a process doesn't have the required credentials to access a
file. Pity the poor application programmer who assumes creat(2) will
never return -EPERM, only -EACCES.

No, any LSM that begins returning unexpected error messages is going to
wind up breaking an awful lot of applications. And the whole point of
starting with Linux is the huge base of applications; right? :)

> In the past, I would have agreed that covert channels are a bit
> esoteric to worry about in real-life OSes.  But given the propensity
> of crackers to defeat so many existing protection mechanisms, isn't
> this something we should consider (at least bookmark it for later
> examination)?

I sure don't want to get sucked down this hole. Don't get me wrong,
talking about it during my leisure time sounds fun :), but during my day
job I want to try to tackle problems a little more tractable. :)

> I'm also curious as to why you don't think Linux is an appropriate
> system for which to eliminate covert channels.

[Warning to regular readers: here we are going way off topic. If you
like staying on topic, you've reached the end, so place a cordial
closing here and enjoy the rest of your day. :]

For several reasons: first, Linux was designed with performance as a
major requirement. With this focus, common cases are going to be more
well-optimized giving a good chance that timing information will be very
useful on hundreds of operations for covert channel bandwidth. Second,
there are many places where processes interact with each other; a system
designed to reduce covert channels will have very few well-defined
interfaces between processes and very little way to get information from
the system as a whole. Third, all the literature I have read suggests
that building secure systems where 'secure' is defined to include
protection from covert channels requires a fairly rigorous design
against covert channels from the beginning.

Not one of the classical documents I have read suggests that patching a
ten year old OS based on a twenty year old revision of a thirty year old
OS strongly borrowing ideas from a forty year old OS is the best place
to start -- especially when the security needs of each of the
intervening OSs has been rather simple and backwards compatability has
been a strong requirement along the way. :)

However, don't let my opinions prevent you from trying, if stopping
covert channels is one of your goals for Linux. :)

Cheers! :)

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