Re: Changes to LSM phase 1 for audit.

sdsat_private

On Tue, 17 Jul 2001, Greg KH wrote:

> Bleah.  I understand that you would like to track fds purely for an
> audit case (from the kernel standpoint, the fd doesn't mean much at all,
> the struct file * means everything.)  But why can't you simply get the
> fd from the struct file * if you really want it?  That doesn't burden
> the hook interface to pass another variable that almost no security
> module will need.

Although I'm not a fan of passing the fd, it isn't clear to me that
SGI can readily obtain the fd from the 'struct file *'.  Wouldn't they
have to search through the file descriptor table for a match, yielding
race conditions?  And what if multiple descriptors referenced the same
struct file?  I suppose that may not be important if they just want a
handle for the file.

In any event, it would be helpful if the SGI folks could explain
why they want a fd for each hook to which they've added such a
parameter and could make the case that the 'struct file' is inadequate
for providing equivalent functionality.  Why audit the fd instead
of a pathname generated from the struct file?  If you are simply
looking for a small handle to reference a given file for numerous audit
records, you can always create and maintain your own mapping from integer
handles to files without needing to deal with the non-persistent 
per-process fd values.

> About moving the hooks before the DAC checks, I don't really mind this,
> but I know some people will have a real problem with this.  Anyone else
> want to comment on this?  Speak up now, or have to change your security
> module greatly later :)

Do you know why "some people" will have a problem with this change?
It doesn't seem like it should affect any of us with restrictive access 
control modules, and it does provide desirable support for MAC
policies.

--
Stephen D. Smalley, NAI Labs
ssmalleyat_private

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