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 -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
