3:58 p.m.
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
8:36 a.m.
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
11:37 a.m.
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
12:03 p.m.
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
2:14 p.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(a)redhat.com
[mailto:linux-audit-bounces@redhat.com] On Behalf Of Steve Grubb
Sent: Friday, January 26, 2007 12:38 PM
To: linux-audit(a)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(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
4:19 p.m.
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.
5 p.m.
On Fri, 26 Jan 2007 17:19:33 -0500
Alexander Viro <aviro(a)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
5:01 p.m.
On Fri, 26 Jan 2007 17:19:33 -0500
Alexander Viro <aviro(a)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
5:20 p.m.
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.
5:46 p.m.
On Fri, 26 Jan 2007 18:20:51 -0500
Alexander Viro <aviro(a)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 :).
3:40 p.m.
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(a)redhat.com>
2:19 p.m.
On Sun, 28 Jan 2007 16:40:56 -0500
James Antill <jantill(a)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
5:29 p.m.
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...
6:03 p.m.
On Fri, 26 Jan 2007 18:29:10 -0500
Alexander Viro <aviro(a)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
6538
days inactive
6568
days old
linux-audit@lists.linux-audit.osci.io
13 comments
9 participants
participants (9)
-
Alexander Viro -
James Antill -
John D. Ramsdell -
Steve Grubb -
Timothy R. Chavez -
Timothy R. Chavez -
Timothy R. Chavez -
Todd, Charles -
Wieprecht, Karen M.