[redhat-lspp] [RFC] Trusted Networking Additions

[Stephen Smalley]

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