Stateless SElinux and writable rootfs

Hello everybody,

I am new to CL coming from Fedora Silverblue.
I am doing a comparison of the two in terms of security.
The only real two differences I can spot is that

  • Fedora has enabled SElinux by default
  • Fedora’s rootfs is mounted read-only by default
    Thoughit seems to me that SElinux makes not that much sense with stateless systems,
    the thing is that still /usr is writable and the first place if I were to write some malware would be /usr/share/defaults that loads something else, having read only rootfs would prevent this, although to have enough permissions to write into /usr would mean that you could just as well remount /usr as read write anyways, what does CL team thinks on further securing the system, is there such need? Would volatiling the system help?

You can read some more details about the security techniques here: A lot of it is the philosophy which comes through in the details.

While Clear Linux does not enable SElinux, it’s important to note that SElinux can do a lot more than just filesystem permissions. It can allow for very granular security policies and contexts. Unfortunately, it often isn’t configured properly and gets in the way more often than not. And too many tutorials online start by saying “disable SElinux” :man_facepalming:

A while ago I spend some hours to understand a bit about SElinux.

What I am trying to say with this post is clear linux should add to the wiki
the reasoning how stateless obsoletes selinux/apparmor:

  • while selinux is great and except for creating a custom Fedora live cd (even not for creating ostree’s or rpm building) selinux did never cause problems and was always enabled.

  • Selinux adds a lot of theoretical security (and slight attack vector),
    preventing infected process A to mess with uninfected processes B:C:D and data prevented
    due to the data and the process being in different context in addition to normal user permissions.

  • Putting selinux on the scales the actual benefit it provides (as the added attack vector and process A and processes BCD equals 0) is infected process A messing with data.

  • the stateless model defeats the purpose of mac’s [the access control, selinux, apparmor] (process A messing with data as the integrity of all files can now be verfied) and clear linux should add this to the wiki as to why there is no need for macs.

  • for the last statement to be completely true though the rootfs needs to be validate-able in one additional way: swupd --make-sure-no-additional-files-in-dirs-notetc-notvar-notopt as adding new files can cause as much of a security issue as manipulating existing files. Having the rootfs read only adds only hypothetical security as an infected process A can just remount stuff although maybe a good idea to default to /usr readonly but remounted on swupd
    EDIT: I think swupd --picky does that

Good security practices are an incredibly good way to secure your online systems, and stateless aspects significantly help, but they’re not mutually exclusive, and certainly do not obsolete MACs - so I would hesitate to write documentation that suggests just that.

Stateless protection is not providing dynamic protection. Clear Linux downloads are checksumed but thereafter you can update any or all.
The warning from Clear Linux is the next update to /bin, /usr, /sbin… some of /etc will overwrite previous values, including the variables you added. Your changes only last to the next update.

To my knowledge, Selinux and app-armor are dynamic realtime access management validators. Both protect the system from unauthorized actions by unauthorized applications.