experimental relaxed policy

[Colin Walters]

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 :)

[Colin Walters]

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).

[Thomas Molina]

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?

[Daniel J Walsh]

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(a)redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-selinux-list
>   
>

[Thomas Molina]

>  >>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.

[Stephen Smoogen]

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.


-- 
Stephen John Smoogen		smoogen(a)lanl.gov
Los Alamos National Lab  CCN-5 Sched 5/40  PH: 4-0645
Ta-03 SM-1498 MailStop B255 DP 10S  Los Alamos, NM 87545
-- You should consider any operational computer to be a security problem --

On Mon, 03 May 2004 18:16:57 EDT, Thomas Molina <tmolina(a)cablespeed.com&gt;  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.

[James Morris]

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
-- 
James Morris
<jmorris(a)redhat.com&gt;

[Stephen Smalley]

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;

-- 
Stephen Smalley <sds(a)epoch.ncsc.mil&gt;
National Security Agency