append only file system - selinux?

Colin Walters walters at redhat.com
Fri Mar 25 17:29:13 UTC 2005


On Fri, 2005-03-25 at 11:50 -0500, Chris Stankaitis wrote:

> Esentially as I mentioned what we need to create is a centralized 
> logging server where all our boxes will log to, which in itself is setup 
> in a way so that even root can not modify the logs without it being 
> painfully obvious that the server had been compromised.  

I guess the question is - what requirements for system administration do
you have?  Will the machine run sshd?  Should the "root" user be able to
perform administration over sshd?  If so, what kinds of administration?
Restarting daemons?  Installing packages?  Rebooting?

> We would be 
> turning off logrotate, the box would be a minimal install, with it's 
> only function to run a logger which would write local messages, as well 
> as take in the logs from all other servers.

If the machine is only running syslogd exposed to the network, i.e. no
sshd, then I think you're already basically there with the syslogd
policy in Fedora.  A compromised or buggy syslogd (even though it runs
as uid 0) can only append to log files.  For example, try this:

yum install setools-gui
apol -p /etc/selinux/targeted/policy/policy.18

Then click on the "Analysis" tab.  Then "Direct Information Flow".  In
the starting type box, enter "syslogd_t".  In the "Find end types" box,
enter ".*_log_t$" (i.e. all types ending in _log_t).  Then click "New".
Under the "Direct Information Flow Tree", click var_log_t (which is the
type of /var/log/messages, which is what you're primarily concerned
with).  Note that apol tells you the direct flow from syslogd_t to
var_log_t is:

 allow syslogd_t var_log_t : file { ioctl create getattr setattr append link };

The important thing to note here is that there is no "write" permission
granted from the syslogd_t domain to files with type var_log_t; only
"append".

You can also see transitive flows by using the "Transitive Information
Flow" tab.

> The issue comes when you have to try and restrict root from doing 
> something :)  

Right; that's why I'm trying to get more clarification from you as to
exactly what "root" means and what that user needs to be able to do.




More information about the fedora-devel-list mailing list