Is there a way to stop root from writing to a directory? I already tried chattr but that did not seem to work.
chattr +i directory
Please do not ask such questions without providing your OS details.
Fedora. Sorry.
This seem to be working OK for me:
# cat /etc/fedora-release
Fedora release 31 (Thirty One)
# mkdir nowrite
# chattr +i nowrite
# cd nowrite
# echo > test
bash: test: Operation not permitted
# cd ..
# rmdir nowrite
rmdir: failed to remove 'nowrite': Operation not permitted
# chattr -i nowrite
# rmdir nowrite
1 Like
Note to Original Poster:
You do realize, of course, that when root runs chattr to prohibit writing to a directory, root can also run chattr to permit the same.
So, this method does not stop malicious activity from a user with root privs because root can recursively reverse this using the same chattr command.
You could restrict using chattr and then remove chattr from the system, but that is also not a 'perfect' solution.
The more important question to the original poster is "what are you actually trying to accomplish, why are you doing this and what is the risk profile of the system in question?".
See this post and others like it: Alternative for chattr
On a similar topic....
On some servers I manage, I have configured PAM to enable Google Authenticator for certain commands.
For example, on some servers, I have configured PAM to require Google Authenticator for sudo.
So, depending on your risk management profile, you could configure PAM to require Google Authenticator for chattr (or any other command you want to add 2FA) ; and only have one admin with their GA set up (and keep that mobile phone, for example, locked away in safe if you need added security).
Anyway, not to belabor this point; but you can use PAM and GA to add 2FA to just about any command you wish. I use it for sudo , sshd , and others and it works well. When set up this way, even root needs 2FA for access.
Again, depending on your risk management profile, that may be "enough", or it may not be "enough".
1 Like
Bottom line is you can't prevent root from either doing something on a system or at least acquire the means to do it (as with chattr and similar mechanisms) and do it then. This is necessary because without this amount of freedom root would not be able to function as the systems ultimate administration account.
The usual remedy if you want some file(-space) to be protected from roots tampering is to put it off the server: create an NFS share on some remote server, mount it where you want to be protected from roots access and adjust the rights accordingly. This is the common way of i.e. protecting logs from possible tampering.
Let me correct your words here.
This is not a "usual remedy", but it is one technical control in wide a range of possible technical controls based on the risk profile of the server.
I don't have a lot of time to write a long reply, so let me summarize:
Security is defined, generally, in three areas (1) confidentiality, (2) integrity and (3) availability.
The original poster has not defined which of these are the most critical to their organization / application / server.
For example, the application on this server may be less interested in file integrity than high availability. If that is the case, then having a network mounted device may not provide the insured availability because networks can fail, wires can break, network devices can go down, even unplugged, etc. In one datacenter I worked, I watched a major device fail because a manager rolled his chair (sitting in the chair) over a LAN cable while talking to the team.
Anyway, it is important, when talking about IT security to talk about the risk and define the risk profile; because what is correct for one application / server may not be the best for another; and the controls: (1) techincal,(2) administration and (3) physical.
More later, if this thread gains any traction.
I had the same question some weeks ago. If you really want to restrict root from accessing certain files, SELinux is probably a working way to go. But the high complexity to configure this and the additional overhead it produces(how to backup/recover if root has no access?, ... ) drove me quickly away from starting to go in that direction.
And the question stays: what are you actually trying to accomplish, why are you doing this and what is the risk profile of the system in question?".
The true mark of an IT security professional is one who understands that IT security controls are based on the risk management profile of the system; and that these IT security controls can be any combination of three types of controls.
Risk Management ... is founded on the Intersection of:
(1) Threat, (2) Vulnerability and (3) Criticality.
Type of Controls:
(1) Administrative, (2) Physical and (3) Technical.
In the content of the IT security requirements (part of the risk profile).
(1) Confidentiality, (2) Availability and (3) Integrity.
In this post, the original poster has not provided any basic IT security information (above). All risk management profiles are different and require an approach based on the risk profile; and the choice of controls follow the risk profile.
I have a VERY annoying and poorly written app that has to be run as root and I am not allowed to get rid of, that will not stop writing to a directory and filling up the file system. When this filesystem fills up it prevents people from logging in through ssh then I have login to the console to fix this. This is also an old server that I can can extent the file system because it does not have lvm.
This is a trivial problem to solve without any necessity to tinker with root permissions, etc.
So, when I have this kind of problem (and I have seen the kind of problem often), I would just remove the directory that your process is trying to write to. Problem solved.
In the next case:
If the process writes to a directory you do not want to remove because other processes write to the same directory and you don't want to reconfigure other processes to write to a different directory, then I would just create a crontab file which runs often and deletes the files you want deleted.
In the case where the file name of the log is the same, then just link the name of that file to /dev/null and problem solved. No need for a cron process..
In other words, there are many ways to solve this simple annoying problem.. These are but a few ways to do it.
This is also an example of why it is best, by far, to get people who post here at unix.com to describe the exact problem they are trying to solve, generally speaking.
What do you do to manually clean up?
If you have a general working sequence of commands then you can put them into a shell script.
If the script has successfully run several times, then the ultimate step is to regularly run it from crontab.