Created attachment 895161 [details] ordering patch The model for rpm-ostree/Atomic is that /var starts *empty*, and is populated on boot. For more information on this: http://lists.freedesktop.org/archives/systemd-devel/2014-March/017489.html Now, with rpm-ostree I post-process the RPM content and look for directories in /var, and synthesize systemd-tmpfiles snippets. This works fine for most services. However, audit is special because it uses DefaultDependencies=no, After=local-fs.target. Thus it starts before systemd-tmpfiles has a chance to create /var/log/audit. There are a few options: 0) Explicitly order auditd.service After=systemd-tmpfiles-setup.service 1) Patch auditd to create the directory itself if it doesn't exist. The annoying part of this is you need to ensure you get the SELinux labeling right. 2) Ship the systemd-tmpfiles snippet in auditd I've attached a quick patch for 0) (not tested yet).
That sounds like a security issue. We need to have lastlog, btmp, utmp, and audit logs persistent. Unused accounts are detected via lastlog so that they can be locked after a time out. We also have requirements to display the number of bad login attempts since the last successful login as well as the last login. These files are all kept in /var. Are they being persisted somewhere and copied back? Audit should be in the same boat because of forensic information it gathers.
We can handle 1 with SELinux without any change. By simply having a transition rule on auditd_t creating the audit directory in a directory labeled var_log_t. commit fbb839977ad1857f3d6499eb609d73326479ee91 Adds these rules to SELinux Policy.
Steve this is only for initial boot. These files would get created on first boot and then would persist.
Yep, /var is persistent. In the OSTree model by default it's a bind mount out of the root to a regular directory, but I'll likely support in the future having it be a mount point itself. This bug is just about how the directories get created. The feature that doing it on boot enables is you *can* choose to rm /var/* -rf and reboot to get a "factory reset".
What about /var/lib/systemd/random-seed? Its needed so that entropy generated during install is preserved so that sshd does not generate the same or similar keys as any other server would. Wrt to auditd, there have been questions about its order in the past (mostly around not being early enough). I was hoping to work out the boot sequence during common criteria. It should be started after all disks are mounted because it may have rules for those paths but before most daemons so that it catches any AVC or system modification that a daemon could make.
When I say /var starts out empty, it is a bit of a lie =) In practice right now I precreate /var/log/journal for example, since otherwise there's a messy bootstrapping problem between journald and systemd-tmpfiles. As to your specific question about /var/lib/systemd/random-seed: If you install via Anaconda, it'll be there on first boot.
Hi, any objections to this patch?
I honestly don't know what systemd does under the hood and can't make any judgment about the patch one way or another. The main thing audit needs is to start at the first chance so that it records service start ups or any AVCs caused on boot.
Pushed into upstream commit 967.
audit-2.3.8-0.2.svn20140803 was pushed to rawhide and f21 a couple days ago. Please let me know if anything else needs to be done.
This is fixed.