9:56 a.m.
For some system calls, the arguments are passed as structures or strings
in userspace memory, and only the _pointer_ is passed in the registers
as an argument to the syscall.
In this case, the current audit code will log the _pointer_ which is
given, but will not show the _contents_ of the memory to which that
pointer refers.
The IPC calls are one specific instance of a case where I have already
inserted a hook to log the contents of the userspace structure instead
of just the pointer.
Two weeks ago on our conference call, I asked if there were any other
syscalls where I should add similar hooks to log the data which are
actually acted upon, rather than merely the pointer. This morning I'll
ask again -- are there any more system calls where we need to log
anything more than the arguments to the syscall?
On the call two weeks ago I pointed out the potential race condition; if
we log the target of the pointer at syscall entry time, another
userspace thread may change the contents of memory at that address by
the time the syscall actually executes and calls copy_from_user(). This
is why we have to add hooks such as the ones in the IPC code, instead of
just doing extra logging in audit_syscall_entry() for certain syscalls.
Just to make sure, I want to repeat the question which nobody deigned to
answer at the time: are there any more system calls for which we should
be adding hooks to log extra information, because the information
currently recorded is not sufficient for CAPP?
--
dwmw2
12:54 p.m.
On Sat, Apr 23, 2005 at 12:56:43AM +1000, David Woodhouse wrote:
On the call two weeks ago I pointed out the potential race condition;
if
we log the target of the pointer at syscall entry time, another
userspace thread may change the contents of memory at that address by
the time the syscall actually executes and calls copy_from_user(). This
is why we have to add hooks such as the ones in the IPC code, instead of
just doing extra logging in audit_syscall_entry() for certain syscalls.
Yes, this race condition has been a frequent topic of discussion, and the
current LAF code uses a third completely different approach to avoid it,
the 2.4 and 2.6 LAuS code had each used other methods for this.
Just to make sure, I want to repeat the question which nobody deigned
to
answer at the time: are there any more system calls for which we should
be adding hooks to log extra information, because the information
currently recorded is not sufficient for CAPP?
For CAPP, the interesting part here is the object identity, which is
handled by the current code for filesystem objects, and is easy for IPC
objects since the numerical ID is available in a register on the
architectures I'm familiar with.
(The definition of "object" of course depends on the specific security
target, CAPP doesn't define that. For unixoid systems, these are usually
filesystem and IPC objects, plus in some cases the TCP/UDP port number
and address for bound sockets.)
One additional piece of information needed would be the struct sockaddr
(port number and address) used by bind(), this would also be useful (but
not required) for connect().
Note that CAPP does not specifically require that the audit record
contains all information for the system call, such as the specific
permission changes made by a shmctl call. Having that information
available is obviously useful (and requires collecting data from
userspace), but you could claim CAPP compliance without auditing it as
long as you have the required fields (success/failure, object identity
where applicable, subject (process ID), and user identity (login UID).
-Klaus
3:39 p.m.
In our syscalls, we are currently checking the expected values of some of
the syscall parameters. We do not always check a0, a1, a2, and a3. One
syscall may check a0, a1, and a2. Another may only check a0, and a1.
When we compile our syscalls in 32bit mode on a 64bit system, the a0, a1,
a2, a3 values are no longer what we expected them to be.
For example, in our access syscall test
a0 = pathname
a1 = mode
When we compile and run in 64bit mode:
The audit record looks like:
type=KERNEL msg=audit(1114696605.916:2151478): item=0 name="./mytest.9825"
inode=6062205 dev=fd:00 mode=0100004 uid=0 gid=0 rdev=00:00
type=KERNEL msg=audit(1114696605.916:2151478): syscall=21 arch=c000003e
success=yes exit=0 a0=50a460 a1=4 a2=3cb762ea03 a3=0 items=1 pid=9825
loginuid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
comm="access_test"
exe=/deb/rhcc/eal4/tests/LTP/ltp-full/testcases/audit/filters/access_test
From our test:
access_test 0 INFO : expected (pfilename)
a0 s=./mytest.9825 h=50a460
d=5284960 u=5284960. (expected a0 printed as a string, hex, decimal,
unsigned values)
Note audit record a0=50a460 which matches expected value
printed in hex
access_test 0 INFO : expected (access_mode) a1 h=4 d=4 u=4.
(expected a1 printed as a hex, decimal, and unsigned value)
Note audit record a1=4 which matches expected (printed in %x,
%d, and %u)
access_test 0 INFO : expected (pfilename) objectname s=./mytest.9825.
Matches "name" in audit record"
access_test 1 PASS : Expected record found!
When we compile and run in 32bit mode:
type=KERNEL msg=audit(1114696996.822:2260436): item=0 name="./mytest.10196"
inode=6062205 dev=fd:00 mode=0100004 uid=0 gid=0 rdev=00:00
type=KERNEL msg=audit(1114696996.822:2260436): syscall=33 arch=40000003
success=yes exit=0 a0=80510e0 a1=76c378 a2=0 a3=0 items=1 pid=10196
loginuid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
comm="access_test"
exe=/deb/rhcc/eal4/tests/LTP/ltp-full/testcases/audit/filters/access_test
From our test
access_test 0 INFO : expected (pfilename) a0
s=./mytest.10196
h=8051260 d=134550112 u=134550112.
Note audit record a0=80510e0 does NOT match expected (in %x, %d, or
%u format).
access_test 0 INFO : expected (access_mode) a1 h=4 d=4 u=4.
Note audit record a1=76c378. does NOT match expected (in %x , %d, or
%u format).
access_test 0 INFO : expected (pfilename) objectname
s=./mytest.10196.
access_test 1 FAIL : Expected record not found.
I know David put some hooks in for the ipc syscalls, I haven't been able to
test those to see if that corrects this problem for those or not. I'm not
sure when that fix was introduced. I'm currently running on
kernel.2.6.9-5.0.3.EL.audit.20 and this problem is true for the ipc
syscalls as well.
If that does fix the problem, should our tests only check a0, a1, a2, a3
values for the syscalls which David is adding these hooks?
Thanks,
debbie
2:44 p.m.
On Sat, Apr 23, 2005 at 12:56:43AM +1000, David Woodhouse wrote:
Two weeks ago on our conference call, I asked if there were any
other
syscalls where I should add similar hooks to log the data which are
actually acted upon, rather than merely the pointer. This morning I'll
ask again -- are there any more system calls where we need to log
anything more than the arguments to the syscall?
In Laus, we decided to log various ioctls related to configuration
changes - mostly the network stuff, but some others as well.
capset() would also be fairly important I guess, as well as setgroups,
setrlimit, setdomainname, the module related stuff, *xattr, setrlimit.
settimeofday and stime as well.
You also need to intercept rtnetlink messages to catch all network
related configuration changes, but I guess you're already doing
that somewhere else.
Olaf
--
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
okir(a)suse.de | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
8:38 p.m.
On Fri, 22 Apr 2005, Olaf Kirch wrote:
You also need to intercept rtnetlink messages to catch all network
related configuration changes, but I guess you're already doing
that somewhere else.
SELinux can trigger auditing of netlink messages, but the granularity is
only the netlink family and whether it's a 'read' or 'write' operation
(for rtnetlink).
- James
--
James Morris
<jmorris(a)redhat.com>
12:32 p.m.
On Fri, Apr 22, 2005 at 09:38:07PM -0400, James Morris wrote:
> You also need to intercept rtnetlink messages to catch all
network
> related configuration changes, but I guess you're already doing
> that somewhere else.
SELinux can trigger auditing of netlink messages, but the granularity is
only the netlink family and whether it's a 'read' or 'write'
operation
(for rtnetlink).
Most likely, this is not enough, because for CAPP you really want to
know what sort of message. Just logging the fact that someone sent a
netlink message doesn't tell you anything about the network configuration
changes this entails.
Laus added a hook into rtnetlink to intercept the entire message. Doing
it inside the netlink dispatch routine was the best solution we found
because that's where you can tell whether it's rtnetlink (the other
families are less interesting), and you can easily match the message to
the result code.
Olaf
--
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
okir(a)suse.de | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
7177
days inactive
7183
days old
linux-audit@lists.linux-audit.osci.io
5 comments
5 participants
participants (5)
-
David Woodhouse -
Debora Velarde -
James Morris -
Klaus Weidner -
Olaf Kirch