RE: State of Audit Proposal ?

steven_kramerat_private

> -----Original Message-----
> From: Seth Arnold [mailto: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.

Are we to use the Linux man pages as a functional spec for the interfaces
that LSM must continue to respect?  Has anyone taken the LSM
changes, looked at the current state of the hooks, and made sure you're not
creating situations where an incorrect errno will be returned?
As an example, I'm looking at the sys_read call.  In the man page, there
is no EACCES failure, nor do I see it in the sys_read kernel code.
So, what kind of error value will the permission(file, MAY_READ) hook
return?  Usually you'd think of EACCES failure with such a hook, but
you said that it's your understanding that LSM hooks won't return
EACCES there because an application wouldn't know how to use such a
failure with read(2).

Furthermore, will the meanings for the errnos (such as EACCES) still
have the same meaning in the man pages with MAC as they do w/o MAC?

> 
> 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 have opinions on this, but it's off-topic and therefore I won't
respond.  (If anyone cares, I'll mail them directly.)

--steve
> 

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