My bad for not asking you what you and your team already tried (as in posting log excerpts)... Anyway. My target is Centos-5U5 with PAM, SELinux targeted policy and auditd enabled and I'll use the default KDE tool "kdepasswd" to change an unprivileged users password. Let's first focus on the groundwork the OS provides. Changing a password requires a userland binary ("/usrbin/passwd"). That binary needs to signal the kernel work needs to be done and as usual this involves system calls. A narrow-focused (leaving out lots) 'strace' (open, execute) of using the binary shows that:
Code:
open("/lib/libselinux.so.1", O_RDONLY) = 3
open("/etc/pam.d/passwd", O_RDONLY|O_LARGEFILE) = 4
open("/etc/pam.d/system-auth", O_RDONLY|O_LARGEFILE) = 5
open("/dev/pts", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 4
open("/etc/passwd", O_RDONLY|O_LARGEFILE) = 4
open("/etc/shadow", O_RDONLY) = -1 EACCES (Permission denied)
open("/var/run/utmp", O_RDONLY|O_LARGEFILE) = 4
execve("/usr/bin/passwd", ["/usr/bin/passwd"], [/* 49 vars */]) = 0
PAM, SELinux and auditd libraries get loaded and configuration files read, a pseudo-terminal gets requested, utmp is checked, the binary executes itself (duh) and /etc/passwd and /etc/shadow are accessed. Ergo the
open and
execve syscalls are crucial in determining what happens.
* Note PAM provides its own independent logging.
Enter /usr/bin/kdepasswd. Before we use it have a look at this:
Code:
ldd /usr/bin/passwd|grep crypt
libcrypt.so.1 => /lib/libcrypt.so.1
ldd /usr/bin/kdepasswd|grep crypt
From this you know kdepasswd can't change a password by itself. It has to execute passwd. Another hint is provided when you 'strings /usr/bin/kdepasswd | grep passwd':
Code:
Conversation with 'passwd' failed.
Could not find the program 'passwd'.
* In short here your target isn't whatever the Desktop Environment offers but the system utilities underneath.
Here is an excerpt from /var/log/audit/audit.log for user UID=501 changing his password with "/usr/bin/kdepasswd". Before I continue you should note I stripped out any "type=CWD cwd="/home/USER"" lines that get logged when the execve syscall rule gets triggered, any .qtrc.lock and .kstylerc.lock errors (SYSCALL success=no exit triggers for KDE base components like dcopserver, kdeinit, kded or kbuildsycoca in the unconfined_t context), any lines with a context of ld_so_t and any host, epoch, arch, args, id and other distractive or repetitive details. Note password changing here itself fails because the user auth files have "iu" file atributes.
Code:
type=SYSCALL syscall=EXECVE success=yes exit=0 items=2 ppid=6922 pid=6934 auid=501 uid=501 tty=pts3 ses=4 comm="passwd" exe="/usr/bin/passwd" subj=user_u:system_r:unconfined_t:s0 key="BIN_logins"
type=EXECVE argc=1 a0="/usr/bin/passwd"
type=PATH item=0 name="/usr/bin/passwd" inode=714641 mode=0104755 ouid=0 ogid=0 obj=system_u:object_r:passwd_exec_t:s0
type=SYSCALL syscall=RENAME success=no exit=-1 items=4 ppid=6922 pid=6937 auid=501 uid=501 tty=pts3 ses=4 comm="passwd" exe="/usr/bin/passwd" subj=user_u:system_r:unconfined_t:s0 key="CFG_logins"
type=PATH item=2 name="/etc/nshadow" inode=65057 mode=0100400 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:shadow_t:s0
type=PATH item=3 name="/etc/shadow" inode=66209 mode=0100400 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:shadow_t:s0
type=USER_CHAUTHTOK user pid=6937 uid=501 auid=501 subj=user_u:system_r:unconfined_t:s0 msg='PAM: chauthtok acct="USER" : exe="/usr/bin/passwd" (hostname=?, addr=?, terminal=pts/3 res=failed)'
type=USER_CHAUTHTOK user pid=6937 uid=501 auid=501 subj=user_u:system_r:unconfined_t:s0 msg='op=change password id=501 exe="/usr/bin/passwd" (hostname=?, addr=?, terminal=pts/3 res=failed)'
Once kdepasswd is started a pseudo-terminal gets requested and the binary executes /usr/bin/passwd as expected:
type=SYSCALL syscall=EXECVE: this rule (key=BIN_logins) logs /usr/bin/passwd execution.
type=SYSCALL syscall=RENAME: this rule watches /etc/shadow (your key=auth).
type=USER_CHAUTHTOK: as stated before PAM conveniently provides its own independent logging.
* Also if you have a watch on wherever KDE expects its $TMP you will see temporary "/${TMP}/.kdepasswd.*" files.
From a log auditing point of view,
even without explicit syscall=execve success=yes rules for kdepasswd or KDE components you can establish who does what because logging works per session (
ses=4). 'ausearch -l -r --start today --session 4' should get you the whole session 4 for today and 'ausearch -l -r --start today --loginuid 501 --session 4 --comm passwd --success yes' for instance only what UID=501 did today in session 4 and related to the passwd binary. In conjunction with epoch time and all user identifiers getting logged you definitely would not have a hard time establishing who did what.
As for the audit.rules my rules match your enclosed section. I add failed syscalls:
Code:
-a exit,always -S chmod -S fchmod -S fchmodat -S chown -S chown32 -S fchown -S fchown32 -S fchownat -S lchown -S umask -S creat -S open -S openat -S truncate -S ftruncate -F success=0 -F exit=-EACCES -F auid!=0 -F auid!=4294967295 -k FAIL
-a exit,always -S chmod -S fchmod -S fchmodat -S chown -S chown32 -S fchown -S fchown32 -S fchownat -S lchown -S umask -S creat -S open -S openat -S truncate -S ftruncate -F success=0 -F exit=-EPERM -F auid!=0 -F auid!=4294967295 -k FAIL
to watch for privilege violations which may get you more verbose and collateral logging. Depending on machine use this may enlarge log size quite a bit.
I configure key usage for three related purposes: syscalls (SYS_), configuration files (CFG_) and binaries (BIN_). So the "BIN_logins" key comprises of any passwd, group and ch.*-related binaries, for example:
Code:
-a always,exit -F path=/usr/bin/passwd -F perm=x -F auid!=0 -F auid!=4294967295 -k BIN_logins
and the "CFG_logins" key watches /etc/passwd and related user auth files. There are no related system calls else there would be a SYS_logins key as well. Grouping them like this makes it easier to (know what to) grep logs for. Anyway. That's about it. Syscalls and watches work. Let me know if it doesn't.
