This is a quick post - I’ll flesh it out later, I promise. I haven’t posted in a while, and I wanted to brain dump what I’m working on at home in some VMs.

Long story short: I accept the fact that at some point, all of my computers will be compromised. Whether that compromise is mass-malware, or some kind of targeted attack is irrelevant. The point is some kind of unauthorized change will occur. If I can reduce the number of disk locations that are writable, I can reduce the number of locations an attacker can leverage to remain on my system.

It’s entirely possible to remain persistent on a system w/o making any changes on-disk, but that’s outside of the scope of this post. Lets assume for the sake of argument that the attacker will want to keep my computer compromised. They’ll need to make some kind of change so they can stay on the system. Replacing the binary of a system service with a trojanized one, adding a new service to start on boot (e.g. in /etc/init.d, or in /etc/systemd), modifying some user’s login scripts, or reoccuring scheduled task (via crond, or atd, etc).

It’s my goal to reduce the number of locations that the attacker can add new things, or replace existing things to keep their foothold on my system. If they can’t add new things to come up on boot, it’s more difficult. This isn’t perfect, but something that could be part of an overall security-minded system posture.

I know that having a UNIX box’s filesystems read-only isn’t a pancea, I read an article once that described a specialized UNIX box that had it’s root filesystem in a read-only flash/PROM device - which the vendor said made it more secure - ultimately, the executables on the read-only device had vulnerabilities, which couldn’t be patched because the filesystem couldn’t be modified. So there are ups and downs of this concept.

Fedora has read-only root support, enabled by /etc/sysconfig/readonly-root. To get it working on a brand new install, you need to do two or three things.

1. Comment out the root filesystem in /etc/fstab - otherwise it will be mounted read-write (this also comes with a side-benefit, alternate root filesystems).
2. Create one or two new filesystems with a specific label for retaining state (read /etc/sysconfig/readonly-root for details).

At this point you should have a read-only root filesystem. Any other filesystems (like /boot) are most likely still read-write, so you’d have to change those to read-only if you want them locked down too.

Bonus: Linode has an API method w/ a read-only flag to set VPS disks to read-only.