[RFC][PATCH 0/3] CAPP-compliant file system auditing

[Timothy R. Chavez]

On Thursday 31 March 2005 01:02 pm, Stephen Smalley wrote:
> On Thu, 2005-03-31 at 12:16 -0600, Timothy R. Chavez wrote:
> > In its present state, the Linux audit subsystem cannot be used in a
> > Common Criteria (ISO/IEC 15408)[1] CAPP/EAL4+[2] evaluation.
>
> Where specifically does CAPP say that you need the particular
> functionality that is missing?  While I don't think the target audience
> will care too much about CC/CAPP per se, it would help to have a more
> specific reference than just the entire document.  And I'm not sure you
> even want to start on this note (as CAPP isn't going to motivate them
> much) vs. just starting with an explanation of the missing functionality
> that is desired.

Alright, but the missing functionality is in terms of what CAPP requires.  But 
I will have another go at it.  I do appreciate the comments.  I can go ahead 
and put at the end, the specific wording in the protection profile, in 
addition to a link to the actual document?

>
> >   This is
> > insufficient for CAPP because (1) the object is not being audited by
> > "name"
>
> Is that truly an issue for CAPP?  Where does it say that?  I'm a bit
> concerned that you are over-emphasizing the importance of the name here.

Well CAPP describes file system objects as "named" objects, so it is my 
understanding that auditing by "name" has a different implication then 
auditing by (inode,device) and thus, to meet CAPP, the ability to audit by 
"name" is important _and_ required.

> The issue really is that some locations in the filesystem have well-
> defined and security-relevant meaning, right?

Yes.  I will work this in.  Thanks.

>
> > nor (2) will it remain auditable if the underlying inode changes.
>
> This part is more likely to make sense to the target audience,
> especially when coupled with the /etc/shadow example.  Again, the point
> being that you care about events on any object that is in that location,
> regardless of the specific object there.
>
> > Here is a relevant example show casing the deficiency:
> >
> > The administrator audits "/etc/shadow".  To do so, she adds the filter
> > rule using /etc/shadow's current inode and device.  Then, she runs
> > 'passwd' to change her password.  She consults the audit log and sees
> > that some records have been generated, but when she runs 'passwd' again,
> > she notices that no longer are audit records being generated.  She does
> > an 'ls -i /etc/shadow' and notices that the inode has changed.  She then
> > decides to consult the audit log and comes to the realization that what's
> > there is incomplete and does not tell the complete story of /etc/shadow
> > during the execuation of 'passwd'.
>
> I think you can state this more briefly, i.e. /etc/shadow is a classic
> example where we want to preserve auditing on it across transactions,
> and each transaction re-creates the file; hence, a simple
> (device,inode)-based filter is inadequate or at least would need to be
> updated after every transaction.

Right.  Thanks.

>
> > The patch is broken into two parts.
> >
> > Part 1: The actual implementation of the file system auditing piece
> > Part 2: The hooks
>
> Hmmm...seems truncated.

Yeah, I suppose so.  Last minute.. I'll provide some more detail.  I tried to 
split up the exposition logically based patch, but  perhaps it certainly 
won't hurt to give a more descriptive preview here.


Thanks for the feedback.

-tim