user message limits
by LC Bruzenak
I know I can go look at the code, however I figured I'd ask here first
about the limits on the user message in both audit_log_user_message and
ausearch.
With audit_log_user_message the maximum length allowed appears to be
around MAX_AUDIT_MESSAGE_LENGTH-100. I think it may depend on the
executable name length (and other stuff auto-pushed into the string)
which is why I say "around".
Even when I get a successful return value (from audit_log_user_message),
I don't get my string back out in "ausearch" unless it is WAY smaller -
~1K or less I think.
Any ideas/thoughts?
This is the latest (1.7.11-2) audit package.
Thx,
LCB.
--
LC (Lenny) Bruzenak
lenny(a)magitekltd.com
11 years, 3 months
linux-audit: reconstruct path names from syscall events?
by John Feuerstein
Hi,
I would like to audit all changes to a directory tree using the linux
auditing system[1].
# auditctl -a exit,always -F dir=/etc/ -F perm=wa
It seems like the GNU coreutils are enough to break the audit trail.
The resulting SYSCALL events provide CWD and multiple PATH records,
depending on the syscall. If one of the PATH records is relative, I can
reconstruct the absolute path using the CWD record.
However, that does not work for the whole *at syscall family
(unlinkat(2), renameat(2), linkat(2), ...); accepting paths relative to
a given directory file descriptor. GNU coreutils are prominent users,
for example "rm -r" making use of unlinkat(2) to prevent races.
Things like dup(2) and fd passing via unix domain sockets come to mind.
It's the same old story again: mapping fds to path names is ambiguous at
best, if not impossible.
I wonder why such incomplete file system auditing rules are considered
sufficient in the CAPP/LSPP/NISPOM/STIG rulesets?
Here's a simplified example:
$ cd /tmp
$ mkdir dir
$ touch dir/file
$ ls -ldi /tmp /tmp/dir /tmp/dir/file
2057 drwxrwxrwt 9 root root 380 Sep 17 00:02 /tmp
58781 drwxr-xr-x 2 john john 40 Sep 17 00:02 /tmp/dir
56228 -rw-r--r-- 1 john john 0 Sep 17 00:02 /tmp/dir/file
$ cat > unlinkat.c
#include <unistd.h>
#include <fcntl.h>
int main(int argc, char **argv)
{
int dirfd = open("dir", O_RDONLY);
unlinkat(dirfd, "file", 0);
return 0;
}
^D
$ make unlinkat
cc unlinkat.c -o unlinkat
$ sudo autrace ./unlinkat
Waiting to execute: ./unlinkat
Cleaning up...
Trace complete. You can locate the records with 'ausearch -i -p 32121'
$ ls -li dir
total 0
Now, looking at the resulting raw SYSCALL event for unlinkat(2):
type=SYSCALL msg=audit(1316210542.899:779): arch=c000003e syscall=263 success=yes exit=0 a0=3 a1=400690 a2=0 a3=0 items=2 ppid=32106 pid=32121 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts12 ses=36 comm="unlinkat" exe="/tmp/unlinkat" key=(null)
type=CWD msg=audit(1316210542.899:779): cwd="/tmp"
type=PATH msg=audit(1316210542.899:779): item=0 name="/tmp" inode=58781 dev=00:0e mode=040755 ouid=1000 ogid=1000 rdev=00:00
type=PATH msg=audit(1316210542.899:779): item=1 name="file" inode=56228 dev=00:0e mode=0100644 ouid=1000 ogid=1000 rdev=00:00
type=EOE msg=audit(1316210542.899:779):
- From this event alone, there's no way to answer "Who unlinked
/tmp/dir/file?". For what it's worth, the provided path names would be
exactly the same if we had unlinked "/tmp/dir/dir/dir/dir/dir/file".
- PATH item 0 reports the inode of "/tmp/dir" (58781, see ls output
above), however, the reported path name is "/tmp" (bug?).
In this example I've used autrace, which traces everything, so I could
possibly search for a previous open(2) of inode 58781. And indeed, there
it is:
type=SYSCALL msg=audit(1316210542.899:778): arch=c000003e syscall=2 success=yes exit=3 a0=40068c a1=0 a2=7fff22724fc8 a3=0 items=1 ppid=32106 pid=32121 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts12 ses=36 comm="unlinkat" exe="/tmp/unlinkat" key=(null)
type=CWD msg=audit(1316210542.899:778): cwd="/tmp"
type=PATH msg=audit(1316210542.899:778): item=0 name="dir" inode=58781 dev=00:0e mode=040755 ouid=1000 ogid=1000 rdev=00:00
type=EOE msg=audit(1316210542.899:778):
Great, so inode 58781 was opened using "/tmp/dir", and therefore, the relative
path "file" given to unlinkat(2) above could possibly translate to
"/tmp/dir/path"... not really feeling confident here.
- All file system auditing rules in various rulesets and the examples in
the documentation add the "-F perm=wa" (or similar) filter, so the
open(2) wouldn't even make it into the audit trail.
- If you can handle the volume and log all open(2), what happens if the
open(2) was done hours, days, weeks, ... ago?
- What if the open(2) was done by another process which passed the fd
on a unix domain socket?
It looks like the kernel auditing code should provide
... item=0 name="/tmp/dir" inode=58781 ...
in the unlinkat(2) syscall event above. Looking up the unlinkat(2)
documentation:
int unlinkat(int dirfd, const char *pathname, int flags);
If the pathname given in pathname is relative, then it is
interpreted relative to the directory referred to by the file
descriptor dirfd (rather than relative to the current working
directory of the calling process, as is done by unlink(2) and
rmdir(2) for a relative pathname).
If the pathname given in pathname is relative and dirfd is the
special value AT_FDCWD, then pathname is interpreted relative
to the current working directory of the calling process (like
unlink(2) and rmdir(2)).
As you might see, there's not only the fd->pathname problem, but
also the special case for AT_FDCWD. In this case the kernel side should
probably just duplicate CWD's path name into item 0's path name. But
that's just unlinkat(2), there are a lot more.
What am I missing here? Is there no way to audit a directory tree?
I've looked at alternatives: Inotify watches won't scale to big trees
and events lack so much detail that they can't be used for auditing.
Fanotify, while providing the pid, still lacks a lot of events and
passes fds; the example code relies on readlink("/proc/self/fd/...").
Thanks,
John
[1] http://people.redhat.com/sgrubb/audit/
--
John Feuerstein <john(a)feurix.com>
12 years, 1 month
[PATCH] auditctl Running In QEMU
by Nathaniel Husted
The current stable version of ARM will not run in QEMU and errors with
an "unknown machine type" error. The following patch adds two machine
times to the ARMEB machine architecture. "armv5tejl" is the type
returned by uname -m when running the versatilepb machine type with a
default CPU (under Debian Squeeze 6.0). "armv7l" is return by uname -m
when run on a Samgsung Galaxy S SGH-I897 phone.
Signed-off by: Nathaniel Husted <nhusted(a)gmail.com>
diff -rpuN audit-2.2.1/lib/machinetab.h audit-2.2.1-patched/lib/machinetab.h
--- audit-2.2.1/lib/machinetab.h 2012-03-23 08:42:44.000000000 -0400
+++ audit-2.2.1-patched/lib/machinetab.h 2012-06-15 16:18:33.069787303 -0400
@@ -35,4 +35,6 @@ _S(MACH_ALPHA, "alpha" )
#endif
#ifdef WITH_ARMEB
_S(MACH_ARMEB, "armeb" )
+_S(MACH_ARMEB, "armv5tejl")
+_S(MACH_ARMEB, "armv7l")
#endif
12 years, 3 months
[PATCH] Audit Compilation on QEMU/Debian Squeeze
by Nathaniel Husted
The current version of audit has issues compiling (Debian Squeeze --
http://www.raspberrypi.org/downloads). The compiler complains about
being unable to find SYS_RECVMMSG. The following patch solves this
issue by removing potential problematic system calls from being
compiled in when using the WITH_ARMEB directive. The patch was made
against the latest stable release (audit 2.2.1) and tested under QEMU
ARM with Debian Squeeze 6.0.
Signed-off by: Nathaniel Husted <nhusted(a)gmail.com>
diff -rpuN audit-2.2.1/auparse/socktab.h audit-2.2.1-patched/auparse/socktab.h
--- audit-2.2.1/auparse/socktab.h 2012-03-23 08:42:42.000000000 -0400
+++ audit-2.2.1-patched/auparse/socktab.h 2012-06-15 16:13:12.470054242 -0400
@@ -39,6 +39,8 @@ _S(SYS_GETSOCKOPT, "getsockopt" )
_S(SYS_SENDMSG, "sendmsg" )
_S(SYS_RECVMSG, "recvmsg" )
_S(SYS_ACCEPT4, "accept4" )
+#ifndef WITH_ARMEB
_S(SYS_RECVMMSG, "recvmmsg" )
_S(20, "sendmmsg" )
+#endif
diff -rpuN audit-2.2.1/src/ausearch-lookup.c
audit-2.2.1-patched/src/ausearch-lookup.c
--- audit-2.2.1/src/ausearch-lookup.c 2012-03-23 08:42:41.000000000 -0400
+++ audit-2.2.1-patched/src/ausearch-lookup.c 2012-06-15
16:12:41.839801930 -0400
@@ -116,7 +116,9 @@ static struct nv_pair socktab[] = {
{SYS_SENDMSG, "sendmsg"},
{SYS_RECVMSG, "recvmsg"},
{SYS_ACCEPT4, "accept4"},
+ #ifndef WITH_ARMEB
{SYS_RECVMMSG, "recvmmsg"},
+ #endif
{20, "sendmmsg"}
};
#define SOCK_NAMES (sizeof(socktab)/sizeof(socktab[0]))
12 years, 3 months
-F dir=/nfs/path ?
by Peter Moody
How does auditd perform on a rule like the following, assuming that
/home/ is an nfs mount?
-a exit,always -F arch=b64 -S open -F dir=/home/ -F a2&2 -F success=1
-C euid!=obj_uid -k
Does this become a watch rule (and to watch rules even work with nfs)?
Assuming that the mount map for /home/ is giant (several K entries),
does this run the risk of filling fsnotify (inotify?) watch lists?
Cheers,
peter
--
Peter Moody Google 1.650.253.7306
Security Engineer pgp:0xC3410038
12 years, 5 months
auditing syscalls made 'by' an inode?
by Peter Moody
Is there anyway to audit syscalls made by a particular, not yet
running, application? For example, if I'm interested in seeing all
exec's by google-chrome, can I do something like the following?
auditctl -a exit,always -F arch=b64 -S execve -F success=1 -F
inode=inode-of-chrome
experimenting seems to indicate that will only tell me when
inode-of-chrome is exec'd, basically a watch rule.
The sort of inverse of this rule that got me thinking about this
initially was auditing a syscall and seeing if it was/wasn't called by
a particular program. For example, audting all bind() calls which
*aren't* made by chrome (a silly rule to be sure, but just thrown out
as a hypothetical)
If it's not possible to do this now, is there interest in adding this feature?
Cheers,
peter
--
Peter Moody Google 1.650.253.7306
Security Engineer pgp:0xC3410038
12 years, 5 months
AUTO: Gavin Appleton is out of the office. (returning 29/06/2012)
by Gavin Appleton
I am out of the office until 29/06/2012.
Note: This is an automated response to your message "Linux-audit Digest,
Vol 93, Issue 10" sent on 28/6/2012 5:00:08 PM.
This is the only notification you will receive while this person is away.This e-mail is confidential and, if you are not the intended recipient, please return it to us and do not retain or disclose it. We filter and monitor e-mails in order to protect our system and the integrity, confidentiality and availability of e-mails. We cannot guarantee that e-mails are risk free and are not responsible for any related damage or unauthorised alteration of e-mails by third parties after sending.
For more information on Standard Life group, visit our website http://www.standardlife.com/
Standard Life plc (SC286832), Standard Life Assurance Limited* (SC286833) and Standard Life Employee Services Limited (SC271355) are all registered in Scotland at Standard Life House, 30 Lothian Road, Edinburgh EH1 2DH. *Authorised and regulated by the Financial Services Authority. 0131 225 2552. Calls may be recorded/monitored. Standard Life group includes Standard Life plc and its subsidiaries.
12 years, 5 months
[PATCH v4 0/9] audit: overhaul audit_names handling to allow for retrying on path-based syscalls
by Jeff Layton
I recently posted a set of patches to have the kernel retry the lookup
and call when path-based syscalls would ordinarily return ESTALE. Al
took a look and pointed out that this would break the fragile logic that
handles the audit_names for syscall auditing.
This patchset comprises a number of incremental changes that should make
it ok to retry on a path-based syscall. The main caveat is that the retry
mustn't redo the getname() on the strings involved.
Unfortunately, we don't have anything that really describes what the
correct behavior is for this stuff, so I'm shooting here for "no
discernable difference" on a retry.
This seems to do the right thing in the cases that I've tested; mostly
the normal case where things succeed or fail for some reason and where
the syscall is retried after an ESTALE error.
Review is of course appreciated. There are some fixes in here too for
some subtle bugs in the existing code. Some of these patches may also
help performance in some cases, but I haven't measured it for that.
I'd like to see this patchset go into 3.6 if at all possible.
Eric Paris (1):
audit: make audit_compare_dname_path use parent_len helper
Jeff Layton (8):
audit: remove unnecessary NULL ptr checks from do_path_lookup
audit: pass in dentry to audit_copy_inode wherever possible
audit: reverse arguments to audit_inode_child
audit: add a new "type" field to audit_names struct
audit: set the name_len in audit_inode for parent lookups
audit: remove dirlen argument to audit_compare_dname_path
audit: optimize audit_compare_dname_path
audit: overhaul __audit_inode_child to accomodate retrying
fs/btrfs/ioctl.c | 2 +-
fs/namei.c | 20 +++-----
fs/open.c | 4 +-
fs/xattr.c | 8 ++--
include/linux/audit.h | 36 ++++++++++-----
include/linux/fsnotify.h | 8 ++--
ipc/mqueue.c | 8 ++--
kernel/audit.h | 7 ++-
kernel/audit_watch.c | 3 +-
kernel/auditfilter.c | 65 +++++++++++++++++---------
kernel/auditsc.c | 115 +++++++++++++++++++++++++++------------------
11 files changed, 165 insertions(+), 111 deletions(-)
--
1.7.7.6
12 years, 6 months
event for exited process
by Giang Nguyen
Hi,
I would like to know when a process terminates. So far I can see the
exit() syscall generates an audit event, but if the process does not
call exit() or is killed by a signal, then it seems currently there is
no audit event generated?
I am using 1.7.18 on Ubuntu 12.04, but I looked at the change logs
between that and 2.2.1 and did not see anything regarding process
exit.
Thanks.
I am using the following test program:
#include <sys/types.h>
#include <sys/socket.h>
#include <stdlib.h>
void main()
{
int count = 0;
while (1) {
if (!count) {
// trigger syscall events for sanity check
close(socket(AF_INET, SOCK_STREAM, 0));
}
++count;
}
}
The following rule
auditctl -a task,always -F pid=`pidof a.out`
will periodically generate in the log events for socket() and close(),
but nothing is logged when I terminate the process.
12 years, 6 months
Linux Audit Framework question
by Jan
Hello,
I write you because i do not know how to go further without solving my problem.
When a user switches from username to root using sudo su - this action is audited by LAF but since that change the user-id in the LAF logfile is 0 for root user. If my user uses chmod afterwords to change file permissions i can not see which user did the change because user-id is 0 and the auditid is always 4294967295.
Can you tell me how it is possible to trace the user after switching to root ??
Thanks in advance,
Jan
12 years, 6 months
