* The secmark "one user" policy @ 2017-06-21 0:41 Casey Schaufler 2017-06-21 7:13 ` James Morris 0 siblings, 1 reply; 24+ messages in thread From: Casey Schaufler @ 2017-06-21 0:41 UTC (permalink / raw) To: linux-security-module I'm looking at the secmark code and am looking in particular at the places where it explicitly says that it is intended for one security module at a time. For extreme stacking I can either enforce this restriction by configuration or remove it by clever uses of secid mappings. Either can be made "transparent" to existing user-space. Paul has expressed distaste for using configuration as a shortcut for dealing with this kind of problem, and I generally agree with him. On the other hand, the code is quite clear that it is designed for one and only one kind of secid at a time. I don't want to put a lot of effort into patches that are unacceptable to the author. Thank you. -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
* The secmark "one user" policy 2017-06-21 0:41 The secmark "one user" policy Casey Schaufler @ 2017-06-21 7:13 ` James Morris 2017-06-21 15:23 ` Casey Schaufler 0 siblings, 1 reply; 24+ messages in thread From: James Morris @ 2017-06-21 7:13 UTC (permalink / raw) To: linux-security-module On Tue, 20 Jun 2017, Casey Schaufler wrote: > I'm looking at the secmark code and am looking in > particular at the places where it explicitly says > that it is intended for one security module at a > time. For extreme stacking I can either enforce this > restriction by configuration or remove it by clever > uses of secid mappings. Either can be made "transparent" > to existing user-space. Paul has expressed distaste for > using configuration as a shortcut for dealing with this > kind of problem, and I generally agree with him. On the > other hand, the code is quite clear that it is designed > for one and only one kind of secid at a time. I don't > want to put a lot of effort into patches that are > unacceptable to the author. How would you see this working, ideally? -- James Morris <jmorris@namei.org> -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
* The secmark "one user" policy 2017-06-21 7:13 ` James Morris @ 2017-06-21 15:23 ` Casey Schaufler 2017-06-21 23:07 ` John Johansen ` (2 more replies) 0 siblings, 3 replies; 24+ messages in thread From: Casey Schaufler @ 2017-06-21 15:23 UTC (permalink / raw) To: linux-security-module On 6/21/2017 12:13 AM, James Morris wrote: > On Tue, 20 Jun 2017, Casey Schaufler wrote: > >> I'm looking at the secmark code and am looking in >> particular at the places where it explicitly says >> that it is intended for one security module at a >> time. For extreme stacking I can either enforce this >> restriction by configuration or remove it by clever >> uses of secid mappings. Either can be made "transparent" >> to existing user-space. Paul has expressed distaste for >> using configuration as a shortcut for dealing with this >> kind of problem, and I generally agree with him. On the >> other hand, the code is quite clear that it is designed >> for one and only one kind of secid at a time. I don't >> want to put a lot of effort into patches that are >> unacceptable to the author. > How would you see this working, ideally? Ideally there would be a separate secmark for each security module that wants to use the mechanism. Mechanism would be provided* so that user-space can identify which security module it is referring to when interacting with the kernel. My understanding is that we're unlikely to get an expanded secmark, so I have concentrated elsewhere. A "clever" secid mapping takes the secids from all the security modules and gently manipulates them until they fit into a single u32. This might be an index into a list of secid sets, but if you have two modules using secids you can give each half of the secmark and accommodate many configurations, including Fedora. Again, you need mechanism* for user-space. This option would require changes to the xt_SECMARK implementation, which goes out of it's way to ensure all secmarks come from the same security module. One option is to add a SECMARK_MODE_COMPOUND, but that isn't any more helpful then removing the restriction. As for configuration options, SELinux only uses secmarks when user-space introduces them. If netfilter doesn't have any security rules that add secmarks, none are used. Smack can be configured to set secmarks on all packets, with the potential for change by user-space, but can also be set up without any use of secmarks. There doesn't need to be any significant change to xt_SECMARK if it is important to maintain the "one user" model. Requiring that the user-space use of netfilter be sane for the multiple security module case (e.g. don't use SELinux firewall if Smack has the secmark) seems somewhat reasonable. I can work with any of these three solutions. Multiple secmarks would be ideal, but I understand is a lost cause. Clever secids add overhead and complexity. Restricting configuration options is unsavory, but I don't think unreasonably so. --- * There's already need to identity which security module you're dealing with at a given time for SO_PEERSEC and /proc/.../attr/current. In the past I've suggested decorating attribute values with the name of the module (smack='System') but I'm currently leaning more toward a prctl() to set the value if you don't want to get whatever comes first. That should maximize the effectiveness of existing user-space tools. -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
* The secmark "one user" policy 2017-06-21 15:23 ` Casey Schaufler @ 2017-06-21 23:07 ` John Johansen 2017-06-21 23:45 ` Casey Schaufler 2017-06-22 9:54 ` James Morris 2017-06-22 22:24 ` Paul Moore 2 siblings, 1 reply; 24+ messages in thread From: John Johansen @ 2017-06-21 23:07 UTC (permalink / raw) To: linux-security-module On 06/21/2017 08:23 AM, Casey Schaufler wrote: > On 6/21/2017 12:13 AM, James Morris wrote: >> On Tue, 20 Jun 2017, Casey Schaufler wrote: >> >>> I'm looking at the secmark code and am looking in >>> particular at the places where it explicitly says >>> that it is intended for one security module at a >>> time. For extreme stacking I can either enforce this >>> restriction by configuration or remove it by clever >>> uses of secid mappings. Either can be made "transparent" >>> to existing user-space. Paul has expressed distaste for >>> using configuration as a shortcut for dealing with this >>> kind of problem, and I generally agree with him. On the >>> other hand, the code is quite clear that it is designed >>> for one and only one kind of secid at a time. I don't >>> want to put a lot of effort into patches that are >>> unacceptable to the author. >> How would you see this working, ideally? > > Ideally there would be a separate secmark for each security > module that wants to use the mechanism. Mechanism would be > provided* so that user-space can identify which security > module it is referring to when interacting with the kernel. > My understanding is that we're unlikely to get an expanded > secmark, so I have concentrated elsewhere. > > A "clever" secid mapping takes the secids from all the > security modules and gently manipulates them until they > fit into a single u32. This might be an index into a list > of secid sets, but if you have two modules using secids > you can give each half of the secmark and accommodate > many configurations, including Fedora. Again, you need > mechanism* for user-space. This option would require changes > to the xt_SECMARK implementation, which goes out of it's > way to ensure all secmarks come from the same security > module. One option is to add a SECMARK_MODE_COMPOUND, but > that isn't any more helpful then removing the restriction. > > As for configuration options, SELinux only uses secmarks > when user-space introduces them. If netfilter doesn't have > any security rules that add secmarks, none are used. Smack > can be configured to set secmarks on all packets, with the > potential for change by user-space, but can also be set up > without any use of secmarks. There doesn't need to be any > significant change to xt_SECMARK if it is important to > maintain the "one user" model. Requiring that the user-space > use of netfilter be sane for the multiple security module > case (e.g. don't use SELinux firewall if Smack has the > secmark) seems somewhat reasonable. > > I can work with any of these three solutions. Multiple > secmarks would be ideal, but I understand is a lost cause. > Clever secids add overhead and complexity. Restricting > configuration options is unsavory, but I don't think > unreasonably so. > I too would prefer multiple secmarks, but doing some sort of mapping seems like what we will be stuck with. For a first pass I think the restricted configurations options is reasonable, but I think it will become a problem as people start trying to actually use LSM stacking. I think for now sticking with restricted configurations and dealing with mappings when it becomes an actual issue and we have better use cases is not an unreasonable approach. > --- > * There's already need to identity which security module > you're dealing with at a given time for SO_PEERSEC and > /proc/.../attr/current. In the past I've suggested decorating > attribute values with the name of the module (smack='System') > but I'm currently leaning more toward a prctl() to set the > value if you don't want to get whatever comes first. That > should maximize the effectiveness of existing user-space > tools. > -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
* The secmark "one user" policy 2017-06-21 23:07 ` John Johansen @ 2017-06-21 23:45 ` Casey Schaufler 2017-06-22 0:48 ` John Johansen 0 siblings, 1 reply; 24+ messages in thread From: Casey Schaufler @ 2017-06-21 23:45 UTC (permalink / raw) To: linux-security-module On 6/21/2017 4:07 PM, John Johansen wrote: > On 06/21/2017 08:23 AM, Casey Schaufler wrote: >> On 6/21/2017 12:13 AM, James Morris wrote: >>> On Tue, 20 Jun 2017, Casey Schaufler wrote: >>> >>>> I'm looking at the secmark code and am looking in >>>> particular at the places where it explicitly says >>>> that it is intended for one security module at a >>>> time. For extreme stacking I can either enforce this >>>> restriction by configuration or remove it by clever >>>> uses of secid mappings. Either can be made "transparent" >>>> to existing user-space. Paul has expressed distaste for >>>> using configuration as a shortcut for dealing with this >>>> kind of problem, and I generally agree with him. On the >>>> other hand, the code is quite clear that it is designed >>>> for one and only one kind of secid at a time. I don't >>>> want to put a lot of effort into patches that are >>>> unacceptable to the author. >>> How would you see this working, ideally? >> Ideally there would be a separate secmark for each security >> module that wants to use the mechanism. Mechanism would be >> provided* so that user-space can identify which security >> module it is referring to when interacting with the kernel. >> My understanding is that we're unlikely to get an expanded >> secmark, so I have concentrated elsewhere. >> >> A "clever" secid mapping takes the secids from all the >> security modules and gently manipulates them until they >> fit into a single u32. This might be an index into a list >> of secid sets, but if you have two modules using secids >> you can give each half of the secmark and accommodate >> many configurations, including Fedora. Again, you need >> mechanism* for user-space. This option would require changes >> to the xt_SECMARK implementation, which goes out of it's >> way to ensure all secmarks come from the same security >> module. One option is to add a SECMARK_MODE_COMPOUND, but >> that isn't any more helpful then removing the restriction. >> >> As for configuration options, SELinux only uses secmarks >> when user-space introduces them. If netfilter doesn't have >> any security rules that add secmarks, none are used. Smack >> can be configured to set secmarks on all packets, with the >> potential for change by user-space, but can also be set up >> without any use of secmarks. There doesn't need to be any >> significant change to xt_SECMARK if it is important to >> maintain the "one user" model. Requiring that the user-space >> use of netfilter be sane for the multiple security module >> case (e.g. don't use SELinux firewall if Smack has the >> secmark) seems somewhat reasonable. >> >> I can work with any of these three solutions. Multiple >> secmarks would be ideal, but I understand is a lost cause. >> Clever secids add overhead and complexity. Restricting >> configuration options is unsavory, but I don't think >> unreasonably so. >> > I too would prefer multiple secmarks, but doing some sort of mapping > seems like what we will be stuck with. For a first pass I think the > restricted configurations options is reasonable, but I think it will > become a problem as people start trying to actually use LSM stacking. > > I think for now sticking with restricted configurations and dealing > with mappings when it becomes an actual issue and we have better use > cases is not an unreasonable approach. It boils down to how many security modules are going to implement network controls that require passing information with the packet. I can easily see a bunch of use cases beyond what SELinux and Smack do, but I can't say that I'd see those used in conjunction with the "old school" security modules. We can have a lousy mapping scheme if we don't expect it to be used except in unnatural cases. Is AppArmor going to be using secmarks? I haven't looked at what's going into 4.13 yet. If you are, are they required or optional, or used when netfilter assigns them? >> --- >> * There's already need to identity which security module >> you're dealing with at a given time for SO_PEERSEC and >> /proc/.../attr/current. In the past I've suggested decorating >> attribute values with the name of the module (smack='System') >> but I'm currently leaning more toward a prctl() to set the >> value if you don't want to get whatever comes first. That >> should maximize the effectiveness of existing user-space >> tools. >> -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
* The secmark "one user" policy 2017-06-21 23:45 ` Casey Schaufler @ 2017-06-22 0:48 ` John Johansen 0 siblings, 0 replies; 24+ messages in thread From: John Johansen @ 2017-06-22 0:48 UTC (permalink / raw) To: linux-security-module On 06/21/2017 04:45 PM, Casey Schaufler wrote: > On 6/21/2017 4:07 PM, John Johansen wrote: >> On 06/21/2017 08:23 AM, Casey Schaufler wrote: >>> On 6/21/2017 12:13 AM, James Morris wrote: >>>> On Tue, 20 Jun 2017, Casey Schaufler wrote: >>>> >>>>> I'm looking at the secmark code and am looking in >>>>> particular at the places where it explicitly says >>>>> that it is intended for one security module at a >>>>> time. For extreme stacking I can either enforce this >>>>> restriction by configuration or remove it by clever >>>>> uses of secid mappings. Either can be made "transparent" >>>>> to existing user-space. Paul has expressed distaste for >>>>> using configuration as a shortcut for dealing with this >>>>> kind of problem, and I generally agree with him. On the >>>>> other hand, the code is quite clear that it is designed >>>>> for one and only one kind of secid at a time. I don't >>>>> want to put a lot of effort into patches that are >>>>> unacceptable to the author. >>>> How would you see this working, ideally? >>> Ideally there would be a separate secmark for each security >>> module that wants to use the mechanism. Mechanism would be >>> provided* so that user-space can identify which security >>> module it is referring to when interacting with the kernel. >>> My understanding is that we're unlikely to get an expanded >>> secmark, so I have concentrated elsewhere. >>> >>> A "clever" secid mapping takes the secids from all the >>> security modules and gently manipulates them until they >>> fit into a single u32. This might be an index into a list >>> of secid sets, but if you have two modules using secids >>> you can give each half of the secmark and accommodate >>> many configurations, including Fedora. Again, you need >>> mechanism* for user-space. This option would require changes >>> to the xt_SECMARK implementation, which goes out of it's >>> way to ensure all secmarks come from the same security >>> module. One option is to add a SECMARK_MODE_COMPOUND, but >>> that isn't any more helpful then removing the restriction. >>> >>> As for configuration options, SELinux only uses secmarks >>> when user-space introduces them. If netfilter doesn't have >>> any security rules that add secmarks, none are used. Smack >>> can be configured to set secmarks on all packets, with the >>> potential for change by user-space, but can also be set up >>> without any use of secmarks. There doesn't need to be any >>> significant change to xt_SECMARK if it is important to >>> maintain the "one user" model. Requiring that the user-space >>> use of netfilter be sane for the multiple security module >>> case (e.g. don't use SELinux firewall if Smack has the >>> secmark) seems somewhat reasonable. >>> >>> I can work with any of these three solutions. Multiple >>> secmarks would be ideal, but I understand is a lost cause. >>> Clever secids add overhead and complexity. Restricting >>> configuration options is unsavory, but I don't think >>> unreasonably so. >>> >> I too would prefer multiple secmarks, but doing some sort of mapping >> seems like what we will be stuck with. For a first pass I think the >> restricted configurations options is reasonable, but I think it will >> become a problem as people start trying to actually use LSM stacking. >> >> I think for now sticking with restricted configurations and dealing >> with mappings when it becomes an actual issue and we have better use >> cases is not an unreasonable approach. > > It boils down to how many security modules are going to > implement network controls that require passing information > with the packet. I can easily see a bunch of use cases > beyond what SELinux and Smack do, but I can't say that I'd > see those used in conjunction with the "old school" security > modules. We can have a lousy mapping scheme if we don't > expect it to be used except in unnatural cases. > > Is AppArmor going to be using secmarks? I haven't looked at > what's going into 4.13 yet. If you are, are they required or > optional, or used when netfilter assigns them? > 4.13 doesn't have any of the networking stuff, it is just an update of the mediation that is already there in 4.12, and the rework of the apparmorfs code to use the securityfs symlink support. As for secmarks, yes we will be using them, I am still messing with it, so there is room for change. AppArmor can certainly offer a level of network support if they are optional, so its likely we will do that. They will certainly supported when netfilter assigns them, but like we would like to also be able to assign them on packets, again this could be a configuration option. Hopefully I can get an RFC up soon, but I need to kick out the namespacing RFC first. -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
* The secmark "one user" policy 2017-06-21 15:23 ` Casey Schaufler 2017-06-21 23:07 ` John Johansen @ 2017-06-22 9:54 ` James Morris 2017-06-22 16:17 ` Casey Schaufler 2017-06-22 18:49 ` John Johansen 2017-06-22 22:24 ` Paul Moore 2 siblings, 2 replies; 24+ messages in thread From: James Morris @ 2017-06-22 9:54 UTC (permalink / raw) To: linux-security-module On Wed, 21 Jun 2017, Casey Schaufler wrote: > Ideally there would be a separate secmark for each security > module that wants to use the mechanism. Mechanism would be > provided* so that user-space can identify which security > module it is referring to when interacting with the kernel. > My understanding is that we're unlikely to get an expanded > secmark, so I have concentrated elsewhere. I don't see us getting an expanded secmark, either. > > A "clever" secid mapping takes the secids from all the > security modules and gently manipulates them until they > fit into a single u32. This might be an index into a list > of secid sets, but if you have two modules using secids > you can give each half of the secmark and accommodate > many configurations, including Fedora. Again, you need > mechanism* for user-space. This option would require changes > to the xt_SECMARK implementation, which goes out of it's > way to ensure all secmarks come from the same security > module. One option is to add a SECMARK_MODE_COMPOUND, but > that isn't any more helpful then removing the restriction. This sounds very ugly, and each user may assume it has 32 bits of secmark. > As for configuration options, SELinux only uses secmarks > when user-space introduces them. If netfilter doesn't have > any security rules that add secmarks, none are used. Smack > can be configured to set secmarks on all packets, with the > potential for change by user-space, but can also be set up > without any use of secmarks. There doesn't need to be any > significant change to xt_SECMARK if it is important to > maintain the "one user" model. Requiring that the user-space > use of netfilter be sane for the multiple security module > case (e.g. don't use SELinux firewall if Smack has the > secmark) seems somewhat reasonable. Reasonable? I don't think so. Trying to stack major LSMs arbitrarily and exposing that to userland is an architectural mess, which is what these kinds of problems are really telling us. How can a user be expected to reason about a system which is running multiple independent MAC security models simultaneously? It's a terrible idea. -- James Morris <jmorris@namei.org> -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
* The secmark "one user" policy 2017-06-22 9:54 ` James Morris @ 2017-06-22 16:17 ` Casey Schaufler 2017-06-23 3:12 ` James Morris 2017-06-22 18:49 ` John Johansen 1 sibling, 1 reply; 24+ messages in thread From: Casey Schaufler @ 2017-06-22 16:17 UTC (permalink / raw) To: linux-security-module On 6/22/2017 2:54 AM, James Morris wrote: > On Wed, 21 Jun 2017, Casey Schaufler wrote: > >> Ideally there would be a separate secmark for each security >> module that wants to use the mechanism. Mechanism would be >> provided* so that user-space can identify which security >> module it is referring to when interacting with the kernel. >> My understanding is that we're unlikely to get an expanded >> secmark, so I have concentrated elsewhere. > I don't see us getting an expanded secmark, either. > >> A "clever" secid mapping takes the secids from all the >> security modules and gently manipulates them until they >> fit into a single u32. This might be an index into a list >> of secid sets, but if you have two modules using secids >> you can give each half of the secmark and accommodate >> many configurations, including Fedora. Again, you need >> mechanism* for user-space. This option would require changes >> to the xt_SECMARK implementation, which goes out of it's >> way to ensure all secmarks come from the same security >> module. One option is to add a SECMARK_MODE_COMPOUND, but >> that isn't any more helpful then removing the restriction. > This sounds very ugly, and each user may assume it has 32 bits of secmark. The "two in one" doesn't scale, as well as being ugly and limited. An index scheme, where there's a table mapping N to 1 is at least as ugly and will do horrible things to performance. >> As for configuration options, SELinux only uses secmarks >> when user-space introduces them. If netfilter doesn't have >> any security rules that add secmarks, none are used. Smack >> can be configured to set secmarks on all packets, with the >> potential for change by user-space, but can also be set up >> without any use of secmarks. There doesn't need to be any >> significant change to xt_SECMARK if it is important to >> maintain the "one user" model. Requiring that the user-space >> use of netfilter be sane for the multiple security module >> case (e.g. don't use SELinux firewall if Smack has the >> secmark) seems somewhat reasonable. > Reasonable? I don't think so. > > Trying to stack major LSMs arbitrarily and exposing that to userland is an > architectural mess, I agree that it would be an administrative nightmare to produce a viable combination of SELinux, Smack, AppArmor and/or TOMOYO. I also agree that anyone who thinks it's a good idea to do so should investigate further what they're trying to accomplish. > which is what these kinds of problems are really telling us. James, I respect you greatly, but disagree with you completely. The problems with secids and secmarks have nothing to do with the complexity of administering policy. They are issues of an architecture that doesn't scale beyond unity. > How can a user be expected to reason about a system which is running > multiple independent MAC security models simultaneously? The combination of SELinux, Smack, AppArmor and/or TOMOYO is not the goal so much as the test case. MAC was the coolest possible technology in 1990. We've implemented it. I don't see anyone doing a new MAC implementation. I *do* see security modules that implement other security models in the pipeline. Some of these need to maintain state, which means using security blobs in the LSM architecture. Some of these models will want to use secmarks to implement socket based controls. If we can provide for SELinux+Smack* we can be confident that we can support anything today's kids want to throw at us. If we blow that off Linux won't be able to adapt to the security needs of the future. > It's a terrible idea. As I keep saying, SELinux+Smack is not the point of complete module stacking. SELinux combined with a time based module, or Smack with Landlock and Tags is the point. It's the future. The technical issues are the same. That is why I persist in the effort to make the existing modules stack together. -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
* The secmark "one user" policy 2017-06-22 16:17 ` Casey Schaufler @ 2017-06-23 3:12 ` James Morris 2017-06-23 15:26 ` Casey Schaufler 0 siblings, 1 reply; 24+ messages in thread From: James Morris @ 2017-06-23 3:12 UTC (permalink / raw) To: linux-security-module On Thu, 22 Jun 2017, Casey Schaufler wrote: > The combination of SELinux, Smack, AppArmor and/or TOMOYO is not > the goal so much as the test case. MAC was the coolest possible > technology in 1990. We've implemented it. I don't see anyone doing > a new MAC implementation. I *do* see security modules that implement > other security models in the pipeline. Some of these need to maintain > state, which means using security blobs in the LSM architecture. > Some of these models will want to use secmarks to implement socket > based controls. Where are these LSMs and where are the discussions about their LSM API needs? -- James Morris <jmorris@namei.org> -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
* The secmark "one user" policy 2017-06-23 3:12 ` James Morris @ 2017-06-23 15:26 ` Casey Schaufler 2017-06-25 9:41 ` James Morris 0 siblings, 1 reply; 24+ messages in thread From: Casey Schaufler @ 2017-06-23 15:26 UTC (permalink / raw) To: linux-security-module On 6/22/2017 8:12 PM, James Morris wrote: > On Thu, 22 Jun 2017, Casey Schaufler wrote: > >> The combination of SELinux, Smack, AppArmor and/or TOMOYO is not >> the goal so much as the test case. MAC was the coolest possible >> technology in 1990. We've implemented it. I don't see anyone doing >> a new MAC implementation. I *do* see security modules that implement >> other security models in the pipeline. Some of these need to maintain >> state, which means using security blobs in the LSM architecture. >> Some of these models will want to use secmarks to implement socket >> based controls. > Where are these LSMs and where are the discussions about their LSM API > needs? LandLock, CaitSith, LoadPin (now in), Checmate, HardChroot, PTAGS, SimpleFlow, SafeName, WhiteEgret, shebang, and S.A.R.A. have all been discussed on the LSM list in the past two years. There is a growing interest in LSM as a hardening mechanism, and there is discussion on kernel-hardening at lists.openwall.com. I get inquiries from people who are considering writing, or have started on new security modules but don't think they're ready for general comment. This isn't surprising as I am the vocal advocate for new, modern security modules. As you might guess, some of those proposals never see wider discussion. -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
* The secmark "one user" policy 2017-06-23 15:26 ` Casey Schaufler @ 2017-06-25 9:41 ` James Morris 2017-06-25 18:05 ` Casey Schaufler 0 siblings, 1 reply; 24+ messages in thread From: James Morris @ 2017-06-25 9:41 UTC (permalink / raw) To: linux-security-module On Fri, 23 Jun 2017, Casey Schaufler wrote: > On 6/22/2017 8:12 PM, James Morris wrote: > > On Thu, 22 Jun 2017, Casey Schaufler wrote: > > > >> The combination of SELinux, Smack, AppArmor and/or TOMOYO is not > >> the goal so much as the test case. MAC was the coolest possible > >> technology in 1990. We've implemented it. I don't see anyone doing > >> a new MAC implementation. I *do* see security modules that implement > >> other security models in the pipeline. Some of these need to maintain > >> state, which means using security blobs in the LSM architecture. > >> Some of these models will want to use secmarks to implement socket > >> based controls. > > Where are these LSMs and where are the discussions about their LSM API > > needs? > > LandLock, CaitSith, LoadPin (now in), Checmate, HardChroot, > PTAGS, SimpleFlow, SafeName, WhiteEgret, shebang, and S.A.R.A. > have all been discussed on the LSM list in the past two years. Which of these need to use secmarks to implement socket controls? -- James Morris <jmorris@namei.org> -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
* The secmark "one user" policy 2017-06-25 9:41 ` James Morris @ 2017-06-25 18:05 ` Casey Schaufler 2017-06-26 7:54 ` José Bollo 0 siblings, 1 reply; 24+ messages in thread From: Casey Schaufler @ 2017-06-25 18:05 UTC (permalink / raw) To: linux-security-module On 6/25/2017 2:41 AM, James Morris wrote: > On Fri, 23 Jun 2017, Casey Schaufler wrote: > >> On 6/22/2017 8:12 PM, James Morris wrote: >>> On Thu, 22 Jun 2017, Casey Schaufler wrote: >>> >>>> The combination of SELinux, Smack, AppArmor and/or TOMOYO is not >>>> the goal so much as the test case. MAC was the coolest possible >>>> technology in 1990. We've implemented it. I don't see anyone doing >>>> a new MAC implementation. I *do* see security modules that implement >>>> other security models in the pipeline. Some of these need to maintain >>>> state, which means using security blobs in the LSM architecture. >>>> Some of these models will want to use secmarks to implement socket >>>> based controls. >>> Where are these LSMs and where are the discussions about their LSM API >>> needs? >> LandLock, CaitSith, LoadPin (now in), Checmate, HardChroot, >> PTAGS, SimpleFlow, SafeName, WhiteEgret, shebang, and S.A.R.A. >> have all been discussed on the LSM list in the past two years. > Which of these need to use secmarks to implement socket controls? PTAGS doesn't, but will need to do so to be complete. -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
* The secmark "one user" policy 2017-06-25 18:05 ` Casey Schaufler @ 2017-06-26 7:54 ` José Bollo 2017-06-26 15:10 ` Casey Schaufler 0 siblings, 1 reply; 24+ messages in thread From: José Bollo @ 2017-06-26 7:54 UTC (permalink / raw) To: linux-security-module On Sun, 25 Jun 2017 11:05:24 -0700 Casey Schaufler <casey@schaufler-ca.com> wrote: > On 6/25/2017 2:41 AM, James Morris wrote: > > On Fri, 23 Jun 2017, Casey Schaufler wrote: > > > >> On 6/22/2017 8:12 PM, James Morris wrote: > >>> On Thu, 22 Jun 2017, Casey Schaufler wrote: > >>> > >>>> The combination of SELinux, Smack, AppArmor and/or TOMOYO is not > >>>> the goal so much as the test case. MAC was the coolest possible > >>>> technology in 1990. We've implemented it. I don't see anyone > >>>> doing a new MAC implementation. I *do* see security modules that > >>>> implement other security models in the pipeline. Some of these > >>>> need to maintain state, which means using security blobs in the > >>>> LSM architecture. Some of these models will want to use secmarks > >>>> to implement socket based controls. > >>> Where are these LSMs and where are the discussions about their > >>> LSM API needs? > >> LandLock, CaitSith, LoadPin (now in), Checmate, HardChroot, > >> PTAGS, SimpleFlow, SafeName, WhiteEgret, shebang, and S.A.R.A. > >> have all been discussed on the LSM list in the past two years. > > Which of these need to use secmarks to implement socket controls? > > PTAGS doesn't, but will need to do so to be complete. Hello Casey, The very sleepy PTAGS is suddently awaken (at least one ear :^). In my mind, PTAGS is dealing with processes. When packets are filtered, the only revelent info is the emitter process. At the moment, I don't see valuable situation where mediation isn't explicit thus faking origin isn't needed. So I would really like to understand your vision here. What do I miss? Best regards Jos? PS. I reworked the TUI (Task Unic Id) and have something valuable now. I haven't submitted it because I wanted to include a kind of FS library to provide /proc like features. But it is a nightmare to find a minute to work on this challenging part. I should really abandon that and work on TUI + PTAGS y basta. > > -- > To unsubscribe from this list: send the line "unsubscribe > linux-security-module" in the body of a message to > majordomo at vger.kernel.org More majordomo info at > http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
* The secmark "one user" policy 2017-06-26 7:54 ` José Bollo @ 2017-06-26 15:10 ` Casey Schaufler 2017-06-27 10:51 ` José Bollo 0 siblings, 1 reply; 24+ messages in thread From: Casey Schaufler @ 2017-06-26 15:10 UTC (permalink / raw) To: linux-security-module On 6/26/2017 12:54 AM, Jos? Bollo wrote: > On Sun, 25 Jun 2017 11:05:24 -0700 > Casey Schaufler <casey@schaufler-ca.com> wrote: > >> On 6/25/2017 2:41 AM, James Morris wrote: >>> On Fri, 23 Jun 2017, Casey Schaufler wrote: >>> >>>> On 6/22/2017 8:12 PM, James Morris wrote: >>>>> On Thu, 22 Jun 2017, Casey Schaufler wrote: >>>>> >>>>>> The combination of SELinux, Smack, AppArmor and/or TOMOYO is not >>>>>> the goal so much as the test case. MAC was the coolest possible >>>>>> technology in 1990. We've implemented it. I don't see anyone >>>>>> doing a new MAC implementation. I *do* see security modules that >>>>>> implement other security models in the pipeline. Some of these >>>>>> need to maintain state, which means using security blobs in the >>>>>> LSM architecture. Some of these models will want to use secmarks >>>>>> to implement socket based controls. >>>>> Where are these LSMs and where are the discussions about their >>>>> LSM API needs? >>>> LandLock, CaitSith, LoadPin (now in), Checmate, HardChroot, >>>> PTAGS, SimpleFlow, SafeName, WhiteEgret, shebang, and S.A.R.A. >>>> have all been discussed on the LSM list in the past two years. >>> Which of these need to use secmarks to implement socket controls? >> PTAGS doesn't, but will need to do so to be complete. > Hello Casey, > > The very sleepy PTAGS is suddently awaken (at least one ear :^). > > In my mind, PTAGS is dealing with processes. When packets are filtered, > the only revelent info is the emitter process. At the moment, I don't > see valuable situation where mediation isn't explicit thus faking origin > isn't needed. > > So I would really like to understand your vision here. What do I miss? My thought is that getting the tags of the process on the other end of a network connection seems like a valuable facility. > > Best regards > Jos? > > PS. I reworked the TUI (Task Unic Id) and have something valuable now. > I haven't submitted it because I wanted to include a kind of FS library > to provide /proc like features. But it is a nightmare to find a minute > to work on this challenging part. I should really abandon that and work > on TUI + PTAGS y basta. > >> -- >> To unsubscribe from this list: send the line "unsubscribe >> linux-security-module" in the body of a message to >> majordomo at vger.kernel.org More majordomo info at >> http://vger.kernel.org/majordomo-info.html > -- > To unsubscribe from this list: send the line "unsubscribe linux-security-module" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
* The secmark "one user" policy 2017-06-26 15:10 ` Casey Schaufler @ 2017-06-27 10:51 ` José Bollo 2017-06-27 11:58 ` Paul Moore 0 siblings, 1 reply; 24+ messages in thread From: José Bollo @ 2017-06-27 10:51 UTC (permalink / raw) To: linux-security-module On Mon, 26 Jun 2017 08:10:44 -0700 Casey Schaufler <casey@schaufler-ca.com> wrote: > On 6/26/2017 12:54 AM, Jos? Bollo wrote: > > On Sun, 25 Jun 2017 11:05:24 -0700 > > Casey Schaufler <casey@schaufler-ca.com> wrote: > > > >> On 6/25/2017 2:41 AM, James Morris wrote: > >>> On Fri, 23 Jun 2017, Casey Schaufler wrote: > >>> > >>>> On 6/22/2017 8:12 PM, James Morris wrote: > >>>>> On Thu, 22 Jun 2017, Casey Schaufler wrote: > >>>>> > >>>>>> The combination of SELinux, Smack, AppArmor and/or TOMOYO is > >>>>>> not the goal so much as the test case. MAC was the coolest > >>>>>> possible technology in 1990. We've implemented it. I don't see > >>>>>> anyone doing a new MAC implementation. I *do* see security > >>>>>> modules that implement other security models in the pipeline. > >>>>>> Some of these need to maintain state, which means using > >>>>>> security blobs in the LSM architecture. Some of these models > >>>>>> will want to use secmarks to implement socket based > >>>>>> controls. > >>>>> Where are these LSMs and where are the discussions about their > >>>>> LSM API needs? > >>>> LandLock, CaitSith, LoadPin (now in), Checmate, HardChroot, > >>>> PTAGS, SimpleFlow, SafeName, WhiteEgret, shebang, and S.A.R.A. > >>>> have all been discussed on the LSM list in the past two > >>>> years. > >>> Which of these need to use secmarks to implement socket > >>> controls? > >> PTAGS doesn't, but will need to do so to be complete. > > Hello Casey, > > > > The very sleepy PTAGS is suddently awaken (at least one ear :^). > > > > In my mind, PTAGS is dealing with processes. When packets are > > filtered, the only revelent info is the emitter process. At the > > moment, I don't see valuable situation where mediation isn't > > explicit thus faking origin isn't needed. > > > > So I would really like to understand your vision here. What do I > > miss? > > My thought is that getting the tags of the process on the other > end of a network connection seems like a valuable facility. I can see 3 objections: (1) secmark isn't really interesting for transmitting hierachical strings; (2) maintaining 2 or more remotes in a coherent state implies more than implicit assumptions; (3) never trust the network. Best regards I sign Jos? but is it me or just someone in the middle that wrote it? > > > > > Best regards > > Jos? > > > > PS. I reworked the TUI (Task Unic Id) and have something valuable > > now. I haven't submitted it because I wanted to include a kind of > > FS library to provide /proc like features. But it is a nightmare to > > find a minute to work on this challenging part. I should really > > abandon that and work on TUI + PTAGS y basta. > > > >> -- > >> To unsubscribe from this list: send the line "unsubscribe > >> linux-security-module" in the body of a message to > >> majordomo at vger.kernel.org More majordomo info at > >> http://vger.kernel.org/majordomo-info.html > > -- > > To unsubscribe from this list: send the line "unsubscribe > > linux-security-module" in the body of a message to > > majordomo at vger.kernel.org More majordomo info at > > http://vger.kernel.org/majordomo-info.html > > -- > To unsubscribe from this list: send the line "unsubscribe > linux-security-module" in the body of a message to > majordomo at vger.kernel.org More majordomo info at > http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
* The secmark "one user" policy 2017-06-27 10:51 ` José Bollo @ 2017-06-27 11:58 ` Paul Moore 0 siblings, 0 replies; 24+ messages in thread From: Paul Moore @ 2017-06-27 11:58 UTC (permalink / raw) To: linux-security-module On Tue, Jun 27, 2017 at 6:51 AM, Jos? Bollo <jobol@nonadev.net> wrote: > On Mon, 26 Jun 2017 08:10:44 -0700 > Casey Schaufler <casey@schaufler-ca.com> wrote: > >> On 6/26/2017 12:54 AM, Jos? Bollo wrote: >> > On Sun, 25 Jun 2017 11:05:24 -0700 >> > Casey Schaufler <casey@schaufler-ca.com> wrote: >> > >> >> On 6/25/2017 2:41 AM, James Morris wrote: >> >>> On Fri, 23 Jun 2017, Casey Schaufler wrote: >> >>> >> >>>> On 6/22/2017 8:12 PM, James Morris wrote: >> >>>>> On Thu, 22 Jun 2017, Casey Schaufler wrote: >> >>>>> >> >>>>>> The combination of SELinux, Smack, AppArmor and/or TOMOYO is >> >>>>>> not the goal so much as the test case. MAC was the coolest >> >>>>>> possible technology in 1990. We've implemented it. I don't see >> >>>>>> anyone doing a new MAC implementation. I *do* see security >> >>>>>> modules that implement other security models in the pipeline. >> >>>>>> Some of these need to maintain state, which means using >> >>>>>> security blobs in the LSM architecture. Some of these models >> >>>>>> will want to use secmarks to implement socket based >> >>>>>> controls. >> >>>>> Where are these LSMs and where are the discussions about their >> >>>>> LSM API needs? >> >>>> LandLock, CaitSith, LoadPin (now in), Checmate, HardChroot, >> >>>> PTAGS, SimpleFlow, SafeName, WhiteEgret, shebang, and S.A.R.A. >> >>>> have all been discussed on the LSM list in the past two >> >>>> years. >> >>> Which of these need to use secmarks to implement socket >> >>> controls? >> >> PTAGS doesn't, but will need to do so to be complete. >> > Hello Casey, >> > >> > The very sleepy PTAGS is suddently awaken (at least one ear :^). >> > >> > In my mind, PTAGS is dealing with processes. When packets are >> > filtered, the only revelent info is the emitter process. At the >> > moment, I don't see valuable situation where mediation isn't >> > explicit thus faking origin isn't needed. >> > >> > So I would really like to understand your vision here. What do I >> > miss? >> >> My thought is that getting the tags of the process on the other >> end of a network connection seems like a valuable facility. > > I can see 3 objections: (1) secmark isn't really interesting for > transmitting hierachical strings; (2) maintaining 2 or more remotes in > a coherent state implies more than implicit assumptions; (3) never > trust the network. A point of clarification: the secmark labels are not communicated across the network, they are assigned to packets based on the local netfilter configuration. A simple example with SELinux/secmark: # iptables -t mangle -A INPUT --src 192.168.0.16 \ -p tcp --dport 22 -j SECMARK \ --selctx system_u:object_r:foo_ssh_packet_t:s0 -- paul moore www.paul-moore.com -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
* The secmark "one user" policy 2017-06-22 9:54 ` James Morris 2017-06-22 16:17 ` Casey Schaufler @ 2017-06-22 18:49 ` John Johansen 2017-06-23 3:02 ` James Morris 1 sibling, 1 reply; 24+ messages in thread From: John Johansen @ 2017-06-22 18:49 UTC (permalink / raw) To: linux-security-module On 06/22/2017 02:54 AM, James Morris wrote: > On Wed, 21 Jun 2017, Casey Schaufler wrote: > >> Ideally there would be a separate secmark for each security >> module that wants to use the mechanism. Mechanism would be >> provided* so that user-space can identify which security >> module it is referring to when interacting with the kernel. >> My understanding is that we're unlikely to get an expanded >> secmark, so I have concentrated elsewhere. > > I don't see us getting an expanded secmark, either. > >> >> A "clever" secid mapping takes the secids from all the >> security modules and gently manipulates them until they >> fit into a single u32. This might be an index into a list >> of secid sets, but if you have two modules using secids >> you can give each half of the secmark and accommodate >> many configurations, including Fedora. Again, you need >> mechanism* for user-space. This option would require changes >> to the xt_SECMARK implementation, which goes out of it's >> way to ensure all secmarks come from the same security >> module. One option is to add a SECMARK_MODE_COMPOUND, but >> that isn't any more helpful then removing the restriction. > > This sounds very ugly, and each user may assume it has 32 bits of secmark. > >> As for configuration options, SELinux only uses secmarks >> when user-space introduces them. If netfilter doesn't have >> any security rules that add secmarks, none are used. Smack >> can be configured to set secmarks on all packets, with the >> potential for change by user-space, but can also be set up >> without any use of secmarks. There doesn't need to be any >> significant change to xt_SECMARK if it is important to >> maintain the "one user" model. Requiring that the user-space >> use of netfilter be sane for the multiple security module >> case (e.g. don't use SELinux firewall if Smack has the >> secmark) seems somewhat reasonable. > > Reasonable? I don't think so. > > Trying to stack major LSMs arbitrarily and exposing that to userland is an > architectural mess, which is what these kinds of problems are really > telling us. > The use case I keep seeing is not exposing multiple LSMs to the user space. Its the container where the container wants a different LSM than the system is running. Stacking 2 LSMs in that case and only exposing one to user space isn't so unreasonable. > How can a user be expected to reason about a system which is running > multiple independent MAC security models simultaneously? It's a terrible > idea. > At a generic system MAC level I agree, but not all LSMs that need state are MACs and in the more limited container case it isn't so unreasonable. Arguably virtualization is a better solution for the container that wants a different MAC but then that forces you to choose virtualization from the start and not just use the existing pre built container that you want to pull in and use. -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
* The secmark "one user" policy 2017-06-22 18:49 ` John Johansen @ 2017-06-23 3:02 ` James Morris 2017-06-23 4:32 ` John Johansen 0 siblings, 1 reply; 24+ messages in thread From: James Morris @ 2017-06-23 3:02 UTC (permalink / raw) To: linux-security-module On Thu, 22 Jun 2017, John Johansen wrote: > > Trying to stack major LSMs arbitrarily and exposing that to userland is an > > architectural mess, which is what these kinds of problems are really > > telling us. > > > > The use case I keep seeing is not exposing multiple LSMs to the user > space. Its the container where the container wants a different LSM > than the system is running. > > Stacking 2 LSMs in that case and only exposing one to user space isn't > so unreasonable. In this case, would they both be labeling LSMs which need to label packets? I can imagine having Smack or SELinux as the base LSM and then having AppArmor in the container, but having Smack and SELinux in that combination would still not make sense to me. > > > How can a user be expected to reason about a system which is running > > multiple independent MAC security models simultaneously? It's a terrible > > idea. > > > > At a generic system MAC level I agree, but not all LSMs that need > state are MACs and in the more limited container case it isn't so > unreasonable. Can you provide a concrete example of needing two independent packet labeling LSMs? -- James Morris <jmorris@namei.org> -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
* The secmark "one user" policy 2017-06-23 3:02 ` James Morris @ 2017-06-23 4:32 ` John Johansen 2017-06-29 9:10 ` James Morris 0 siblings, 1 reply; 24+ messages in thread From: John Johansen @ 2017-06-23 4:32 UTC (permalink / raw) To: linux-security-module On 06/22/2017 08:02 PM, James Morris wrote: > On Thu, 22 Jun 2017, John Johansen wrote: > >>> Trying to stack major LSMs arbitrarily and exposing that to userland is an >>> architectural mess, which is what these kinds of problems are really >>> telling us. >>> >> >> The use case I keep seeing is not exposing multiple LSMs to the user >> space. Its the container where the container wants a different LSM >> than the system is running. >> >> Stacking 2 LSMs in that case and only exposing one to user space isn't >> so unreasonable. > > In this case, would they both be labeling LSMs which need to label > packets? > > I can imagine having Smack or SELinux as the base LSM and then having > AppArmor in the container, but having Smack and SELinux in that > combination would still not make sense to me. > I don't see why not. The container could be built expecting smack labeling, selinux applies 1 or just a few labels to the whole container, and accesses within the container are mediated fine grained with smack. If you are talking system containers like LXC/D this makes even more sense, your running selinux on the host and the container is using smack or AppArmor. It does mean you would have to do some namespacing of some sort so that the interface would know which LSM to multiplex to. Tasks in the container write to smack or apparmor, system tasks get selinux. selinux still gets to enforce a system policy even on the container as it does today, and the other LSM applies policy as if the container is the system (at least for system containers). >> >>> How can a user be expected to reason about a system which is running >>> multiple independent MAC security models simultaneously? It's a terrible >>> idea. >>> >> >> At a generic system MAC level I agree, but not all LSMs that need >> state are MACs and in the more limited container case it isn't so >> unreasonable. > > Can you provide a concrete example of needing two independent packet > labeling LSMs? > System containers come to mind, as mentioned above. Take an Ubuntu LXC container and run it on fedora or RHEL. While apparmor isn't doing packet label yet, patches for that should float up to the list soon, and really it doesn't have to be ubuntu/apparmor the container guys want to be a replacement for virtualization, allowing you to run applications from different OSes on the same host. You could take the same basic situation of an LXC container built expecting smack and run it on fedora/RHEL with selinux enforcing for the host. Except it isn't currently supported. Right now LXC is limited as to what it can do with the MAC system in the container. It can currently stack an apparmor host with an apparmor guest each applying their own policy, but I know they would love to be mix and match MAC systems, getting them closer to being a replacement for virtualization. Again it could be argued that going full virtualization is a better solution if you want different MAC systems but people will choose (currently are choosing) to run the container without a MAC instead of going with virtualization. Another use case would be running snappy packages (chosen because it is using apparmor to enforce some things, but same could be done with flatpak if/when it starts using an LSM) on fedora. Currently you have to either boot the system into apparmor (disabling selinux) or disable part of the applications mediation. Again yes apparmor doesn't label packets today but it will soon. A little more speculatively another potential example would be an LSM doing a personal firewalls around individual applications. Its really very similar to the snappy/flatpak sandboxing of apps but maybe someone wants that with out the additional baggage of a bigger LSM. Whether it would ever get in upstream is a separate question. I think we are just starting to scratch the surface of how stacking will be used. Especially with all the different container/sandboxing that is going on, and projects like flatpak and snappy pushing to be system agnostic. -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
* The secmark "one user" policy 2017-06-23 4:32 ` John Johansen @ 2017-06-29 9:10 ` James Morris 2017-06-29 16:46 ` John Johansen 0 siblings, 1 reply; 24+ messages in thread From: James Morris @ 2017-06-29 9:10 UTC (permalink / raw) To: linux-security-module On Thu, 22 Jun 2017, John Johansen wrote: > I don't see why not. The container could be built expecting smack > labeling, selinux applies 1 or just a few labels to the whole > container, and accesses within the container are mediated fine grained > with smack. This would require that all LSM-tagged objects and subjects be namespaced, correct? If there is some way that a mediation happens across the container boundary, things could get confusing (e.g. Smack policy not seeming to allow things which SELinux is in fact denying). Note also that LSM and namespaces are not abstracted in identical ways, so we would need to know what it it means for LSM policy when say networking is namespaced but not mounts. Or how to deal with shared subtrees. Namespacing of LSM is probably the more fundamental issue to be resolved. > A little more speculatively another potential example would be an LSM > doing a personal firewalls around individual applications. Its really > very similar to the snappy/flatpak sandboxing of apps but maybe > someone wants that with out the additional baggage of a bigger LSM. > Whether it would ever get in upstream is a separate question. Landlock shows promise here, and stacking it inside one of the major MAC LSMs seems to make sense. -- James Morris <jmorris@namei.org> -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
* The secmark "one user" policy 2017-06-29 9:10 ` James Morris @ 2017-06-29 16:46 ` John Johansen 0 siblings, 0 replies; 24+ messages in thread From: John Johansen @ 2017-06-29 16:46 UTC (permalink / raw) To: linux-security-module On 06/29/2017 02:10 AM, James Morris wrote: > On Thu, 22 Jun 2017, John Johansen wrote: > >> I don't see why not. The container could be built expecting smack >> labeling, selinux applies 1 or just a few labels to the whole >> container, and accesses within the container are mediated fine grained >> with smack. > > This would require that all LSM-tagged objects and subjects be namespaced, > correct? If there is some way that a mediation happens across the > container boundary, things could get confusing (e.g. Smack policy not > seeming to allow things which SELinux is in fact denying). > > Note also that LSM and namespaces are not abstracted in identical ways, so > we would need to know what it it means for LSM policy when say networking > is namespaced but not mounts. Or how to deal with shared subtrees. > > Namespacing of LSM is probably the more fundamental issue to be resolved. > Yes namespacing of LSMs is an open issue that needs to be solved, and probably would be needed for the selinux, and smack case, or apparmor system + (selinux/smack container) but would not be needed for the (selinux/smack system) + apparmor container case. Stacking should be sufficient today because apparmor internally supports stacking and namespacing of it self. ie. system apparmor + container with a different apparmor policy With Casey's stacking patches today we can do an selinux host with an apparmor container by having selinux do regular enforcement and setting the system apparmor policy to unconfined. The container is then setup to use an apparmor policy namespace. Permissions for the host are determined by selinux and in the container by the intersection of what is granted by the selinux system policy and what is allowed by the apparmor policy in the container. But we run into problems with networking as soon as apparmor's support for secmark lands. > >> A little more speculatively another potential example would be an LSM >> doing a personal firewalls around individual applications. Its really >> very similar to the snappy/flatpak sandboxing of apps but maybe >> someone wants that with out the additional baggage of a bigger LSM. >> Whether it would ever get in upstream is a separate question. > > Landlock shows promise here, and stacking it inside one of the major MAC > LSMs seems to make sense. > agreed Landlock is promising here -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
* The secmark "one user" policy 2017-06-21 15:23 ` Casey Schaufler 2017-06-21 23:07 ` John Johansen 2017-06-22 9:54 ` James Morris @ 2017-06-22 22:24 ` Paul Moore 2017-06-22 23:20 ` Casey Schaufler 2 siblings, 1 reply; 24+ messages in thread From: Paul Moore @ 2017-06-22 22:24 UTC (permalink / raw) To: linux-security-module On Wed, Jun 21, 2017 at 11:23 AM, Casey Schaufler <casey@schaufler-ca.com> wrote: > On 6/21/2017 12:13 AM, James Morris wrote: >> On Tue, 20 Jun 2017, Casey Schaufler wrote: >> >>> I'm looking at the secmark code and am looking in >>> particular at the places where it explicitly says >>> that it is intended for one security module at a >>> time. For extreme stacking I can either enforce this >>> restriction by configuration or remove it by clever >>> uses of secid mappings. Either can be made "transparent" >>> to existing user-space. Paul has expressed distaste for >>> using configuration as a shortcut for dealing with this >>> kind of problem, and I generally agree with him. On the >>> other hand, the code is quite clear that it is designed >>> for one and only one kind of secid at a time. I don't >>> want to put a lot of effort into patches that are >>> unacceptable to the author. We've talked about these problems quite a bit the past few years, although I believe most of those discussions have occurred in hallways and bars, and with a random collection of bored, uninterested, or frightened contributors. Let me try to summarize my thoughts a bit below ... >> How would you see this working, ideally? > > Ideally there would be a separate secmark for each security > module that wants to use the mechanism. Mechanism would be > provided* so that user-space can identify which security > module it is referring to when interacting with the kernel. > My understanding is that we're unlikely to get an expanded > secmark, so I have concentrated elsewhere. I think "unlikely" is putting it kindly when it comes to an expanded secmark. However, expanding the secmark isn't really the solution we need, or want for that matter. The core of the problem is that we don't have a security pointer/blob in the skb, and unfortunately, just like an expanded secmark, it isn't going to happen ... at least not in the traditional sense. > A "clever" secid mapping takes the secids from all the > security modules and gently manipulates them until they > fit into a single u32. This might be an index into a list > of secid sets ... As we've talked about before, I believe the only real general solution to this problem is to use the secmark as an index into some list/array/???/datastore that acts like a traditional LSM security blob. The blob could contain whatever the LSM requires: a secmark, a peer label, and/or whatever else comes up later down the line. While painful, I'm hopeful that we could do this in a way which wouldn't completely tank performance, and I expect that reference counting could be used to help limit memory pressure in most of the current use cases. This would likely require a few more hooks (I think, it has been about a year since I looked into this last), but based on my last go-round with DaveM the additional hooks weren't a major source of concern for him. This approach would also have the advantage of finally allowing us to handle traffic forwarding in a proper manner. It's a big mess at the moment and depending on how your network labeling is configured it may, or may not, work. As software based switches grow in importance for cloud based solutions, having proper LSM per-packet forwarding controls becomes more important (IMHO). > ... but if you have two modules using secids > you can give each half of the secmark and accommodate > many configurations, including Fedora. Again, you need > mechanism* for user-space. This option would require changes > to the xt_SECMARK implementation, which goes out of it's > way to ensure all secmarks come from the same security > module. One option is to add a SECMARK_MODE_COMPOUND, but > that isn't any more helpful then removing the restriction. I don't mean to make light of this as an issue, but I think we have larger problems to deal with first (see above). I think once we solve those we should be able to deal with this in a reasonable manner. > As for configuration options, SELinux only uses secmarks > when user-space introduces them. If netfilter doesn't have > any security rules that add secmarks, none are used. Smack > can be configured to set secmarks on all packets, with the > potential for change by user-space, but can also be set up > without any use of secmarks. There doesn't need to be any > significant change to xt_SECMARK if it is important to > maintain the "one user" model. Requiring that the user-space > use of netfilter be sane for the multiple security module > case (e.g. don't use SELinux firewall if Smack has the > secmark) seems somewhat reasonable. Ugh, no. Please, no. The configuration route is tempting because it is easy, but just think of the users, the poor confused admins. Seriously, think of them, because they are just going to configure the LSMs the way they do now and some of them are going to have a configuration the either 1) doesn't work and they will (rightly) complain or 2) blows up in their face with a kernel panic, a relabeling bug, or something else equally nasty. -- paul moore www.paul-moore.com -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
* The secmark "one user" policy 2017-06-22 22:24 ` Paul Moore @ 2017-06-22 23:20 ` Casey Schaufler 2017-06-23 20:47 ` Paul Moore 0 siblings, 1 reply; 24+ messages in thread From: Casey Schaufler @ 2017-06-22 23:20 UTC (permalink / raw) To: linux-security-module On 6/22/2017 3:24 PM, Paul Moore wrote: > On Wed, Jun 21, 2017 at 11:23 AM, Casey Schaufler > <casey@schaufler-ca.com> wrote: >> On 6/21/2017 12:13 AM, James Morris wrote: >>> On Tue, 20 Jun 2017, Casey Schaufler wrote: >>> >>>> I'm looking at the secmark code and am looking in >>>> particular at the places where it explicitly says >>>> that it is intended for one security module at a >>>> time. For extreme stacking I can either enforce this >>>> restriction by configuration or remove it by clever >>>> uses of secid mappings. Either can be made "transparent" >>>> to existing user-space. Paul has expressed distaste for >>>> using configuration as a shortcut for dealing with this >>>> kind of problem, and I generally agree with him. On the >>>> other hand, the code is quite clear that it is designed >>>> for one and only one kind of secid at a time. I don't >>>> want to put a lot of effort into patches that are >>>> unacceptable to the author. > We've talked about these problems quite a bit the past few years, > although I believe most of those discussions have occurred in hallways > and bars, and with a random collection of bored, uninterested, or > frightened contributors. Let me try to summarize my thoughts a bit > below ... ... Which is the right way to discuss these things, although I have been warned about frightening the contributors. >>> How would you see this working, ideally? >> Ideally there would be a separate secmark for each security >> module that wants to use the mechanism. Mechanism would be >> provided* so that user-space can identify which security >> module it is referring to when interacting with the kernel. >> My understanding is that we're unlikely to get an expanded >> secmark, so I have concentrated elsewhere. > I think "unlikely" is putting it kindly when it comes to an expanded secmark. > > However, expanding the secmark isn't really the solution we need, or > want for that matter. The core of the problem is that we don't have a > security pointer/blob in the skb, and unfortunately, just like an > expanded secmark, it isn't going to happen ... at least not in the > traditional sense. I had been thinking in terms of a blob that contains the various secids provided by the modules, but a blob that contains more/other information has possibilities. Hmm. >> A "clever" secid mapping takes the secids from all the >> security modules and gently manipulates them until they >> fit into a single u32. This might be an index into a list >> of secid sets ... > As we've talked about before, I believe the only real general solution > to this problem is to use the secmark as an index into some > list/array/???/datastore that acts like a traditional LSM security > blob. The blob could contain whatever the LSM requires: a secmark, a > peer label, and/or whatever else comes up later down the line. While > painful, I'm hopeful that we could do this in a way which wouldn't > completely tank performance, and I expect that reference counting > could be used to help limit memory pressure in most of the current use > cases. This would likely require a few more hooks (I think, it has > been about a year since I looked into this last), but based on my last > go-round with DaveM the additional hooks weren't a major source of > concern for him. The specific concern I have here is that the code in xt_SECMARK wants you to declare a specific security module when using secmarks. > This approach would also have the advantage of finally allowing us to > handle traffic forwarding in a proper manner. It's a big mess at the > moment and depending on how your network labeling is configured it > may, or may not, work. As software based switches grow in importance > for cloud based solutions, having proper LSM per-packet forwarding > controls becomes more important (IMHO). I confess to having spent no time on the traffic forwarding implementation. I didn't know there was an issue, but now that I do it will influence my choices. >> ... but if you have two modules using secids >> you can give each half of the secmark and accommodate >> many configurations, including Fedora. Again, you need >> mechanism* for user-space. This option would require changes >> to the xt_SECMARK implementation, which goes out of it's >> way to ensure all secmarks come from the same security >> module. One option is to add a SECMARK_MODE_COMPOUND, but >> that isn't any more helpful then removing the restriction. > I don't mean to make light of this as an issue, but I think we have > larger problems to deal with first (see above). I think once we solve > those we should be able to deal with this in a reasonable manner. Lining up for the eventuality. >> As for configuration options, SELinux only uses secmarks >> when user-space introduces them. If netfilter doesn't have >> any security rules that add secmarks, none are used. Smack >> can be configured to set secmarks on all packets, with the >> potential for change by user-space, but can also be set up >> without any use of secmarks. There doesn't need to be any >> significant change to xt_SECMARK if it is important to >> maintain the "one user" model. Requiring that the user-space >> use of netfilter be sane for the multiple security module >> case (e.g. don't use SELinux firewall if Smack has the >> secmark) seems somewhat reasonable. > Ugh, no. Please, no. The configuration route is tempting because it > is easy, but just think of the users, the poor confused admins. > Seriously, think of them, because they are just going to configure the > LSMs the way they do now and some of them are going to have a > configuration the either 1) doesn't work and they will (rightly) > complain or 2) blows up in their face with a kernel panic, a > relabeling bug, or something else equally nasty. Regardless of what we do there will be configurations that just won't be possible to make work. A Tizen Smack configuration and a DoD SELinux MLS internal network setup would be pretty well guaranteed to result in no packets being delivered in either direction. You've worked on putting distributions together, so you know that at some point there have to be limits on just how general any "solution" can be. -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
* The secmark "one user" policy 2017-06-22 23:20 ` Casey Schaufler @ 2017-06-23 20:47 ` Paul Moore 0 siblings, 0 replies; 24+ messages in thread From: Paul Moore @ 2017-06-23 20:47 UTC (permalink / raw) To: linux-security-module On Thu, Jun 22, 2017 at 7:20 PM, Casey Schaufler <casey@schaufler-ca.com> wrote: > On 6/22/2017 3:24 PM, Paul Moore wrote: >> On Wed, Jun 21, 2017 at 11:23 AM, Casey Schaufler >> <casey@schaufler-ca.com> wrote: >>> On 6/21/2017 12:13 AM, James Morris wrote: >>>> On Tue, 20 Jun 2017, Casey Schaufler wrote: ... >>>> How would you see this working, ideally? >>> Ideally there would be a separate secmark for each security >>> module that wants to use the mechanism. Mechanism would be >>> provided* so that user-space can identify which security >>> module it is referring to when interacting with the kernel. >>> My understanding is that we're unlikely to get an expanded >>> secmark, so I have concentrated elsewhere. >> >> I think "unlikely" is putting it kindly when it comes to an expanded secmark. >> >> However, expanding the secmark isn't really the solution we need, or >> want for that matter. The core of the problem is that we don't have a >> security pointer/blob in the skb, and unfortunately, just like an >> expanded secmark, it isn't going to happen ... at least not in the >> traditional sense. > > I had been thinking in terms of a blob that contains the > various secids provided by the modules, but a blob that contains > more/other information has possibilities. Hmm. You *might* be able to get away with a blob that contains just secids and is entirely managed at the LSM shim layer, but that is a big missed opportunity as it doesn't really fix any of the problems we have now that are caused by a lack of a skb security blob. The jump from a blob of secids to a set of LSM specific blobs is a very small one and solves a lot of problems. The hard bit is the secmark-as-a-blob-index, once you've got that working, it shouldn't matter quite as much what you are indexing. >>> A "clever" secid mapping takes the secids from all the >>> security modules and gently manipulates them until they >>> fit into a single u32. This might be an index into a list >>> of secid sets ... >> >> As we've talked about before, I believe the only real general solution >> to this problem is to use the secmark as an index into some >> list/array/???/datastore that acts like a traditional LSM security >> blob. The blob could contain whatever the LSM requires: a secmark, a >> peer label, and/or whatever else comes up later down the line. While >> painful, I'm hopeful that we could do this in a way which wouldn't >> completely tank performance, and I expect that reference counting >> could be used to help limit memory pressure in most of the current use >> cases. This would likely require a few more hooks (I think, it has >> been about a year since I looked into this last), but based on my last >> go-round with DaveM the additional hooks weren't a major source of >> concern for him. > > The specific concern I have here is that the code in xt_SECMARK wants > you to declare a specific security module when using secmarks. I understand, and perhaps I'm not thinking about it correctly, but I just don't think it is as large a problem as you believe. If it truly is impossible to overcome, we can always create a SECMARK_STACKED target or something. I'm reasonably confident this is not the hard part of this work. >> This approach would also have the advantage of finally allowing us to >> handle traffic forwarding in a proper manner. It's a big mess at the >> moment and depending on how your network labeling is configured it >> may, or may not, work. As software based switches grow in importance >> for cloud based solutions, having proper LSM per-packet forwarding >> controls becomes more important (IMHO). > > I confess to having spent no time on the traffic forwarding > implementation. I didn't know there was an issue, but now that > I do it will influence my choices. Fun exercise: trace a packet through the forwarding path and watch as it is either encapsulated or descapsulated by IPsec, similar problems exist for IP tunnels/conversions (e.g. IPv6 <-> IPv4). In order to solve this we need a security blob tied to the skb, we can't rely on IP headers (CIPSO, CALIPSO) or xfrm state (labeled IPsec). >>> As for configuration options, SELinux only uses secmarks >>> when user-space introduces them. If netfilter doesn't have >>> any security rules that add secmarks, none are used. Smack >>> can be configured to set secmarks on all packets, with the >>> potential for change by user-space, but can also be set up >>> without any use of secmarks. There doesn't need to be any >>> significant change to xt_SECMARK if it is important to >>> maintain the "one user" model. Requiring that the user-space >>> use of netfilter be sane for the multiple security module >>> case (e.g. don't use SELinux firewall if Smack has the >>> secmark) seems somewhat reasonable. >> >> Ugh, no. Please, no. The configuration route is tempting because it >> is easy, but just think of the users, the poor confused admins. >> Seriously, think of them, because they are just going to configure the >> LSMs the way they do now and some of them are going to have a >> configuration the either 1) doesn't work and they will (rightly) >> complain or 2) blows up in their face with a kernel panic, a >> relabeling bug, or something else equally nasty. > > Regardless of what we do there will be configurations > that just won't be possible to make work. A Tizen Smack > configuration and a DoD SELinux MLS internal network > setup would be pretty well guaranteed to result in no > packets being delivered in either direction. You've worked > on putting distributions together, so you know that at > some point there have to be limits on just how general > any "solution" can be. The difference is that in this Smack-SELinux/MLS case it fails due to security policy incompatibilities, not due to limitations in the LSM or the LSM stacking layer. I want to make sure that the LSM stacking layer isn't the source of the problem. NOTE: I'm intentionally avoiding the arguments regarding stacking specific LSMs, e.g. Smack with SELinux, because I fear this brings us back around to the old religious arguments. I would encourage others to do the same. These debates were not constructive in the past, and I don't believe they will be constructive now. -- paul moore www.paul-moore.com -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2017-06-29 16:46 UTC | newest] Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-06-21 0:41 The secmark "one user" policy Casey Schaufler 2017-06-21 7:13 ` James Morris 2017-06-21 15:23 ` Casey Schaufler 2017-06-21 23:07 ` John Johansen 2017-06-21 23:45 ` Casey Schaufler 2017-06-22 0:48 ` John Johansen 2017-06-22 9:54 ` James Morris 2017-06-22 16:17 ` Casey Schaufler 2017-06-23 3:12 ` James Morris 2017-06-23 15:26 ` Casey Schaufler 2017-06-25 9:41 ` James Morris 2017-06-25 18:05 ` Casey Schaufler 2017-06-26 7:54 ` José Bollo 2017-06-26 15:10 ` Casey Schaufler 2017-06-27 10:51 ` José Bollo 2017-06-27 11:58 ` Paul Moore 2017-06-22 18:49 ` John Johansen 2017-06-23 3:02 ` James Morris 2017-06-23 4:32 ` John Johansen 2017-06-29 9:10 ` James Morris 2017-06-29 16:46 ` John Johansen 2017-06-22 22:24 ` Paul Moore 2017-06-22 23:20 ` Casey Schaufler 2017-06-23 20:47 ` Paul Moore
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.