0

Now, it may sound silly, but here is the idea:

I want to make so that to write on a file the user (even if is the root user) will need a key. The first thing that may have popped onto your mind may be:

"Why not just encrypt the file?"

My idea is to do this on certain configuration files. They can't be encrypted, or the system would crash. Also, with this approach, I would still be able to read the files and see how they are set up.

I know this fundamentally sounds very against the linux system's logic: why would the root user prevent itself from having power over his own system? The answer is: I am the root user and I want to protect me from myself. But for real: chmod -w file is, of course, easily reversed.

This may be fundamentally impossible, but I figured there was no harm in asking.

chedieck
  • 1

2 Answers2

1

You're looking for an integrity protection system, not for an encryption system.

In theory...

  • One way to achieve this is using digital signatures – they're usually made using an asymmetric key pair (such as RSA or ECDSA). After performing writes you use the private key to sign the final file, and whenever reads are performed the OS uses the public key to verify the signature and match it against the contents.

    (You might be familiar with using SSH pubkeys – well, they're exactly the same thing. SSH pubkeys work by signing the login challenge which the server can verify i.e. "read", but no one except you can "write".)

    Linux appears to support this through the IMA/EVM subsystem.

  • Another way to achieve this is using a plain hash that's just stored in a place that even root is not allowed to modify. For example, Linux has the dm-verity subsystem, which is often used on embedded devices – the entire "/" filesystem is read-only and its hash is stored in a separate flash area accessible only by the bootloader.

In practice...

  • Root can bypass these mechanisms by simply using mount --bind to overlay a different file on top of your "verified" file. For example, even if you make /etc/sudoers completely unwritable, root can create a new file in /tmp and use mount --bind /tmp/sudoers /etc/sudoers to make the same file appear inside /etc. As this happens at the VFS layer, it is completely unaffected by any lower-layer security protections.

  • So if you really want to constrain root, you'll need some of the above mechanisms and you'll need Secure Boot and you'll need SELinux or other similar "mandatory access control" system, just to create additional hoops to jump through.

  • Or really just remove your own root privileges completely.

u1686_grawity
  • 426,297
  • 64
  • 894
  • 966
0

Linux has FUSE, an API to implement file systems in use space.

Think of some way to store a key or keys (in a different, or at the beginning of each file). Think of some way to have the user communicate a key to unlock the file for writing. For example by requiring that key as the first part of the write (maybe with fixed length). Or by providing an additional companion file you need to write the key to. Think of some way to automatically lock the file again, e.g. after a tinmeout.

The take the example implementation and modify it with these ideas. Done.

dirkt
  • 16,421
  • 3
  • 31
  • 37