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

[Colin Walters <walters verbum org>]

On Thu, Sep 7, 2017, at 02:51 PM, Ryan Barry wrote:

I'd imagine the same. That said, oVirt Node is also not managed by yum, and the specific request there was still to have separate filesystems. The theory being that a runaway process or attacker which/who fills one of the partitions can't lock out the entire system or block logging of activities.

In that sense, I suspect that most of the guidelines still apply.

Right, I'd agree.

We did something similar in vintage oVirt Node, so I completely understand -- we saw a large number of problems with some system utilities not playing nice with bind mounts and redirection/symlinks on a ro root, but that's a definite tangent.

The only bind mount we have by default is var; the only side

effect I can think of for this is

https://github.com/ostreedev/ostree/issues/960

>> In my testing, Atomic seems to only take ~3GB of the volume group when installed,

That's going to change; it already has for FAH (this is why I tend to use

abbreviations like FAH, CAH, and RHELAH since there isn't just one "Atomic").

See https://pagure.io/atomic-wg/issue/281

https://bugzilla.redhat.com/show_bug.cgi?id=1391725

Updating the document is certainly a solution, though I expect that /var/log and /var/log/audit will need to be separate volumes, at least. I would also not be surprised to see that /opt and /home needed to be also, so docker containers with VOLUME could not maliciously fill those and simultaneously fill /var

Is this something we can help with?

I just tested this with

Fedora-Atomic-ostree-x86_64-26-20170821.0.iso

and it worked fine to make `/var/log` and `/var/log/audit` mount points.

Outside of that, "full" STIG compliance (minus bootloader locking and some other finicky bits -- cloud-init can handle most of the edge cases for users who want the whole shebang) is another target. I've seen some work on openscap for Atomic, but I haven't tried a run yet to see what the status is...

What do you mean by bootloader locking?  Secure boot?  Or

having /boot be read-only?  Something else

Hmm, are you talking about cloud-init on bare metal?  We were playing with

that but didn't really "productize" it.