Hello,

I would like to configure auditd to only log events issued by some users acting as root after a 'sudo su -'

Unfortunately, after the user system makes a "sudo su -" the ids of user are the same as root.

Heres is the log of the command date issued by the user "system" uid 500


May 27 10:20:36 doma audispd: node=doma type=SYSCALL msg=audit(1274948436.000:57884): arch=c000003e syscall=59 success=yes exit=0 a0=6cf250 a1=6cf730 a2=6cf510 a3=0 items=2 ppid=26772 pid=27006 auid=4294967295 uid=1000 gid=19 euid=1000 suid=1000 fsuid=1000 egid=19 sgid=19 fsgid=19 tty=tty1 comm="date" exe="/bin/date" key=(null)
May 27 10:20:36 doma audispd: node=doma type=EXECVE msg=audit(1274948436.000:57884): a0="date"
May 27 10:20:36 doma audispd: node=doma type=PATH msg=audit(1274948436.000:57884): item=0 name="/bin/date" inode=48341 dev=fd:60 mode=0100755 ouid=0 ogid=0 rdev=00:00


Here's the same report of the date command after the user "system" changed its id using sudo su - :

May 27 10:22:13 doma audispd: node=doma type=SYSCALL msg=audit(1274948533.407:58095): arch=c000003e syscall=59 success=yes exit=0 a0=6d4b20 a1=6d4ff0 a2=6d4de0 a3=0 items=2 ppid=27175 pid=27181 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=tty1 comm="date" exe="/bin/date" key=(null)
May 27 10:22:13 doma audispd: node=doma type=EXECVE msg=audit(1274948533.407:58095): a0="date"
May 27 10:22:13 doma audispd: node=doma type=PATH msg=audit(1274948533.407:58095): item=0 name="/bin/date" inode=48341 dev=fd:60 mode=0100755 ouid=0 ogid=0 rdev=00:00

Any idea for me to idendify the primary login user for one specific command ?

At first I've though it was auid but its value is always set at 4294967295. It seems auditd cannot read pam or anything else affiliated.

I've also searched for logging commands specifics to a TTY but it seems auditd cannot filter on one specific TTY.

Regards

FP.

Wrong tool for the right job? Shouldn't you use 'rootsh' instead?

I'm also in the evaluation of this tool. Thank you for the idea.

No no, rootsh will only log commands, while a proper auditing subsytem will be able to capture substanially more than that.

Such as how many resources were used, what resources were used, which files were accessed, which network addresss were connected to...etc

I'm not disputing Audit is a good tool (after all I've written many threads since say 2003 about LIDS, TOMOYO, GRSecurity, SELinux, syscall vs userland logging, logging requirements wrt privacy aspects, security or PCI-DSS, etc, etc) but while it may be easy to write "proper auditing subsytem", as far as I'm aware, Auditd logs only what you configure it to log. Please remember that by default none of the CAPP, NISPOM, STIG or LSPP rulesets in the audit package are loaded (for good reasons), so these are the effective /etc/audit/audit.rules contents you start out with when installing audit (grep -v ^# /etc/audit/audit.rules):
So what would an administrator have to do to turn Audit into a proper auditing subsystem? And will it then also only log events issued by users after a 'sudo su -'?


By default Auditd does not log which network addresses were connected to as far as I know.


If you've ran it you would know rootsh logs commands and CLI output. Sure I should have said that the Audit subsystem and userland tools like Rootsh complement each other.

Running audit-1.7.17-3.el5 shows auid values correctly.

Hi, it doesn't matter what the default settings are one bit, we are talking about the capabilities of an auditing system compared to rootsh.

The fact is, you can configure an auditing system to log pretty much anything, while rootsh is severely restricted by comparison.

That is why I disagreed when you suggested rootsh as the right tool for the job, and implied auditd was not.

Neat! So you know the answer to the OPs question about how to configure auditd to only log events issued by users transitioned to root, right?

I'm sure I can help, but I would request more clarification.

Specifically, which events does he want logged after the user switches to root?

I would also question the point of running "sudo su -".

I would like to log every command the user issues after a sudo su -.

Out of curiosity, why do you have it set up so users do "sudo su -"? You realize that is redundant, and missing the whole point of sudo?

What auditd rules do you have set up at the moment, and what happens if you explicitly specify sudo to use uid 0?

The goal is to monitor/trace any root access that is able to connect to a machine only for troubleshooting/maintenance. So we don't know in advance which orders will be issued.

Because we want to know which folk connects to the system, I choose to use sudo su - to keep a trace of the real user.

Hope it's clear. This is I think a typical security concern for root.

Regards

If you use 'ausearch' then you'll find all sessions start with a LOGIN line and then a new session Id. So when you use 'ausearch --ses $sessionNumber' you get an account of (amongst other things) commands issued. Note that, as is typical for syscall-based logging, command args are obscured and you'll ever get those, nor any command output, from the Auditd subsystem alone.

Thank fot his. But I would prefer not to register all but syscals operated by a specific terminal and would like to read auid at each line.

I've been told to set-up pam_loginuid.so to make able audit to register auid

and to use pam_tty_audit about my tty filtering.

I'm looking for how to set-up that.

pam_loginuid should be a RHEL/Centos PAM stack default module and as for pam_tty_audit, are you sure? While limiting audit.rules may seem like a Good Thing to do it would be better to filter at the reporting stage. For instance "terminal" in 'ausearch' is a filter ("-tm").