[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Decoding arguments passed to system calls

On Tue, 2007-07-03 at 00:23 +0100, Matthew Booth wrote:
> On Tue, 2007-07-03 at 10:48 +1200, Darryl Dixon - Winterhouse Consulting
> wrote:
> > Hi Matt,
> > 
> > Thank you for your very thorough response. What you say about not being
> > able to audit 'write()' is worrying to me. The problem with auditing write
> > by inference from open(), is that one doesn't know *when* the file was
> > written, or even if it really ever was at all (eg, was data written
> > continuously from open() to close(), or only sporadically over the course
> > of hours or days?). Auditing for actual alterations is definitely
> > something that we need to be able to track. Assuming for a moment that we
> > have beefy enough hardware ( heh ), can the path be extracted from write()
> > as with your example for open() above? My assumption would have been that
> > CWD reflected only where the exe was launched from, and not necessarily
> > where the write()-en file was located...
> Well, you can audit write(). The question is whether you can handle the
> resulting data volume.
> read() and write() don't generate a PATH record. The only time at which
> a path is relevant is at the time the file is opened. Once the file is
> opened, it can have zero or more paths, which can all change without
> affecting the open file. An open file is genuinely divorced from its
> path.
> That said, it's *not* divorced from its filesystem, which I understand
> is what you're really looking for. Unfortunately that information
> doesn't appear to live on its own in the audit trail, and it's not
> available to filter on for these calls. This would leave you having to
> audit all read() and write() calls and filtering them in
> post-processing. I doubt this would be a practical solution.

Another option might be to audit based on SELinux type, if the files in
question can have a different type than the rest of the files.  A
SELinux audit message on write would generate an AVC_PATH record.

$ vi myaudit.te
policy_module(myaudit, 1.0)
require {
	attribute domain;
	type etc_t;
auditallow domain etc_t:file write;

$ make -f /usr/share/selinux/devel/Makefile myaudit.pp
$ su
# /usr/sbin/semodule -i myaudit.pp
# vi /etc/fstab

Audit log contains:
type=AVC msg=audit(1183463480.620:6351): avc:  granted  { write } for  pid=13773 comm="vi" name="fstab" dev=dm-0 ino=1280187 scontext=user_u:system_r:unconfined_t:s0 tcontext=user_u:object_r:etc_t:s0 tclass=file
type=SYSCALL msg=audit(1183463480.620:6351): arch=40000003 syscall=4 success=yes exit=767 a0=3 a1=9047510 a2=2ff a3=2ff items=0 ppid=13662 pid=13773 auid=4204 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts2 comm="vi" exe="/bin/vi" subj=user_u:system_r:unconfined_t:s0 key=(null)
type=AVC_PATH msg=audit(1183463480.620:6351):  path="/etc/fstab"

Stephen Smalley
National Security Agency

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]