Re: [atomic-devel] Atomic and NIST-800/STIG compliance

[Colin Walters <walters verbum org>]

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?