3 ms·

Oh, I forgot one! The OS is read-only while the host is up, which is a big security and stability benefit.

usr1106 7y ago
Fedora CoreOS is read-only? CoreOS Container Linux is not. But changes are not persistent over redeployment. That's nice for quick testing and development, but of course fatal should you do it in a production system. And of course not ideal for security. Disclaimer: Edited for false claims. Hope, it's correct now...
- robszumski 7y ago
  Go look at /usr on Container Linux, where the actual OS lives. It’s literally mounted R/O. Binaries are symlinked from there, so it’s impossible to modify OpenSSL, etc.
  - fulafel 7y ago
    How is root prevented from modifying it? (Readonly mount alone is trivial to bypass)
    - robszumski 7y ago
      The entire partition is signed so the machine will detect it
    - pa7ch 7y ago
      dm-verity mainly https://coreos.com/blog/verifying-os-at-runtime.html https://coreos.com/blog/verifying-os-at-runtime.html
      - cmurf 7y ago
        Bit more on dm-verity as it relates to appliance and non-appliance systems. https://blog.verbum.org/2017/06/12/on-dm-verity-and-operating-systems/ https://blog.verbum.org/2017/06/12/on-dm-verity-and-operatin... Btrfs will support cryptographically secure hash algorithms (sha256 and blake2) starting with kernel 5.5. I wonder if this is a suitable compromise over dm-verity, which can't be updated, and more conventional file system options? When I consider various use cases, Btrfs always results in EIO rather than propagating bad data to user space; compress=zstd:1 reduces writes, saves storage space, and can improve performance of slower storage. There's also two interesting read-only options: read-only snapshots and read-only volume (via the seed flag), root can't write to either. Root would need to unset the flag first. A read-only seed can support writes via a volatile 2nd device, e.g. /dev/zram device, reboot and you get a reset. Or persistence via a partition. Either way a reset also resets filesystem state.
igetspam 7y ago
I'm shipping a test appliance out this week but we haven't completely locked on a production OS. This feels like an interesting path. Host level data persistence isn't something I need or desire, so a RO filesystem is perfect. For $reasons I've been on an Ubuntu track (changed from Debian because of an official upstream LTS). My hesitation about Fedora is the fact that it's bleeding edge (ish) and doesn't have an LTS path (reasonably, bases in the design goal). The evidence is in they fact that the upgrade path is not expected to be smooth here. I can eat a lot of shakeup in my own data center or cloud but a shipped box makes that a lot more problematic.

Fedora CoreOS is read-only? CoreOS Container Linux is not. But changes are not persistent over redeployment. That's nice for quick testing and development, but of course fatal should you do it in a production system. And of course not ideal for security. Disclaimer: Edited for false claims. Hope, it's correct now...

robszumski 7y ago
Go look at /usr on Container Linux, where the actual OS lives. It’s literally mounted R/O. Binaries are symlinked from there, so it’s impossible to modify OpenSSL, etc.
- fulafel 7y ago
  How is root prevented from modifying it? (Readonly mount alone is trivial to bypass)
  - robszumski 7y ago
    The entire partition is signed so the machine will detect it
  - pa7ch 7y ago
    dm-verity mainly https://coreos.com/blog/verifying-os-at-runtime.html https://coreos.com/blog/verifying-os-at-runtime.html
    - cmurf 7y ago
      Bit more on dm-verity as it relates to appliance and non-appliance systems. https://blog.verbum.org/2017/06/12/on-dm-verity-and-operating-systems/ https://blog.verbum.org/2017/06/12/on-dm-verity-and-operatin... Btrfs will support cryptographically secure hash algorithms (sha256 and blake2) starting with kernel 5.5. I wonder if this is a suitable compromise over dm-verity, which can't be updated, and more conventional file system options? When I consider various use cases, Btrfs always results in EIO rather than propagating bad data to user space; compress=zstd:1 reduces writes, saves storage space, and can improve performance of slower storage. There's also two interesting read-only options: read-only snapshots and read-only volume (via the seed flag), root can't write to either. Root would need to unset the flag first. A read-only seed can support writes via a volatile 2nd device, e.g. /dev/zram device, reboot and you get a reset. Or persistence via a partition. Either way a reset also resets filesystem state.

igetspam 7y ago

I'm shipping a test appliance out this week but we haven't completely locked on a production OS. This feels like an interesting path. Host level data persistence isn't something I need or desire, so a RO filesystem is perfect. For $reasons I've been on an Ubuntu track (changed from Debian because of an official upstream LTS). My hesitation about Fedora is the fact that it's bleeding edge (ish) and doesn't have an LTS path (reasonably, bases in the design goal). The evidence is in they fact that the upgrade path is not expected to be smooth here. I can eat a lot of shakeup in my own data center or cloud but a shipped box makes that a lot more problematic.