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 useabbreviations 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 withthat but didn't really "productize" it.
