[redhat-lspp] [RFC] Trusted Networking Additions

[Venkat Yekkirala]

Here's a way that seems to take care of the forward case as well while
promoting the notion of a secmark being just a security marking on an skb
from a datamodel point of view.

On the inbound and forward:

1.	Packet will initially be secmarked per iptables policy like it
currently does.
2.	If it is an ipsec packet, then it will inherit the ipsec sid.
3.	Further, if it's a CIPSO packet (NetLabel), it will get the NetLabel
sid.
4.	INBOUND ONLY: Socket access to the packet/secmark is checked in
rcv_skb like it is currently being done.

On the outbound and forward:

In the POSTROUTING chain of the mangle table, the following will happen:

1.	The "iptables sid" is determined per the iptables POSTROUTING policy
chain in the mangle table. But it WON'T go into the secmark of the packet
like it currently does.
2.	If this is a locally generated packet, the socket sid is checked
against the "iptables sid" (formerly done in postroute_last).
3.	Otherwise, the packet should already have a secmark from the forward
rules and such. This secmark is checked against the "iptables sid".


The iptables policy would look something like:

iptables -t mangle -A INPUT -p tcp --dport 80 -j SECMARK --selctx
system_u:object_r:httpd_packet_t:s0
iptables -t mangle -A POSTROUTING -p tcp --sport 80 -j SECMARK --selctx
system_u:object_r:httpd_packet_t:s0


The above would be consistent with the idea that on the inbound the
"consumer" is the socket and on the outbound the "consumer" is really the
netif/node/port/whatever (as expressed in the iptables rules).


> -----Original Message-----
> From: Stephen Smalley [mailto:sds at tycho.nsa.gov]
> Sent: Thursday, June 01, 2006 10:14 AM
> To: Venkat Yekkirala
> Cc: James Morris; Karl MacMillan; Chad Hanson; Darrel Goeddel; RedHat
> LSPP
> Subject: RE: [redhat-lspp] [RFC] Trusted Networking Additions
> 
> 
> On Thu, 2006-06-01 at 10:55 -0400, Venkat Yekkirala wrote:
> > On the inbound, secmark seems fine (as also the socket 
> access to the skb per
> > secmark), but on the outbound, wouldn't it be logical to 
> take the secmark
> > from the socket (or in the forward case from the forward 
> iptables rules) and
> > perform a check of the secmark against the node/netif.
> 
> Hmmm..that wouldn't be the expected usage of secmark, but I understand
> the confusion here, as that would be the expected usage of a 
> traditional
> skb security field ala the old LSM patches and older SELinux 
> code.  With
> secmark, the idea is that you'd set the secmark field based on the
> node/netif via iptables rules, and then use the packet send check
> between the sending socket SID and the secmark to control whether the
> socket can send to that node/via that netif.  That avoids the need for
> the kernel security policy to maintain node context mappings (which
> you'd really like to be a distributed database, not something 
> the kernel
> needs to directly deal with), and separates label assignment from
> enforcement (consistent with the filesystem, where the kernel policy
> does not specify that inode 6 has label Y).  It also avoids the
> performance overhead of per-packet node/netif SID lookups, which is
> expensive.
> 
> Not sure how to handle the forwarding case cleanly.
> 
> -- 
> Stephen Smalley
> National Security Agency
>