From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <451A796C.7030609@tresys.com> Date: Wed, 27 Sep 2006 09:15:24 -0400 From: Joshua Brindle MIME-Version: 1.0 To: Stephen Smalley CC: James Morris , Venkat Yekkirala , "Christopher J. PeBenito" , Chad Hanson , Karl MacMillan , selinux@tycho.nsa.gov, Darrel Goeddel , dwalsh@redhat.com, jmorris@redhat.com, latten@austin.ibm.com, Paul Moore Subject: Re: Labeled networking packets References: <36282A1733C57546BE392885C061859201573917@chaos.tcs.tcs-sec.com> <1159357078.32075.20.camel@moss-spartans.epoch.ncsc.mil> <451A7151.3000800@tresys.com> <1159361908.32075.42.camel@moss-spartans.epoch.ncsc.mil> In-Reply-To: <1159361908.32075.42.camel@moss-spartans.epoch.ncsc.mil> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov Stephen Smalley wrote: > On Wed, 2006-09-27 at 08:40 -0400, Joshua Brindle wrote: > >> Stephen Smalley wrote: >> >>> On Tue, 2006-09-26 at 18:43 -0400, James Morris wrote: >>> >>>> On Tue, 26 Sep 2006, Venkat Yekkirala wrote: >>>> >>>> >>>>> FOR "INCOMING" CONNECTIONS TO HTTPD (define the client peer): >>>>> >>>>> # Create a chain for connection setup and security point labeling >>>>> # for http client peers. >>>>> iptables -t mangle -N SEL_HTTP >>>>> >>>>> # Accept incoming connections from, and define and save the >>>>> >>> security point >>> >>>>> for >>>>> # http client peers. >>>>> iptables -t mangle -A INPUT -p tcp --dport 80 -m state --state NEW -j >>>>> SEL_HTTP >>>>> iptables -t mangle -A SEL_HTTP -j SECPOINT --selctx >>>>> system_u:object_r:http_client_t:s0 >>>>> iptables -t mangle -A SEL_HTTP -j CONNSECPOINT --save >>>>> iptables -t mangle -A SEL_HTTP -j ACCEPT >>>>> >>>>> # Common rules which restore security points for established >>>>> # and related packets. >>>>> iptables -t mangle -A INPUT -m state --state ESTABLISHED,RELATED -j >>>>> CONNSECPOINT --restore >>>>> iptables -t mangle -A OUTPUT -m state --state ESTABLISHED,RELATED -j >>>>> CONNSECPOINT --restore >>>>> >>>>> FOR "OUTGOING" CONNECTIONS TO POSTGRES (define the postgres server >>>>> >>> peer): >>> >>>>> iptables -t mangle -N SEL_PGRESD >>>>> iptables -t mangle -A OUTPUT -p tcp --dport -m >>>>> >>> state --state >>> >>>>> NEW -j SEL_POSTGRESD >>>>> iptables -t mangle -A SEL_PGRESD -j SECPOINT --selctx >>>>> system_u:object_r:postgresd_t:s0 >>>>> iptables -t mangle -A SEL_PGRESD -j CONNSECPOINT --save >>>>> iptables -t mangle -A SEL_PGRESD -j ACCEPT >>>>> >>>> This just seems the same as SECMARK and CONNSECMARK but with different >>>> naming. What problem is this solving? >>>> >>> The name isn't important (Venkat just views the "secpoint" and "peer" >>> names as more intuitive). The issue is how we label the packets - >>> Venkat is assigning labels that correspond to domains (potentially >>> generic placeholder domains when we don't actually know a specific one), >>> like http_client_t (or mozilla_t) and httpd_t versus object types like >>> http_client_packet_t and http_server_packet_t. >>> >>> We could leave the secmark and packet names alone. >>> >>> >> I'd rather change the packet name as that could lead to some serious >> confusion when reconciliation happens. "packet" has a connotation of >> being a discrete visible thing so overriding its label with something >> more abstract (eg., an ipsec tunnel) will be confusing. Since "peer" is >> a more abstract object it can, more understandably, represent more than >> 1 kind of network labeling. >> > > Sorry, I don't see that. There is a discrete visible object here (the > sk_buff), and it isn't truly a "peer", even if it is propagating the > peer's information. "packet" is no less applicable to all forms of > network labeling than "peer". "peer" is also confusing in the datagram > case, as peer usually suggests the remote endpoint of a (stream) > connection. And changing the names means a lot of useless busy work > when there is plenty of real work to be done. > > I'm talking about the users perspective, packet is alot more 'tangible' than peer. Doesn't matter much though, as long as there is something to explain it to users. -- 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.