Stephen Smalley wrote: > > On Tue, 17 Jul 2001, richard offer wrote: > > > 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. > > But the fd is a non-global (per-process) and ephemeral value (it > is both non-persistent and can even refer to different files at > different times during the lifetime of a process). So what good > does it do in an audit record? Better to audit information that > might possibly be useful in reconstructing what happened, like > the pathname and inode number. You want to know what object's > data was read, not what fd was used. You really want both. The fd is the name by which the process refers to the object. If the file is unlinked (has a link count of 0) there is no pathname which is associated with it, and it would be erronious to report the pathname which it had when it was opened. We also have the case of pseudo file systems, where the inode number is just as transient as the fd. A good audit analysis tool is going to be able to answer querys based on fd, such as "where did this Trojan Horse get stdin from?". It does an audit system a lot of good to have the fd, and it is trivial to provide. -- Casey Schaufler Manager, Trust Technology, SGI caseyat_private voice: 650.933.1634 casey_pat_private Pager: 888.220.0607 _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Wed Jul 18 2001 - 09:42:25 PDT