Red Hat Bugzilla – Bug 382721
Add labeled networking controls at the interface level
Last modified: 2009-07-01 10:42:32 EDT
Description of problem:
The networking security model lacks the ability to control the flow of packets
between interfaces based on MLS label. This is needed to meet DCID 6/3
Controlled Interface support.
Version-Release number of selected component (if applicable):
This patch requires several supporting elements. These items are a
selinux-policy patch, updated iptables (for SECMARK), and generic secmark
The eventual upstream solution to this is being actively developed on the
SELinux mailing list. We need this ability on a NIAP certified baseline for a
potential certification update.
Created attachment 258251 [details]
Secure Networking Patch
Created attachment 258331 [details]
XFRM Patch -- (upstreamed)
Created attachment 258341 [details]
SELinux Policy Patch for Kernel Patch
Created attachment 258351 [details]
Generic SECMARK configuration
I can already tell that the change to struct sk_buff is a RHEL non-starter for
kABI reasons. We cannot change that struct size or basic layout. Period. End
of story. Any binary change to sk_buf is a NAK.
I would almost always agree with this statement. This is a very limited use
patch for a specific case (even more specific than the original LSPP). It was a
shame we never got agreement on these concepts originally as they are incredibly
important to networking. These patches wouldn't be brought forward as we are
finally getting this addressed upstream.
Given this very limited distribution, is their a greater potential than zero for
the application of this patch for a set of rpms?
Sorry, no. I very much understand your position but changing sk_buf during
RHEL5 is a non-starter. Even if upstream were to take the sk_buf change we
still won't for kABI reasons. Once we promise (at GA) certain structures are
allowed to be used by 3rd party kernel module developers we will NEVER change
them unless required to do so in order to fix a security issue.
redefining the secmark field to be 2 16bit secid's which map back to real 32 bit
secids would be reasonable. Since we don't ship a working secmark iptables
implementation we can (ab)use that field basically any way we want, but we
cannot change the size, layout, or meaning of anything in sk_buf which a 3rd
party might happen to be using. That's just how RHEL kernels work.
Sorry, closing WONTFIX for RHEL5 :(