# How to protect log files from root?

## Jimini

Hey there,

I am currently thinking about how to protect a system's log files even from root. By crawling Google, I found the following blog post: http://blog.siphos.be/2015/07/restricting-even-root-access-to-a-folder/

Thus, it is possible to use SELinux to prevent root from reading a directory. I assume, that it should be possible to grant root read access, but to prevent him from writing into the secured folder. 

Could it be possible for root to take over the syslog user to be able to delete / manipulate log files?

Best regards,

Jimini

----------

## bunder

I'm not sure if this is possible since most sysloggers run as root.  If root can't write, chances are the loggers can't either.

----------

## NeddySeagoon

Jimini,

Anyone who has root can do anything. SELinux can delay things.

You need to log to a remote system, so that the logs are not even on the system whose logs you want to protect.

The remote system needs a different root password to the system you want to protect too.

----------

## krinn

put a post-it "do not delete anything in /var/log" on your sreen  :Wink: 

----------

## Jimini

 *bunder wrote:*   

> I'm not sure if this is possible since most sysloggers run as root.  If root can't write, chances are the loggers can't either.

 

syslog-ng seems to be able to run as a different user: https://syslog-ng.com/wiki/syslog-ng-faq-non-root

 *NeddySeagoon wrote:*   

> Jimini,
> 
> Anyone who has root can do anything. SELinux can delay things.
> 
> You need to log to a remote system, so that the logs are not even on the system whose logs you want to protect.
> ...

 

Yes, of course these procedures would not lead to absolute security. But it would be at least a big step if I could document, when someone manipulates or deletes log files.

 *krinn wrote:*   

> put a post-it "do not delete anything in /var/log" on your sreen ;)

 

:D

To be honest, I am only thinking of a situation, when a root user is not trustworthy anymore. Maybe a dedicated logging server with multi factor authentication and tenshi, which sends an email as soon as the connection to the logging client is interrupted?

Best regads,

Jimini

----------

## depontius

Or "chattr +a" your log files, then drop the capability to run the chattr command from the system bounding set.  Once it's dropped only PID1 can restore it, and I don't believe systemd has added that function - yet.  This also means that you'd have to reboot in order to rotate your logfiles.  After rotating logs you'd want to "chattr +i" old logfiles.

chattr +a - append-only

chattr +i - immutable

Offhand, remote logging is easier.  If you want to be paranoid about the remote logging, get to that system through a hub (or add an upstream tap) and add a "stealth logger" that has no other network presence detectable.

----------

## mvaterlaus

Hi Jimini,

you could secure your logs with a cryptographic hash[1], so you can at least tell if someone modified the logs. The article is a good read, because it also explains other, additional approaches to secure your log files.

[1]https://security.stackexchange.com/questions/4320/techniques-for-ensuring-verifiability-of-event-log-files

----------

## Ant P.

Very late reply, but there is one case where the kernel won't even let root access another user's filesystem hierarchy: FUSE mounts.

It's usually a source of much aggravation but maybe here it could work as an advantage. Make it an encrypted mount with password supplied at boot, and it'll be *very* hard to circumvent.

----------

