| Message ID | 405c8b6e-c63e-c61b-3363-14ad85b1147a@schaufler-ca.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, Jan 25, 2017 at 9:07 PM, Casey Schaufler <casey@schaufler-ca.com> wrote: > Subject: [PATCH RFC 9/9] SELinux: Allow explicit netlabel configuration > > In certain stacking configurations it is convenient to disable > the netlabel subsystem for SELinux even if it is compiled in. > If Smack is being used at the same time as SELinux there are > cases where SELinux should defer all network labeling to its peer. > No code changes, really. > > Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> > --- > security/selinux/Kconfig | 12 ++++++++++++ > security/selinux/Makefile | 2 +- > security/selinux/include/netlabel.h | 4 ++-- > security/selinux/include/objsec.h | 2 +- > security/selinux/include/security.h | 4 ++-- > security/selinux/ss/ebitmap.c | 4 ++-- > security/selinux/ss/ebitmap.h | 2 +- > security/selinux/ss/mls.c | 4 ++-- > security/selinux/ss/mls.h | 2 +- > security/selinux/ss/services.c | 4 ++-- > 10 files changed, 26 insertions(+), 14 deletions(-) > > diff --git a/security/selinux/Kconfig b/security/selinux/Kconfig > index ea7e3ef..86cc9e8 100644 > --- a/security/selinux/Kconfig > +++ b/security/selinux/Kconfig > @@ -93,3 +93,15 @@ config SECURITY_SELINUX_CHECKREQPROT_VALUE > via /selinux/checkreqprot if authorized by policy. > > If you are unsure how to answer this question, answer 0. > + > +config SECURITY_SELINUX_NETLABEL > + bool "NSA SELinux labeled networking support" > + depends on SECURITY_SELINUX > + depends on NETLABEL > + default y > + help > + This option enables SELinux to use the netlabel subsystem > + for labeling IPv4 packets with CIPSO and IPv6 packets with > + CALYPSO. > + > + If you are unsure how to answer this question, answer Y. It's "CALIPSO" (Common Architecture Label IPv6 Security Option), see RFC 5570. I am concerned that there does not appear to be any effort to attempt to multiple-LSM use of NetLabel, especially when I believe it should be possible if the NetLabel cache is avoided/disabled. The cache could be made multiple-LSM aware so that it could be enabled, but I think even cache disabled NetLabel support is a better option than this.
On 1/26/2017 5:35 AM, Paul Moore wrote: > On Wed, Jan 25, 2017 at 9:07 PM, Casey Schaufler <casey@schaufler-ca.com> wrote: >> Subject: [PATCH RFC 9/9] SELinux: Allow explicit netlabel configuration >> >> In certain stacking configurations it is convenient to disable >> the netlabel subsystem for SELinux even if it is compiled in. >> If Smack is being used at the same time as SELinux there are >> cases where SELinux should defer all network labeling to its peer. >> No code changes, really. >> >> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> >> --- >> security/selinux/Kconfig | 12 ++++++++++++ >> security/selinux/Makefile | 2 +- >> security/selinux/include/netlabel.h | 4 ++-- >> security/selinux/include/objsec.h | 2 +- >> security/selinux/include/security.h | 4 ++-- >> security/selinux/ss/ebitmap.c | 4 ++-- >> security/selinux/ss/ebitmap.h | 2 +- >> security/selinux/ss/mls.c | 4 ++-- >> security/selinux/ss/mls.h | 2 +- >> security/selinux/ss/services.c | 4 ++-- >> 10 files changed, 26 insertions(+), 14 deletions(-) >> >> diff --git a/security/selinux/Kconfig b/security/selinux/Kconfig >> index ea7e3ef..86cc9e8 100644 >> --- a/security/selinux/Kconfig >> +++ b/security/selinux/Kconfig >> @@ -93,3 +93,15 @@ config SECURITY_SELINUX_CHECKREQPROT_VALUE >> via /selinux/checkreqprot if authorized by policy. >> >> If you are unsure how to answer this question, answer 0. >> + >> +config SECURITY_SELINUX_NETLABEL >> + bool "NSA SELinux labeled networking support" >> + depends on SECURITY_SELINUX >> + depends on NETLABEL >> + default y >> + help >> + This option enables SELinux to use the netlabel subsystem >> + for labeling IPv4 packets with CIPSO and IPv6 packets with >> + CALYPSO. >> + >> + If you are unsure how to answer this question, answer Y. > It's "CALIPSO" (Common Architecture Label IPv6 Security Option), see RFC 5570. Oops. Too long since I've been to the Caribbean. Calling Dr. Freud. > I am concerned that there does not appear to be any effort to attempt > to multiple-LSM use of NetLabel, It's not a matter of no effort, it's a matter of no result that passes the laugh test. I hope to have something worthy of review in the next cycle. > especially when I believe it should > be possible if the NetLabel cache is avoided/disabled. I have been playing with a model in which the modules are called upon to approve (or disapprove) each others attempts to set netlabel attributes. As you might expect, the problem comes with what to do when SELinux wants something that Smack can't abide, or the other way around. Socket creation, for example, shouldn't fail in that case, but the netlabel attributes shouldn't be set inappropriately, either. > The cache > could be made multiple-LSM aware so that it could be enabled, but I > think even cache disabled NetLabel support is a better option than > this. I don't intend this as a solution, but it sure is convenient. I expect to drop it as a better solution evolves. As always, suggestions are welcome. -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jan 26, 2017 at 11:51 AM, Casey Schaufler <casey@schaufler-ca.com> wrote: > On 1/26/2017 5:35 AM, Paul Moore wrote: >> On Wed, Jan 25, 2017 at 9:07 PM, Casey Schaufler <casey@schaufler-ca.com> wrote: >>> Subject: [PATCH RFC 9/9] SELinux: Allow explicit netlabel configuration >>> >>> In certain stacking configurations it is convenient to disable >>> the netlabel subsystem for SELinux even if it is compiled in. >>> If Smack is being used at the same time as SELinux there are >>> cases where SELinux should defer all network labeling to its peer. >>> No code changes, really. >>> >>> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> >>> --- >>> security/selinux/Kconfig | 12 ++++++++++++ >>> security/selinux/Makefile | 2 +- >>> security/selinux/include/netlabel.h | 4 ++-- >>> security/selinux/include/objsec.h | 2 +- >>> security/selinux/include/security.h | 4 ++-- >>> security/selinux/ss/ebitmap.c | 4 ++-- >>> security/selinux/ss/ebitmap.h | 2 +- >>> security/selinux/ss/mls.c | 4 ++-- >>> security/selinux/ss/mls.h | 2 +- >>> security/selinux/ss/services.c | 4 ++-- >>> 10 files changed, 26 insertions(+), 14 deletions(-) >>> >>> diff --git a/security/selinux/Kconfig b/security/selinux/Kconfig >>> index ea7e3ef..86cc9e8 100644 >>> --- a/security/selinux/Kconfig >>> +++ b/security/selinux/Kconfig >>> @@ -93,3 +93,15 @@ config SECURITY_SELINUX_CHECKREQPROT_VALUE >>> via /selinux/checkreqprot if authorized by policy. >>> >>> If you are unsure how to answer this question, answer 0. >>> + >>> +config SECURITY_SELINUX_NETLABEL >>> + bool "NSA SELinux labeled networking support" >>> + depends on SECURITY_SELINUX >>> + depends on NETLABEL >>> + default y >>> + help >>> + This option enables SELinux to use the netlabel subsystem >>> + for labeling IPv4 packets with CIPSO and IPv6 packets with >>> + CALYPSO. >>> + >>> + If you are unsure how to answer this question, answer Y. >> It's "CALIPSO" (Common Architecture Label IPv6 Security Option), see RFC 5570. > > Oops. Too long since I've been to the Caribbean. Calling Dr. Freud. I'm still a strong advocate of locating a future LSS somewhere tropical, with a beach, and those nice big cocktails with the little umbrellas. Umbrellas in my hand = bad, umbrealls in my drink = good. >> I am concerned that there does not appear to be any effort to attempt >> to multiple-LSM use of NetLabel, > > It's not a matter of no effort, it's a matter of no result > that passes the laugh test. I hope to have something worthy > of review in the next cycle. Okay great, I misunderstood your intent with this patchset. As long as that work is upcoming in a future revision I'm happy to wait. >> especially when I believe it should >> be possible if the NetLabel cache is avoided/disabled. > > I have been playing with a model in which the modules > are called upon to approve (or disapprove) each others > attempts to set netlabel attributes. As you might expect, > the problem comes with what to do when SELinux wants > something that Smack can't abide, or the other way around. > Socket creation, for example, shouldn't fail in that case, > but the netlabel attributes shouldn't be set inappropriately, > either. Oddly enough I have been more worried about in inbound side, especially with respect to the cache so we don't tank performance. In my mind, the outbound side is (relatively) easy, if the netlabel_lsm_secattr values aren't the same for every LSM then the operation should be denied. I'm not sure how much can be done in one LSM, or the LSM shim layer for that matter, to approve/reject labels from another LSM; I think they either match or they don't. Yes, this is rather strict, but let's be honest, if you are running two major LSMs simultaneously, you've probably got much bigger problems to worry about (I still wonder how prevalent this will be outside of some LSM developers and hobbyists). >> The cache >> could be made multiple-LSM aware so that it could be enabled, but I >> think even cache disabled NetLabel support is a better option than >> this. > > I don't intend this as a solution, but it sure is convenient. > I expect to drop it as a better solution evolves. > As always, suggestions are welcome. Good, glad to hear it. Yes, disabling the cache is going to have a nasty performance impact - it's been years since I've done performance measurements, but when I introduced the cache it was a *huge* win on per-packet overhead as it allows us to sidestep a lot of label interpretation steps and got straight from the on-the-wire label to a LSM internalized secid/secctx.
On 1/27/2017 2:09 AM, Paul Moore wrote: > On Thu, Jan 26, 2017 at 11:51 AM, Casey Schaufler > <casey@schaufler-ca.com> wrote: >> On 1/26/2017 5:35 AM, Paul Moore wrote: >>> On Wed, Jan 25, 2017 at 9:07 PM, Casey Schaufler <casey@schaufler-ca.com> wrote: >>>> Subject: [PATCH RFC 9/9] SELinux: Allow explicit netlabel configuration >>>> >>>> In certain stacking configurations it is convenient to disable >>>> the netlabel subsystem for SELinux even if it is compiled in. >>>> If Smack is being used at the same time as SELinux there are >>>> cases where SELinux should defer all network labeling to its peer. >>>> No code changes, really. >>>> >>>> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> >>>> --- >>>> security/selinux/Kconfig | 12 ++++++++++++ >>>> security/selinux/Makefile | 2 +- >>>> security/selinux/include/netlabel.h | 4 ++-- >>>> security/selinux/include/objsec.h | 2 +- >>>> security/selinux/include/security.h | 4 ++-- >>>> security/selinux/ss/ebitmap.c | 4 ++-- >>>> security/selinux/ss/ebitmap.h | 2 +- >>>> security/selinux/ss/mls.c | 4 ++-- >>>> security/selinux/ss/mls.h | 2 +- >>>> security/selinux/ss/services.c | 4 ++-- >>>> 10 files changed, 26 insertions(+), 14 deletions(-) >>>> >>>> diff --git a/security/selinux/Kconfig b/security/selinux/Kconfig >>>> index ea7e3ef..86cc9e8 100644 >>>> --- a/security/selinux/Kconfig >>>> +++ b/security/selinux/Kconfig >>>> @@ -93,3 +93,15 @@ config SECURITY_SELINUX_CHECKREQPROT_VALUE >>>> via /selinux/checkreqprot if authorized by policy. >>>> >>>> If you are unsure how to answer this question, answer 0. >>>> + >>>> +config SECURITY_SELINUX_NETLABEL >>>> + bool "NSA SELinux labeled networking support" >>>> + depends on SECURITY_SELINUX >>>> + depends on NETLABEL >>>> + default y >>>> + help >>>> + This option enables SELinux to use the netlabel subsystem >>>> + for labeling IPv4 packets with CIPSO and IPv6 packets with >>>> + CALYPSO. >>>> + >>>> + If you are unsure how to answer this question, answer Y. >>> It's "CALIPSO" (Common Architecture Label IPv6 Security Option), see RFC 5570. >> Oops. Too long since I've been to the Caribbean. Calling Dr. Freud. > I'm still a strong advocate of locating a future LSS somewhere > tropical, with a beach, and those nice big cocktails with the little > umbrellas. Umbrellas in my hand = bad, umbrealls in my drink = good. My fear on that is that you might call in all the drinks that I owe you. I can't imagine that rolling you up the beach afterwords would be a pretty sight. >>> I am concerned that there does not appear to be any effort to attempt >>> to multiple-LSM use of NetLabel, >> It's not a matter of no effort, it's a matter of no result >> that passes the laugh test. I hope to have something worthy >> of review in the next cycle. > Okay great, I misunderstood your intent with this patchset. As long > as that work is upcoming in a future revision I'm happy to wait. > >>> especially when I believe it should >>> be possible if the NetLabel cache is avoided/disabled. >> I have been playing with a model in which the modules >> are called upon to approve (or disapprove) each others >> attempts to set netlabel attributes. As you might expect, >> the problem comes with what to do when SELinux wants >> something that Smack can't abide, or the other way around. >> Socket creation, for example, shouldn't fail in that case, >> but the netlabel attributes shouldn't be set inappropriately, >> either. > Oddly enough I have been more worried about in inbound side, > especially with respect to the cache so we don't tank performance. My admittedly incomplete look at the inbound side leads me to think that for the Smack & SELinux case it's reasonably simple, but that's because Smack doesn't use the netlabel cache features. At least, I don't think it does. Am I wrong? > In > my mind, the outbound side is (relatively) easy, if the > netlabel_lsm_secattr values aren't the same for every LSM then the > operation should be denied. OK, that's pretty much what I'd come up with, too. > I'm not sure how much can be done in one > LSM, or the LSM shim layer for that matter, to approve/reject labels > from another LSM; I think they either match or they don't. I had been looking at checking for equivalence when the netlabel attributes were set on the socket, but it seems that checking on send might work better. That would mean checking all the netlabel attributes at send time, but there are clever ways to make that happen without too much fuss. > Yes, this is rather strict, We are talking Mandatory Access Control after all. > but let's be honest, if you are running > two major LSMs simultaneously, you've probably got much bigger > problems to worry about (I still wonder how prevalent this will be > outside of some LSM developers and hobbyists). Major modules *that use CIPSO* is the key. A major module is any module that uses any security blob. I don't see any of the 8 modules proposed recently supplying network hooks that care about passing information abroad. Unless AppArmor surprises me when the long awaited update arrives I only see an issue with SELinux + Smack, and we're in complete agreement on how likely that is to be a production configuration. >>> The cache >>> could be made multiple-LSM aware so that it could be enabled, but I >>> think even cache disabled NetLabel support is a better option than >>> this. >> I don't intend this as a solution, but it sure is convenient. >> I expect to drop it as a better solution evolves. >> As always, suggestions are welcome. > Good, glad to hear it. Yes, disabling the cache is going to have a > nasty performance impact - it's been years since I've done performance > measurements, but when I introduced the cache it was a *huge* win on > per-packet overhead as it allows us to sidestep a lot of label > interpretation steps and got straight from the on-the-wire label to a > LSM internalized secid/secctx. I have some new ideas to try out based on this. Thanks for the feedback. drinksowed++ -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Jan 27, 2017 at 2:41 PM, Casey Schaufler <casey@schaufler-ca.com> wrote: > On 1/27/2017 2:09 AM, Paul Moore wrote: >> On Thu, Jan 26, 2017 at 11:51 AM, Casey Schaufler >> <casey@schaufler-ca.com> wrote: >>> On 1/26/2017 5:35 AM, Paul Moore wrote: >>>> On Wed, Jan 25, 2017 at 9:07 PM, Casey Schaufler <casey@schaufler-ca.com> wrote: >>>>> Subject: [PATCH RFC 9/9] SELinux: Allow explicit netlabel configuration ... >>>> especially when I believe it should >>>> be possible if the NetLabel cache is avoided/disabled. >>> I have been playing with a model in which the modules >>> are called upon to approve (or disapprove) each others >>> attempts to set netlabel attributes. As you might expect, >>> the problem comes with what to do when SELinux wants >>> something that Smack can't abide, or the other way around. >>> Socket creation, for example, shouldn't fail in that case, >>> but the netlabel attributes shouldn't be set inappropriately, >>> either. >> Oddly enough I have been more worried about in inbound side, >> especially with respect to the cache so we don't tank performance. > > My admittedly incomplete look at the inbound side leads me > to think that for the Smack & SELinux case it's reasonably > simple, but that's because Smack doesn't use the netlabel > cache features. At least, I don't think it does. Am I wrong? If you're not using any of the NetLabel caching functions than you're not using any of the NetLabel caching. This might be a happy bit of luck for the stacking effort, but you really want to use the NetLabel cache whenever you can. >> I'm not sure how much can be done in one >> LSM, or the LSM shim layer for that matter, to approve/reject labels >> from another LSM; I think they either match or they don't. > > I had been looking at checking for equivalence when the netlabel > attributes were set on the socket, but it seems that checking on > send might work better. That would mean checking all the netlabel > attributes at send time, but there are clever ways to make that > happen without too much fuss. I fear I may have confused things a bit with my previous comment; when I spoke about outbound traffic I was speaking rather generically. Right now NetLabel provides two methods for labeling traffic, labeling traffic via the associated socket, and labeling traffic by labeling the packets directly. The NetLabel configuration will determine how this happens (are you using the NetLabel address selectors?), and the stacking mechanism will need to handle both ... I think the good news here is that if you solve the equivalence problem across LSMs for one of these methods, you should be able to use the same approach for the other. >> but let's be honest, if you are running >> two major LSMs simultaneously, you've probably got much bigger >> problems to worry about (I still wonder how prevalent this will be >> outside of some LSM developers and hobbyists). > > Major modules *that use CIPSO* is the key. ... or CALIPSO ... or the static/fallback labels ;) > A major module is > any module that uses any security blob. I don't see any of the > 8 modules proposed recently supplying network hooks that care > about passing information abroad. Unless AppArmor surprises me > when the long awaited update arrives I only see an issue with > SELinux + Smack, and we're in complete agreement on how likely > that is to be a production configuration. > >>>> The cache >>>> could be made multiple-LSM aware so that it could be enabled, but I >>>> think even cache disabled NetLabel support is a better option than >>>> this. >>> I don't intend this as a solution, but it sure is convenient. >>> I expect to drop it as a better solution evolves. >>> As always, suggestions are welcome. >> Good, glad to hear it. Yes, disabling the cache is going to have a >> nasty performance impact - it's been years since I've done performance >> measurements, but when I introduced the cache it was a *huge* win on >> per-packet overhead as it allows us to sidestep a lot of label >> interpretation steps and got straight from the on-the-wire label to a >> LSM internalized secid/secctx. > > I have some new ideas to try out based on this. Thanks for > the feedback. drinksowed++
On 1/28/2017 12:45 AM, Paul Moore wrote: > On Fri, Jan 27, 2017 at 2:41 PM, Casey Schaufler <casey@schaufler-ca.com> wrote: >> On 1/27/2017 2:09 AM, Paul Moore wrote: >>> On Thu, Jan 26, 2017 at 11:51 AM, Casey Schaufler >>> <casey@schaufler-ca.com> wrote: >>>> On 1/26/2017 5:35 AM, Paul Moore wrote: >>>>> On Wed, Jan 25, 2017 at 9:07 PM, Casey Schaufler <casey@schaufler-ca.com> wrote: >>>>>> Subject: [PATCH RFC 9/9] SELinux: Allow explicit netlabel configuration > .. > >>>>> especially when I believe it should >>>>> be possible if the NetLabel cache is avoided/disabled. >>>> I have been playing with a model in which the modules >>>> are called upon to approve (or disapprove) each others >>>> attempts to set netlabel attributes. As you might expect, >>>> the problem comes with what to do when SELinux wants >>>> something that Smack can't abide, or the other way around. >>>> Socket creation, for example, shouldn't fail in that case, >>>> but the netlabel attributes shouldn't be set inappropriately, >>>> either. >>> Oddly enough I have been more worried about in inbound side, >>> especially with respect to the cache so we don't tank performance. >> My admittedly incomplete look at the inbound side leads me >> to think that for the Smack & SELinux case it's reasonably >> simple, but that's because Smack doesn't use the netlabel >> cache features. At least, I don't think it does. Am I wrong? > If you're not using any of the NetLabel caching functions than you're > not using any of the NetLabel caching. This might be a happy bit of > luck for the stacking effort, but you really want to use the NetLabel > cache whenever you can. > >>> I'm not sure how much can be done in one >>> LSM, or the LSM shim layer for that matter, to approve/reject labels >>> from another LSM; I think they either match or they don't. >> I had been looking at checking for equivalence when the netlabel >> attributes were set on the socket, but it seems that checking on >> send might work better. That would mean checking all the netlabel >> attributes at send time, but there are clever ways to make that >> happen without too much fuss. > I fear I may have confused things a bit with my previous comment; when > I spoke about outbound traffic I was speaking rather generically. > Right now NetLabel provides two methods for labeling traffic, labeling > traffic via the associated socket, and labeling traffic by labeling > the packets directly. The NetLabel configuration will determine how > this happens (are you using the NetLabel address selectors?), and the > stacking mechanism will need to handle both ... I think the good news > here is that if you solve the equivalence problem across LSMs for one > of these methods, you should be able to use the same approach for the > other. Should I propose a netlabel kapi function for "equivalence"? The alternative is to grub around in the netlbl_lsm_secattr structure in security.c, which does not appeal to me. I've looked at creating a new hook to ask the modules if the netlbl data matches, but that gets messy and duplicative in a hurry. And, it still really wants a netlabel equivalence function. > >>> but let's be honest, if you are running >>> two major LSMs simultaneously, you've probably got much bigger >>> problems to worry about (I still wonder how prevalent this will be >>> outside of some LSM developers and hobbyists). >> Major modules *that use CIPSO* is the key. > .. or CALIPSO ... or the static/fallback labels ;) > >> A major module is >> any module that uses any security blob. I don't see any of the >> 8 modules proposed recently supplying network hooks that care >> about passing information abroad. Unless AppArmor surprises me >> when the long awaited update arrives I only see an issue with >> SELinux + Smack, and we're in complete agreement on how likely >> that is to be a production configuration. >> >>>>> The cache >>>>> could be made multiple-LSM aware so that it could be enabled, but I >>>>> think even cache disabled NetLabel support is a better option than >>>>> this. >>>> I don't intend this as a solution, but it sure is convenient. >>>> I expect to drop it as a better solution evolves. >>>> As always, suggestions are welcome. >>> Good, glad to hear it. Yes, disabling the cache is going to have a >>> nasty performance impact - it's been years since I've done performance >>> measurements, but when I introduced the cache it was a *huge* win on >>> per-packet overhead as it allows us to sidestep a lot of label >>> interpretation steps and got straight from the on-the-wire label to a >>> LSM internalized secid/secctx. >> I have some new ideas to try out based on this. Thanks for >> the feedback. drinksowed++ -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Jan 31, 2017 at 2:31 PM, Casey Schaufler <casey@schaufler-ca.com> wrote: > On 1/28/2017 12:45 AM, Paul Moore wrote: >> On Fri, Jan 27, 2017 at 2:41 PM, Casey Schaufler <casey@schaufler-ca.com> wrote: >>> On 1/27/2017 2:09 AM, Paul Moore wrote: >>>> On Thu, Jan 26, 2017 at 11:51 AM, Casey Schaufler >>>> <casey@schaufler-ca.com> wrote: >>>>> On 1/26/2017 5:35 AM, Paul Moore wrote: >>>>>> On Wed, Jan 25, 2017 at 9:07 PM, Casey Schaufler <casey@schaufler-ca.com> wrote: >>>>>>> Subject: [PATCH RFC 9/9] SELinux: Allow explicit netlabel configuration >> .. >> >>>>>> especially when I believe it should >>>>>> be possible if the NetLabel cache is avoided/disabled. >>>>> I have been playing with a model in which the modules >>>>> are called upon to approve (or disapprove) each others >>>>> attempts to set netlabel attributes. As you might expect, >>>>> the problem comes with what to do when SELinux wants >>>>> something that Smack can't abide, or the other way around. >>>>> Socket creation, for example, shouldn't fail in that case, >>>>> but the netlabel attributes shouldn't be set inappropriately, >>>>> either. >>>> >>>> Oddly enough I have been more worried about in inbound side, >>>> especially with respect to the cache so we don't tank performance. >>> >>> My admittedly incomplete look at the inbound side leads me >>> to think that for the Smack & SELinux case it's reasonably >>> simple, but that's because Smack doesn't use the netlabel >>> cache features. At least, I don't think it does. Am I wrong? >> >> If you're not using any of the NetLabel caching functions than you're >> not using any of the NetLabel caching. This might be a happy bit of >> luck for the stacking effort, but you really want to use the NetLabel >> cache whenever you can. >> >>>> I'm not sure how much can be done in one >>>> LSM, or the LSM shim layer for that matter, to approve/reject labels >>>> from another LSM; I think they either match or they don't. >>> I had been looking at checking for equivalence when the netlabel >>> attributes were set on the socket, but it seems that checking on >>> send might work better. That would mean checking all the netlabel >>> attributes at send time, but there are clever ways to make that >>> happen without too much fuss. >> >> I fear I may have confused things a bit with my previous comment; when >> I spoke about outbound traffic I was speaking rather generically. >> Right now NetLabel provides two methods for labeling traffic, labeling >> traffic via the associated socket, and labeling traffic by labeling >> the packets directly. The NetLabel configuration will determine how >> this happens (are you using the NetLabel address selectors?), and the >> stacking mechanism will need to handle both ... I think the good news >> here is that if you solve the equivalence problem across LSMs for one >> of these methods, you should be able to use the same approach for the >> other. > > Should I propose a netlabel kapi function for "equivalence"? > The alternative is to grub around in the netlbl_lsm_secattr > structure in security.c, which does not appeal to me. I've > looked at creating a new hook to ask the modules if the netlbl > data matches, but that gets messy and duplicative in a hurry. > And, it still really wants a netlabel equivalence function. My apologies, this got lost while I was doing some traveling ... yes, I think a NetLabel kapi function for netlbl_lsm_secattr equivalence is probably the right thing to do.
On 2/8/2017 2:09 PM, Paul Moore wrote: > On Tue, Jan 31, 2017 at 2:31 PM, Casey Schaufler <casey@schaufler-ca.com> wrote: >> On 1/28/2017 12:45 AM, Paul Moore wrote: >>> On Fri, Jan 27, 2017 at 2:41 PM, Casey Schaufler <casey@schaufler-ca.com> wrote: >>>> On 1/27/2017 2:09 AM, Paul Moore wrote: >>>>> On Thu, Jan 26, 2017 at 11:51 AM, Casey Schaufler >>>>> <casey@schaufler-ca.com> wrote: >>>>>> On 1/26/2017 5:35 AM, Paul Moore wrote: >>>>>>> On Wed, Jan 25, 2017 at 9:07 PM, Casey Schaufler <casey@schaufler-ca.com> wrote: >>>>>>>> Subject: [PATCH RFC 9/9] SELinux: Allow explicit netlabel configuration >>> .. >>> >>>>>>> especially when I believe it should >>>>>>> be possible if the NetLabel cache is avoided/disabled. >>>>>> I have been playing with a model in which the modules >>>>>> are called upon to approve (or disapprove) each others >>>>>> attempts to set netlabel attributes. As you might expect, >>>>>> the problem comes with what to do when SELinux wants >>>>>> something that Smack can't abide, or the other way around. >>>>>> Socket creation, for example, shouldn't fail in that case, >>>>>> but the netlabel attributes shouldn't be set inappropriately, >>>>>> either. >>>>> Oddly enough I have been more worried about in inbound side, >>>>> especially with respect to the cache so we don't tank performance. >>>> My admittedly incomplete look at the inbound side leads me >>>> to think that for the Smack & SELinux case it's reasonably >>>> simple, but that's because Smack doesn't use the netlabel >>>> cache features. At least, I don't think it does. Am I wrong? >>> If you're not using any of the NetLabel caching functions than you're >>> not using any of the NetLabel caching. This might be a happy bit of >>> luck for the stacking effort, but you really want to use the NetLabel >>> cache whenever you can. >>> >>>>> I'm not sure how much can be done in one >>>>> LSM, or the LSM shim layer for that matter, to approve/reject labels >>>>> from another LSM; I think they either match or they don't. >>>> I had been looking at checking for equivalence when the netlabel >>>> attributes were set on the socket, but it seems that checking on >>>> send might work better. That would mean checking all the netlabel >>>> attributes at send time, but there are clever ways to make that >>>> happen without too much fuss. >>> I fear I may have confused things a bit with my previous comment; when >>> I spoke about outbound traffic I was speaking rather generically. >>> Right now NetLabel provides two methods for labeling traffic, labeling >>> traffic via the associated socket, and labeling traffic by labeling >>> the packets directly. The NetLabel configuration will determine how >>> this happens (are you using the NetLabel address selectors?), and the >>> stacking mechanism will need to handle both ... I think the good news >>> here is that if you solve the equivalence problem across LSMs for one >>> of these methods, you should be able to use the same approach for the >>> other. >> Should I propose a netlabel kapi function for "equivalence"? >> The alternative is to grub around in the netlbl_lsm_secattr >> structure in security.c, which does not appeal to me. I've >> looked at creating a new hook to ask the modules if the netlbl >> data matches, but that gets messy and duplicative in a hurry. >> And, it still really wants a netlabel equivalence function. > My apologies, this got lost while I was doing some traveling ... yes, > I think a NetLabel kapi function for netlbl_lsm_secattr equivalence is > probably the right thing to do. > OK, I will take that approach. Does bool netlbl_lsm_secattr_equal(const struct netlbl_lsm_secattr *theone, const struct netlbl_lsm_secattr *theother) look like the right start? Do you think there are error conditions that are worthy of reporting, and making it an int instead of a bool? -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Feb 8, 2017 at 5:30 PM, Casey Schaufler <casey@schaufler-ca.com> wrote: > On 2/8/2017 2:09 PM, Paul Moore wrote: >> On Tue, Jan 31, 2017 at 2:31 PM, Casey Schaufler <casey@schaufler-ca.com> wrote: ... >>> Should I propose a netlabel kapi function for "equivalence"? >>> The alternative is to grub around in the netlbl_lsm_secattr >>> structure in security.c, which does not appeal to me. I've >>> looked at creating a new hook to ask the modules if the netlbl >>> data matches, but that gets messy and duplicative in a hurry. >>> And, it still really wants a netlabel equivalence function. >> My apologies, this got lost while I was doing some traveling ... yes, >> I think a NetLabel kapi function for netlbl_lsm_secattr equivalence is >> probably the right thing to do. >> > OK, I will take that approach. Does > > bool netlbl_lsm_secattr_equal(const struct netlbl_lsm_secattr *theone, > const struct netlbl_lsm_secattr *theother) > > look like the right start? Yep, pretty close. If you want to bother with details, a few tweaks should be made for the sake of consistency with the rest of the NetLabel code; I would suggest the following: bool netlbl_secattr_equal(const struct netlbl_lsm_secattr *secattr_a, const struct netlbl_lsm_secattr *secattr_b); > Do you think there are error conditions that are worthy of reporting, and making it an int instead of a bool? We shouldn't need to worry about any memory allocation errors or similar problems so it really should come down to a yes/no verdict on equality; a bool should be fine. Regardless, this is a kernel internal API so if we have to change it at some point in the future it shouldn't be a major problem.
On 2/8/2017 2:39 PM, Paul Moore wrote: > On Wed, Feb 8, 2017 at 5:30 PM, Casey Schaufler <casey@schaufler-ca.com> wrote: >> On 2/8/2017 2:09 PM, Paul Moore wrote: >>> On Tue, Jan 31, 2017 at 2:31 PM, Casey Schaufler <casey@schaufler-ca.com> wrote: > .. > >>>> Should I propose a netlabel kapi function for "equivalence"? >>>> The alternative is to grub around in the netlbl_lsm_secattr >>>> structure in security.c, which does not appeal to me. I've >>>> looked at creating a new hook to ask the modules if the netlbl >>>> data matches, but that gets messy and duplicative in a hurry. >>>> And, it still really wants a netlabel equivalence function. >>> My apologies, this got lost while I was doing some traveling ... yes, >>> I think a NetLabel kapi function for netlbl_lsm_secattr equivalence is >>> probably the right thing to do. >>> >> OK, I will take that approach. Does >> >> bool netlbl_lsm_secattr_equal(const struct netlbl_lsm_secattr *theone, >> const struct netlbl_lsm_secattr *theother) >> >> look like the right start? > Yep, pretty close. If you want to bother with details, a few tweaks > should be made for the sake of consistency with the rest of the > NetLabel code; I would suggest the following: > > bool netlbl_secattr_equal(const struct netlbl_lsm_secattr *secattr_a, > const struct netlbl_lsm_secattr *secattr_b); Thanks. I will use this. > >> Do you think there are error conditions that are worthy of reporting, and making it an int instead of a bool? > We shouldn't need to worry about any memory allocation errors or > similar problems so it really should come down to a yes/no verdict on > equality; a bool should be fine. Regardless, this is a kernel > internal API so if we have to change it at some point in the future it > shouldn't be a major problem. > -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/security/selinux/Kconfig b/security/selinux/Kconfig index ea7e3ef..86cc9e8 100644 --- a/security/selinux/Kconfig +++ b/security/selinux/Kconfig @@ -93,3 +93,15 @@ config SECURITY_SELINUX_CHECKREQPROT_VALUE via /selinux/checkreqprot if authorized by policy. If you are unsure how to answer this question, answer 0. + +config SECURITY_SELINUX_NETLABEL + bool "NSA SELinux labeled networking support" + depends on SECURITY_SELINUX + depends on NETLABEL + default y + help + This option enables SELinux to use the netlabel subsystem + for labeling IPv4 packets with CIPSO and IPv6 packets with + CALYPSO. + + If you are unsure how to answer this question, answer Y. diff --git a/security/selinux/Makefile b/security/selinux/Makefile index 3411c33..06f1573 100644 --- a/security/selinux/Makefile +++ b/security/selinux/Makefile @@ -11,7 +11,7 @@ selinux-y := avc.o hooks.o selinuxfs.o netlink.o nlmsgtab.o netif.o \ selinux-$(CONFIG_SECURITY_NETWORK_XFRM) += xfrm.o -selinux-$(CONFIG_NETLABEL) += netlabel.o +selinux-$(CONFIG_SECURITY_SELINUX_NETLABEL) += netlabel.o ccflags-y := -I$(srctree)/security/selinux -I$(srctree)/security/selinux/include diff --git a/security/selinux/include/netlabel.h b/security/selinux/include/netlabel.h index 75686d5..c6e3019 100644 --- a/security/selinux/include/netlabel.h +++ b/security/selinux/include/netlabel.h @@ -37,7 +37,7 @@ #include "avc.h" #include "objsec.h" -#ifdef CONFIG_NETLABEL +#ifdef CONFIG_SECURITY_SELINUX_NETLABEL void selinux_netlbl_cache_invalidate(void); void selinux_netlbl_err(struct sk_buff *skb, u16 family, int error, @@ -146,6 +146,6 @@ static inline int selinux_netlbl_socket_connect(struct sock *sk, { return 0; } -#endif /* CONFIG_NETLABEL */ +#endif /* CONFIG_SECURITY_SELINUX_NETLABEL */ #endif diff --git a/security/selinux/include/objsec.h b/security/selinux/include/objsec.h index b89e1b0c..52528ec 100644 --- a/security/selinux/include/objsec.h +++ b/security/selinux/include/objsec.h @@ -106,7 +106,7 @@ struct netport_security_struct { }; struct sk_security_struct { -#ifdef CONFIG_NETLABEL +#ifdef CONFIG_SECURITY_SELINUX_NETLABEL enum { /* NetLabel state */ NLBL_UNSET = 0, NLBL_REQUIRE, diff --git a/security/selinux/include/security.h b/security/selinux/include/security.h index 308a286..2da3575 100644 --- a/security/selinux/include/security.h +++ b/security/selinux/include/security.h @@ -213,7 +213,7 @@ int security_fs_use(struct super_block *sb); int security_genfs_sid(const char *fstype, char *name, u16 sclass, u32 *sid); -#ifdef CONFIG_NETLABEL +#ifdef CONFIG_SECURITY_SELINUX_NETLABEL int security_netlbl_secattr_to_sid(struct netlbl_lsm_secattr *secattr, u32 *sid); @@ -232,7 +232,7 @@ static inline int security_netlbl_sid_to_secattr(u32 sid, { return -ENOENT; } -#endif /* CONFIG_NETLABEL */ +#endif /* CONFIG_SECURITY_SELINUX_NETLABEL */ const char *security_get_initial_sid_context(u32 sid); diff --git a/security/selinux/ss/ebitmap.c b/security/selinux/ss/ebitmap.c index 7d10e5d..df017e0 100644 --- a/security/selinux/ss/ebitmap.c +++ b/security/selinux/ss/ebitmap.c @@ -74,7 +74,7 @@ int ebitmap_cpy(struct ebitmap *dst, struct ebitmap *src) return 0; } -#ifdef CONFIG_NETLABEL +#ifdef CONFIG_SECURITY_SELINUX_NETLABEL /** * ebitmap_netlbl_export - Export an ebitmap into a NetLabel category bitmap * @ebmap: the ebitmap to export @@ -188,7 +188,7 @@ int ebitmap_netlbl_import(struct ebitmap *ebmap, ebitmap_destroy(ebmap); return -ENOMEM; } -#endif /* CONFIG_NETLABEL */ +#endif /* CONFIG_SECURITY_SELINUX_NETLABEL */ /* * Check to see if all the bits set in e2 are also set in e1. Optionally, diff --git a/security/selinux/ss/ebitmap.h b/security/selinux/ss/ebitmap.h index 9637b8c..f03153a 100644 --- a/security/selinux/ss/ebitmap.h +++ b/security/selinux/ss/ebitmap.h @@ -130,7 +130,7 @@ void ebitmap_destroy(struct ebitmap *e); int ebitmap_read(struct ebitmap *e, void *fp); int ebitmap_write(struct ebitmap *e, void *fp); -#ifdef CONFIG_NETLABEL +#ifdef CONFIG_SECURITY_SELINUX_NETLABEL int ebitmap_netlbl_export(struct ebitmap *ebmap, struct netlbl_lsm_catmap **catmap); int ebitmap_netlbl_import(struct ebitmap *ebmap, diff --git a/security/selinux/ss/mls.c b/security/selinux/ss/mls.c index e108884..9dd384a 100644 --- a/security/selinux/ss/mls.c +++ b/security/selinux/ss/mls.c @@ -565,7 +565,7 @@ int mls_compute_sid(struct context *scontext, return -EINVAL; } -#ifdef CONFIG_NETLABEL +#ifdef CONFIG_SECURITY_SELINUX_NETLABEL /** * mls_export_netlbl_lvl - Export the MLS sensitivity levels to NetLabel * @context: the security context @@ -665,4 +665,4 @@ int mls_import_netlbl_cat(struct context *context, ebitmap_destroy(&context->range.level[0].cat); return rc; } -#endif /* CONFIG_NETLABEL */ +#endif /* CONFIG_SECURITY_SELINUX_NETLABEL */ diff --git a/security/selinux/ss/mls.h b/security/selinux/ss/mls.h index e4369e3..d2d52c2 100644 --- a/security/selinux/ss/mls.h +++ b/security/selinux/ss/mls.h @@ -55,7 +55,7 @@ int mls_compute_sid(struct context *scontext, int mls_setup_user_range(struct context *fromcon, struct user_datum *user, struct context *usercon); -#ifdef CONFIG_NETLABEL +#ifdef CONFIG_SECURITY_SELINUX_NETLABEL void mls_export_netlbl_lvl(struct context *context, struct netlbl_lsm_secattr *secattr); void mls_import_netlbl_lvl(struct context *context, diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c index c91ad88..f713d47 100644 --- a/security/selinux/ss/services.c +++ b/security/selinux/ss/services.c @@ -3266,7 +3266,7 @@ static int __init aurule_init(void) } __initcall(aurule_init); -#ifdef CONFIG_NETLABEL +#ifdef CONFIG_SECURITY_SELINUX_NETLABEL /** * security_netlbl_cache_add - Add an entry to the NetLabel cache * @secattr: the NetLabel packet security attributes @@ -3409,7 +3409,7 @@ int security_netlbl_sid_to_secattr(u32 sid, struct netlbl_lsm_secattr *secattr) read_unlock(&policy_rwlock); return rc; } -#endif /* CONFIG_NETLABEL */ +#endif /* CONFIG_SECURITY_SELINUX_NETLABEL */ /** * security_read_policy - read the policy.
Subject: [PATCH RFC 9/9] SELinux: Allow explicit netlabel configuration In certain stacking configurations it is convenient to disable the netlabel subsystem for SELinux even if it is compiled in. If Smack is being used at the same time as SELinux there are cases where SELinux should defer all network labeling to its peer. No code changes, really. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> --- security/selinux/Kconfig | 12 ++++++++++++ security/selinux/Makefile | 2 +- security/selinux/include/netlabel.h | 4 ++-- security/selinux/include/objsec.h | 2 +- security/selinux/include/security.h | 4 ++-- security/selinux/ss/ebitmap.c | 4 ++-- security/selinux/ss/ebitmap.h | 2 +- security/selinux/ss/mls.c | 4 ++-- security/selinux/ss/mls.h | 2 +- security/selinux/ss/services.c | 4 ++-- 10 files changed, 26 insertions(+), 14 deletions(-)