From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Booth Subject: Re: Decoding arguments passed to system calls Date: Mon, 02 Jul 2007 23:27:36 +0100 Message-ID: <1183415256.4534.50.camel@localhost.localdomain> References: <52930.65.99.233.211.1183412786.squirrel@pythonhacker.is-a-geek.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1492172768==" Return-path: Received: from [10.181.247.223] (sebastian-int.corp.redhat.com [172.16.52.221]) by pobox.fab.redhat.com (8.13.1/8.13.1) with ESMTP id l62MRZ3R028069 for ; Mon, 2 Jul 2007 18:27:36 -0400 In-Reply-To: <52930.65.99.233.211.1183412786.squirrel@pythonhacker.is-a-geek.net> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: linux-audit@redhat.com List-Id: linux-audit@redhat.com --===============1492172768== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-lrnra9DFOTMcASs3LBz0" --=-lrnra9DFOTMcASs3LBz0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2007-07-03 at 09:46 +1200, Darryl Dixon - Winterhouse Consulting wrote: > Scenario: > A very large filesystem with potentially millions of files in an ad-hoc, > unordered directory structure. The requirement is to be able to audit any > action on any file in this filesystem (moves, adds, changes, deletes, > etc). In auditfs terms, there is a requirement to have a 'watch' on every > single file (millions of files), and on any new file that is added. >=20 > Hypothetical solution: > Clearly, scanning the filesystem with `find` and adding calling auditctl > with the appropriate arguments to generate a watch on every singly file i= s > totally infeasible (find takes almost an hour to run, and in the meantime > stuff is potentially changing...). Instead, I envision it would make > better sense to simply audit every call to write(), open(), rename(), etc= , > and then filter backwards from there with ausearch and a filter based on > the path. On Solaris with BSM, this is possible. My problem is that this > doesn't seem possible with the Linux Audit subsystem, as the arguments to > the system calls are not decoded (eg, the audit records for write() > include only an opaque filehandle and pointer to the written data, etc). This is entirely feasible, with the exception that you probably don't want to audit write() calls generally. That would be a truly insane amount of traffic. A highly effective heuristic is to look at the arguments to the open() system call. If the file was opened for write (a1 | 1 =3D=3D 1 || a1 | 2 =3D=3D 2), then assume that the file was altered= . Take the following example: type=3DSYSCALL msg=3Daudit(1183414428.656:2779): arch=3D40000003 syscall=3D= 5 success=3Dyes exit=3D3 a0=3D91d4088 a1=3D8000 a2=3D0 a3=3D8000 items =3D1 ppid=3D16166 pid=3D16270 auid=3D500 uid=3D0 gid=3D0 euid=3D0 suid=3D0 = fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3Dpts2 comm=3D"vi" exe=3D"/bin/vi" sub j=3Duser_u:system_r:unconfined_t:s0 key=3D(null) type=3DCWD msg=3Daudit(1183414428.656:2779): cwd=3D"/root" type=3DPATH msg=3Daudit(1183414428.656:2779): item=3D0 name=3D"install.log" inode=3D720898 dev=3Dfd:00 mode=3D0100644 ouid=3D0 ogid=3D0 rdev=3D00 :00 obj=3Droot:object_r:user_home_t:s0 You can tell the filesystem from the dev field of the PATH record: [mbooth@mbooth ~]$ ls -l /dev/mapper/vg_local-root=20 brw-rw---- 1 root disk 253, 0 Jul 2 19:53 /dev/mapper/vg_local-root 253, 0 =3D=3D fd:00 You can tell it was opened for read, because the last 2 bits of a1 in the SYSCALL record are 00. I guess doing this automatically is the crux of your question. For ease of path handling, you're also going to want a solution to the absolute path question. As an aside, adding the rules you mention above with a standard audit configuration is likely to kill your system as soon as you put load on it. The principal reason for this is the frequent flushing of the log file. If integrity of the audit trail isn't that important, tone down the flushing on the audit log and you'll find that it can sustain pretty intense throughput. If you need both integrity and performance, the best solution I've come up with is to send audit records to a remote host via syslog in real time over a network which we trust not to drop packets, and not write anything to disk. Matt --=20 Matthew Booth, RHCA, RHCSS Red Hat, Global Professional Services M: +44 (0)7977 267231 GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 --=-lrnra9DFOTMcASs3LBz0 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBGiXvYNEHqGdM8NJARAto8AJ4m6qsvSi9JeDIc3pTncaZdKu2vLACfaH0F t7BVBKID789AgQXvQ+vRatA= =j1Jj -----END PGP SIGNATURE----- --=-lrnra9DFOTMcASs3LBz0-- --===============1492172768== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============1492172768==--