Fwd: Re: Fw: Audit records for start/stop auditd
by Steve Grubb
Hello,
This is the discussion about meeting the CAPP requirement to log the real
user's ID that initiated a shutdown. The core issue is that shutdown sequence
is started by a SIGTERM. I can use sigaction to get some additional
information delivered to the signal handler. All you get is pid. It would be
racy to trace that back to the caller and see what their loginuid is.
Klaus proposed the following patch. Its an OK solution, but I was wanting to
see if there are alternatives. The problems I see is that this will always
require adding some rules, you will always have to start the audit daemon
from the init script to make sure the pid is captured, its racy on
termination - it waits a finite amount of time hoping the record makes it to
disk, people may accidentally delete the rule not knowing what it does,
there's a race getting the pid of the audit daemon - it forks starting up, it
slows down performance because it adds a another rule the audit system has to
evaluate each time there's a potential audit event, it occupies memory, etc.
Some other ideas I've pondered:
*adding user information to sigaction signal delivery
*having the kernel recognize kill to the audit daemon and auto generate an
event before delivering the signal
We need some ideas to pick the best way to solve the problem.
-Steve
---------- Forwarded Message ----------
Subject: Re: Fw: Audit records for start/stop auditd
Date: Thursday 17 March 2005 19:04
From: Klaus Weidner <klaus(a)atsec.com>
To: Kris Wilson <krisw(a)us.ibm.com>, Steve Grubb <sgrubb(a)redhat.com>
Hello,
I've worked around the problem in the following way - it's a bit of a
hack but I think easier than completely restructuring the code:
- dynamically add an audit rule from /etc/init.d/audit to monitor
signals sent to the auditd pid
- change auditd to keep processing kernel messages for two seconds
after getting the shutdown signal so that it has a chance to save
the "signal" event record.
This is what it looks like (i386, syscall 37 is "kill"):
type=KERNEL msg=audit(1111114589.580:4100282): syscall=37 exit=0
a0=469d a1=f a2=469d a3=469d items=0 pid=18094 loginuid=500 uid=0 gid=0
euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
type=DAEMON msg=auditd(1111114591) auditd normal halt, pid=18077, uid=0
I think this way the CAPP requirement is covered, even though it's not
pretty.
The patch contains one separate change - /etc/init.d/audit did not
actually reload the audit rules when run with the "reload" argument,
this caused me some head scratching while testing. The change adds the
reload.
-Klaus
On Thu, Mar 17, 2005 at 01:16:49PM -0600, Kris Wilson wrote:
> What needs to be done? Here is the currrent record when auditd is stopped:
>
> type=DAEMON msg=auditd(1110848990) auditd normal halt, pid=12552, uid=0
>
> ----- Forwarded by Kris Wilson/Austin/IBM on 03/17/2005 01:14 PM -----
>
> Steve Grubb
> <sgrubb(a)redhat.co
> m> To
> Kris Wilson/Austin/IBM@IBMUS
> 03/17/2005 12:44 cc
> PM
> Subject
> Re: Fw: Audit records for
> start/stop auditd
>
> On Thursday 17 March 2005 13:23, you wrote:
> > Is there any way for the auditd stop record to include auid?
>
> The shutdown comes from a signal. The sigaction call can send extra
> information upon signal delivery. It has a field for the Real User ID.
> However, the audit daemon runs as root, so only root can send it a signal.
> So, I can go ahead and put root as the user that sent the shutdown
> message...however, I can't get the loginuid. That's out of reach.
>
> So, do you want me to "fake it" or leave it as is?
>
> -Steve
-------------------------------------------------------
20 years, 2 months
[PATCH] Auditd shutdown credentials
by Steve Grubb
The attached patch addresses the problem with getting the audit daemon
shutdown credential information. It creates a new message type
AUDIT_TERM_INFO, which is used by the audit daemon to query who issued the
shutdown.
It requires the placement of a hook function that gathers the information. The
hook is after the DAC & MAC checks and before the function returns. Racing
threads could overwrite the uid & pid - but they would have to be root and
have policy that allows signalling the audit daemon. That should be a
manageable risk.
The userspace component will be released later in audit 0.7.2. When it
receives the TERM signal, it queries the kernel for shutdown information.
When it receives it, it writes the message and exits. The message looks
like this:
type=DAEMON msg=auditd(1114551182.000) auditd normal halt, sending pid=2650
uid=525, auditd pid=1685
Signed-off-by: Steve Grubb <sgrubb(a)redhat.com>
20 years, 2 months
Fw: audit syscall information.
by Debora Velarde
Just in case this one came out in html too, this should be only in text.
----- Forwarded by Debora Velarde/Austin/IBM on 04/29/2005 12:27 PM -----
Debora Velarde/Austin/IBM wrote on 04/28/2005 03:39:09 PM:
> 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
20 years, 2 months
test cases (in plain text)
by Timothy R. Chavez
Hello,
David requested the test cases in plain text, so I'm sending them to the
list on behalf of Loulwa (we're getting her IMAP account setup :-)). No
updates have been made.
By the time this entire project is over, it's my hope the entire IBM
team is internet-friendly :)
------------------------
These are the testcases I am writing to test the code Tim is providing
for the audit filesystem. The testcases will be included in LTP.
These cases are meant to cover the CAPP requirements. there is some FVT
testing covered as well, but that still needs to be expanded to test the
permissions and boundary cases (watch fields lengths, invalid fields ...
etc).
Please give feedback if you can think of any scenarios that I have not
considered, or modifications that I need to implement.
Thanks
- Loulwa
Test 1 : Access watched file by opening it (file already exists)
Expected: 1 watch records for file access/open
Test 2 : Create a watched file (file created after watch is inserted)
Expected: 1 watch records for open() with regards to file
creation
Test 3 : Create hard link to a watched file and then access it by
opening it for read
Expected: 1 watch record for open() on original file
Test 4 : Create hard link to an unwatched file, watch file, then access
hard link by opening it for read
Expected: 1 watch record for open() on original file
Test 5 : Create hard link to watched file, delete watched file, then
access hard link by opening it for read
Expected: No watch record
Test 6 : Recreate a watched file that has been deleted previously
Expected: 1 watch record for unlink() with regards to
file deletion
Expected: 1 watch record for open() with regards to file
recreation
Test 7 : Recreate a watched file that has been deleted previously
(creating hardlink to it first, so on recreation we are
certain we get new inode number)
Expected: 1 watch record for unlink() with regards to
file deletion
Expected: 1 watch record for open() with regards to file
recreation
Test 8 : Delete a watched file
Expected: 1 watch record for file deletion
Test 9 : Remove a watched directory
Expected: 1 watch record for rmdir() with respect to
directory removal
Test 10 : copy a watched file to unwatched name (copy out) - access
through new name
Expected: 1 watch record for original file access/open
Expected: No record for accessing through new name
Test 11 : copy a file to a watched name (copy in) - access through new
name
Expected: 1 record for file creation in new name
Expected: 1 record for new file access/open
Test 12 : Move a watched file out of a watched location and access by
opening it for read
Expected: 1 watch record for rename() with regards to
moving out of a watched location.
Expected: No watch record for new file open()
Test 13 : Move a watched file into a watched location and access by
opening it for read
Expected: 1 record for rename() with regards to moving
out of a watched location.
Expected: 1 watch record for open() in new location
Test 14 : Move a directory having a watched file - access file in new
location
Expected: No watch record
-tim
20 years, 2 months
Audit capabilities message
by Steve Grubb
Hello,
What I'm thinking about is either to create a new capabilities message or
piggyback the info onto the get status message. What we need to know is what
configurable subsystem in included in the kernel. For example,
CONFIG_AUDITSYSCALL and CONFIG_AUDITFILESYSTEM should enable individual
messages. Any new auditing subsystem in the future would add a message so
that old tools can warn about a more capable kernel.
Also, when we start doing LSPP, we probably need to known whether or not the
kernel supports labled subjects & objects.
If we ever split netlink into control and data channels, this would be the
place to tell user space. The audit daemon could query capabilities, see the
kernel supports dual channel and open another netlink socket. Older kernels
won't have this so we stay on the same socket. (Not that this will ever
happen...but if it did, this would help tools adapt.)
-Steve
20 years, 2 months
Is the "possible" option used when checking a syscall filter rule?
by Mounir Bsaibes
Does this option make sense when setting a syscall entry filter or exit
filter? Or, it is meant just for task filtering?
During task creation this option is checked. If true, the per-task
audit_context is created and always filled at syscall entry time.
What is the meaning (how it is used) of "possible" in the following
example:
auditctl -a entry,possible -S chmod
`
20 years, 2 months
audit syscall information.
by David Woodhouse
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
20 years, 2 months
file system auditing, zany timezone issues, design document, etc, etc
by Timothy R. Chavez
Hello,
First and foremost I want to apologize for the zany timezone issues I've
been having -- probably would have helped to have /etc/localtime, eh?
Having to reconstruct the root filesystem from a lost+found because it's
faster then redoing a gentoo stage1 isn't fun ;-) Anyway, hoping that
that's fixed (and hoping I never have to relive the experience ;-)).
So yeah... I was asked to wait until after tommorow's meeting to submit
to LKML, which is just as-well. That gives you all a little time to
test it :-) J/K -- But, really, it would be nice if some people just
tried to patch/install the kernel and play with auditctl -w/-W for a
couple minutes and respond with yay or nay.
Just to get a bearing of where I'm at and what I'm thinking. I'm hoping
that by the end of next week:
* auditfs RFC on LKML
* FVT testcases will be completed
* intial design document drafted
Perhaps, we could also merge auditfs into BK or git-audit (or whatever
it'll be called) as well by next week.
Thanks.
-tim
20 years, 2 months
Re: Strange audit messages - whitespace
by Stephen Smalley
On Sun, 2005-04-24 at 09:28 -0700, Steve G wrote:
> >I get audit messages that look like this (with lots of
> >extra whitespace) for my new GConf domain. Any idea what
> >can cause this?
>
> This sounds like an old kernel bug. There was a patch on the audit mail list that
> fixes it. It is pending being merged in the mm kernel. It only affects syslog
> messages. If you use the audit daemon, you won't see the problem.
>
> -Steve Grubb
>
>
> --- linux/kernel/audit.c.orig 2005-02-16 13:49:28.839925080 -0500
> +++ linux/kernel/audit.c 2005-02-16 13:53:24.757060224 -0500
> @@ -513,8 +513,8 @@
> if (!audit_pid) { /* No daemon */
> int offset = ab->nlh ? NLMSG_SPACE(0) : 0;
> int len = skb->len - offset;
> - printk(KERN_ERR "%*.*s\n",
> - len, len, skb->data + offset);
> + skb->data[offset + len] = '\0';
> + printk(KERN_ERR "%s\n", skb->data + offset);
> }
> kfree_skb(skb);
> ab->nlh = NULL;
Any reason that small bug fixes like this aren't upstreamed immediately
rather than waiting on the overall audit patchset?
Although I suppose that the real bug here is in printk's handling of the
"%*.*s" format, so either it should not support that format at all or
someone needs to find the bug in it and fix it. Also, what does skb-
>data[offset+len] contain prior to setting it to the NUL character as
above?
--
Stephen Smalley <sds(a)tycho.nsa.gov>
National Security Agency
20 years, 2 months
audit-0.6.2 released
by Steve Grubb
Hi,
A new version of auditd has been released. You can download it from:
http://people.redhat.com/sgrubb/audit
Some of the changes:
- Add R option to auditctl to allow reading rules from file.
- Do not allow task creation list to have syscall auditing
- Add D option to allow deleting all rules with 1 command
- Added pam_audit man page & sample.rules
- Mod initscript to call auditctl to load rules at start-up
- Write message to log file for daemon start up
- Write message that daemon is shutting down
- Modify auditd shutdown to wait until logger thread is finished
- Fix bug where extra info was appended to some messages
This version now supports reading a set of rules when the daemon is started.
Edit the file: /etc/audit.rules and place the audit ctl commands. There is a
sample audit rules file included. Look for sample.rules.
Compiled versions will be available in rawhide tomorrow morning.
-Steve Grubb
20 years, 2 months
