12:53 p.m.
I have audit set to monitor all system calls for a file. I see some
system calls for it, but I think some may be missing... If I create the
file using vi, I only see an open followed by a stat64. Shouldn't there
be a write of some type? stat and open can't write to a file, can they?
Thanks,
Steve
1:10 p.m.
On Tue, Jun 20, 2006 at 01:53:14PM -0400, Steve wrote:
| I have audit set to monitor all system calls for a file. I see some
| system calls for it, but I think some may be missing... If I create the
| file using vi, I only see an open followed by a stat64. Shouldn't there
| be a write of some type? stat and open can't write to a file, can they?
Generally (and I'm speaking from my experience with Snare, here), one
does not attempt to audit the actual read and write syscalls. Mainly
because there are far, far too many of them, and you need their
performance to be as high as conceivably possible.
Instead, you audit the file open, and make a note of whether the file
was opened read-only, or for read/write. If it was opened for
read/write, one presumes that it was written to.
Jon
| Thanks,
| Steve
--
-------------------------------------------------------------------------------
Jonathan Abbey jonabbey(a)arlut.utexas.edu
Applied Research Laboratories The University of Texas at Austin
GPG Key: 71767586 at keyserver pgp.mit.edu, http://www.ganymeta.org/workkey.gpg
1:22 p.m.
On Tue, 2006-06-20 at 13:10 -0500, Jonathan Abbey wrote:
On Tue, Jun 20, 2006 at 01:53:14PM -0400, Steve wrote:
| I have audit set to monitor all system calls for a file. I see some
| system calls for it, but I think some may be missing... If I create the
| file using vi, I only see an open followed by a stat64. Shouldn't there
| be a write of some type? stat and open can't write to a file, can they?
Generally (and I'm speaking from my experience with Snare, here), one
does not attempt to audit the actual read and write syscalls. Mainly
because there are far, far too many of them, and you need their
performance to be as high as conceivably possible.
I think it has more to do with security relevancy than anything. Audit
development has primarily been driven by CAPP and LSPP requirements for
the last couple of years.
-tim
Instead, you audit the file open, and make a note of whether the file
was opened read-only, or for read/write. If it was opened for
read/write, one presumes that it was written to.
Jon
| Thanks,
| Steve
--
Linux-audit mailing list
Linux-audit(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
1:32 p.m.
> Instead, you audit the file open, and make a note of whether the
file
> was opened read-only, or for read/write. If it was opened for
> read/write, one presumes that it was written to.
Is it possible to tell if a file was opened read/write or read-only from
the events generated by audit?
Thanks,
Steve
1:40 p.m.
On Tue, 2006-06-20 at 14:32 -0400, Steve wrote:
>> Instead, you audit the file open, and make a note of whether
the file
>> was opened read-only, or for read/write. If it was opened for
>> read/write, one presumes that it was written to.
Is it possible to tell if a file was opened read/write or read-only from
the events generated by audit?
Thanks,
Steve
Hi Steve,
You should be able to ascertain this information from the open() audit
record. I thought at one time the flags were recorded in the record,
but perhaps no longer (or maybe my memory does not serve me well :)).
The record does record syscall arguments, however, so perhaps you could
analyze a1= (I believe this is the argument that passes flags), and
figure out with what flags open() was called with. Admittedly, I'm not
so knowledgeable these days as to what is actually being reported in the
audit log.
-tim
1:52 p.m.
> Is it possible to tell if a file was opened read/write or
read-only from
> the events generated by audit?
The record does record syscall arguments, however, so perhaps you
could
analyze a1= (I believe this is the argument that passes flags), and
figure out with what flags open() was called with.
I performed an open on a file twice, the first is when the user had
read/write privileges to the file and in the second the user only has
read permissions. These were the a# values from the events, respectively:
a0=bfe6ac25 a1=8000 a2=0 a3=8000
a0=bfd25b55 a1=8000 a2=0 a3=8000
I'm not sure how to analyze that...
1:55 p.m.
Steve wrote:
>> Is it possible to tell if a file was opened read/write or
read-only
>> from the events generated by audit?
> The record does record syscall arguments, however, so perhaps you could
> analyze a1= (I believe this is the argument that passes flags), and
> figure out with what flags open() was called with.
I performed an open on a file twice, the first is when the user had
read/write privileges to the file and in the second the user only has
read permissions. These were the a# values from the events, respectively:
a0=bfe6ac25 a1=8000 a2=0 a3=8000
a0=bfd25b55 a1=8000 a2=0 a3=8000
I'm not sure how to analyze that...
In both cases, a1 (the flags) is O_RDONLY (000 octal, 0x0 hex) and
O_LARGEFILE (0100000 octal, 0x8000 hex).
So you were opened as read-only. You can't determine the level of access
the user has from the above, although you should be able to infer some
information about it form the entire record.
Mike
2:08 p.m.
Michael C Thompson wrote:
Steve wrote:
>>> Is it possible to tell if a file was opened read/write or read-only
>>> from the events generated by audit?
>
>> The record does record syscall arguments, however, so perhaps you could
>> analyze a1= (I believe this is the argument that passes flags), and
>> figure out with what flags open() was called with.
>
> I performed an open on a file twice, the first is when the user had
> read/write privileges to the file and in the second the user only has
> read permissions. These were the a# values from the events,
> respectively:
>
> a0=bfe6ac25 a1=8000 a2=0 a3=8000
>
> a0=bfd25b55 a1=8000 a2=0 a3=8000
>
> I'm not sure how to analyze that...
In both cases, a1 (the flags) is O_RDONLY (000 octal, 0x0 hex) and
O_LARGEFILE (0100000 octal, 0x8000 hex).
So you were opened as read-only. You can't determine the level of access
the user has from the above, although you should be able to infer some
information about it form the entire record.
Mike
The file is owned by root and the group for the file is root. The
permissions are 664.
Here is the whole record for root accessing the file
audit(1150830257.233:250): arch=40000003 syscall=5 success=yes exit=3
a0=9a62398 a1=8000 a2=0 a3=8000 items=1 ppid=23750 pid=25063 auid=500
uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1
comm="vi" exe="/bin/vi" subj=user_u:system_r:unconfined_t:s0
cwd="/home/m6x/src/iitds/sensor/plugins" item=0 name="/tmp/test.c"
inode=5358299 dev=03:02 mode=0100664 ouid=0 ogid=0 rdev=00:00
obj=user_u:object_r:tmp_t:s0
and for the normal user:
audit(1150830316.688:251): arch=40000003 syscall=5 success=yes exit=3
a0=8669560 a1=8000 a2=0 a3=8000 items=1 ppid=24750 pid=25069 auid=500
uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500
tty=pts3 comm="vim" exe="/usr/bin/vim"
subj=user_u:system_r:unconfined_t:s0 cwd="/home/m6x" item=0
name="/tmp/test.c" inode=5358299 dev=03:02 mode=0100664 ouid=0 ogid=0
rdev=00:00 obj=user_u:object_r:tmp_t:s0
I am not sure why it opens the file as read-only when root opens it...
Steve
2:56 p.m.
On Tue, 20 Jun 2006 15:08:53 EDT, Steve said:
Here is the whole record for root accessing the file
audit(1150830257.233:250): arch=40000003 syscall=5 success=yes exit=3
a0=9a62398 a1=8000
^^^^
I am not sure why it opens the file as read-only when root opens it...
Because when root passes O_RDONLY, the kernel doesn't second-guess and open
it read-right....
1:52 p.m.
Timothy R. Chavez wrote:
On Tue, 2006-06-20 at 14:32 -0400, Steve wrote:
>>> Instead, you audit the file open, and make a note of whether the file
>>> was opened read-only, or for read/write. If it was opened for
>>> read/write, one presumes that it was written to.
> Is it possible to tell if a file was opened read/write or read-only from
> the events generated by audit?
>
> Thanks,
> Steve
Hi Steve,
You should be able to ascertain this information from the open() audit
record. I thought at one time the flags were recorded in the record,
but perhaps no longer (or maybe my memory does not serve me well :)).
The record does record syscall arguments, however, so perhaps you could
analyze a1= (I believe this is the argument that passes flags), and
figure out with what flags open() was called with. Admittedly, I'm not
so knowledgeable these days as to what is actually being reported in the
audit log.
Tim,
You are correct, the associated meaning for a1 with the open syscall is
flags [ http://www.linux-m32r.org/lxr/http/source/fs/open.c#L1100 ].
In the following example open() syscall record, you can see a1 is 0x8000.
type=SYSCALL msg=audit(1150567434.940:1386): arch=40000003 syscall=5
success=yes exit=3 a0=93bd6e0 a1=8241 a2=1b6 a3=8241 items=2 ppid=2106
pid=2108 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
tty=pts1 comm="bash" exe="/bin/bash"
subj=root:staff_r:staff_t:s0-s15:c0.c255
a0 -- pointer, not useful
s1 -- the flags used for creation, in this case 0x8241 -> O_WRONLY |
O_CREAT | O_TRUNC | O_LARGEFILE
a2 -- the mode, in this case 0x1b6 -> 0666
http://www.linux-m32r.org/lxr/http/source/include/asm-generic/fcntl.h#L7
Can you guess what simple shell command I used to get this log? :P
Thanks,
Mike
3:30 p.m.
Hi Steve,
Steve wrote: [Tue Jun 20 2006, 01:53:14PM EDT]
I have audit set to monitor all system calls for a file. I see some
system calls for it, but I think some may be missing... If I create the
file using vi, I only see an open followed by a stat64. Shouldn't there
be a write of some type?
You don't see a record for write because write operates on an fd
rather than a pathname. The audit hooks that collect the information
used to match the 'inode' and 'path' filter fields are typically only
called when the syscall args specify a pathname.
The exception is the fchmod, fchown, fsetxattr and fremovexattr
syscalls. We added extra hooks there to satisfy CAPP requirements.
In order to support filtering by 'inode' or 'path' for read/write
calls, we could add audit_inode() hooks like we did for the f*
syscalls. But as Jonathan mentioned, most people don't want to audit
individual reads and writes, so no one has pursued adding that
capability.
With the current behavior, your only option is to audit all opens for
the file and examine the a1 field in the resulting records.
It would be nice if it were possible to further filter the open calls,
by allowing the rule to specify certain flags like O_CREAT, O_RDONLY,
O_WRONLY or O_RDWR. That could do quite a bit to eliminate
unwanted log data.
What do others think, should we consider adding somthing like this?
Amy
3:41 p.m.
On Tuesday 20 June 2006 16:30, Amy Griffis wrote:
It would be nice if it were possible to further filter the open
calls,
by allowing the rule to specify certain flags like O_CREAT, O_RDONLY,
O_WRONLY or O_RDWR. That could do quite a bit to eliminate
unwanted log data.
What do others think, should we consider adding somthing like this?
Yes, this is what the "rwex" flags to -p of auditctl allowed us to do. But we
also need to have a perm field that makes it easy to see what the requested
perm was.
-Steve
4:06 p.m.
--- Amy Griffis <amy.griffis(a)hp.com> wrote:
It would be nice if it were possible to further
filter the open calls,
by allowing the rule to specify certain flags like
O_CREAT, O_RDONLY,
O_WRONLY or O_RDWR. That could do quite a bit to
eliminate
unwanted log data.
What do others think, should we consider adding
somthing like this?
The LSPP project may need to pipe in at some
point, depending on how they decide(d) to
address tranquility, especially on devices
that may be "allocated" by users.
In the UNIX B1/LSPP evaluations we found it
easier to provide the capability of auditing
file descriptor operations (read, write, seek,
fcheverything, ...) than to prove that they
weren't necessary. It's easy to win the
arguement that it's ok to write to a file
with mode 0 if you opened it when it was 666.
That arguement is much harder if the file
was TopSecret and is now Unclassified.
Casey Schaufler
casey(a)schaufler-ca.com
6768
days inactive
6768
days old
linux-audit@lists.linux-audit.osci.io
12 comments
8 participants
participants (8)
-
Amy Griffis -
Casey Schaufler -
Jonathan Abbey -
Michael C Thompson -
Steve -
Steve Grubb -
Timothy R. Chavez -
Valdis.Kletnieks＠vt.edu