Re: [RFC][PATCH 0/3] CAPP-compliant file system auditing
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