Re: Audit patch split into 5 parts

sarnoldat_private

On Tue, Jul 24, 2001 at 04:01:24PM -0700, richard offer wrote:
> sgi-1-add-fds

Seems fine to me. (BTW -- I think Casey and I proposed different uses
for the fds; he was saying some files could not be used as the
source/target (I am generalizing for him :) for 'common' file
descriptors. I was saying that every setuid program should have stdin,
stdout, and stderr assigned to *something*.) (BTW #2 -- I could envision
some sort of MAC policy for close-on-exec flags on file descriptors when
processes of different types execute either other. If someone would
rather code this one up, it may or may not be easier/more useful. In any
event, this is nearing three possible policies for filedescriptors.. :)

> sgi-2-post-hooks

Seems fine to me. (Frankly, I think this might lead to a performance
improvement despite now having to pass one more parameter .. the call is
no longer conditional.) Is there anything I may have missed?

> sgi-4-mac-before-dac
> ====================
> 
> Try and call a hook before any other DAC logic (including calls to
> capable()).
> 
> The issue here is that SubDomain wants DAC before MAC, classic B1 systems
> (as we will be aiming for) insist on having MAC before DAC. As we have two
> reasonable policies that have mutual conflicts in hook placement we need a
> third solution.

Oh, more than POSIX requires MAC to come first? (It has been a while
since I last read the orange book..) Since giving this up would mean
a reasonable amount of re-thinking and recoding for our complain mode
subdomain module, I am reluctant to just acquiesce.. :) Considering that
much the same could be said for the SGI group, I think some more time
could be spent trying to figure out a third solution that may suit the
both of us better..

> sgi-5-truncate
> ==============
> 
> A separate patch since I'm not sure about this, what with all the inode vs
> name discussion. We really want the name, the truncate() hook is passed an
> inode. We've added the name as well, but this is api sticks out like a sore
> thumb. It would be nice if we could come up with a generic solution for the
> all of the inode hooks, and just happen to fix this one at the same time...

Now, on this one, I am utterly confused. You guys change the prototype
but then hardcode one of the parameters to NULL in the only call? :) I
also don't understand why the file offset is included. Is it really
needed? (Especially considering that the results are going to be
'fuzzy', i.e., the results are unspecified in certain cases. Yes, I know
Linux will tend to do one thing consistently, but the applications
running on top of Linux may be coded to try several different things for
platform compatibility reasons.. I just don't see this value being
useful to anyone ever. :)

I am far from convinced that this is more than a mistake. :) Heheh.

Thanks richard.

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