Format of EXECVE

Format of EXECVE

[Matthew Booth]

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

Firstly, on RHEL4 U5, I've noticed that if an argument has spaces in it,
it won't be pretty printed in the EXECVE record. E.g.:

# /bin/echo foo
EXECVE... argv[1]="foo"

# /bin/echo "foo bar"
EXECVE... argv[1]=1234ABCD

Is that a feature?

Secondly, I noticed that the sequence of messages is:
SYSCALL
EXECVE
CWD
PATH

I'm considering expanding argv[0] of EXECVE to be an absolute path.
However, that would mean either buffering things or moving EXECVE after
the PATH record. Would that break any contract, or reasonable
expectations that anyone's aware of?

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: Format of EXECVE

[Steve Grubb]

On Monday 17 September 2007 12:50:16 Matthew Booth wrote:
> Firstly, on RHEL4 U5, I've noticed that if an argument has spaces in it,
> it won't be pretty printed in the EXECVE record. Is that a feature?

Yes. Any field originating in something that a user can alter is escaped when 
one of several characters is found in the field.


> Secondly, I noticed that the sequence of messages is:
> SYSCALL
> EXECVE
> CWD
> PATH
>
> I'm considering expanding argv[0] of EXECVE to be an absolute path.
> However, that would mean either buffering things or moving EXECVE after
> the PATH record. Would that break any contract, or reasonable
> expectations that anyone's aware of?

They come out in the order the kernel creates them. I don't think anything in 
the audit package cares about that ordering. It buffers an event at a time in 
ausearch and aureport.

-Steve

Re: Format of EXECVE

[Valdis.Kletnieks]

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

On Mon, 17 Sep 2007 17:50:16 BST, Matthew Booth said:

> I'm considering expanding argv[0] of EXECVE to be an absolute path.

I take it you mean "*an* absolute path that was valid when we cut the EXECVE
record", and document that it may not be *the* actual path used?  In a quarter
century, I've just seen *too* many race conditions, tricks with ../symlink/foo
links, and the like (including some interesting malware that would dynamically
create a symlink and execve through it, just to frustrate attempts at figuring
out which binary was being exploited).

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

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

Re: Format of EXECVE

[Matthew Booth]

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

On Mon, 2007-09-17 at 16:54 -0400, Valdis.Kletnieks@vt.edu wrote:
> On Mon, 17 Sep 2007 17:50:16 BST, Matthew Booth said:
> 
> > I'm considering expanding argv[0] of EXECVE to be an absolute path.
> 
> I take it you mean "*an* absolute path that was valid when we cut the EXECVE
> record", and document that it may not be *the* actual path used?  In a quarter
> century, I've just seen *too* many race conditions, tricks with ../symlink/foo
> links, and the like (including some interesting malware that would dynamically
> create a symlink and execve through it, just to frustrate attempts at figuring
> out which binary was being exploited).

This would be an issue in a single-pronged approach.

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