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, 1 month
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
[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, 2 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, 2 months
aureport and command lines
by Michael Mather
I have written my own version of aureport. It is still buggy etc, but it
does already provide something interesting.
For example, it can show command lines. It takes something in the log
like:
uid=1000 euid=0
argc=4 a0="sudo" a1="cp" a2="qwerty" a3="/etc/xxx"
uid = 0 euid=0
argc=4 a0="cp" a1="qwerty" a2="/etc/xxx"
and puts out:
uid euid command
--- ---- -------
1000 0 sudo cp qwerty /etc/xxx
0 0 cp qwerty /etc/xxx
which is interesting.
My question is whether I could have done something like this with
aureport.
(This is part of a much bigger question as to how audit can be used to
meet PCI requirements.)
Thanks - Michael
----------------
12 years, 2 months
missing user name
by Harris, Todd
I'm looking at a problem that has me really scratching my head.
I've got a rhel 5.4 system that's using likewise and active directory to authenticate users, at least ones that are not defined locally. Locally defined users work just fine, but any user that is defined in the active directory server is showing up in events as "unknown(uid)" the uid appears to be filled out correctly, and if the user is defined locally as well as in active directory it works just fine, but that kind of defeats the purpose. Also failed logins are showing up correctly, but I can't figure out what they have done to their system to cause this. Can anyone give me a little direction on where I should look to determine what's actually going on. I haven't been able to determine how the system actually resolves the user names.
Don't know if this is important but we are using the prelude plugin and where we notice the discrepancy is in the output from the prelude-manager, I have not looked to see if it's wrong in the aureords.
_______________________________
Todd Harris
Progeny Systems
Office Number: 703-368-6107 ext517
12 years, 3 months
AUTO: Gavin Appleton is out of the office. (returning 01/08/2012)
by Gavin Appleton
I am out of the office until 01/08/2012.
Note: This is an automated response to your message "Linux-audit Digest,
Vol 94, Issue 17" sent on 31/7/2012 5:00:04 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, 3 months
mode = forward
by Michael Mather
I am using Ubuntu 12.04, which uses version 1.7.18 of auditd.
Audispd is complaining that the queue is full and it is dropping events.
According to the man page for audisp-remote.conf (as found at
linux.die.net), the parameter "mode" can be set to "immediate" or
"forward". "forward" means that events are buffered in a queue.
I found that "mode" was set to "immediate", and the queue did not exist.
But when I try to set the value as "forward" and restart auditd,
audisp-remote complains that "Option forward not found". And the queue
still gets full.
Last October, Steve was writing about how big the queue might be on this
very site.
Can someone explain what is going on?
Thanks - Michael
----------------
12 years, 3 months
[PATCH] audit: missing variable declaration/initialization when AUDIT_DEBUG == 2.
by Peter Moody
Additionally it looks like audit_free_names might return too early when
AUDIT_DEBUG was set to 2.
Signed-off-by: Peter Moody <pmoody(a)google.com>
---
kernel/auditsc.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index 4b96415..0c1db46 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -997,6 +997,7 @@ static inline void audit_free_names(struct audit_context *context)
#if AUDIT_DEBUG == 2
if (context->put_count + context->ino_count != context->name_count) {
+ int i = 0;
printk(KERN_ERR "%s:%d(:%d): major=%d in_syscall=%d"
" name_count=%d put_count=%d"
" ino_count=%d [NOT freeing]\n",
@@ -1005,11 +1006,10 @@ static inline void audit_free_names(struct audit_context *context)
context->name_count, context->put_count,
context->ino_count);
list_for_each_entry(n, &context->names_list, list) {
- printk(KERN_ERR "names[%d] = %p = %s\n", i,
+ printk(KERN_ERR "names[%d] = %p = %s\n", i++,
n->name, n->name ?: "(null)");
}
dump_stack();
- return;
}
#endif
#if AUDIT_DEBUG
@@ -2084,10 +2084,10 @@ void audit_putname(const char *name)
__FILE__, __LINE__, context->serial, name);
if (context->name_count) {
struct audit_names *n;
- int i;
+ int i = 0;
list_for_each_entry(n, &context->names_list, list)
- printk(KERN_ERR "name[%d] = %p = %s\n", i,
+ printk(KERN_ERR "name[%d] = %p = %s\n", i++,
n->name, n->name ?: "(null)");
}
#endif
--
1.7.7.3
12 years, 3 months
[PATCH v5 0/9] audit: overhaul audit_names handling to allow for retrying on path-based syscalls
by Jeff Layton
This patchset is a minor respin of the series that I posted June 26th.
The main reason is to deal with some fairly minor merge conflicts that
have cropped up due to recent changes. This patch also relies on the
patch that I sent separately yesterday entitled "vfs: don't let do_last
pass negative dentry to audit_inode".
This series is available via the "audit" branch of my git tree as well:
git://git.samba.org/jlayton/linux.git audit
The original cover letter text follows:
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 | 22 ++++-----
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, 166 insertions(+), 112 deletions(-)
--
1.7.11.2
12 years, 3 months
