auditd and bash builtins

Vypadkovyy · 07-10-2009, 07:05 AM

Hey there (first post here, so please tell me if I'm being a bit noobish)

I've been searching google for days now trying to find the answer to this question, but so far all of my searches have been pretty much useless.

I'm trying to configure auditd on a RHEL 5 server to keep track of a users every action. So far, i've added this rule to my /etc/audit/audit rules file

Code:

-a entry,always -S execve
-a entry,never

but the problem is that it won't keep track of shell builtins. A disgruntled administrator could gain root access to the machine, use shell builtins like "kill" and we would never know what happened (if he cleared his bash history)

Anybody know how to make auditd track shell builtins? If it can't, can anyone suggest and open source solution which can?

unSpawn · 07-10-2009, 08:07 AM

Auditd no but you could use Rootsh as logging shell wrapper. In any case there are privacy and security considerations attached to logging output. BTW, if you allow root account access then root can undo any action. Best configure logging to a hardened remote syslog server.

Vypadkovyy · 07-10-2009, 08:59 AM

it actually logs to a splunk server for that very reason

to add to my previous post, I've found an awesome guide on novell's site [novell.com] which helped me to configure auditd.

I can get it to track the kill call, but I'm looking for a way to log everything and then whitelist the programs that I do not want to log.

forcing users to have an alternate shell is probably not an option.

unSpawn · 07-10-2009, 09:18 AM

Sure you can log syscalls with Auditd no problem. It's all in the LSPP/CAPP/SNARE audit rulesets, examples galore. The "problem" (not really, unless) with Auditd logging is that it's in-kernel and the kernel as usual gives zilch about "everything" nor does it provide you with the kind of mapping or resolution you get in userland. As a consequence saying "log everything" sounds greedy-matching enough until you actually define any auditing aspects as "...and also give me all the commands arguments" and "... and CLI output". If something is "not an option" if could help explain why, pointing to rules 'n regulations, policies or whatever else in effect.

Vypadkovyy · 07-10-2009, 09:48 AM

thx unSpawn. I'll definitely keep researching. I suppose "log everything" does sound a bit greedy

I suppose what I really meant was that I want to log enough so that I know what actions a certain user has done and the consequences of this action.

for example. a certain user (uid and gid known) executes a command which starts a process (pid and ppid known). this process kicks off two others, one which runs with certain permissions, the other which drops down to lower permissions. The end result is that a file is written to and another process is killed.

right now auditd is doing a good job at logging things like this. but there are a few situations that give no feedback. I'm just trying to fill in the holes in those situations.

right now, the biggest problem is shell builtin commands. right now, it looks like i have to explicitly state each one I'd like to track (some of which don't match up with their command names). I'm just worried that I might miss a few and leave an obvious security hole open.

I'll keep looking at the examples you mentioned and try to learn more about auditd. thanks

unSpawn · 07-10-2009, 10:47 AM

Quote:

Originally Posted by Vypadkovyy

I suppose "log everything" does sound a bit greedy

No, not really. "greedy match" has nothing to do with greed: it's a common term for regexes that aren't properly anchored. In your case as in not defining exactly what you need. Most wheels have been invented: we just need to know if you need huge tires or ludicrously huge tires...

Quote:

Originally Posted by Vypadkovyy

I suppose what I really meant was that I want to log enough so that I know what actions a certain user has done and the consequences of this action. for example. a certain user (uid and gid known) executes a command which starts a process (pid and ppid known). this process kicks off two others, one which runs with certain permissions, the other which drops down to lower permissions. The end result is that a file is written to and another process is killed.

This looks more like strace-like style troubleshooting than auditing but maybe that's just me.

Quote:

Originally Posted by Vypadkovyy

right now auditd is doing a good job at logging things like this. but there are a few situations that give no feedback. I'm just trying to fill in the holes in those situations. right now, the biggest problem is shell builtin commands. right now, it looks like i have to explicitly state each one I'd like to track (some of which don't match up with their command names). I'm just worried that I might miss a few and leave an obvious security hole open.

Userland processes communicating with the kernel requires a fixed set of syscalls. Getting all syscalls isn't hard either if you check lib/modules/$(uname -r)/build)/include/asm-i386/unistd.h. For looking up things for reporting and adding rules I use two shell functions:

Code:

syscallName2Num() { # Resolve system call name to its number
 HDRLOC="$(readlink -f /lib/modules/$(uname -r)/build)/include/asm-i386/unistd.h"
 grep "^#define __NR_${1}[[:blank:]]" $HDRLOC | awk '{print $3}'
}

syscallNum2Name() { # Resolve system call number to canonical name
 HDRLOC="$(readlink -f /lib/modules/$(uname -r)/build)/include/asm-i386/unistd.h"
 grep "^#define __NR_.*[[:blank:]]$1$" $HDRLOC | awk -F'_' '{print $4}'
}

* BTW, if you want to see which syscalls get used just strace something.

Vypadkovyy · 07-10-2009, 11:37 AM

heh, thanks

This was just what I was looking for. And yes, i suppose it really isn't auditing, I'm trying to set up a system for user process accounting. I need to know who's doing things to what and auditd seems to do what i need.