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: Always Steps to Reproduce: 1. make one-one-server LDFLAGS=-lsctp 2. ./one-one-server 8888 3. ./one-one-client 127.0.0.1 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.
Created attachment 357552 [details] one-one-server.c Example SCTP server appliation
Created attachment 357553 [details] one-one-client.c Example STCP client application
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.
See: http://marc.info/?l=selinux&m=124342862804578&w=2 for a summary of what would need to be done to properly support SCTP.
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.
Created attachment 357841 [details] strace of one-one-server
Created attachment 357842 [details] audit.log with setenforce 0 and without the policy stub
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.
(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.
Any progress on this?
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 ;)
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 http://datatag.web.cern.ch/datatag/WP3/sctp/primer.htm 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.
Paul, you can get a quick overview here as well: http://lksctp.sourceforge.net/overview.html I'll be happy to answer any questions you have on sctp as well.
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
*** Bug 677622 has been marked as a duplicate of this bug. ***
Some links to prior discussions on what is needed to implement support http://marc.info/?l=selinux&m=124342862804578&w=2 http://marc.info/?l=selinux&m=120889478612107&w=2 And apparently first reported for F4. http://marc.info/?l=fedora-selinux-list&m=112805478805484&w=2
Proper SCTP support landed in Linux v4.17.