On 12/06/2016 09:10 AM, Richard Haines wrote: > On Mon, 2016-12-05 at 17:54 -0500, Paul Moore wrote: >> On Mon, Dec 5, 2016 at 9:11 AM, Stephen Smalley <sds@xxxxxxxxxxxxx> >> wrote: >>> On 12/02/2016 05:39 PM, Paul Moore wrote: >>>> On Fri, Dec 2, 2016 at 12:40 PM, Stephen Smalley <sds@xxxxxxxxx.g >>>> ov> wrote: >>>>> I suppose a further question on this patch is whether it should >>>>> also add >>>>> new classes for ICMP, IGMP, and SCTP sockets (any others that >>>>> are >>>>> presently mapped to SECCLASS_RAWIP_SOCKET that ought to be >>>>> given their >>>>> own class?). In the SCTP case, this would at least allow them >>>>> to be >>>>> distinguished, but we would still lack the full support added >>>>> by the >>>>> separate SCTP patchset. >>>> >>>> For the record, I'm okay with this patch and I agree that the >>>> compatibility concerns aren't likely to be significant. However, >>>> I >>>> would like to continue the discussion on the idea to include >>>> classes >>>> for ICMP, IGMP, and SCTP. I haven't looked into ICMP or IGMP, >>>> but >>>> considering the changes necessary for SCTP I think it is okay to >>>> leave >>>> SCTP out for now and add it in with proper SCTP support (and its >>>> own >>>> policy capability). >>>> >>>> Stephen, I'm assuming you feel the same since you left that out >>>> of the patch? >>> >>> It depends on whether we think full SCTP support will be merged >>> sooner >>> or later. If there is the possibility that full SCTP support will >>> not >>> be merged for a while, then I think I'd rather just add a SCTP >>> socket >>> class as part of this patch so that we can at least distinguish >>> between >>> SCTP sockets and raw IP sockets in policy in the interim. >> >> As I sit here I would like to think that we'll get proper SCTP >> support >> merged sooner rather than later, but well ... things happen. I guess >> there is no harm in adding the SCTP socket class now just in case. >> >>> The other question is whether you agreed with Guido's suggested >>> change >>> for readability/maintainability or prefer the current style. I have >>> no >>> strong opinion either way. >> >> I really don't care too much either way which is why I didn't comment >> on it. I suppose I have a slight preference for Guido's suggested >> style, but I wouldn't respin the patch just for that. However, if >> you >> are going to add SCTP (which I'm guessing we should) go ahead and use >> Guido's style. > > Not sure if helpful but I plan to submit the SCTP patch next week after > testing on Fedora 25 with kernel 4.8.11. I chose to go ahead and add the SCTP socket security class to this patch so that we have all known socket classes defined by this patch, and then your patch can further add new permissions and other logic specific to SCTP under its own policy capability (at least I assume we'll want a policy capability unless we aren't overly concerned with breaking SCTP applications running under old policies with new kernels). _______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
