State of Audit Proposal ?

offerat_private

Its been a few days now since we released our patch and the discussion has
died down, so I think its time to summarize.

No one ever came back to say why moving the hooks in-front of the DAC
checks was objectionable, so that seems to be a moot point.

There was some discussion as to the relevence of fd's vs inodes. And all
the points made by everyone were gone through when the POSIX 1.e spec was
written.

To quote from draft 17 of the Posix spec.

   "The audit events for interfaces that operate on files via file 
    descriptors include the fd among the data reported. There was some 
    feeling that this was in itself not very useful, since the file 
    descriptor is not directly meaningful to an audit administrator, but 
    the audit record for the open() call that created the file descriptor 
    is also reportable, and does enable an audit post-processing tool or 
    audit administrator, to make the link back to a human-readable name."

Without adding the fd to the audit record we make our implementation of
audit non-POSIX compliant, which makes any trusted evaluation a lot more
challenging to have any design accepted by the evaluation team.

We are really keen to get the API changed as soon as possible so that we
can start working on the rest of the audit code ready for phase 2. 

What does the rest of the list feel we need to do to have the patch
accepted ?

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