Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

Is there a way to protect a file in such a way that even root cannot delete it or rewrite it after creating it? I have a file which is created by root under /var/log/ and I want to restrict all users (including root) so that they can just read this particular file after it has been created.

share|improve this question
    
If you want a way to stop even root, completely, then you need mandatory access control. see en.wikipedia.org/wiki/Mandatory_access_control It may however be more complex than you need. Protecting the one file is not enough, as a change to any significant system file could be used to circumvent it. –  richard Dec 16 '13 at 22:30
2  
This is not a duplicate of How do I make a file NOT modifiable?! This question asks for something that root cannot undo. The other question only addresses the cooperative case. –  Gilles Dec 17 '13 at 13:40

6 Answers 6

up vote 7 down vote accepted

No there is no way to do this, to my knowledge. The answer about chflags pertains to BSD variants. A similar command for Linux is chattr.

The concept of the root user is that they can do anything on the system.

share|improve this answer

You may be looking for the "system immutable" flag. The details may depend on precisely which operating system you're running, but the basic idea will be the same. You'll want something like this in BSD (or OSX):

# chflags schg /path/to/file

or the equivalent in Linux:

# chattr +i /path/to/file

Note that root can always remove the system immutable flag in order to change the file, so your next option is to place the file on a read-only filesystem. Even so, with root access one might still be able to unmount a read-only filesystem and mount it read-write.

The next step would be to put it on a physical disk that has a write protect switch. Check with your vendor to see if this is available with your hardware. If it is not, you could consider putting the files on a WORM drive of some sort. A CD-R is an option.

What about putting the file on a read-only NFS filesystem stored on another server?

Probably easier to figure out a better solution to this XY problem.

share|improve this answer
    
It is a modified version of SUSE Linux. Not sure if this command is available in it. I will check it later. –  coffeMug Dec 16 '13 at 20:06
1  
chflags is for BSD variants, chattr might do what you want. en.wikipedia.org/wiki/Chattr –  slm Dec 16 '13 at 20:11
    
@slm, good catch, I guess I'm showing my colours. :-) I've updated my answer. –  ghoti Dec 16 '13 at 20:30
    
or write to /dev/printer –  richard Dec 16 '13 at 22:35

Generally speaking, root can do everything. Whatever steps you take to prevent root from doing something (such as setting file attributes), root can undo.

OpenBSD and FreeBSD have a notion of security level, also known as securelevel. The securelevel is an integer value. If the value is negative or 0, only the usual unix security rules apply. At securelevel 1 and above, a number of restrictions come into place, in particular:

  • It is impossible to reduce the value of the securelevel.
  • It is impossible to load or unload any kernel module. Thus the code running in kernel mode cannot change anymore.
  • Raw access to the memory or block devices is disabled.
  • The chflags system call denies attempts to remove the immutable or append-only flags from any file.

Securelevels 2 and 3 add additional restrictions. The important thing is that it is impossible to reduce the security level without rebooting, even with root access. Thus securelevels bring in restrictions to what root can do, at the expense of making certain maintenance tasks impossible (such as repairing or reconfiguring a RAID array).

Of course these restrictions are only effective against users who do not have access to the physical machine or to a console during boot. The bootloader data (including the kernel file) must be immutable, otherwise a root user could introduce a backdoor and trigger or wait for a reboot.

It may be possible to configure something like this with Linux's security frameworks (AppArmor, SELinux, …), but these are primarily tools to set restrictive policies for processes that are not running as root. If it is at all possible, it would require a lot of care in defining the policy (even in the ordinary case, designing useful policies is hard).

If you don't have the option to restrict root's power in this way, the way to make a file read-only for root is to store it on a different system. Options include:

  • Run the system in a virtual machine and store the file on the host.
  • Store the file on another system accessible via the network.
  • Store the file on a physically read-only media.
share|improve this answer

Seems like the only valid way is to use chattr command as follows:

chattr +i /var/log/file

This way even root cannot modify the file unless it removes the i attribute from the file.

So it is just one step toward a better protection I think.

share|improve this answer
2  
I would consider it useless protection, but if you must 8-) –  slm Dec 16 '13 at 20:15
    
I agree...! ;-) –  coffeMug Dec 16 '13 at 20:16
    
“root cannot modify the file unless it removes the i attribute from the file”. Or in other words this doesn't actually solve the problem. –  Gilles Dec 16 '13 at 23:12
    
@Gilles OK true; is there a solution though? –  coffeMug Dec 16 '13 at 23:19
    
@coffeMug Not on Linux, as far as I know. See my answer for an answer on FreeBSD and OpenBSD. –  Gilles Dec 17 '13 at 13:45

Will the file be frozen, or do you need to keep writing to it? In the first case, you could put the file on a read-only medium: CD-ROM, flash drive with a physical write-protect switch, etc. (That protects the integrity of the file, but wouldn't prevent root from unmounting it and/or masking it with a fake).

If you want to continue writing to the log file, there's no solution unless you can find a write-once-read-many physical medium: If a file can be written to, it can be overwritten. (For completeness: It is possible to set a file's "append-only" attribute with chattr or chflags, which will protect the file contents from being overwritten. But it is not possible to block root from unsetting this attribute.)

share|improve this answer

chattr can do this, or at least something pretty close to it. There are two attributes that may be relevant, depending on what exact behavior you want.

For example, you may want to set the a attribute, using chattr +a filename:

A file with the `a' attribute set can only be open in append mode for writing. Only the superuser or a process possessing the CAP_LINUX_IMMUTABLE capability can set or clear this attribute.

Since this would seem to be a log file, that may be the more appropriate option. Or you can use the i attribute:

A file with the `i' attribute cannot be modified: it cannot be deleted or renamed, no link can be created to this file and no data can be written to the file. Only the superuser or a process possessing the CAP_LINUX_IMMUTABLE capability can set or clear this attribute.

Note that the superuser can clear these attributes with the corresponding chattr -X command.

share|improve this answer
    
chattr can do this” — where you mean “chattr cannot do this”, since root can do chattr +i. –  Gilles Dec 16 '13 at 23:12
    
@Gilles I'm not sure what you're getting at; even the OP's self-answer specifically mentions chattr +i. Even root cannot modify immutable files as long as the immutable attribute is set. I don't think there's anything that root can do that root cannot undo. (Well, maybe encrypting the file and throwing away the decryption key could work, but I don't think that's very useful...) –  Michael Kjörling Dec 17 '13 at 8:01
    
Just because it's a self-answer doesn't mean it's correct. On OpenBSD and FreeBSD, there is an immutable flag that root cannot unset, if the OS is configured for it (which implies a trade-off between security and ease of maintenance). See my answer for details. –  Gilles Dec 17 '13 at 13:46
    
@Gilles Of course a self-answer is not necessarily correct, but in this case it does state that chattr is a "valid way" to do what the OP is trying to do. (It was also posted about ten seconds before my answer, which is a big reason why I'm leaving my longer answer around.) –  Michael Kjörling Dec 17 '13 at 13:48
    
And in the comment exchange: “this doesn't actually solve the problem.” — “OK true”. Your answer, like coffeeMug's, would be ok for the duplicate question, where a cooperative solution is good enough. But this question requests security from root. –  Gilles Dec 17 '13 at 13:58

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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