https://bugzilla.suse.com/show_bug.cgi?id=1196048
Bug ID: 1196048 Summary: audit file watches do not really work? Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs@opensuse.org Reporter: meissner@suse.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: ---
auditctl -e 1 auditctl -w /etc/issue
if i do echo hallo >> /etc/issue -> not audited
if i do vim /etc/issue ... remove hallo line and save ...
-> audited
cat /etc/issue
-> not audited
Not sure if I am doing it right.
https://bugzilla.suse.com/show_bug.cgi?id=1196048 https://bugzilla.suse.com/show_bug.cgi?id=1196048#c1
Takashi Iwai tiwai@suse.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tiwai@suse.com
--- Comment #1 from Takashi Iwai tiwai@suse.com --- In my local test, I could see the log via cat, but not the echo. It seems that it can't detect reliably enough...
https://bugzilla.suse.com/show_bug.cgi?id=1196048
Jiri Slaby jslaby@suse.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jslaby@suse.com Assignee|kernel-bugs@opensuse.org |ematsumiya@suse.com
https://bugzilla.suse.com/show_bug.cgi?id=1196048 https://bugzilla.suse.com/show_bug.cgi?id=1196048#c2
Enzo Matsumiya ematsumiya@suse.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CONFIRMED
--- Comment #2 from Enzo Matsumiya ematsumiya@suse.com --- Quoting from my comment #4, bug 1196053:
The behaviour is expected by design.
auditd works "only" on syscalls level; filesystem watches and auditd daemon/config changes are more of an abstraction implemented on top of the syscall monitoring.
I belive it _might_ be possible to monitor shell built-ins, but there's no audit built-in way, nor I can't think of an easy way of doing so.
[Using /usr/bin/echo] would work, but the problem is not echo, but rather ">>" which is a shell built-in, and AFAIK, there doesn't exist a separate binary for that.
IOW:
# /usr/bin/echo "test" >> /etc/issue
would also log "/bin/bash" in audit.log
https://bugzilla.suse.com/show_bug.cgi?id=1196048 https://bugzilla.suse.com/show_bug.cgi?id=1196048#c3
--- Comment #3 from Marcus Meissner meissner@suse.com --- The problem is however that NOTHING is logged, not even under name of bash.
SO something with filewatches is not meeting expectations.
https://bugzilla.suse.com/show_bug.cgi?id=1196048 https://bugzilla.suse.com/show_bug.cgi?id=1196048#c5
--- Comment #5 from Enzo Matsumiya ematsumiya@suse.com --- So, something new for me as well... audit will not follow symlinks on file watch.
See the following example:
tw-audit:~ # ls -l /etc/issue lrwxrwxrwx 1 root root 12 Apr 5 2022 /etc/issue -> ../run/issue tw-audit:~ # auditctl -w /etc/issue -k w_issue tw-audit:~ # cat /etc/issue # nothing logged here ... tw-audit:~ # mv /etc/issue /etc/issue2 # this modifies the symlink itself, so it gets logged, see below tw-audit:~ # echo "hello" > /etc/issue # 'echo' is shell builtin, nothing logged tw-audit:~ # cat /etc/issue # this is logged now since /etc/issue is not a symlink anymore tw-audit:~ # /usr/bin/echo "hello" >> /etc/issue # using the 'echo' binary now, entry logged under 'proctitle=-bash' tw-audit:~ # ausearch -i -k w_issue
type=PROCTITLE msg=audit(03/21/23 17:24:36.732:291) : proctitle=auditctl -w /etc/issue -k w_issue type=SYSCALL msg=audit(03/21/23 17:24:36.732:291) : arch=x86_64 syscall=sendto success=yes exit=1076 a0=0x4 a1=0x7ffda4fef0c0 a2=0x434 a3=0x0 items=0 ppid=1227 pid=2100 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=1 comm=auditctl exe=/usr/sbin/auditctl subj=unconfined key=(null) type=CONFIG_CHANGE msg=audit(03/21/23 17:24:36.732:291) : auid=root ses=1 subj=unconfined op=add_rule key=w_issue list=exit res=yes
type=PROCTITLE msg=audit(03/21/23 17:25:09.536:292) : proctitle=mv /etc/issue /etc/issue2 type=PATH msg=audit(03/21/23 17:25:09.536:292) : item=3 name=/etc/issue2 inode=8367 dev=fd:02 mode=link,777 ouid=root ogid=root rdev=00:00 nametype=CREATE cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 type=PATH msg=audit(03/21/23 17:25:09.536:292) : item=2 name=/etc/issue inode=8367 dev=fd:02 mode=link,777 ouid=root ogid=root rdev=00:00 nametype=DELETE cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 type=PATH msg=audit(03/21/23 17:25:09.536:292) : item=1 name=/etc/ inode=131 dev=fd:02 mode=dir,755 ouid=root ogid=root rdev=00:00 nametype=PARENT cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 type=PATH msg=audit(03/21/23 17:25:09.536:292) : item=0 name=/etc/ inode=131 dev=fd:02 mode=dir,755 ouid=root ogid=root rdev=00:00 nametype=PARENT cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 type=CWD msg=audit(03/21/23 17:25:09.536:292) : cwd=/root type=SYSCALL msg=audit(03/21/23 17:25:09.536:292) : arch=x86_64 syscall=renameat2 success=yes exit=0 a0=AT_FDCWD a1=0x7ffe3d16e479 a2=AT_FDCWD a3=0x7ffe3d16e484 items=4 ppid=1227 pid=2118 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=1 comm=mv exe=/usr/bin/mv subj=unconfined key=w_issue
type=PROCTITLE msg=audit(03/21/23 17:26:06.488:293) : proctitle=cat /etc/issue type=PATH msg=audit(03/21/23 17:26:06.488:293) : item=0 name=/etc/issue inode=12814 dev=fd:02 mode=file,644 ouid=root ogid=root rdev=00:00 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 type=CWD msg=audit(03/21/23 17:26:06.488:293) : cwd=/root type=SYSCALL msg=audit(03/21/23 17:26:06.488:293) : arch=x86_64 syscall=openat success=yes exit=3 a0=AT_FDCWD a1=0x7ffd3f9f6483 a2=O_RDONLY a3=0x0 items=1 ppid=1227 pid=2120 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=1 comm=cat exe=/usr/bin/cat subj=unconfined key=w_issue
type=PROCTITLE msg=audit(03/21/23 17:28:02.848:294) : proctitle=-bash type=PATH msg=audit(03/21/23 17:28:02.848:294) : item=1 name=/etc/issue inode=12814 dev=fd:02 mode=file,644 ouid=root ogid=root rdev=00:00 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 type=PATH msg=audit(03/21/23 17:28:02.848:294) : item=0 name=/etc/ inode=131 dev=fd:02 mode=dir,755 ouid=root ogid=root rdev=00:00 nametype=PARENT cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 type=CWD msg=audit(03/21/23 17:28:02.848:294) : cwd=/root type=SYSCALL msg=audit(03/21/23 17:28:02.848:294) : arch=x86_64 syscall=openat success=yes exit=3 a0=AT_FDCWD a1=0x55c9aa5d38a0 a2=O_WRONLY|O_CREAT|O_APPEND a3=0x1b6 items=2 ppid=1227 pid=2123 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=1 comm=bash exe=/usr/bin/bash subj=unconfined key=w_issue
https://bugzilla.suse.com/show_bug.cgi?id=1196048 https://bugzilla.suse.com/show_bug.cgi?id=1196048#c6
--- Comment #6 from Enzo Matsumiya ematsumiya@suse.com --- That said, I think improving the manpages/docs would be the best alternative as this seem to be really confusing.
As for the shell builtins problem, old discussions shows that they (upstream) are not interested in implementing such functionality and always suggest using a different solution instead of audit.
https://bugzilla.suse.com/show_bug.cgi?id=1196048 https://bugzilla.suse.com/show_bug.cgi?id=1196048#c7
--- Comment #7 from Marcus Meissner meissner@suse.com --- Nice spotted with the symlink!
The shell builtin ... i still fail to understand why it is not audited.
the audit is for filewatch and this basically looks for file access system calls
Bash supposedly uses system calls to open the file, write to it and close it.
So bash builtin operations should be logged by the filewatch systemcall auditing the same way?
https://bugzilla.suse.com/show_bug.cgi?id=1196048 https://bugzilla.suse.com/show_bug.cgi?id=1196048#c8
--- Comment #8 from Enzo Matsumiya ematsumiya@suse.com --- (In reply to Marcus Meissner from comment #7)
Nice spotted with the symlink!
The shell builtin ... i still fail to understand why it is not audited.
the audit is for filewatch and this basically looks for file access system calls
Bash supposedly uses system calls to open the file, write to it and close it.
So bash builtin operations should be logged by the filewatch systemcall auditing the same way?
You're right and I agree.
It seems my thoughts got stuck on a loop and doing isolated tests this whole time was not productive at all... I was doing the builtin tests with the symlink, but after changing the watch to a proper file I found this:
- reading, writing, executing, and changing attributes will get logged, but just under the bash process (the builtin command used is not logged at all AFAICS) (ok-ish, but could log at least the builtin name as an argument maybe?) - reading and executing logs the openat and execve syscalls (ok) - writing logs openat,fchmod,and setxattr (with vim) and only openat with echo, but not the write syscall in neither (not ok IMHO)
I have other tasks I need shift attention to, but I'll get back to check on this "write syscall not getting logged" issue later.
-
bugzilla_noreply＠suse.com