Re: Labeled networking packets

[Joshua Brindle <jbrindle@tresys.com>]

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