Re: [RFC][PATCH 0/3] CAPP-compliant file system auditing
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.
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.
The issue really is that some locations in the filesystem have well-
defined and security-relevant meaning, right?
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.
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.
--
Stephen Smalley <sds(a)tycho.nsa.gov>
National Security Agency