Re: Labeled networking packets

[Joshua Brindle <jbrindle@tresys.com>]

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


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