6

Is it possible from a bash running as a non-privileged user to mark the file immune so it cannot be altered in any way from any process running as that user? It is OK if other users or a root can alter it.

My user case is to prepare a config file before starting another process. I want to prevent that process from doing any modifications to the file either through a bug or through a deliberate exploit.

Using chmod a-w path or similar is not good as it can be trivially undone. I cannot change ownership of the file as the process is not root. I also cannot use chattr +i path as the process does not have CAP_LINUX_IMMUTABLE.

Is the only option to have a setuid/sudo program or a program with CAP_LINUX_IMMUTABLE set on its executable that does such alteration?

9
  • 8
    can you not just read it on stdin? what do you need access to the filesystem link for after the config is prepared? you could just write the config out to a temp file, put it on some descriptor, delete the temp file, then fork and pass the descriptor off to the child. it wouldnt stop the child from modifying in memory what it reads, but nothing will do that - its the child's memory. it will stop the process from altering any persistent copies. – mikeserv Jan 9 '16 at 10:23
  • @mikeserv A very good point about using file descriptors especially if the child can be instructed to read /proc/self/fd/number. Unfortunately in my case the child is a complex web application that starts own child processes that reads the config. So passing fd does not work. Note also that I have workarounds, it is just I thought that I missed something about pemissions. – Igor Bukanov Jan 9 '16 at 11:12
  • i dont get the thing you said about passing the fd doesnt work. if its a complex application it ought to be able to handle an lseek and dup2 per fork. – mikeserv Jan 9 '16 at 14:03
  • If you have a particular program in mind, then you can use LD_PRELOAD and some library to intercept file operating calls any way you want. – TNW Jan 9 '16 at 14:10
  • @mikeserv The grandchild process that reads the config has no access to the fd as the child process closes all unknown fd before executing the grandchild process. – Igor Bukanov Jan 9 '16 at 21:52
1

Apparmor and selinux can be used for fine grained control over a processes permissions. This includes giving a process the ability to read by not write to a file.

firejail is an easier to user wrapper for this.

The --read-only option can be used to drop write access to a file when you spawn a new process - which seems to be precisely what you want.

0

I imagine that the most secure you can possibly make this, without acls or any other user available via sudo or setuid, is by chmod 444'ing the file.

To make chmod'ing the file back to o+w more difficult for any child process, you could try to set up a wrapper script which invokes bash -r --rcfile restricted.rc, where restricted.rc sets PATH to avoid chmod. This doesn't prevent scripts which invoke bash or some other process from invoking a script with its own path and modifying the file, but it's unlikely that anyone's bothered to do so explicitly.

However, creating the files without u+w permissions as a different user is still more operationally sound, if you cannot chattr or chflags.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.