Re: Denials from newest kernel

["Christopher J. PeBenito" <cpebenito@tresys.com>]

On Tue, 2006-10-17 at 14:23 -0500, Darrel Goeddel wrote:
> Christopher J. PeBenito wrote:
> >>>>This relationship is implicit in that a packet from apache_t can only
> >>>>use an association labeled apache_t. This would be currently shown in the
> >>>>SELinux policy itself as:
> >>>>
> >>>>allow apache_t apache_t:association { sendto };
> >>>>
> >>>>We did talk about moving this "implicit" relationship into the kernel itself
> >>>>essentially eliminating the association indirection for SAs.
> >>>
> >>>
> >>>Exactly, implicit isn't sufficient, because we won't be able to specify
> >>>that http packets can go over the apache association but not dns
> >>>packets.
> >>
> >>Wouldn't the absence of "allow dns_t apache_t:association { sendto };" prevent
> >>dns packets using an apache_t association?
> > 
> > 
> > What I'm referring in this case is dns client packets; the ones used
> > when a process does a DNS name resolution.  I believe you're confusing
> > that with dns server packets which named_t would be sending to answer
> > DNS queries.  Apache can do name resolution, so it sends both httpd
> > server packets and dns client packets.
> 
> Ahh, gotcha...  I think I'll need a little more info on what you're going after
> though.  I'll take a stab anyway...

I want to be able to restrict which associations a packet can go over,
specified by TE policy _alone_.

> One option is to modify apache to use setsockcreate to indicate different
> network usages.  However, I think what you are really wanting lies in the
> scope of IPSec SPD definitions, not SELinux policy.  I'm assuming that you
> are wanting http traffic to use one SA, and dns requests to use another SA
> (If that is not correct, I'll try again).  All traffic generated by apache
> will fall within the same equivalence class (apache_t) in the eyes of
> SELinun, so further action there is not feasible.  The IPSec
> configuration is able to make a distinction based on other properties
> such as addresses/ports.  What I think you want to do in this case is to
> set up SPD as such (very informal pseudo syntax...):
> 
> SPD1 localhost dnsserver:53 ipsec out context=...dns_t...
> SPD2 * localhost:80 ipsec in context=...http_t...
> 
> you would then allow apache to use both of the SPDs:
> 
> allow apache_t { dns_t http_t } association:polmatch;

This is exactly what I'm saying, the above encodes policy into the SPD!
When the question is "how to specify which packets can go over the
association?", the answer should not be "write a SPD rule", it should be
"write a SELinux rule".  These SPD entries only configure association
behaviors, but the current implementation makes an implicit relationship
between the packet and the association configuration.  Say we change the
first SPD entry to:

SPD1 localhost dnsserver:* ipsec out context=::dns_t

Now http packets can go over the same association as dns packets.  Your
first reaction would be "user error: misconfiguration", which would mean
you're encoding the packet->association policy into the SPD.  If SELinux
was mediating this correctly, it could still deny http packets from
going over this association.

> >>I think the analogy between ipsec and files isn't working all that well :)
> >>The policy (SELinux policy) must specifically allow for the sock vs SA
> >>polmatch to choose the correct SPD and it must specifically allow for
> >>the sock vs SA sendto to choose the correct SA.  If a domain such as
> >>apache_t is allow to sendto SAs of many types (say http1_t, http2_t, etc.)
> >>and SAs already exist for all of those types, it will use the first SA
> >>that it can successfully sendto.  This would be analogous to passwd trying
> >>/etc/shadow, /etc/shadow1, ... until it could write a shadow file.  In
> >>any case, the policy still governs what can happen.  At least this is my
> >>current understanding and that is always subject to change ;)
> > 
> > 
> > I'm not trying to argue that polmatch is a bad check; I understand its
> > reasons for existing.  I'm just saying its insufficient for checking if
> > a packet can go over an association.  The above contrived example shows
> > this, since you can't truly tell what you can access without looking at
> > the FC.
> 
> IIRC, the polmatch check is used only for choosing the SPD, the sendto check
> is used in determining the specific SA to use.
> 
> I think you can tell with certainty what you *can* access, but not what you
> *will* access.  What you can access is based on policy.  What you will access
> is based on the order in which the SA are looked at - first "match" wins, but
> it still must be allowed via policy.
> 
> I should have pointed talked a bit more more about the idea of replacing the
> association:sendto check with a straight up context comparison in the kernel
> for choosing the SA.  This removes flexibility, but it also removes some
> complexity.
[cut]
> Would the hardcoded proxy behavior be preferable in your eyes?

No.  In fact, Joshua and I were testing and the current SA labeling
behavior is not what I thought it was.  The association on both sides of
the connection is currently labeled with the type of the client, e.g.,
for mozilla_t making a new SA while connecting to httpd_t, the
association is labeled mozilla_t on both machines.  The current
implementation breaks the idea that the label of the association
represents the domain on the other side of the connection, which is why
the sendto check seems redundant.  Mozilla_t should sendto/recvfrom the
httpd_t association, and httpd_t should sendto/recvfrom the mozilla_t
association in this example.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.