Bug 382721 - Add labeled networking controls at the interface level
Add labeled networking controls at the interface level
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.0
All Linux
low Severity low
: ---
: ---
Assigned To: Eric Paris
Red Hat Kernel QE team
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-14 11:08 EST by Chad Hanson
Modified: 2009-07-01 10:42 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-01 10:42:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Secure Networking Patch (24.68 KB, text/plain)
2007-11-14 11:08 EST, Chad Hanson
no flags Details
XFRM Patch -- (upstreamed) (639 bytes, text/plain)
2007-11-14 11:28 EST, Chad Hanson
no flags Details
SELinux Policy Patch for Kernel Patch (12.09 KB, text/plain)
2007-11-14 11:30 EST, Chad Hanson
no flags Details
Generic SECMARK configuration (767 bytes, text/plain)
2007-11-14 11:31 EST, Chad Hanson
no flags Details

  None (edit)
Description Chad Hanson 2007-11-14 11:08:47 EST
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.
Comment 1 Chad Hanson 2007-11-14 11:08:47 EST
Created attachment 258251 [details]
Secure Networking Patch
Comment 2 Chad Hanson 2007-11-14 11:28:47 EST
Created attachment 258331 [details]
XFRM Patch -- (upstreamed)
Comment 3 Chad Hanson 2007-11-14 11:30:14 EST
Created attachment 258341 [details]
SELinux Policy Patch for Kernel Patch
Comment 4 Chad Hanson 2007-11-14 11:31:29 EST
Created attachment 258351 [details]
Generic SECMARK configuration
Comment 5 Eric Paris 2007-11-14 11:37:32 EST
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.
Comment 6 Chad Hanson 2007-11-14 14:29:59 EST
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?
Comment 7 Eric Paris 2007-11-14 14:53:33 EST
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.
Comment 8 Eric Paris 2009-07-01 10:42:32 EDT
Sorry, closing WONTFIX for RHEL5   :(

Note You need to log in before you can comment on or make changes to this bug.