Logging failed open() calls on /var/log/audit/audit.log
LC Bruzenak
lenny at bruzenak.com
Thu Jun 29 18:04:38 UTC 2006
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 at bruzenak.com
More information about the Linux-audit
mailing list