September 2012 - Linux-audit - Linux-Audit List Archives

[PATCH] Support for auditing on the actions of a not-yet-executed process.

by Peter Moody

eg: -a exit,always -F arch=b64 -S socket -F 'a0!=1' -F exe=/bin/bash -F success=1 to see instances of /bin/bash opening a non-local socket. Or -a exit,always -F arch=b64 -S socket -F 'a0!=1' -F exe_children=/bin/bash -F success=1 to instances of /bin/bash, and any descendant processes, opening a non local socket. proposed https://www.redhat.com/archives/linux-audit/2012-June/msg00002.html and it seemed like there was interest. Signed-off-by: Peter Moody <pmoody(a)google.com> --- trunk/lib/errormsg.h | 2 +- trunk/lib/fieldtab.h | 2 ++ trunk/lib/libaudit.c | 11 +++++++++++ trunk/lib/libaudit.h | 7 ++++++- 4 files changed, 20 insertions(+), 2 deletions(-) diff --git a/trunk/lib/errormsg.h b/trunk/lib/errormsg.h index 4d996d5..cd595ec 100644 --- a/trunk/lib/errormsg.h +++ b/trunk/lib/errormsg.h @@ -51,7 +51,7 @@ static const struct msg_tab err_msgtab[] = { { -15, 2, "-F unknown errno -"}, { -16, 2, "-F unknown file type - " }, { -17, 1, "can only be used with exit and entry filter list" }, - { -18, 1, "" }, // Unused + { -18, 1, "only takes = operator" }, { -19, 0, "Key field needs a watch or syscall given prior to it" }, { -20, 2, "-F missing value after operation for" }, { -21, 2, "-F value should be number for" }, diff --git a/trunk/lib/fieldtab.h b/trunk/lib/fieldtab.h index c0432cc..245b541 100644 --- a/trunk/lib/fieldtab.h +++ b/trunk/lib/fieldtab.h @@ -66,3 +66,5 @@ _S(AUDIT_ARG3, "a3" ) _S(AUDIT_FILTERKEY, "key" ) _S(AUDIT_FIELD_COMPARE, "field_compare" ) +_S(AUDIT_EXE, "exe" ) +_S(AUDIT_EXE_CHILDREN, "exe_children" ) diff --git a/trunk/lib/libaudit.c b/trunk/lib/libaudit.c index 20eaf5f..06eed86 100644 --- a/trunk/lib/libaudit.c +++ b/trunk/lib/libaudit.c @@ -1400,6 +1400,17 @@ int audit_rule_fieldpair_data(struct audit_rule_data **rulep, const char *pair, else return -21; break; + case AUDIT_EXE_CHILDREN: + case AUDIT_EXE: + { + struct stat buf; + if ((stat(v, &buf)) < 0) + return -2; + if (op != AUDIT_EQUAL) + return -18; + rule->values[rule->field_count] = (unsigned long)buf.st_ino; + } + break; case AUDIT_DEVMAJOR...AUDIT_INODE: case AUDIT_SUCCESS: if (flags != AUDIT_FILTER_EXIT) diff --git a/trunk/lib/libaudit.h b/trunk/lib/libaudit.h index 89dd588..2c8a802 100644 --- a/trunk/lib/libaudit.h +++ b/trunk/lib/libaudit.h @@ -243,6 +243,12 @@ extern "C" { #ifndef AUDIT_FIELD_COMPARE #define AUDIT_FIELD_COMPARE 111 #endif +#ifndef AUDIT_EXE +#define AUDIT_EXE 112 +#endif +#ifndef AUDIT_EXE_CHILDREN +#define AUDIT_EXE_CHILDREN 113 +#endif #ifndef AUDIT_COMPARE_UID_TO_OBJ_UID #define AUDIT_COMPARE_UID_TO_OBJ_UID 1 @@ -524,4 +530,3 @@ extern void audit_rule_free_data(struct audit_rule_data *rule); #endif #endif - -- 1.7.7.3

11 years, 4 months

3
3
0 / 0

[PATCH] audit: audit on the future execution of a binary.

by Peter Moody

This adds the ability audit the actions of a not-yet-running process, as well as the children of a not-yet-running process. Signed-off-by: Peter Moody <pmoody(a)google.com> --- include/linux/audit.h | 2 ++ kernel/auditfilter.c | 6 ++++++ kernel/auditsc.c | 47 +++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 55 insertions(+), 0 deletions(-) diff --git a/include/linux/audit.h b/include/linux/audit.h index 22f292a..5506cb1 100644 --- a/include/linux/audit.h +++ b/include/linux/audit.h @@ -260,6 +260,8 @@ #define AUDIT_OBJ_UID 109 #define AUDIT_OBJ_GID 110 #define AUDIT_FIELD_COMPARE 111 +#define AUDIT_EXE 112 +#define AUDIT_EXE_CHILDREN 113 #define AUDIT_ARG0 200 #define AUDIT_ARG1 (AUDIT_ARG0+1) diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c index a6c3f1a..1e6c571 100644 --- a/kernel/auditfilter.c +++ b/kernel/auditfilter.c @@ -546,6 +546,12 @@ static struct audit_entry *audit_data_to_entry(struct audit_rule_data *data, if (f->val > AUDIT_MAX_FIELD_COMPARE) goto exit_free; break; + case AUDIT_EXE: + case AUDIT_EXE_CHILDREN: + if (f->op != Audit_equal) { + goto exit_free; + } + break; default: goto exit_free; } diff --git a/kernel/auditsc.c b/kernel/auditsc.c index 4b96415..9cebe95 100644 --- a/kernel/auditsc.c +++ b/kernel/auditsc.c @@ -46,6 +46,7 @@ #include <asm/types.h> #include <linux/atomic.h> #include <linux/fs.h> +#include <linux/dcache.h> #include <linux/namei.h> #include <linux/mm.h> #include <linux/export.h> @@ -68,6 +69,7 @@ #include <linux/capability.h> #include <linux/fs_struct.h> #include <linux/compat.h> +#include <linux/sched.h> #include "audit.h" @@ -592,6 +594,35 @@ static int audit_field_compare(struct task_struct *tsk, return 0; } +int audit_match_exe(struct task_struct *tsk, struct audit_field *f) +{ + int result = 0; + struct mm_struct *mm; + struct vm_area_struct *vma; + + if (!tsk) + goto out; + + mm = tsk->mm; + if (!mm) + goto out; + + down_read(&mm->mmap_sem); + vma = mm->mmap; + while (vma) { + if ((vma->vm_flags & VM_EXECUTABLE) && + vma->vm_file) { + struct inode *ino = vma->vm_file->f_path.dentry->d_inode; + result = audit_comparator(ino->i_ino, f->op, f->val); + break; + } + vma = vma->vm_next; + } + up_read(&mm->mmap_sem); +out: + return result; +} + /* Determine if any context name data matches a rule's watch data */ /* Compare a task_struct with an audit_rule. Return 1 on match, 0 * otherwise. @@ -629,6 +660,22 @@ static int audit_filter_rules(struct task_struct *tsk, result = audit_comparator(ctx->ppid, f->op, f->val); } break; + case AUDIT_EXE: + result = audit_match_exe(tsk, f); + break; + case AUDIT_EXE_CHILDREN: + { + struct task_struct *ptsk; + for (ptsk = tsk; + ptsk->parent->pid > 0; + ptsk = find_task_by_vpid(ptsk->parent->pid)) { + if (audit_match_exe(ptsk, f)) { + ++result; + break; + } + } + } + break; case AUDIT_UID: result = audit_comparator(cred->uid, f->op, f->val); break; -- 1.7.7.3

11 years, 11 months

4
9
0 / 0

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, 11 months

5
17
0 / 0

[PATCH 0/5] Build time disabling of auditd network listener

by Tyler Hicks

Hello Steve - This is a patch set that allows --disable-listener to be passed to the configure script to disable the auditd network listener code at build time. The reasoning is that a large number of users do not need centralized audit logging and removing the network listening code from a root-owned auditd process is appealing from a security perspective. The existing implementation clearly does not initialize the listener when tcp_listen_port is undefined in auditd.conf, but I still think there is value in not having the listening code present in all auditd installations. The first three patches in the set are refactoring patches to move nearly all of the listening code into auditd-listen.c in order to minimize the number of ifdefs that would need to be scattered throughout C source files. The fourth patch is an optional cleanup patch. The last patch introduces the --disable-listener option. The auditd listener code is still enabled by default so that existing distro packaging recipes will not need to be updated. I look forward to your feedback. Thanks! Tyler

12 years, 10 months

2
11
0 / 0

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, 10 months

6
21
0 / 0

[PATCH] audit: grab a reference to context->pwd when it's cached

by Peter Moody

On certain systems, in certain pathalogical cases, current's cwd can be deleted while we're still processing a syscall. This should prevent the system from evicting the inode while we're still referencing it. This seems to fix the bug I reported here: https://www.redhat.com/archives/linux-audit/2012-August/msg00017.html Signed-off-by: Peter Moody <pmoody(a)google.com> --- kernel/auditsc.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/kernel/auditsc.c b/kernel/auditsc.c index 4b96415..e86b8b9 100644 --- a/kernel/auditsc.c +++ b/kernel/auditsc.c @@ -2064,6 +2064,7 @@ void __audit_getname(const char *name) if (!context->pwd.dentry) get_fs_pwd(current->fs, &context->pwd); + path_get(&context->pwd); } /* audit_putname - intercept a putname request @@ -2091,6 +2092,7 @@ void audit_putname(const char *name) n->name, n->name ?: "(null)"); } #endif + path_put(&context->pwd); __putname(name); } #if AUDIT_DEBUG -- 1.7.7.3

12 years, 10 months

4
25
0 / 0

'Nested rule' error message when getting auditd set up on my server

by Tola Odejayi

Hello, I'm trying to figure out which processes are deleting files from a specific directory, so I want to set up and run auditd on my system. I've set up the following (only) rule in audit.rules: -a exit,always -F arch=x86_64 -S unlinkat -S truncate -S ftruncate -F dir=/home/myfolder/cache -F key=cache_deletion Then I type this to start the audit daemon: auditctl -R /etc/audit/audit.rules -e 1 But I get this error message: Error - nested rule files not supported Does anyone know what I am doing wrong here, and how I can resolve this? Tola

12 years, 11 months

1
0
0 / 0

Capturing USB insertions and removal events with auditd

by Diaz, DavidA (Plymouth)

Hi: I am wondering how to use auditd and specifically ausearch, to pull out USB thumbdrive event insertions and removals on my Redhat Enterprise Linux 6 Server? I can see very easily in the /var/log/messages file detailed logging when I insert a USB thumbdrive and when I then remove it. But I would really like to be able to use auditd's ausearch utility to pull these types of events out. Any ideas on what my audit.rule should be, and the syntax for ausearch to extract it for reporting purposes? When I do look at the audit.log to see what is being captured when I insert the USB stick, I see indications of comm="usb_id"... But when I remove it, I do not see any usb text only the umount command. Thanks, I am relatively new to ausearch so any suggestions would be appreciated! David A. Diaz Minneapolis, MN

12 years, 11 months

2
1
0 / 0

[PATCH v2 00/10] vfs: getname/putname overhaul

by Jeff Layton

This patchset is a second pass at overhauling the getname/putname interface to use a struct. The main differences from the last set are a few bugfixes and changes to account for Al's execve overhaul. The idea here is to add a new getname_info struct that allow us to pass around some auxillary info along with the string that getname() returns. This allows us to do some interesting things: - no need to walk the list of audit_names in certain cases since we can store a pointer to the correct audit_name - we can now call getname() more than once on a userland string. Since we track the original userland pointer, we can avoid doing a second allocation, and can instead fill out the getname_info from the audit_names struct. That makes the ESTALE patchset cleaner, and doesn't explode out the list of getname() callers like the last set. - eventually we might be able to track the length of the parent portion of the string so the audit code doesn't need to walk it again. I haven't implemented that yet, but it doesn't look too hard to do. This is based on top of Al's signal.git#experimental-kernel_thread branch, with my most recent audit series on top of that. Al is working on unifying much of the execve code, which will reduce the number of getname callers greatly. This set is still preliminary since Al's set isn't complete yet and will probably need to be respun again once he's completed that work. That should shrink patch #4 since we'll have fewer getname callers to deal with at that point. This set is based on top of my audit overhaul patchset (posted earlier today). My most recent ESTALE retry set should also apply cleanly on top of this set. The stack of all three sets is also available in my git tree at: git://git.samba.org/jlayton/linux.git#estale While this all seems to work correctly, I have my doubts about patch #9 in this series. That was suggested by Al and should make it so that we only need a single allocation per getname() call in most cases. OTOH, it adds a rarely traveled codepath that could be a source of bugs in the future. Jeff Layton (10): vfs: allocate page instead of names_cache buffer in mount_block_root vfs: make dir_name arg to do_mount a const char * acct: constify the name arg to acct_on vfs: define getname_info struct and have getname() return it audit: allow audit code to satisfy getname requests from its names_list vfs: turn do_path_lookup into wrapper around getname_info variant vfs: make path_openat take a getname_info pointer audit: make audit_inode take getname_info vfs: embed getname_info inside of names_cache allocation if possible vfs: unexport getname and putname symbols arch/alpha/kernel/osf_sys.c | 16 +-- arch/avr32/kernel/process.c | 4 +- arch/blackfin/kernel/process.c | 4 +- arch/cris/arch-v10/kernel/process.c | 4 +- arch/cris/arch-v32/kernel/process.c | 4 +- arch/h8300/kernel/process.c | 4 +- arch/hexagon/kernel/syscall.c | 4 +- arch/ia64/kernel/process.c | 4 +- arch/m32r/kernel/process.c | 4 +- arch/microblaze/kernel/sys_microblaze.c | 4 +- arch/mips/kernel/linux32.c | 4 +- arch/mips/kernel/syscall.c | 4 +- arch/openrisc/kernel/process.c | 4 +- arch/parisc/hpux/fs.c | 4 +- arch/parisc/kernel/process.c | 4 +- arch/parisc/kernel/sys_parisc32.c | 4 +- arch/score/kernel/sys_score.c | 4 +- arch/sh/kernel/process_32.c | 4 +- arch/sh/kernel/process_64.c | 4 +- arch/sparc/kernel/process_32.c | 4 +- arch/sparc/kernel/process_64.c | 4 +- arch/sparc/kernel/sys_sparc32.c | 4 +- arch/tile/kernel/process.c | 8 +- arch/unicore32/kernel/sys.c | 4 +- arch/xtensa/kernel/process.c | 4 +- fs/compat.c | 12 +- fs/exec.c | 14 +- fs/filesystems.c | 4 +- fs/internal.h | 4 +- fs/namei.c | 218 +++++++++++++++++++++----------- fs/namespace.c | 6 +- fs/open.c | 33 ++++- fs/quota/quota.c | 4 +- include/linux/audit.h | 26 ++-- include/linux/fs.h | 23 +++- init/do_mounts.c | 7 +- ipc/mqueue.c | 9 +- kernel/acct.c | 6 +- kernel/auditsc.c | 136 +++++++++++++------- mm/swapfile.c | 11 +- 40 files changed, 400 insertions(+), 229 deletions(-) -- 1.7.11.4

12 years, 11 months

2
15
0 / 0

Excluding events by command

by Laura Martín

Hi all, I'm trying to exclude cron events from audit logging. I can't see how can I do to only exclude this kind of entries: ---- time->Mon Sep 17 11:00:01 2012 type=PATH msg=audit(1347872401.521:5212): item=0 name="/etc/pam.d/system-auth" inode=33635 dev=fd:00 mode=0100644 ouid=0 ogid=0 rdev=00:00 type=CWD msg=audit(1347872401.521:5212): cwd="/var/spool" type=SYSCALL msg=audit(1347872401.521:5212): arch=c000003e syscall=2 success=yes exit=5 a0=2b5b7b627300 a1=0 a2=1b6 a3=0 items=1 ppid=11640 pid=1965 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="crond" exe="/usr/sbin/crond" key=(null) ---- I didn't see any option to exclude events by 'exe' or 'comm' field. Any hints? Thanks in advance, Laura

12 years, 11 months

3
6
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Linux-audit September 2012