From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <45352DCE.7040605@trustedcs.com> Date: Tue, 17 Oct 2006 14:23:58 -0500 From: Darrel Goeddel MIME-Version: 1.0 To: "Christopher J. PeBenito" CC: vyekkirala@TrustedCS.com, "'Karl MacMillan'" , "'Joshua Brindle'" , selinux@tycho.nsa.gov, sds@tycho.nsa.gov Subject: Re: Denials from newest kernel References: <000501c6f151$147d5180$cc0a010a@tcssec.com> <1161093390.29584.27.camel@sgc> <453519D6.8060802@trustedcs.com> <1161109338.10392.12.camel@sgc> In-Reply-To: <1161109338.10392.12.camel@sgc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov 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)? >>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.