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): kernel-2.6.18-8.1.3.lspp.80.el5 Additional info: This patch requires several supporting elements. These items are a selinux-policy patch, updated iptables (for SECMARK), and generic secmark configuration. 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 :(