2

I'd like to know how to make files completely immutable. "Completely" refers in this case to: immutable while the system is running. I could live with something like physical access where someone e.g uses a live cd to change the immutable files on a harddrive. I'm not worried about physical access that much.

I know there is chattr -i which makes a file immutable. Of course some hacker could just change the attribute back. According to the debian security manual (https://www.debian.org/doc/manuals/securing-debian-howto/ch4.en.html#s4.17 under 4.17.2) you can prevent this by removing the CAP_LINUX_IMMUTABLE capability and making lcap itself immutable. According to this site: https://www.win.tue.nl/~aeb/linux/lk/lk-7.html you also have to remove CAP_SYS_RAWIO because it allows to patch the running kernel code. This is not mentioned in the debian manual.

Also from crossreading some other sites regarding sandboxing on linux, seccomp etc I gathered that kernel exploits in principle can bypass such systems with reduced capabilities. But I'm not sure if this also holds true for my case.

I'm assuming the attacker has complete (except physical) access to my system. Will the capability based approach above prevent him from changing the immutable file X on my system? If not is there anything I could do in order to accomplish this?

Improve this question
9
  • 2
    put on read-only media?
    – schroeder ♦
    Commented Feb 12, 2016 at 18:07
  • I also had sort of this idea. But in my case they should belong to a running live system with everything copied to RAM. Usually aufs or overlayfs is used for this and the underlying boot media with the "real" files is removed anyways. But the files also exist in RAM and still could be changed there.
    – rover01
    Commented Feb 12, 2016 at 18:15
  • ok - then you need to put this requirement in your question. BTW, why not place the sensitive files on a RO media to satisfy your requirement? Pretty cheap and easy solution that cannot be circumvented (through software).
    – schroeder ♦
    Commented Feb 12, 2016 at 18:20
  • This would of course be an option. What RO media would you suggest ? CD, DVD? But my threat model is rather advanced so I'd like to add no devices to my system if possible. Firmware attacks are rare, though they exist. I would really like to have a USB or DVD drive where I can be 100% sure that the firmware can't be changed (without physical access). For the moment I would prefer a software approach e.g. via removing capabilities. Though I'm not sure if this is enough. I also have to ensure that only these specific (driver) files are used. Guess I'll open another thread for this.
    – rover01
    Commented Feb 12, 2016 at 18:55
  • 2
    Are you saying you want to ensure that a specific file / datum is read-only for as long as the system is live, including when the kernel is compromised? If the kernel is compromised it doesn't matter to the attacker what is on that file. They can simply serve anyone who asks for said file something else instead. Or am I missing something?
    – Steve Dodier-Lazaro
    Commented Feb 12, 2016 at 22:49

2 Answers 2

Reset to default
4

If the kernel is exploited then any software based constraints on file access can be bypassed. Using an encrypted filesystem would prevent someone from booting up from a USB key or removable media, mounting the filesystem and changing the file, but not against a loadable kernel module inserted in the running system.

I remember when most hard disks had jumper settings to make them read only at the hardware level, but its been a long time since I've seen such a device. Maybe some disks still do this but you might have to do a bit of digging.

You can get USB drives with a physical switch. But they are not cheap - indeed it might be easier to set up something like a raspberry pi with read only NFS access.

Improve this answer
1
  • Those physical switches usually just toggle a firmware-defined rule for disallowing writes. I don't believe it actually cuts power to the flash write pins.
    – forest
    Commented Nov 17, 2018 at 8:26
0

With code executing in the kernel the readfile calls could be hooked to return attacker defined data regardless of the file's actual content. Or the process could get killed and restarted in a chroot, or , or, or.

The short answer is it cannot be done.

Improve this answer

You must log in to answer this question.

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