File watching

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

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 				              [email protected]
Applied Research Laboratories                 The University of Texas at Austin
GPG Key: 71767586 at keyserver pgp.mit.edu, http://www.ganymeta.org/workkey.gpg

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

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

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

                ^^^^

Because when root passes O_RDONLY, the kernel doesn't second-guess and open it read-right....

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

Hi Steve,

Steve wrote: [Tue Jun 20 2006, 01:53:14PM EDT]

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

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

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
[email protected]