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

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

[Robert Giles]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed, Size: 1399 bytes --]

Howdy folks - I'm running audit-1.2.2 with the latest audit-current git 
tree (lspp.b20)...

The filesystem auditing seems to be working fine for all files *except* 
the audit.log file.

For example, I do this:
auditctl -w /etc/shadow
auditctl -w /var/log/audit/audit.log

The audit daemon generates audit events for both successful and failed 
open() calls to /etc/shadow, but only records *successful* accesses to 
/var/log/audit/audit.log.

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).

*Successful* reads of /var/log/audit/audit.log (ie: as super-user) do 
indeed generate the appropriate audit event in audit.log ("success=yes").

Is this the way the audit daemon is supposed to work?  (some kind of race 
condition if the audit daemon fully audits its own audit trail?)

(this question may seem unusual, but we're trying to audit "unsuccessful 
attempts to access security-relevant objects"...  the audit trail itself 
constitutes a "security-relevant object").

Thanks again!

-----------------------------------------------------------
Robert Giles                     Group System Administrator
SPD/ARL:UT              (512) 835-3077 · Fax (512) 490-4244

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

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

[Amy Griffis]

Hi Robert,

Robert Giles wrote:     [Tue Jun 27 2006, 04:43:10PM EDT]
> Howdy folks - I'm running audit-1.2.2 with the latest audit-current git 
> tree (lspp.b20)...
> 
> The filesystem auditing seems to be working fine for all files *except* 
> the audit.log file.
> 
> For example, I do this:
> auditctl -w /etc/shadow
> auditctl -w /var/log/audit/audit.log
> 
> The audit daemon generates audit events for both successful and failed 
> open() calls to /etc/shadow, but only records *successful* accesses to 
> /var/log/audit/audit.log.
> 
> 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.

> *Successful* reads of /var/log/audit/audit.log (ie: as super-user) do 
> indeed generate the appropriate audit event in audit.log ("success=yes").
> 
> Is this the way the audit daemon is supposed to work?  (some kind of race 
> condition if the audit daemon fully audits its own audit trail?)
> 
> (this question may seem unusual, but we're trying to audit "unsuccessful 
> attempts to access security-relevant objects"...  the audit trail itself 
> constitutes a "security-relevant object").
> 
> Thanks again!

Hope this helps.

Amy

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

[Steve Grubb]

On Tuesday 27 June 2006 17:15, Amy Griffis wrote:
> If you would like to see a record in this case, you must add a watch
> for /var/log/audit.

I don't see a record watching this either.

-Steve

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

[Timothy R. Chavez]

On Tue, 2006-06-27 at 17:21 -0400, Steve Grubb wrote:
> On Tuesday 27 June 2006 17:15, Amy Griffis wrote:
> > If you would like to see a record in this case, you must add a watch
> > for /var/log/audit.
> 
> I don't see a record watching this either.
> 
> -Steve

Maybe because you're executing in the system-call attempting the access
of audit.log and it's in this context the permissions to do so are
checked.  Been awhile, but looking at fs/open.c:do_sys_open, should
there be an fsnotify_open() hook in the error path as well?

-tim

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

[Amy Griffis]

Steve Grubb wrote:     [Tue Jun 27 2006, 05:21:05PM EDT]
> On Tuesday 27 June 2006 17:15, Amy Griffis wrote:
> > If you would like to see a record in this case, you must add a watch
> > for /var/log/audit.
> 
> I don't see a record watching this either.

Hmmm, you're right.

In this implementation, a directory lookup isn't considered an access
of the object, but a directory listing is.

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

[Linda Knippers]

Steve Grubb wrote:
> On Tuesday 27 June 2006 17:15, Amy Griffis wrote:
> 
>>If you would like to see a record in this case, you must add a watch
>>for /var/log/audit.
> 
> 
> I don't see a record watching this either.

I think we're missing the directory lookup syscall(s) on watches
right now.

-- ljk

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

[Alexander Viro]

On Tue, Jun 27, 2006 at 05:36:43PM -0400, Linda Knippers wrote:
> Steve Grubb wrote:
> > On Tuesday 27 June 2006 17:15, Amy Griffis wrote:
> > 
> >>If you would like to see a record in this case, you must add a watch
> >>for /var/log/audit.
> > 
> > 
> > I don't see a record watching this either.
> 
> I think we're missing the directory lookup syscall(s) on watches
> right now.

Careful - that's one hell of a hot path.  Note that we'll get many of
those for each syscall that does pathname resolution; moreover, when
we hit dcache, we should be careful about blocking.

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

[Linda Knippers]

Alexander Viro wrote:
> On Tue, Jun 27, 2006 at 05:36:43PM -0400, Linda Knippers wrote:
> 
>>Steve Grubb wrote:
>>
>>>On Tuesday 27 June 2006 17:15, Amy Griffis wrote:
>>>
>>>
>>>>If you would like to see a record in this case, you must add a watch
>>>>for /var/log/audit.
>>>
>>>
>>>I don't see a record watching this either.
>>
>>I think we're missing the directory lookup syscall(s) on watches
>>right now.
> 
> 
> Careful - that's one hell of a hot path.  Note that we'll get many of
> those for each syscall that does pathname resolution; moreover, when
> we hit dcache, we should be careful about blocking.

Maybe its not actually the lookup we need.  If I do this on RHEL4
I get an audit record for an open failure on /var/log/audit.
With the .34 lspp kernel and the 1.2.2 audit tools, I don't get
a record for a failed open, even though open seems to be registered
with the watch.

> [root@cert-e2 kernel]# /sbin/auditctl -l
> LIST_RULES: exit,always watch=/var/log/audit/audit.log (0x18) syscall=open,truncate,ftruncate,rename,mkdir,rmdir,creat,link,unlink,symlink,chmod,fchmod,chown,fchown,lchown
> LIST_RULES: exit,always watch=/var/log/audit (0xe) syscall=open,truncate,ftruncate,rename,mkdir,rmdir,creat,link,unlink,symlink,chmod,fchmod,chown,fchown,lchown

-- ljk

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

[Amy Griffis]

Timothy R. Chavez wrote:     [Tue Jun 27 2006, 05:32:46PM EDT]
> Maybe because you're executing in the system-call attempting the access
> of audit.log and it's in this context the permissions to do so are
> checked.  Been awhile, but looking at fs/open.c:do_sys_open, should
> there be an fsnotify_open() hook in the error path as well?

That wouldn't help.  If do_filp_open() returns an error, we don't have
an inode for the filename the user wanted to open.  So we don't have
any additional information to give the hook other than what audit has
already collected.

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

[Klaus Weidner]

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

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

[LC Bruzenak]

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

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

[Robert Giles]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed, Size: 671 bytes --]

On Thu, 29 Jun 2006, Klaus Weidner wrote:
> 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.

Thanks for the suggestion, didn't even think to try that - the failed 
attempts are recorded now and I don't think we really lose anything from 
our CSA's perspective in terms of security.

Thanks!

-----------------------------------------------------------
Robert Giles                     Group System Administrator
SPD/ARL:UT              (512) 835-3077 · Fax (512) 490-4244

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]