On Thu, 2005-03-24 at 15:58 -0500, Chris Stankaitis wrote:
If there is no 2.4 kernel solution, is there a 2.6/selinux solution to my problem? that would not allow anyone (even root) to do anything but append to logs?
Yes, definitely. SELinux provides a fine-grained "append" permission for files that one can grant to specific domains for specific file types (such as log files).
How exactly you implement this depends on which threats you are trying to counter. If you are simply trying to prevent a compromised daemon program which runs as uid 0 from changing logs, you could probably stick with the default Fedora "targeted" policy, which for a number of daemons such as Apache HTTPD already enforces this restriction. If you have daemons outside the targeted set, it is typically not too difficult to pull in the relevant policy from the "strict" into targeted, although there are a few gotchas which we can help with on fedora-selinux-list.
In order to confine user logins (e.g. someone logging in as root via sshd), you will need to use the "strict" policy. You then have to make a decision on exactly what permissions to grant to the login. One option is to simply place root into the user_r role (i.e. not sysadm_r). There, the login is restricted in a way similar in effect to a Linux non-zero uid. However, system administration such as restarting daemons is not possible.
It is theoretically possible to have a role similar to sysadm_r/sysadm_t but that prevents direct access to log files. However, it seems very likely to me that someone with privileges similar to sysadm_t could indirectly influence log files in other ways; e.g. by simply installing a malicious version of a daemon package. I imagine the same is true of the BSD securitylevel, of course.
One nice thing about SELinux though is that you can use a tool such as "apol" to find all of those means of influence; i.e. what is the information flow from user_t to httpd_log_t. With BSD security levels you don't have any such assurance.
If you have more questions about SELinux, please ask on fedora-selinux-list.
Colin Walters wrote:
On Thu, 2005-03-24 at 15:58 -0500, Chris Stankaitis wrote:
If there is no 2.4 kernel solution, is there a 2.6/selinux solution to my problem? that would not allow anyone (even root) to do anything but append to logs?
Yes, definitely. SELinux provides a fine-grained "append" permission for files that one can grant to specific domains for specific file types (such as log files).
How exactly you implement this depends on which threats you are trying to counter. If you are simply trying to prevent a compromised daemon program which runs as uid 0 from changing logs, you could probably stick with the default Fedora "targeted" policy, which for a number of daemons such as Apache HTTPD already enforces this restriction. If you have daemons outside the targeted set, it is typically not too difficult to pull in the relevant policy from the "strict" into targeted, although there are a few gotchas which we can help with on fedora-selinux-list.
In order to confine user logins (e.g. someone logging in as root via sshd), you will need to use the "strict" policy. You then have to make a decision on exactly what permissions to grant to the login. One option is to simply place root into the user_r role (i.e. not sysadm_r). There, the login is restricted in a way similar in effect to a Linux non-zero uid. However, system administration such as restarting daemons is not possible.
It is theoretically possible to have a role similar to sysadm_r/sysadm_t but that prevents direct access to log files. However, it seems very likely to me that someone with privileges similar to sysadm_t could indirectly influence log files in other ways; e.g. by simply installing a malicious version of a daemon package. I imagine the same is true of the BSD securitylevel, of course.
One nice thing about SELinux though is that you can use a tool such as "apol" to find all of those means of influence; i.e. what is the information flow from user_t to httpd_log_t. With BSD security levels you don't have any such assurance.
If you have more questions about SELinux, please ask on fedora-selinux-list.
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. 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.
The issue comes when you have to try and restrict root from doing something :) I'll pop onto the selinux list and start getting better aquainted with the in's and out's of selinux and the functions which could let us acomplish this.
--Chris
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.
selinux@lists.fedoraproject.org
-
Chris Stankaitis -
Colin Walters