Bug 517676 - RFE: SCTP support missing from SELinux
RFE: SCTP support missing from SELinux
Status: NEW
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Paul Moore
Fedora Extras Quality Assurance
: FutureFeature
: 677622 (view as bug list)
Depends On:
Blocks: 517000 715517 715518 715519
  Show dependency treegraph
Reported: 2009-08-15 19:15 EDT by Henrik Nordström
Modified: 2016-08-02 07:19 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
one-one-server.c (2.34 KB, text/plain)
2009-08-15 19:16 EDT, Henrik Nordström
no flags Details
one-one-client.c (3.88 KB, text/plain)
2009-08-15 19:17 EDT, Henrik Nordström
no flags Details
rawip selinux policy stub (303 bytes, application/octet-stream)
2009-08-15 19:21 EDT, Henrik Nordström
no flags Details
strace of one-one-server (1.03 KB, text/plain)
2009-08-18 14:41 EDT, Henrik Nordström
no flags Details
audit.log with setenforce 0 and without the policy stub (2.45 KB, text/plain)
2009-08-18 14:41 EDT, Henrik Nordström
no flags Details

  None (edit)
Description Henrik Nordström 2009-08-15 19:15:28 EDT
Description of problem:

SELinux handles non-TCP/UDP network protocols such as SCTP very poorly

Version-Release number of selected component (if applicable):

How reproducible:


Steps to Reproduce:
1. make one-one-server LDFLAGS=-lsctp
2. ./one-one-server 8888
3. ./one-one-client 8888
Actual results:

one-one-server is denied to bind.

if that's solved then reading/writing from the socket is denied as well.

Expected results:

Should work.

Additional info:

Not sure what to file this bug on.. Support for SCTP is missing completely in SELinux, not just the from the policy. The kernel maps everything "unknown" as if it was rawip, which allows to workaround the problem but not sure if this is entirely safe as rawip is a bit more than just SCTP...

For rawip there is no rule governing name_bind, and as result only the dynamic port range is allowed (>32768). Ideally the kernel should know about SCTP and perhaps other port based protocols and map these as suitable to the policy. TCP/IP port numbers are assigned pretty much protocol neutral over tcp/udp/sctp, and unless one has specific reason to do different port policy should generally apply equal to allow protocol support to evolve without having to update policy each time as such updates is too easily forgotten.
Comment 1 Henrik Nordström 2009-08-15 19:16:45 EDT
Created attachment 357552 [details]

Example SCTP server appliation
Comment 2 Henrik Nordström 2009-08-15 19:17:24 EDT
Created attachment 357553 [details]

Example STCP client application
Comment 3 Henrik Nordström 2009-08-15 19:21:03 EDT
Created attachment 357554 [details]
rawip selinux policy stub

A dummy selinux policy stub module usable as workaround enabling the test appliations to run by relaxing rawip considerably. Not meant as a solution without further analysis of the use of rawip.
Comment 4 Stephen Smalley 2009-08-18 10:40:07 EDT
for a summary of what would need to be done to properly support SCTP.
Comment 5 Stephen Smalley 2009-08-18 10:42:10 EDT
The policy stub in comment #3 has an unlabeled_t socket, which shouldn't happen (not even for SCTP).  That would be a bug in the kernel.  More details would be helpful, including the original raw audit log entries.
Comment 6 Henrik Nordström 2009-08-18 14:41:04 EDT
Created attachment 357841 [details]
strace of one-one-server
Comment 7 Henrik Nordström 2009-08-18 14:41:50 EDT
Created attachment 357842 [details]
audit.log with setenforce 0 and without the policy stub
Comment 8 Stephen Smalley 2009-08-19 07:44:55 EDT
Ok, so lack of security hooks within the sctp code means that new server sockets returned by accept() are left in the unlabeled state.  Not good.
This is a kernel bug that should be fixed regardless of whether we do the steps outlined in comment #4, although they could be done together.
Comment 9 Paul Moore 2009-08-19 15:20:04 EDT
(In reply to comment #8)
> Ok, so lack of security hooks within the sctp code means that new server
> sockets returned by accept() are left in the unlabeled state.  Not good.
> This is a kernel bug that should be fixed regardless ...

I just started looking at this today and talking with the SCTP maintainer about it - it will probably be a few days before I can propose a solution.  However, if anyone has any bright ideas I'd love to hear them.
Comment 10 Henrik Nordström 2009-10-28 21:10:42 EDT
Any progress on this?
Comment 11 Paul Moore 2009-10-29 17:10:58 EDT
Nothing substantial at this point.  Problems involve limited time to devote to this and my own limited understanding of SCTP.  The first hurdle is trying to understand how SCTP operates and if a socket returned by accept() can be labeled the same way as TCP and UDP.  The next step is to figuring out what the SCTP analogue is for an incoming connection request (this is where we do the bulk of the child socket labeling); I suspect this is a SCTP "association" but I haven't looked into it enough yet.

Henrik (or anyone else for that matter), do you have a pointer to document with provides a brief overview of how SCTP works?  I'm thinking about detail along the lines of an "executive summary" and not RFC level detail.

Also, as usual, I'm happy to review patches ;)
Comment 12 Henrik Nordström 2009-10-29 18:29:32 EDT
SCTP "connections" are associations, and sets up a relation between two nodes

SCTP is different and similar to both TCP and UDP depending on how it's used. My comment there is that standard port number assignments is generally the same for all three protocols. I.e. port 80 is assigned for both TCP (common), UDP (uncommon) and SCTP (not yet in use, but hopefully...) so from a policy perspective it may be beneficial to merge the three in many cases, but not neccesarily from SELinux implementation.

A quick google turned up the following primer which seems to be the level you ask for


what is missing from there is the sockets api which has some additional twists. This is quite well documented in the SCTP(7) man page however. But to connect the two:

- SCTP sockets come in one-to-one and one-to-many flavors. one-to-one has explicit association setup like TCP, while one-to-many is more like unconnected UDP. In the one-to-many case assications are automatically created and closed by the kernel as needed by the traffic flow and is a major difference from UDP which is connectionless.
Comment 13 Neil Horman 2009-10-29 18:59:09 EDT
Paul, you can get a quick overview here as well:

I'll be happy to answer any questions you have on sctp as well.
Comment 14 Bug Zapper 2010-04-28 05:47:13 EDT
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
Comment 15 Bug Zapper 2010-07-30 06:42:58 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.

More information and reason for this action is here:
Comment 16 Daniel Walsh 2011-02-16 16:59:46 EST
*** Bug 677622 has been marked as a duplicate of this bug. ***
Comment 17 Henrik Nordström 2011-06-23 04:10:46 EDT
Some links to prior discussions on what is needed to implement support


And apparently first reported for F4.


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