On 12/06/2016 10:04 AM, Stephen Smalley wrote: > 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). Actually, perhaps we don't need another separate policy capability for it if it goes in soon, since the extended_socket_class capability isn't yet enabled in any policies. _______________________________________________ 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.
