File watching

File watching

[Steve]

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

Re: File watching

[Jonathan Abbey]

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

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@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

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

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

Re: File watching

[Timothy R. Chavez]

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@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit

Re: File watching

[Steve]

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

Re: File watching

[Timothy R. Chavez]

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

Re: File watching

[Steve]

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

Re: File watching

[Michael C Thompson]

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

Re: File watching

[Steve]

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

Re: File watching

[Valdis.Kletnieks]

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

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


[-- Attachment #1.2: Type: application/pgp-signature, Size: 226 bytes --]

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

Re: File watching

[Michael C Thompson]

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

Re: File watching

[Amy Griffis]

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

Re: File watching

[Steve Grubb]

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

Re: File watching

[Casey Schaufler]

--- Amy Griffis <amy.griffis@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@schaufler-ca.com