Absolute path names in PATH records

Absolute path names in PATH records

[Matthew Booth]

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

I've hit a hurdle trying to do some post processing on audit output
because PATH records contain paths relative to the CWD, rather than the
absolute path. How much effort would likely be involved in making sure
these paths were always absolute?

Thanks,

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

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

Re: Absolute path names in PATH records

[Valdis.Kletnieks]

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

On Mon, 02 Jul 2007 20:44:55 BST, Matthew Booth said:

> I've hit a hurdle trying to do some post processing on audit output
> because PATH records contain paths relative to the CWD, rather than the
> absolute path. How much effort would likely be involved in making sure
> these paths were always absolute?

Probably quite a bit, especially if they traverse symlinks and the like.
Additionally, you'd need to track *current* state of $CWD, as the absolute
path will change each time a chdir() happens, or if somebody does something
like 'mv . ../../foo'.  Particularly evil to track:

cd foo/bar/baz
./myprog &
cd ../
mv baz ..

Where's myprog's ../../bin pointing now?  And how would your post processor
know that happened?

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

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

Re: Absolute path names in PATH records

[Matthew Booth]

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

On Mon, 2007-07-02 at 16:31 -0400, Valdis.Kletnieks@vt.edu wrote:
> Probably quite a bit, especially if they traverse symlinks and the like.
> Additionally, you'd need to track *current* state of $CWD, as the absolute
> path will change each time a chdir() happens, or if somebody does something
> like 'mv . ../../foo'.  Particularly evil to track:
> 
> cd foo/bar/baz
> ./myprog &
> cd ../
> mv baz ..
> 
> Where's myprog's ../../bin pointing now?  And how would your post processor
> know that happened?

I don't think tracking CWD is an issue as it's already right there in
the same audit event as the PATH record. The question is one of
combining data that's already present in a manner which is easier to
process. E.g.:

type=CWD msg=audit(1183402887.758:2083):  cwd="/root"
type=PATH msg=audit(1183402887.758:2083): item=0 name="/etc/ld.so.cache"
inode=2362196 dev=fd:00 mode=0100644 ouid=0 ogid=0 
rdev=00:00 obj=system_u:object_r:ld_so_cache_t:s0

In this case, /etc/ld.so.cache is already absolute, but there's no
requirement for it to be.

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

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

Re: Absolute path names in PATH records

[John Dennis]

On Mon, 2007-07-02 at 20:44 +0100, Matthew Booth wrote:
> I've hit a hurdle trying to do some post processing on audit output
> because PATH records contain paths relative to the CWD, rather than the
> absolute path. How much effort would likely be involved in making sure
> these paths were always absolute?

There has been a lot of work in this area to improve the reporting of
path information.

First I want to call your attention to the fact audit information is
emitted as independent records comprising a single audit event. The best
way to think of a record is that it is a single audit message and/or a
single line in a log file. If you are only looking at individual records
instead of all the records constituting an event you may be missing
information. For instance the path information is emitted in a separate
record. The audit parsing library (auparse) can reassemble independent
records into a single event (but currently only if the records occur
sequentially, non-sequential record assembly is a future feature).

The ability of the kernel to emit audit records with path information
has been evolving in different kernel versions. I'm sorry but I don't
have detailed version information on some of this. The AUDIT_AVC_PATH
record was added to give complete path information in conjunction with
an AUDIT_AVC record (i.e. these two records are members of a single
audit event). However in RHEL 5.1, kernel 2.6.22 the AUDIT_AVC_PATH
record is going away and the path instead will be in the avc record.

I'm not 100% positive, but I believe the work done to support
AUDIT_AVC_PATH by capturing path information prior to sys call
transition where only the inode is passed to the kernel will now result
in complete path information in other audit records as well, perhaps
Steve Grubb can give precise information on this.

Bottom line: It is recognized better path information is needed,
different audit/kernel versions have different support so it's a version
sensitive issue, and you must parse audit information as complete events
and not individual records.

-- 
John Dennis <jdennis@redhat.com>

Re: Absolute path names in PATH records

[Matthew Booth]

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

On Mon, 2007-07-02 at 16:43 -0400, John Dennis wrote:
> The audit parsing library (auparse) can reassemble independent
> records into a single event (but currently only if the records occur
> sequentially, non-sequential record assembly is a future feature).

I'm evaluating a third party product (RSA's enVision) for handling large
volumes of audit data from large numbers of hosts. I'm delivering audit
records to it from a custom auditd which does little other than wrap the
records it receives as syslog and sending it in a UDP packet to the
collector. This is for performance reasons as we're generating a lot of
audit data. Post-processing with auparse would require either doing this
inline, on-node, which I don't think would be feasible because of
performance, or running it on the enVision appliance, which definitely
isn't feasible as it runs Windows ;) enVision can plug things back
together, but again it's limited in what it can do in-line for
performance reasons. It would be easiest all-round if we got the
information pre-digested.

> The ability of the kernel to emit audit records with path information
> has been evolving in different kernel versions. I'm sorry but I don't
> have detailed version information on some of this. The AUDIT_AVC_PATH
> record was added to give complete path information in conjunction with
> an AUDIT_AVC record (i.e. these two records are members of a single
> audit event). However in RHEL 5.1, kernel 2.6.22 the AUDIT_AVC_PATH
> record is going away and the path instead will be in the avc record.
> 
> I'm not 100% positive, but I believe the work done to support
> AUDIT_AVC_PATH by capturing path information prior to sys call
> transition where only the inode is passed to the kernel will now result
> in complete path information in other audit records as well, perhaps
> Steve Grubb can give precise information on this.

Steve? I'm using RHEL 4.5, btw.

Thanks,

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

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

Re: Absolute path names in PATH records

[John Dennis]

On Mon, 2007-07-02 at 22:02 +0100, Matthew Booth wrote:
> On Mon, 2007-07-02 at 16:43 -0400, John Dennis wrote:
> > The audit parsing library (auparse) can reassemble independent
> > records into a single event (but currently only if the records occur
> > sequentially, non-sequential record assembly is a future feature).
> 
> I'm evaluating a third party product (RSA's enVision) for handling large
> volumes of audit data from large numbers of hosts. I'm delivering audit
> records to it from a custom auditd which does little other than wrap the
> records it receives as syslog and sending it in a UDP packet to the
> collector. This is for performance reasons as we're generating a lot of
> audit data. Post-processing with auparse would require either doing this
> inline, on-node, which I don't think would be feasible because of
> performance, or running it on the enVision appliance, which definitely
> isn't feasible as it runs Windows ;) enVision can plug things back
> together, but again it's limited in what it can do in-line for
> performance reasons. It would be easiest all-round if we got the
> information pre-digested.

A few quick points:

enVision can only reassemble records into event if you are transmitting
the record header information, are you? If so and enVision can properly
interpret the header and coalesce matching headers you're all set.

There is a lot of planned work surrounding aggregate auditing from
multiple hosts, perhaps not relevant to the current evaluation of
enVision, but be aware this technology area is in high churn.

For example the current audit system now allows for interested third
parties to monitor audit information, no need for custom audit daemons,
there is a well defined framework for monitoring.
-- 
John Dennis <jdennis@redhat.com>

Re: Absolute path names in PATH records

[Steve Grubb]

On Monday 02 July 2007 04:43:47 pm John Dennis wrote:
> I'm not 100% positive, but I believe the work done to support
> AUDIT_AVC_PATH by capturing path information prior to sys call
> transition where only the inode is passed to the kernel will now result
> in complete path information in other audit records as well, perhaps
> Steve Grubb can give precise information on this.

Not to my knowledge. AFAIK, changes for AVC only affect AVC's and nothing 
else.

-Steve

Re: Absolute path names in PATH records

[Steve Grubb]

On Monday 02 July 2007 03:44:55 pm Matthew Booth wrote:
> I've hit a hurdle trying to do some post processing on audit output
> because PATH records contain paths relative to the CWD, 

Actually, they are exactly what was passed to the kernel. If its an absolute 
path, then you will get that and the CWD record is not needed. But if the 
path starts with a '.', then you have to pay attention to the CWD record. 
Also, if you have a chroot situation, you must pay attention to the CWD 
record. The PATH record is from the PoV of the application using files.

> How much effort would likely be involved in making sure these paths were
> always absolute?

We only record what the kernel is working with. There is no chance to do 
anything during the recording side and save that for post-processing.

-Steve