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 [EMAIL PROTECTED] -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
