Since it's difficult to reproduce the bug, what I'm going to do is setup
a system with the previous auditd, setup some rules, confirm they are
working, then upgrade, and confirm it keeps working, also after a
reboot.
# Bionic verification
auditd from bionic:
auditd:
Installed: 1:2.8.2-1ubuntu1
Candidate: 1:2.8.2-1ubuntu1
Version table:
*** 1:2.8.2-1ubuntu1 500
500 http://br.archive.ubuntu.com/ubuntu bionic/main amd64 Packages
Created a simple rule:
# cat /etc/audit/rules.d/30-shadow.rules
-w /etc/shadow -p wa -k shadow-changed
Loaded after restart:
# auditctl -l
-w /etc/shadow -p wa -k shadow-changed
Confirmed a change to the file gets logged:
# chmod 0400 /etc/shadow
#
/var/log/audit/auditd.log (parsed with ausearch -i):
type=PROCTITLE msg=audit(01/18/21 17:49:31.077:32) : proctitle=chmod 0400
/etc/shadow
type=PATH msg=audit(01/18/21 17:49:31.077:32) : item=0 name=/etc/shadow
inode=64070 dev=fc:01 mode=file,640 ouid=root ogid=shadow rdev=00:00
nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0
type=CWD msg=audit(01/18/21 17:49:31.077:32) : cwd=/root
type=SYSCALL msg=audit(01/18/21 17:49:31.077:32) : arch=x86_64 syscall=fchmodat
success=yes exit=0 a0=0xffffff9c a1=0x5577580dc1c0 a2=0400 a3=0x0 items=1
ppid=1499 pid=1992 auid=ubuntu uid=root gid=root euid=root suid=root fsuid=root
egid=root sgid=root fsgid=root tty=pts1 ses=3 comm=chmod exe=/bin/chmod
key=shadow-changed
Now updating the package:
# apt-cache policy auditd
auditd:
Installed: 1:2.8.2-1ubuntu1.1
Candidate: 1:2.8.2-1ubuntu1.1
Version table:
*** 1:2.8.2-1ubuntu1.1 500
500 http://br.archive.ubuntu.com/ubuntu bionic-proposed/main amd64
Packages
100 /var/lib/dpkg/status
1:2.8.2-1ubuntu1 500
500 http://br.archive.ubuntu.com/ubuntu bionic/main amd64 Packages
(and its deps, like libaudit1, etc).
The same rule continues loaded:
# auditctl -l
-w /etc/shadow -p wa -k shadow-changed
Also after a manual restart:
# systemctl restart auditd
# auditctl -l
-w /etc/shadow -p wa -k shadow-changed
And changing /etc/shadow is logged (let's use 0640 this time):
# chmod 0640 /etc/shadow
#
log:
type=PROCTITLE msg=audit(01/18/21 17:54:51.942:56) : proctitle=chmod 0640
/etc/shadow
type=PATH msg=audit(01/18/21 17:54:51.942:56) : item=0 name=/etc/shadow
inode=64070 dev=fc:01 mode=file,400 ouid=root ogid=shadow rdev=00:00
nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0
type=CWD msg=audit(01/18/21 17:54:51.942:56) : cwd=/root
type=SYSCALL msg=audit(01/18/21 17:54:51.942:56) : arch=x86_64 syscall=fchmodat
success=yes exit=0 a0=0xffffff9c a1=0x563ae04471c0 a2=0640 a3=0x0 items=1
ppid=1499 pid=2845 auid=ubuntu uid=root gid=root euid=root suid=root fsuid=root
egid=root sgid=root fsgid=root tty=pts1 ses=3 comm=chmod exe=/bin/chmod
key=shadow-changed
I then rebooted the system, performed the same tests, and got the same results
with the updated package.
It would be great if people who were affected by this bug, and can
reasonably reproduce it, could test the packages from proposed. In the
meantime, I'll mark this as verification succeeded.
** Tags removed: verification-needed-bionic
** Tags added: verification-done-bionic
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to audit in Ubuntu.
https://bugs.launchpad.net/bugs/1848330
Title:
Installing auditd sometimes fails in post-inst
Status in audit package in Ubuntu:
Fix Released
Status in audit source package in Bionic:
Fix Committed
Status in audit package in Debian:
New
Bug description:
[Impact]
Sometimes, auditd will get stuck when starting up, causing systemd to
kill it after a while since it (systemd) never got the start
notification.
Upstream troubleshooted this to be caused by calling a syslog()
function inside a signal handler.
[Test Case]
There is no reliable test case to reproduce the bug, other than trying the
fixed packages on an affected system where the hang occurs more frequently.
Basically:
sudo systemctl stop auditd
sudo systemctl start auditd
should work reliably. Do not run that in a tight loop, however, as
that will trigger a it's-restarting-too-frequently failure.
[Where problems could occur]
- if auditd fails to start, then the first fallback is syslog, and if that is
not picking up the audit messages, the last resort is the kernel buffer, which
can fill up. In the case it fills up, audit logs will be lost.
- it's possible to configure the audit system to panic() the machine
if audit messages are lost or otherwise not able to be recorded
(auditctl -f 2; default is 1 which is printk())
- the update restarts auditd as expected. Misconfiguration on very
very busy systems could mean that audit logs would be lost during the
brief moment the service is restarted. If that's the case, this update
would just be one more way to trigger it, but not be the root cause of
the problem
- similarly, as is usual with updates that restart services, it's
possible than an incorrect configuration for auditd is present, but
was never loaded before. The restart will load the config, and will
fail in such a case.
- this update removes a logging statement that occurs during startup:
("dispatcher %d reaped", pid)
It's unlikely, but possible, that some monitoring software could be
looking for that message in the logs. It won't be there anymore after
this update.
[Other Info]
The patch is committed upstream and part of the 2.8.5 release, which is
present in Focal and later.
The real fix for this bug is just dropping the audit_msg() call in the signal
handler code. But the original reporter of the bug, who is also who came up
with the fix (see https://bugzilla.redhat.com/show_bug.cgi?id=1587995#c4)
stated that with the 3 changes in the patch the startup hang didn't happen to
him anymore. Since this bug is difficult to reproduce elsewhere (either you
have it, or you don't), I chose to keep the 3 changes instead of just the
removal of the audit_msg() call.
[Original Description]
This happens sometimes when installing auditd on Ubuntu 18.04.2, most
installations work successfully, though. Re-running the install also
fixes the issue, but the failure breaks our automation. The log from
the failure looks like this:
# apt install auditd
...
Setting up auditd (1:2.8.2-1ubuntu1) ...
Created symlink /etc/systemd/system/multi-user.target.wants/auditd.service →
/lib/systemd/system/auditd.service.
Job for auditd.service failed because a timeout was exceeded.
See "systemctl status auditd.service" and "journalctl -xe" for details.
invoke-rc.d: initscript auditd, action "start" failed.
● auditd.service - Security Auditing Service
Loaded: loaded (/lib/systemd/system/auditd.service; enabled; vendor
preset: enabled)
Active: failed (Result: timeout) since Tue 2019-09-17 18:43:06 UTC; 11ms
ago
Docs: man:auditd(8)
https://github.com/linux-audit/audit-documentation
Process: 9702 ExecStart=/sbin/auditd (code=killed, signal=KILL)
Sep 17 18:40:06 compute-node21 systemd[1]: Starting Security Auditing
Service...
Sep 17 18:40:06 compute-node21 auditd[9703]: Started dispatcher:
/sbin/audispd pid: 9705
Sep 17 18:40:06 compute-node21 audispd[9705]: No plugins found, exiting
Sep 17 18:41:36 compute-node21 systemd[1]: auditd.service: Start operation
timed out. Terminating.
Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: State
'stop-sigterm' timed out. Killing.
Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Killing process
9702 (auditd) with signal SIGKILL.
Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Killing process
9703 (auditd) with signal SIGKILL.
Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Control process
exited, code=killed status=9
Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Failed with result
'timeout'.
Sep 17 18:43:06 compute-node21 systemd[1]: Failed to start Security Auditing
Service.
dpkg: error processing package auditd (--configure):
installed auditd package post-installation script subprocess returned error
exit status 1
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/audit/+bug/1848330/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : [email protected]
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
