Hi Ryan, thanks for bringing this up! On Wed, Aug 23, 2017, at 03:31 PM, Ryan Barry wrote: > > /home > /opt > /var > /var/log > /var/log/audit
As I understand it, the NIST-800 specification was designed for a "traditional" system managed via yum. I imagine they did a default RHEL7 install and looked at hardening on top of that. The ostree model is in contrast *very* prescriptive about the system layout. It's different from how things worked before, but I think still compatible enough; and worth the change. There's some more info here: https://ostree.readthedocs.io/en/latest/manual/adapting-existing/ But this boils down to: every mount point you've listed above actually lives underneath /var. Stated even more strongly, *all local state* lives under /var or /etc, and everything else appears immutable (though rpm-ostree can mutate it). > > (ideally with any 'persistent' data like the rpmdb relocated off of /var, Indeed: ``` $ rpm-ostree status State: idle Deployments: atomicws:fedora/x86_64/workstation Version: 26.64 (2017-08-23 07:44:49) BaseCommit: 73f5c6bfa0365f4170921b95ae420439f2f904564c7bdb12680dc1c8ddd47986 $ ls -al /var/lib/rpm lrwxrwxrwx. 1 root root 19 Apr 18 15:29 /var/lib/rpm -> ../../usr/share/rpm ``` > with the contents of /var[/*] being the same across all ostree instances, so > logs are not lost if users need to roll back). Yep, that's also enforced. ostree (and rpm-ostree) will never touch /var, whether upgrading or rolling back. The only twist here is that we generate systemd tmpfiles.d entries - so for example `rpm-ostree install postgresql` will cause some directories to be generated on the *next* boot. Related to all of this, rpm-ostree for example will cleanly reject installing RPMs that do things like have content in /home: https://github.com/projectatomic/rpm-ostree/issues/233 > In my testing, Atomic seems to only take ~3GB of the volume group when > installed, though I understand that the remainder of the volume group is > often used for Docker image storage. We performed a conversion to a NIST-800 > layout as part of an update on oVirt Node, but we were fortunate enough to be > using lvmthin, so we didn't need to worry too much about it, but I'm not sure > how this would be done on Atomic. I know that /var was added recently, so > some shuffling must be possible, but I haven't looked into the details of how > that was performed. Yep, it's ironic that it took so long for https://github.com/ostreedev/ostree/pull/859 to land - it really helps complete the picture of having basically all local system state easily put onto separate storage, consistently backed up, etc. > Additionally, getting as close as possible to full STIG compliance would be > ideal. I see that atomic supports scanning containers running on Atomic > hosts, but I'm not sure what the actual status of the host itself is. I think we can do that more easily now that the above PR landed; however, it seems likely to me that the guidelines need to be updated to account for things like /home → /var/home. Also unfortunately for RHEL7, systemd refusing to mount on symlinks is fairly problematic. See: https://github.com/systemd/systemd/pull/6293 But administrators can work around that by using /var/home as the mount point. Anyways, so I think the current F26AH's support for /var as a mount point covers most of this; the tricky part is probably updating the document to account for the ostree/AH differences?
