close(2) not being audited?

close(2) not being audited?

[Todd, Charles]

[-- Attachment #1.1: Type: text/plain, Size: 1271 bytes --]

All,
I'm on an RHEL4u3 with Steve's preliminary 1.0.15 package (I built the
RPM) under x86_64 2.6.9-34-ELsmp.  I'm using the CAPP.rules sample
fileset to great success.  NISPOM 8-602 requires that CLOSE operations
on security-relevant objects be logged.  Well, I've got logging for OPEN
on security-relevant objects (with the watches) working VERY well
(yeah!!!).  The default CAPP.rules file had nothing about close(2), so
just to test it, I ran:
  auditctl -a entry,possible -S close
and then as a normal user typed: cat /etc/group (which is a
security-relevant object that I have permission to open, and thus
eventually close)
However, when I review the audit files, nothing is logged.  If I change
the "entry,possible" to "entry,always" then lots of stuff gets logged,
but not my actual opening of the /etc/group file.
  There is only one other thing that could be a configuration issue:
"auditctl -l |grep /etc/group" reveals an additional "perm=wa" field
that is set by the -p option in CAPP.rules, but even if root writes to
one of the watched files, close(2) is still not logged.
 
Do I have a configuration problem or is something deeper going on?
 
Thanks,
Charlie Todd 
Ball Aerospace & Technologies Corp.  
ctodd- at -ball.com 

 

[-- Attachment #1.2: Type: text/html, Size: 2672 bytes --]

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

Re: close(2) not being audited?

[Steve Grubb]

On Thursday 28 December 2006 16:58, Todd, Charles wrote:
> NISPOM 8-602 requires that CLOSE operations on security-relevant objects be
> logged.  Well, I've got logging for OPEN on security-relevant objects (with
> the watches) working VERY well (yeah!!!).  The default CAPP.rules file had
> nothing about close(2), 

CAPP says nothing about this syscall other than the ability to audit it. Which 
you can get with "auditctl -a entry,always -S close", which admittedly is 
overkill.

> so just to test it, I ran: 
>   auditctl -a entry,possible -S close
> and then as a normal user typed: cat /etc/group (which is a
> security-relevant object that I have permission to open, and thus
> eventually close)

I'd want to see the accompanying watch for that file.

> However, when I review the audit files, nothing is logged.  

Hmm.

> If I change the "entry,possible" to "entry,always" then lots of stuff gets
> logged, but not my actual opening of the /etc/group file.

This would log all close system calls - even socket closes.

>   There is only one other thing that could be a configuration issue:
> "auditctl -l |grep /etc/group" reveals an additional "perm=wa" field
> that is set by the -p option in CAPP.rules, but even if root writes to
> one of the watched files, close(2) is still not logged.

I think that open is called with either read and/or write flag set. This is 
how it picks up an event for open. However, close is neither read nor write.

> Do I have a configuration problem or is something deeper going on?

Probably something deeper. I'd say you should open a support request so that 
it gets fixed. 

I think we'd also want to verify this for the current upstream kernels to make 
sure kernel.org kernels havethis solved. FC6 is probably new enough to test 
for that purpose.

-Steve

Re: close(2) not being audited?

[Steve Grubb]

On Thursday 28 December 2006 16:58, Todd, Charles wrote:
> NISPOM 8-602 requires that CLOSE operations on security-relevant objects be
> logged.

Out of curiosity, what level of effort does the audit system need to go to? 
Would auditing the close syscall be sufficient? Does dups() need to be 
followed? What about descriptor inheritance? And passing descriptors between 
processes via af_unix?

-Steve

Re: close(2) not being audited?

[John D. Ramsdell]

> Out of curiosity, what level of effort does the audit system need to
> go to?  Would auditing the close syscall be sufficient? Does dups()
> need to be followed? What about descriptor inheritance? And passing
> descriptors between processes via af_unix?

Keeping track of the life cycle of file descriptors, though dups,
forks, and close on execs, is what Polgen's tracker does.  Well,
almost--it doesn't handle passing descriptors between processes via
af_unix, and it doesn't handle the System V IPC calls invoked through
ipc.  In short, once the audit parsing library is available, I'll use
it to feed the results of an ausearch to the tracker.  It's output may
be of use in analyzing logs, in addition to being an important
component in our policy generation tool.

John

RE: close(2) not being audited?

[Wieprecht, Karen M.]

Actually, the exact wording says:

"Successful and unsuccessful accesses to security-relevant objects and
directories"

It does not specify exactly how that should be collected,  but the
NISPOM does request that the audit record  include who tried to access
it, what they tried to access, the time and date of the access attempt,
what command they were trying to run (rm, chmod, etc.),  and if they
were successful or not.  What happens behind the scenes after the
operating system takes over the request may not be of as much interest
unless collecting that info helps to provide the above details to the
audit record. 

-Karen Wieprecht

-----Original Message-----
From: linux-audit-bounces@redhat.com
[mailto:linux-audit-bounces@redhat.com] On Behalf Of Steve Grubb
Sent: Friday, January 26, 2007 12:38 PM
To: linux-audit@redhat.com
Cc: Todd, Charles
Subject: Re: close(2) not being audited?

On Thursday 28 December 2006 16:58, Todd, Charles wrote:
> NISPOM 8-602 requires that CLOSE operations on security-relevant 
> objects be logged.

Out of curiosity, what level of effort does the audit system need to go
to? 
Would auditing the close syscall be sufficient? Does dups() need to be
followed? What about descriptor inheritance? And passing descriptors
between processes via af_unix?

-Steve

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: close(2) not being audited?

[Alexander Viro]

On Fri, Jan 26, 2007 at 03:14:10PM -0500, Wieprecht, Karen M. wrote:
> Actually, the exact wording says:
> 
> "Successful and unsuccessful accesses to security-relevant objects and
> directories"
> 
> It does not specify exactly how that should be collected,  but the
> NISPOM does request that the audit record  include who tried to access
> it, what they tried to access, the time and date of the access attempt,
> what command they were trying to run (rm, chmod, etc.),  and if they
> were successful or not.  What happens behind the scenes after the
> operating system takes over the request may not be of as much interest
> unless collecting that info helps to provide the above details to the
> audit record. 

Please, define "access".  Consider the following sequence:
	on April 1st:
	fd = open(foo, O_RDWR);
	p = mmap(..., fd, ...);
	close(fd);
	two days later: modify area pointed to by p
	a month later: munmap(p, ...);

What do you want in the log?  More specifically, _when_ do you want it?

Is that close() worth more than munmap()?  All file access will be done
at least a couple of days after it and file will remain open for more than
a month, despite successful call of close(2).

The main question here is what are those logs supposed to be useful for,
beside the CYA exercises.

Re: close(2) not being audited?

[Timothy R. Chavez]

On Fri, 26 Jan 2007 17:19:33 -0500
Alexander Viro <aviro@redhat.com> wrote:

> On Fri, Jan 26, 2007 at 03:14:10PM -0500, Wieprecht, Karen M. wrote:
> > Actually, the exact wording says:
> > 
> > "Successful and unsuccessful accesses to security-relevant objects and
> > directories"
> > 
> > It does not specify exactly how that should be collected,  but the
> > NISPOM does request that the audit record  include who tried to access
> > it, what they tried to access, the time and date of the access attempt,
> > what command they were trying to run (rm, chmod, etc.),  and if they
> > were successful or not.  What happens behind the scenes after the
> > operating system takes over the request may not be of as much interest
> > unless collecting that info helps to provide the above details to the
> > audit record. 
> 
> Please, define "access".  Consider the following sequence:
> 	on April 1st:
> 	fd = open(foo, O_RDWR);
> 	p = mmap(..., fd, ...);
> 	close(fd);
> 	two days later: modify area pointed to by p
> 	a month later: munmap(p, ...);
> 
> What do you want in the log?  More specifically, _when_ do you want it?

Write out a log when the last reference to the fd is put back... whether
that's from a close or an munmap.

-tim

Re: close(2) not being audited?

[Timothy R. Chavez]

On Fri, 26 Jan 2007 17:19:33 -0500
Alexander Viro <aviro@redhat.com> wrote:

> On Fri, Jan 26, 2007 at 03:14:10PM -0500, Wieprecht, Karen M. wrote:
> > Actually, the exact wording says:
> > 
> > "Successful and unsuccessful accesses to security-relevant objects and
> > directories"
> > 
> > It does not specify exactly how that should be collected,  but the
> > NISPOM does request that the audit record  include who tried to access
> > it, what they tried to access, the time and date of the access attempt,
> > what command they were trying to run (rm, chmod, etc.),  and if they
> > were successful or not.  What happens behind the scenes after the
> > operating system takes over the request may not be of as much interest
> > unless collecting that info helps to provide the above details to the
> > audit record. 
> 
> Please, define "access".  Consider the following sequence:
> 	on April 1st:
> 	fd = open(foo, O_RDWR);
> 	p = mmap(..., fd, ...);
> 	close(fd);
> 	two days later: modify area pointed to by p
> 	a month later: munmap(p, ...);
> 
> What do you want in the log?  More specifically, _when_ do you want it?

Write out a log when the last reference to the fd is put back... whether
that's from a close or an munmap.

-tim

Re: close(2) not being audited?

[Alexander Viro]

On Fri, Jan 26, 2007 at 05:01:12PM -0600, Timothy R. Chavez wrote:
> > Please, define "access".  Consider the following sequence:
> > 	on April 1st:
> > 	fd = open(foo, O_RDWR);
> > 	p = mmap(..., fd, ...);
> > 	close(fd);
> > 	two days later: modify area pointed to by p
> > 	a month later: munmap(p, ...);
> > 
> > What do you want in the log?  More specifically, _when_ do you want it?
> 
> Write out a log when the last reference to the fd is put back... whether
> that's from a close or an munmap.

Sigh...  One more time: there are two distinct classes of objects - opened
files and opened descriptors.  That's the point - by the time of munmap()
there is no file descriptor at all.  It's been gone for a month.

Descriptor getting closed != file getting closed.  If you are talking about
the last reference to opened file - OK.  But there won't necessary be
any descriptors refering to it.

Re: close(2) not being audited?

[Alexander Viro]

On Fri, Jan 26, 2007 at 05:01:12PM -0600, Timothy R. Chavez wrote:
> > What do you want in the log?  More specifically, _when_ do you want it?
> 
> Write out a log when the last reference to the fd is put back... whether
> that's from a close or an munmap.

BTW...  Consider the following: threads A and B share descriptor table.
Their stdin is a terminal.
Apr 1: thread A calls read(0, buf, 512);
Apr 2: thread B does close(0);
May 1: user hits enter

After Apr 2 we'll have descriptor 0 closed.  Thread A is still sitting in
read() and it couldn't care less about descriptors.  The file is still
opened, even though all descriptors are gone.

On May 1 read() in thread A finally completes.  Upon exit from read()
we give up a reference to file, so it finally gets closed.

IOW, you'll get "it's been closed by read(2)" in logs.  The same
may apply to any system call doing file IO.  So userland would better
not assume that something recognizable is doing that...

Re: close(2) not being audited?

[Timothy R. Chavez]

On Fri, 26 Jan 2007 18:20:51 -0500
Alexander Viro <aviro@redhat.com> wrote:

> On Fri, Jan 26, 2007 at 05:01:12PM -0600, Timothy R. Chavez wrote:
> > > Please, define "access".  Consider the following sequence:
> > > 	on April 1st:
> > > 	fd = open(foo, O_RDWR);
> > > 	p = mmap(..., fd, ...);
> > > 	close(fd);
> > > 	two days later: modify area pointed to by p
> > > 	a month later: munmap(p, ...);
> > > 
> > > What do you want in the log?  More specifically, _when_ do you want it?
> > 
> > Write out a log when the last reference to the fd is put back... whether
> > that's from a close or an munmap.
> 
> Sigh...  One more time: there are two distinct classes of objects - opened
> files and opened descriptors.  That's the point - by the time of munmap()
> there is no file descriptor at all.  It's been gone for a month.
> 
> Descriptor getting closed != file getting closed.  If you are talking about
> the last reference to opened file - OK.  But there won't necessary be
> any descriptors refering to it.

Yep, I was referring to last reference to opened file.

I'd hate to suggest adding a field to the file like "opened_as" which would
store the original fd it was assigned, but that would be enough to associate
the open() record and the final "close" record.

-tim

PS: Ugh, at this list for being write-protected :).

Re: close(2) not being audited?

[Timothy R. Chavez]

On Fri, 26 Jan 2007 18:29:10 -0500
Alexander Viro <aviro@redhat.com> wrote:

> On Fri, Jan 26, 2007 at 05:01:12PM -0600, Timothy R. Chavez wrote:
> > > What do you want in the log?  More specifically, _when_ do you want it?
> > 
> > Write out a log when the last reference to the fd is put back... whether
> > that's from a close or an munmap.
> 
> BTW...  Consider the following: threads A and B share descriptor table.
> Their stdin is a terminal.
> Apr 1: thread A calls read(0, buf, 512);
> Apr 2: thread B does close(0);
> May 1: user hits enter
> 
> After Apr 2 we'll have descriptor 0 closed.  Thread A is still sitting in
> read() and it couldn't care less about descriptors.  The file is still
> opened, even though all descriptors are gone.
> 
> On May 1 read() in thread A finally completes.  Upon exit from read()
> we give up a reference to file, so it finally gets closed.
> 
> IOW, you'll get "it's been closed by read(2)" in logs.  The same
> may apply to any system call doing file IO.  So userland would better
> not assume that something recognizable is doing that...

That seems perfectly reasonable to me.

-tim

Re: close(2) not being audited?

[James Antill]

[-- Attachment #1.1: Type: text/plain, Size: 787 bytes --]

On Fri, 2007-01-26 at 17:46 -0600, Timothy R. Chavez wrote:

> Yep, I was referring to last reference to opened file.
> 
> I'd hate to suggest adding a field to the file like "opened_as" which would
> store the original fd it was assigned, but that would be enough to associate
> the open() record and the final "close" record.


fd1 = open(...);
ptr1 = mmap(fd1, ...);
close(fd1);

fd2 = open(...);
assert(fd1 == fd2);
ptr2 = mmap(fd2, ...);
close(fd2);

munmap(ptr1, ...);
munmap(ptr2, ...);

...what should appear in the logs here? How are you going to tell which
fd each munmap() belongs to?
 Maybe you mean "log inode/device for the file" and not "original fd",
and then if/when you get confused it doesn't matter?

-- 
James Antill <jantill@redhat.com>

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

Re: close(2) not being audited?

[Timothy R. Chavez]

On Sun, 28 Jan 2007 16:40:56 -0500
James Antill <jantill@redhat.com> wrote:

> On Fri, 2007-01-26 at 17:46 -0600, Timothy R. Chavez wrote:
> 
> > Yep, I was referring to last reference to opened file.
> > 
> > I'd hate to suggest adding a field to the file like "opened_as" which would
> > store the original fd it was assigned, but that would be enough to associate
> > the open() record and the final "close" record.
> 
> 
> fd1 = open(...);
> ptr1 = mmap(fd1, ...);
> close(fd1);
> 
> fd2 = open(...);
> assert(fd1 == fd2);
> ptr2 = mmap(fd2, ...);
> close(fd2);
> 
> munmap(ptr1, ...);
> munmap(ptr2, ...);
> 
> ...what should appear in the logs here? How are you going to tell which
> fd each munmap() belongs to?
>  Maybe you mean "log inode/device for the file" and not "original fd",
> and then if/when you get confused it doesn't matter?
> 

Well yes, I was assuming you would have the additional context provided by other
fields in the record such as inode and device, but on second thought, I think you
are right that such information should be sufficient to tie the "close" record with
the open() record without needing to correlate an fd between the two (which, like
you suggest, would be ambiguous without the additional context, anyway).

-tim