Hi,
There has been some work done on a "relaxed" policy. The intention of this policy is to simply protect system daemons, and not user logins. Right now there is just a policy for apache (which doesn't really work due to a kernel bug). Everything else runs in an "unconfined_t" domain, which essentially has every SELinux permission, and thus you are back to relying on DAC.
But we'll be working on improving this policy. Right now the binary packages are called policy-relaxed and policy-relaxed-sources. This is likely to change.
If you want to experiment with this, please see: http://people.redhat.com/~walters/selinux/
Again, much is likely to change, so you should basically only try this now if you are willing to help hack on it :)
One important thing: You need to relabel your filesystem after installation!
I suggest that if you are running the current strict policy you do this:
setenforce 0 rpm -e policy{,-sources} rpm -Uvh /path/to/policy-relaxed*.rpm fixfiles relabel reboot fixfiles relabel
Good luck, and please send bug reports here for now until we figure out how packaging is going to work (and thus what bugzilla product it will be).
On Sun, 2 May 2004, Colin Walters wrote:
Hi,
There has been some work done on a "relaxed" policy. The intention of this policy is to simply protect system daemons, and not user logins. Right now there is just a policy for apache (which doesn't really work due to a kernel bug). Everything else runs in an "unconfined_t" domain, which essentially has every SELinux permission, and thus you are back to relying on DAC.
This sounds like a regression to me. Is this going to be instead of further development of the strict policy, or in addition to it?
Thomas Molina wrote:
On Sun, 2 May 2004, Colin Walters wrote:
Hi,
There has been some work done on a "relaxed" policy. The intention of this policy is to simply protect system daemons, and not user logins. Right now there is just a policy for apache (which doesn't really work due to a kernel bug). Everything else runs in an "unconfined_t" domain, which essentially has every SELinux permission, and thus you are back to relying on DAC.
This sounds like a regression to me. Is this going to be instead of further development of the strict policy, or in addition to it?
We are having talks now and are investigating how we can support both a strict and relaxed policy. Nothing formal has been decided. One of the goals is to figure out how we can have one policy(te) file shared between them that will work for both. I don't want to end up with and apache-strict.te and an apache-relaxed.te. But this is probably a matter of tunables within the policy file.
One of the things we are considering is limiting the number of daemons we will lock down. We have picked out an arbitrary number of 5 for now and are trying to figure out which are the 5 daemons we would like to put in relaxed policy.
My ideas are
apache bind sendmail ftp ssh??? (Not sure this one is worth securing).
I would like to have other comments on what which daemons should be in the first version of Relaxed policy. We hope to have something out this week.
Dan
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-selinux-list
There has been some work done on a "relaxed" policy. The intention of this policy is to simply protect system daemons, and not user logins. Right now there is just a policy for apache (which doesn't really work due to a kernel bug). Everything else runs in an "unconfined_t" domain, which essentially has every SELinux permission, and thus you are back to relying on DAC.
One of the things we are considering is limiting the number of daemons we will lock down. We have picked out an arbitrary number of 5 for now and are trying to figure out which are the 5 daemons we would like to put in relaxed policy.
My ideas are
apache bind sendmail ftp ssh??? (Not sure this one is worth securing).
I am apparently not expressing myself well. My point is that if we are relaxing policy to the point where you are relying on DAC, what is the point? I want to test strict policy on those things where it most makes a difference. In that vein, sendmail and bind are two which have historically had a lot of problems. I would think those would be candidates for stricter policy, not more permissive.
On Mon, 2004-05-03 at 16:16, Thomas Molina wrote:
There has been some work done on a "relaxed" policy. The intention of this policy is to simply protect system daemons, and not user logins. Right now there is just a policy for apache (which doesn't really work due to a kernel bug). Everything else runs in an "unconfined_t" domain, which essentially has every SELinux permission, and thus you are back to relying on DAC.
One of the things we are considering is limiting the number of daemons we will lock down. We have picked out an arbitrary number of 5 for now and are trying to figure out which are the 5 daemons we would like to put in relaxed policy.
My ideas are
apache bind sendmail ftp ssh??? (Not sure this one is worth securing).
I am apparently not expressing myself well. My point is that if we are relaxing policy to the point where you are relying on DAC, what is the point? I want to test strict policy on those things where it most makes a difference. In that vein, sendmail and bind are two which have historically had a lot of problems. I would think those would be candidates for stricter policy, not more permissive.
I think you are in violent agreement in some ways. Selinux people are looking to write policies that lock down a small set of daemons (sendmail/bind/apache/ftp/portmap) but have user space and other items to end up with a permissive policy until wrinkles can be ironed out.
On Mon, 03 May 2004 18:16:57 EDT, Thomas Molina tmolina@cablespeed.com said:
I am apparently not expressing myself well. My point is that if we are relaxing policy to the point where you are relying on DAC, what is the point? I want to test strict policy on those things where it most makes a difference. In that vein, sendmail and bind are two which have historically had a lot of problems. I would think those would be candidates for stricter policy, not more permissive.
I think the intent was "these 5 will be subject to strict policy, but we won't worry about *other* stuff, which will be more relaxed".
So it isn't that sendmail and bind would be less relaxed, it would be things like 'hwclock' and 'ping' that would have the relaxed policy.
So instead of 460 .te files (like policy-sources-1.11.2-18 has), we'd trim it down to the "top 10" and then one catch-all policy.
On Mon, 3 May 2004, Thomas Molina wrote:
an arbitrary number of 5 for now and are trying to figure out which are the 5 daemons we would like to put in relaxed policy.
My ideas are
apache bind sendmail ftp ssh??? (Not sure this one is worth securing).
I am apparently not expressing myself well. My point is that if we are relaxing policy to the point where you are relying on DAC, what is the point? I want to test strict policy on those things where it most makes a difference. In that vein, sendmail and bind are two which have historically had a lot of problems. I would think those would be candidates for stricter policy, not more permissive.
There is a bit of confusion here, totally understandable.
The daemons referred to above are candidates for being strictly controlled.
The term 'relaxed policy' here refers to the concept of providing very strict policies for a small, critical subset of the system, then allowing the rest of the system to be unconfined. It's relaxed in terms of not trying to provide strict policies for every domain.
- James
On Sun, 2004-05-02 at 18:49, Colin Walters wrote:
There has been some work done on a "relaxed" policy. The intention of this policy is to simply protect system daemons, and not user logins. Right now there is just a policy for apache (which doesn't really work due to a kernel bug). Everything else runs in an "unconfined_t" domain, which essentially has every SELinux permission, and thus you are back to relying on DAC.
IIRC, the problem with apache is simply upon restarting it from an admin shell; with the current policy, SELinux will close the descriptors to the admin tty, and apache misbehaves if descriptors 0-2 don't exist.
We have a patch to the SELinux module to change it to re-open descriptors it closes upon exec to the null device to avoid such problems. But in the meantime, there are several options: 1) Change /etc/init.d/httpd to redirect descriptors 0-2 to /dev/null when starting httpd. 2) Remove noatsecure permission from initrc_t to the daemon domains in the daemon_base_domain macro in policy/macros/global_macros.te. This will cause glibc secure mode to be enabled upon the daemon execution, so that glibc will itself re-open descriptors 0-2 to /dev/null if they are closed (but will also cause glibc to perform other sanitization that may not be appropriate). 3) Allow httpd_t to access the tty/pty; not good for production use, but ok for experimentation with the policy, e.g.: allow httpd_t { tty_device_t devpts_t }:chr_file rw_file_perms;
selinux@lists.fedoraproject.org