[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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

>> 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

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
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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]