Re: Logging failed open() calls on /var/log/audit/audit.log

[LC Bruzenak <lenny@bruzenak.com>]

On Thu, 2006-06-29 at 11:34 -0500, Klaus Weidner wrote:
> On Tue, Jun 27, 2006 at 05:15:53PM -0400, Amy Griffis wrote:
> > Robert Giles wrote:     [Tue Jun 27 2006, 04:43:10PM EDT]
> > > So if I attempt to access /etc/shadow as a regular user, a "success=no" 
> > > audit event is generated to indicate read failure - but if a regular user 
> > > attempts to read /var/log/audit/audit.log, nothing happens (no audit event 
> > > whatsoever is created).
> > 
> > This is because the regular doesn't have permissions to read
> > /var/log/audit.  Since the path didn't fully resolve to
> > /var/log/audit/audit.log, the user didn't actually fail to access
> > audit.log, they failed to access /var/log/audit.
> > 
> > If you would like to see a record in this case, you must add a watch
> > for /var/log/audit.
> 
> CAPP etc. require audit records for unsuccessful attempts to access
> objects, but we've generally used the interpretation that there is no
> access attempt to the object if a containing directory already rejects
> the directory traversal before getting to the object. It's not ideal but
> it's the best fit to the way the path access works.
> 
> If you really insist on the audit records, you could weaken the
> restrictions on the /var/log/audit/ directory (for example 711
> permissions) so that it doesn't reject the traversal. The audit files are
> still protected of course.
> 
> -Klaus


Klaus,

What you are saying is true, however I would caution against allowing
the traversal because I think my accreditors would argue that it would
open a covert channel potential.

Obviously there would need to be a participating high-side or privileged
signaler, but at least in our case I believe we can live with the
directory rejection rather than the file itself.

In short, I agree with your interpretation.

LCB.

-- 
LC Bruzenak
lenny@bruzenak.com