Re: Changes to LSM phase 1 for audit.

offerat_private

* frm chrisat_private "07/17/01 15:19:34 -0700" | sed '1,$s/^/* /'
*
** Greg KH (gregat_private) wrote:
*> On Tue, Jul 17, 2001 at 03:10:12PM -0400, Stephen Smalley wrote:
*> > 

*> > 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.
*> 
*> I agree.  The fd is an arbitrary number.  The struct file is so much
*> more authoritative.
* 
* as i mentioned before, the fd is critical in at least one case:
* fnctl(F_SETFD) or close_on_exec.  it is possible to have the a descriptor
* that references the same filp, but they could have different close_on_exec
* values.  so i can see it would be useful in at least that case.

The rationale for using the fd in the audit record rather than the pathname
or any arbitary number is that fd is the object handle that is being acted
on. read() is not acting on a pathname, it acts on a fd. 

Once the open has succedded the file can be unlinked, what then should one
report as the object that is being read ? A new file may have been created
with the same pathname in the meantime. So reporting the pathname is
incorrect, its a different object that just happens to have the same value
in one particular namespace.

Once its accepted that audit wants to record exactly what it is presented
with, not a best guess, its just a question of performance whether we pass
the fd to each hook (no performance hit) or force audit to write its own
get_fd_from_filp() routine (non trivial and sub-optimal in performance). 

If the fd was not immediately available, or fd was large or that it made
the number of parameters passed to a hook excede the number of registers
I'd agree that pushing it inside a hook maybe a reasonable thing to call
for. But an fd is none of these.

* 
* -chris

richard.

-----------------------------------------------------------------------
Richard Offer                     Technical Lead, Trust Technology, SGI
"Specialization is for insects"
_______________________________________________________________________

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