2:26 p.m.
I'm missing what in auditd allows for continuation of a netlink packet
from the kernel. If the payload is larger than one packet, AFAICT the
whole thing is dropped. This could be used to hide activity I think.
Problem is this:
lib/netlink.c::adjust_reply()
if (!NLMSG_OK(rep->nlh, (unsigned int)len))
return 0;
If the payload spans audit_buffers, the first packet has the netlink
header, and subsequent packets don't. Also, the netlink header on the
first packet says the length is the full audit buffer, which could be
larger than the 1200byte + header size that audit_get_reply() looks for.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
2:36 p.m.
On Friday 29 April 2005 15:26, Chris Wright wrote:
I'm missing what in auditd allows for continuation of a netlink
packet
from the kernel.
Nothing does. This was one of my concerns back in December and I even started
putting code in place to allow multiple packets. It was discussed and I was
told we aren't sending continuations.
Show me how to produce the problem and I'll fix it.
-Steve
2:41 p.m.
* Steve Grubb (sgrubb(a)redhat.com) wrote:
On Friday 29 April 2005 15:26, Chris Wright wrote:
> I'm missing what in auditd allows for continuation of a netlink packet
> from the kernel.
Nothing does. This was one of my concerns back in December and I even started
putting code in place to allow multiple packets. It was discussed and I was
told we aren't sending continuations.
We are (in theory, not sure about practice). Say a exe path of > 990
bytes, or any payload of that size. Kernel has this interesting notion of
fragmentation. I'm not very fond of it.
Show me how to produce the problem and I'll fix it.
Do a audit_log_format("%s", buffer that's > 998 bytes) in the kernel.
You should get two fragments, and auditd drops them both. The second
I'm suspecting it's pure luck because NLMSG_OK() is looking a audit
data as a netlink header. That data could happen to have a value in the
byte stream that corresponds to nlmsg_len <= 1200, and get printed, but
the first half will certainly be dropped.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
2:57 p.m.
On Friday 29 April 2005 15:41, Chris Wright wrote:
We are (in theory, not sure about practice).
The code was in a function called audit_listen that was removed after 0.6.4.
Say a exe path of > 990 bytes, or any payload of that size.
That was my concern. Paths can be 4096 bytes. (which is another reason I
wanted to see test cases with big filenames - to see what all breaks.)
You should get two fragments, and auditd drops them both. The
second
I'm suspecting it's pure luck because NLMSG_OK() is looking a audit
data as a netlink header.
It has to be coded differently. I'll see if I can create this problem by
making a long pathname and accessing it while doing syscall auditing.
-Steve
2:57 p.m.
On Fri, 2005-04-29 at 15:57 -0400, Steve Grubb wrote:
On Friday 29 April 2005 15:41, Chris Wright wrote:
> We are (in theory, not sure about practice).
The code was in a function called audit_listen that was removed after 0.6.4.
> Say a exe path of > 990 bytes, or any payload of that size.
That was my concern. Paths can be 4096 bytes. (which is another reason I
wanted to see test cases with big filenames - to see what all breaks.)
> You should get two fragments, and auditd drops them both. The second
> I'm suspecting it's pure luck because NLMSG_OK() is looking a audit
> data as a netlink header.
It has to be coded differently. I'll see if I can create this problem by
making a long pathname and accessing it while doing syscall auditing.
-Steve
It's Friday afternoon... don't you ever get the urge to just "rm -rf
*" :)?
--
Linux-audit mailing list
Linux-audit(a)redhat.com
http://www.redhat.com/mailman/listinfo/linux-audit
2:58 p.m.
* Steve Grubb (sgrubb(a)redhat.com) wrote:
On Friday 29 April 2005 15:41, Chris Wright wrote:
> We are (in theory, not sure about practice).
The code was in a function called audit_listen that was removed after 0.6.4.
You mean I'm looking at old code, or old code to handle this was removed?
Apologies if I've got the old stuff.
> Say a exe path of > 990 bytes, or any payload of that size.
That was my concern. Paths can be 4096 bytes. (which is another reason I
wanted to see test cases with big filenames - to see what all breaks.)
> You should get two fragments, and auditd drops them both. The second
> I'm suspecting it's pure luck because NLMSG_OK() is looking a audit
> data as a netlink header.
It has to be coded differently. I'll see if I can create this problem by
making a long pathname and accessing it while doing syscall auditing.
I just made a kernel module that does it (it requires a patch to kernel
to export the needed symbols). It's just an ugly hack, but it shows
the problem.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
3:08 p.m.
On Friday 29 April 2005 15:58, Chris Wright wrote:
You mean I'm looking at old code, or old code to handle this was
removed?
Old code was removed. I did not want the added complexity if it wasn't a
problem. The basic gist is you cannot use recvfrom to do it. You switch over
to recvmsg to do the job and loop. I think there are some other bits that I
didn't put there yet.
I just made a kernel module that does it (it requires a patch to
kernel
to export the needed symbols).
It takes an hour to compile a kernel. Its a friday afternoon.
-Steve
3:13 p.m.
* Steve Grubb (sgrubb(a)redhat.com) wrote:
On Friday 29 April 2005 15:58, Chris Wright wrote:
> You mean I'm looking at old code, or old code to handle this was removed?
Old code was removed. I did not want the added complexity if it wasn't a
problem. The basic gist is you cannot use recvfrom to do it. You switch over
to recvmsg to do the job and loop. I think there are some other bits that I
didn't put there yet.
I think you did the right thing. I'd like to do the same on kernel side
(the whole fragmentation scheme is to complex). But I was confused by
some behaviour, and then realized it's just broken ;-)
>I just made a kernel module that does it (it requires a patch to
kernel
>to export the needed symbols).
It takes an hour to compile a kernel. Its a friday afternoon.
Heh no worries, I'm 3 hours behind you, I'll plug at it a bit.
The basics are:
1) Not all audit messages the kernel sends have a netlink header only the
first fragment. Note, however, that most calls don't fragment.
2) All audit netlink headers tell you how long the reassembled packet would be.
3) Any fragmentation completely confuses userspace. First one is dropped
because NLMSG_OK() is false (netlink header says packet is bigger
still). Subsequent ones are subject to random chance whether they'll be
handled (and how, since header is just audit message bytestream data).
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
7176
days inactive
7176
days old
linux-audit@lists.linux-audit.osci.io
8 comments
3 participants
participants (3)
-
Chris Wright -
Steve Grubb -
Timothy R. Chavez