4

I work for a company that makes portable devices running Linux and I was recently asked to make the underlying file system read-only for "security" purposes.

Since the distribution is based on LinuxFromScratch, I know that very little writing happens at run time. So, even if the device runs on a usb flash device, I doubt that putting the root file system RO will be that beneficial.

I am actually more concerned about a process actually breaking because it cannot open a file in RW mode than a process going rogue and filling the root file system with log files, etc.

I'd really like to ear what kind of advantages disadvantages there really is with read-only file-systems.

Thanks!

2
  • Currently reading about union fs. While it seems to be working it doesn't seem to be a long term solution.
    – bookmarc
    Commented Nov 3, 2010 at 15:57
  • I'm thinking more and more about reviewing the partition layout. I currently only have one root fs and a user reserved partition. This user partition only contains files created by the user and nothing else.
    – bookmarc
    Commented Nov 3, 2010 at 16:02

6 Answers 6

4

Making the filesystem read-only isn't a foolproof mechanism. It does, however, make life more complex for an attacker. If their attack relies on dropping a file to be executed later, then they fail. If their attack isn't custom built for your portable device, then they fail.

It does also prevent the filesystem from filling (and helps you isolate any issues that might have arisen in that case) and prevents performance of the filesystem from changing due to fragmentation / filesystem changes.

As far as the danger of an application failing, that is the job of your testing team. Test the device thoroughly and you can be confident that everything is fine. Note that the read-only filesystem will come up again when you work on in-the-field updates.

3

Security is never about your processes "going rogue" with log files.

It's about processes not made by you "going rogue" and wiping the thing from existence.

Especially in the hands of users, read-only is the most basic protection you can give them.

0

The main disadvantage is not being able to store persistent data that the user might want - like a password that's not 'universal' - or customisations to program settings. While useful for some purposes a RO installation is (usually) a pain-in-the-aaa for long term users.

0

You'll want an append-only file system for logs, but that would be another partition from system.

Most user processes can handle a RO system in ROM if they don't run as root. They only need to write to a few files.

0

If an evil person h as gotten into your system with a privileged account then having a filesystem mounted read-only doesn't really help you all that much since the attacker could just remount read-write if the underlying media is not also read-only.

Unless you have a really strong reason to enable it, I wouldn't. Personally I think a good backups combined with good log data that shows who changed what and when is far more useful. Setting up services not to run under the root account and having properly configured filesystem permissions are also more useful.

1
  • The application described is for portable devices. Consumer devices are not going to take advantage of log data. Commented Nov 3, 2010 at 20:33
0

I would say one of the advantages is that if the system partition can (and therefore will) be upgraded in bulk (like a whole system image kind of thing), mounting it RO ensures the update doesn't overwrite things that got changed. In a tight environment such as an embedded device, mounting read-only forces you to examine every write access any of the system components makes, and then carefully decide whether this change is volatile (put on some tmpfs, like the dhcp lease info) or has to be kept (even across updates, so put on some RW user or system partition).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .