Re: Denials from newest kernel

[Darrel Goeddel <dgoeddel@TrustedCS.com>]

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

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;

When apache tries to send dns requests, the polmatch on the SPD1 will
be chosen based on the IPSec selectors and the SELinux policy (polmatch)
The second would have failed due to port specification.  An SA will
be established with the type apache_t (from the socket).

Then when a http request is serviced, SPD2 will be chosen.  A new SA
would be used, also having the type apache_t (from the socket), but
with a different spi because of the differing SPDs.  The SA created
above with apache_t will not be looked at because they will come from
different SPDs.

I think that all seems right.  Does that help at all?  Anyone see where I
may be sniffing glues here (I haven't actually done this lately)?

<snip, hopefully nothing important>

>>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.  In this scenario, the check for choosing the SA would be replaced
with something that actually looks for context equality (this is the exact
behavior that we demonstrated with the constraints u1==u2, r1==r2, etc.).
Explicitly requiring this equality would essentially make the SA a proxy for
the socket, along the lines that the socket was always a proxy for the process
before the likes of setsockcreate.  The association:sendto check could then
be thrown out because the SA context would always equal that of the socket.
The results are the same, but the path is different.  In the current case,
the policy helps determine the match, and analysis can take that into
consideration since it should know about the policy ;).  With the kernel mod,
the kernel will always enforce and exact match and the analysis can work from
that fact.  Would the hardcoded proxy behavior be preferable in your eyes?

-- 

Darrel

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