* [LSM Stacking] SELinux policy inside container affects a process on Host @ 2023-07-06 5:12 Leesoo Ahn 2023-07-06 13:43 ` Paul Moore 0 siblings, 1 reply; 24+ messages in thread From: Leesoo Ahn @ 2023-07-06 5:12 UTC (permalink / raw) To: Casey Schaufler, linux-security-module Hello! Here is another weird behavior of lsm stacking.. test env - Ubuntu 23.04 Ubuntu Kernel v6.2 w/ Stacking patch v38 - boot param: lsm=apparmor,selinux - AppArmor (Host) + SELinux (LXD Container Fedora 36) In the test environment mentioned above and applying selinux policy enforcing by running "setenforce 1" within the container, executing the following command on the host will result in "Permission denied" output. root@stack-v6:/home/lsahn# insmod /lib/modules/6.2.0-20-generic/kernel/net/netfilter/nft_ct.ko insmod: ERROR: could not insert module /lib/modules/6.2.0-20-generic/kernel/net/netfilter/nft_ct.ko: Permission denied In dmesg, the following kernel log is displayed, [ +0.000003] audit: type=1400 audit(1688619411.654:1072): avc: denied { module_load } for pid=67703 comm="insmod" path="/usr/lib/modules/6.2.0-20-generic/kernel/net/netfilter/nft_ct.ko" dev="sda2" ino=1444804 scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=system permissive=0 I have the following questions by the results: - Why the policy applied within the container affects the host? and whether it is a bug or not. - If this is a bug, I'm curious about where to start the analysis. It would be helpful if you could provide relevant resources or links. best regards, Leesoo ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LSM Stacking] SELinux policy inside container affects a process on Host 2023-07-06 5:12 [LSM Stacking] SELinux policy inside container affects a process on Host Leesoo Ahn @ 2023-07-06 13:43 ` Paul Moore 2023-07-07 0:35 ` Serge E. Hallyn 2023-07-07 8:28 ` [LSM Stacking] SELinux policy inside container affects a process on Host Leesoo Ahn 0 siblings, 2 replies; 24+ messages in thread From: Paul Moore @ 2023-07-06 13:43 UTC (permalink / raw) To: Leesoo Ahn; +Cc: Casey Schaufler, linux-security-module On Thu, Jul 6, 2023 at 1:20 AM Leesoo Ahn <lsahn@wewakecorp.com> wrote: > > Hello! Here is another weird behavior of lsm stacking.. > > test env > - Ubuntu 23.04 Ubuntu Kernel v6.2 w/ Stacking patch v38 > - boot param: lsm=apparmor,selinux > - AppArmor (Host) + SELinux (LXD Container Fedora 36) > > In the test environment mentioned above and applying selinux policy > enforcing by running "setenforce 1" within the container, executing the > following command on the host will result in "Permission denied" output. SELinux operates independently of containers, or kernel namespacing in general. When you load a SELinux policy it applies to all processes on the system, regardless of where they are in relation to the process which loaded the policy into the kernel. This behavior is independent of the LSM stacking work, you should be able to see the same behavior even in cases where SELinux is the only loaded LSM on the system. -- paul-moore.com ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LSM Stacking] SELinux policy inside container affects a process on Host 2023-07-06 13:43 ` Paul Moore @ 2023-07-07 0:35 ` Serge E. Hallyn 2023-07-07 1:17 ` [LSM Stacking] SELinux policy inside container affects a processon Host Leesoo Ahn 2023-07-07 8:28 ` [LSM Stacking] SELinux policy inside container affects a process on Host Leesoo Ahn 1 sibling, 1 reply; 24+ messages in thread From: Serge E. Hallyn @ 2023-07-07 0:35 UTC (permalink / raw) To: Paul Moore; +Cc: Leesoo Ahn, Casey Schaufler, linux-security-module On Thu, Jul 06, 2023 at 09:43:01AM -0400, Paul Moore wrote: > On Thu, Jul 6, 2023 at 1:20 AM Leesoo Ahn <lsahn@wewakecorp.com> wrote: > > > > Hello! Here is another weird behavior of lsm stacking.. > > > > test env > > - Ubuntu 23.04 Ubuntu Kernel v6.2 w/ Stacking patch v38 > > - boot param: lsm=apparmor,selinux > > - AppArmor (Host) + SELinux (LXD Container Fedora 36) > > > > In the test environment mentioned above and applying selinux policy > > enforcing by running "setenforce 1" within the container, executing the > > following command on the host will result in "Permission denied" output. > > SELinux operates independently of containers, or kernel namespacing in > general. When you load a SELinux policy it applies to all processes > on the system, regardless of where they are in relation to the process > which loaded the policy into the kernel. > > This behavior is independent of the LSM stacking work, you should be > able to see the same behavior even in cases where SELinux is the only The real question might be what kind of container was this? Since it was allowed to setenforce 1, it must not have been in a user namespace? Did you do "lxc config set c1 security.privileged true" ? ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LSM Stacking] SELinux policy inside container affects a processon Host 2023-07-07 0:35 ` Serge E. Hallyn @ 2023-07-07 1:17 ` Leesoo Ahn 0 siblings, 0 replies; 24+ messages in thread From: Leesoo Ahn @ 2023-07-07 1:17 UTC (permalink / raw) To: Serge E. Hallyn, Paul Moore; +Cc: Casey Schaufler, linux-security-module 2023-07-07 오전 9:36에 Serge E. Hallyn 이(가) 쓴 글: > On Thu, Jul 06, 2023 at 09:43:01AM -0400, Paul Moore wrote: > > On Thu, Jul 6, 2023 at 1:20 AM Leesoo Ahn <lsahn@wewakecorp.com> wrote: > > > > > > Hello! Here is another weird behavior of lsm stacking.. > > > > > > test env > > > - Ubuntu 23.04 Ubuntu Kernel v6.2 w/ Stacking patch v38 > > > - boot param: lsm=apparmor,selinux > > > - AppArmor (Host) + SELinux (LXD Container Fedora 36) > > > > > > In the test environment mentioned above and applying selinux policy > > > enforcing by running "setenforce 1" within the container, executing the > > > following command on the host will result in "Permission denied" > output. > > > > SELinux operates independently of containers, or kernel namespacing in > > general. When you load a SELinux policy it applies to all processes > > on the system, regardless of where they are in relation to the process > > which loaded the policy into the kernel. > > > > This behavior is independent of the LSM stacking work, you should be > > able to see the same behavior even in cases where SELinux is the only > > The real question might be what kind of container was this? Since it > was allowed to setenforce 1, it must not have been in a user namespace? > Did you do "lxc config set c1 security.privileged true" ? Yes, I did. For a reason that I wanted to use SELinux policy in Enforcing mode inside container and expected it applied to only container side. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LSM Stacking] SELinux policy inside container affects a process on Host 2023-07-06 13:43 ` Paul Moore 2023-07-07 0:35 ` Serge E. Hallyn @ 2023-07-07 8:28 ` Leesoo Ahn 2023-07-07 14:20 ` Paul Moore 2023-07-07 17:51 ` [LSM Stacking] SELinux policy inside container affects a process on Host Dr. Greg 1 sibling, 2 replies; 24+ messages in thread From: Leesoo Ahn @ 2023-07-07 8:28 UTC (permalink / raw) To: Paul Moore, Casey Schaufler; +Cc: linux-security-module 2023-07-06 오후 10:43에 Paul Moore 이(가) 쓴 글: > On Thu, Jul 6, 2023 at 1:20 AM Leesoo Ahn <lsahn@wewakecorp.com> wrote: > > > > Hello! Here is another weird behavior of lsm stacking.. > > > > test env > > - Ubuntu 23.04 Ubuntu Kernel v6.2 w/ Stacking patch v38 > > - boot param: lsm=apparmor,selinux > > - AppArmor (Host) + SELinux (LXD Container Fedora 36) > > > > In the test environment mentioned above and applying selinux policy > > enforcing by running "setenforce 1" within the container, executing the > > following command on the host will result in "Permission denied" output. > > SELinux operates independently of containers, or kernel namespacing in > general. When you load a SELinux policy it applies to all processes > on the system, regardless of where they are in relation to the process > which loaded the policy into the kernel. > > This behavior is independent of the LSM stacking work, you should be > able to see the same behavior even in cases where SELinux is the only > loaded LSM on the system. Thank you for the reply! So as far as I understand, the environment of LSM Stacking, AppArmor (Host) + SELinux (Container) couldn't provide features "using SELinux policy inside the container shouldn't affect to the host side" for now. If so, I wonder if you and Casey plan to design future features like that, because my co-workers and I are considering taking LSM stacking of AppArmor + SELinux in products that both policies must be working separately. best regards, Leesoo ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LSM Stacking] SELinux policy inside container affects a process on Host 2023-07-07 8:28 ` [LSM Stacking] SELinux policy inside container affects a process on Host Leesoo Ahn @ 2023-07-07 14:20 ` Paul Moore 2023-07-07 16:50 ` Casey Schaufler ` (2 more replies) 2023-07-07 17:51 ` [LSM Stacking] SELinux policy inside container affects a process on Host Dr. Greg 1 sibling, 3 replies; 24+ messages in thread From: Paul Moore @ 2023-07-07 14:20 UTC (permalink / raw) To: Leesoo Ahn; +Cc: Casey Schaufler, linux-security-module On Fri, Jul 7, 2023 at 4:29 AM Leesoo Ahn <lsahn@wewakecorp.com> wrote: > 2023-07-06 오후 10:43에 Paul Moore 이(가) 쓴 글: > > On Thu, Jul 6, 2023 at 1:20 AM Leesoo Ahn <lsahn@wewakecorp.com> wrote: > > > > > > Hello! Here is another weird behavior of lsm stacking.. > > > > > > test env > > > - Ubuntu 23.04 Ubuntu Kernel v6.2 w/ Stacking patch v38 > > > - boot param: lsm=apparmor,selinux > > > - AppArmor (Host) + SELinux (LXD Container Fedora 36) > > > > > > In the test environment mentioned above and applying selinux policy > > > enforcing by running "setenforce 1" within the container, executing the > > > following command on the host will result in "Permission denied" output. > > > > SELinux operates independently of containers, or kernel namespacing in > > general. When you load a SELinux policy it applies to all processes > > on the system, regardless of where they are in relation to the process > > which loaded the policy into the kernel. > > > > This behavior is independent of the LSM stacking work, you should be > > able to see the same behavior even in cases where SELinux is the only > > loaded LSM on the system. > > Thank you for the reply! > > So as far as I understand, the environment of LSM Stacking, > AppArmor (Host) + SELinux (Container) couldn't provide features "using > SELinux policy inside the container shouldn't affect to the host side" > for now. > > If so, I wonder if you and Casey plan to design future features like > that, because my co-workers and I are considering taking LSM stacking of > AppArmor + SELinux in products that both policies must be working > separately. What you are looking for is a combination of LSM stacking and individual LSM namespacing. Sadly, I think the communications around LSM stacking have not been very clear on this and I worry that many people are going to be disappointed with LSM stacking for this very reason. While stacking of LSMs is largely done at the LSM layer, namespacing LSMs such that they can be customized for individual containers requires work to be done at the per-LSM level as each LSM is different. AppArmor already has a namespacing concept, but SELinux does not. Due to differences in the approach taken by the two LSMs, namespacing is much more of a challenge for SELinux, largely due to issues around filesystem labeling. We have not given up on the idea, but we have yet to arrive at a viable solution for namespacing SELinux. If you are interested in stacking SELinux and AppArmor, I believe the only practical solution is to run SELinux on the host system (initial namespace) and run AppArmor in the containers. Even in a world where SELinux is fully namespaced, it would likely still be necessary to run some type of SELinux policy on the host (initial namespace) in order to support SELinux policies in the containers. -- paul-moore.com ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LSM Stacking] SELinux policy inside container affects a process on Host 2023-07-07 14:20 ` Paul Moore @ 2023-07-07 16:50 ` Casey Schaufler 2023-07-07 21:41 ` Paul Moore 2023-07-18 10:34 ` Dr. Greg 2023-07-17 15:24 ` [LSM Stacking] SELinux policy inside container affects a processon Host Leesoo Ahn 2023-07-28 1:54 ` [LSM Stacking] SELinux policy inside container affects a processon Host Leesoo Ahn 2 siblings, 2 replies; 24+ messages in thread From: Casey Schaufler @ 2023-07-07 16:50 UTC (permalink / raw) To: Paul Moore, Leesoo Ahn; +Cc: linux-security-module, Casey Schaufler On 7/7/2023 7:20 AM, Paul Moore wrote: > On Fri, Jul 7, 2023 at 4:29 AM Leesoo Ahn <lsahn@wewakecorp.com> wrote: >> 2023-07-06 오후 10:43에 Paul Moore 이(가) 쓴 글: >>> On Thu, Jul 6, 2023 at 1:20 AM Leesoo Ahn <lsahn@wewakecorp.com> wrote: >>> > >>> > Hello! Here is another weird behavior of lsm stacking.. >>> > >>> > test env >>> > - Ubuntu 23.04 Ubuntu Kernel v6.2 w/ Stacking patch v38 >>> > - boot param: lsm=apparmor,selinux >>> > - AppArmor (Host) + SELinux (LXD Container Fedora 36) >>> > >>> > In the test environment mentioned above and applying selinux policy >>> > enforcing by running "setenforce 1" within the container, executing the >>> > following command on the host will result in "Permission denied" output. >>> >>> SELinux operates independently of containers, or kernel namespacing in >>> general. When you load a SELinux policy it applies to all processes >>> on the system, regardless of where they are in relation to the process >>> which loaded the policy into the kernel. >>> >>> This behavior is independent of the LSM stacking work, you should be >>> able to see the same behavior even in cases where SELinux is the only >>> loaded LSM on the system. >> Thank you for the reply! >> >> So as far as I understand, the environment of LSM Stacking, >> AppArmor (Host) + SELinux (Container) couldn't provide features "using >> SELinux policy inside the container shouldn't affect to the host side" >> for now. >> >> If so, I wonder if you and Casey plan to design future features like >> that, because my co-workers and I are considering taking LSM stacking of >> AppArmor + SELinux in products that both policies must be working >> separately. > What you are looking for is a combination of LSM stacking and > individual LSM namespacing. Sadly, I think the communications around > LSM stacking have not been very clear on this and I worry that many > people are going to be disappointed with LSM stacking for this very > reason. There have been many discussions regarding the viability of the using different LSM policies in containers. Some of these discussions have been quite lively. I have never claimed that LSM stacking addresses all of the possible use cases for multiple concurrent LSMs. If people are disappointed by how little they can accomplish with what is currently being proposed I can only say that we can't get on to the next phase until this work is complete. > > While stacking of LSMs is largely done at the LSM layer, namespacing > LSMs such that they can be customized for individual containers > requires work to be done at the per-LSM level as each LSM is > different. AppArmor already has a namespacing concept, but SELinux > does not. Due to differences in the approach taken by the two LSMs, > namespacing is much more of a challenge for SELinux, largely due to > issues around filesystem labeling. We have not given up on the idea, > but we have yet to arrive at a viable solution for namespacing > SELinux. I remain more optimistic than Paul about the options for supporting generic LSM namespacing. I hope to explore a couple notions that I have more fully, but as they depend on the current stacking work I may not get to them very soon. > > If you are interested in stacking SELinux and AppArmor, I believe the > only practical solution is to run SELinux on the host system (initial > namespace) and run AppArmor in the containers. Even in a world where > SELinux is fully namespaced, it would likely still be necessary to run > some type of SELinux policy on the host (initial namespace) in order > to support SELinux policies in the containers. SELinux policy is sufficiently flexible to support what would look like different policies on the host system and in the container. I think that the administration of such a system would be tricky, and the policy would be very complex, but it could be done, for some use cases at least. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LSM Stacking] SELinux policy inside container affects a process on Host 2023-07-07 16:50 ` Casey Schaufler @ 2023-07-07 21:41 ` Paul Moore 2023-07-18 10:34 ` Dr. Greg 1 sibling, 0 replies; 24+ messages in thread From: Paul Moore @ 2023-07-07 21:41 UTC (permalink / raw) To: Casey Schaufler; +Cc: Leesoo Ahn, linux-security-module On Fri, Jul 7, 2023 at 12:50 PM Casey Schaufler <casey@schaufler-ca.com> wrote: > On 7/7/2023 7:20 AM, Paul Moore wrote: ... > > What you are looking for is a combination of LSM stacking and > > individual LSM namespacing. Sadly, I think the communications around > > LSM stacking have not been very clear on this and I worry that many > > people are going to be disappointed with LSM stacking for this very > > reason. > > There have been many discussions regarding the viability of the using > different LSM policies in containers. Some of these discussions have > been quite lively. I have never claimed that LSM stacking addresses > all of the possible use cases for multiple concurrent LSMs. If people > are disappointed by how little they can accomplish with what is currently > being proposed I can only say that we can't get on to the next phase > until this work is complete. The issue of namespacing LSMs is independent of stacking. > > While stacking of LSMs is largely done at the LSM layer, namespacing > > LSMs such that they can be customized for individual containers > > requires work to be done at the per-LSM level as each LSM is > > different. AppArmor already has a namespacing concept, but SELinux > > does not. Due to differences in the approach taken by the two LSMs, > > namespacing is much more of a challenge for SELinux, largely due to > > issues around filesystem labeling. We have not given up on the idea, > > but we have yet to arrive at a viable solution for namespacing > > SELinux. > > I remain more optimistic than Paul about the options for supporting > generic LSM namespacing. I hope to explore a couple notions that I > have more fully, but as they depend on the current stacking work I > may not get to them very soon. I remain unconvinced that namespacing should be done at the LSM layer; my opinion is that namespacing should be handled individually by the LSMs. Just as there is no single security model across LSMs, I don't believe there should be a single approach to namespacing. > > If you are interested in stacking SELinux and AppArmor, I believe the > > only practical solution is to run SELinux on the host system (initial > > namespace) and run AppArmor in the containers. Even in a world where > > SELinux is fully namespaced, it would likely still be necessary to run > > some type of SELinux policy on the host (initial namespace) in order > > to support SELinux policies in the containers. > > SELinux policy is sufficiently flexible to support what would look like > different policies on the host system and in the container. I think that > the administration of such a system would be tricky, and the policy would > be very complex, but it could be done, for some use cases at least. The concept of loading a separate SELinux policy into a container, and having that policy apply only to that container, is not currently possible. Of course there are ways to introduce additional security domains within the container with SELinux, but that requires cooperation between the container and the host. There are also several different approaches available today for isolating containers with SELinux, which tends to fit very well with most container workloads, but I get the impression that is not what Leesoo is interested in at the moment. -- paul-moore.com ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LSM Stacking] SELinux policy inside container affects a process on Host 2023-07-07 16:50 ` Casey Schaufler 2023-07-07 21:41 ` Paul Moore @ 2023-07-18 10:34 ` Dr. Greg 2023-07-18 17:20 ` Casey Schaufler 1 sibling, 1 reply; 24+ messages in thread From: Dr. Greg @ 2023-07-18 10:34 UTC (permalink / raw) To: Casey Schaufler; +Cc: Paul Moore, Leesoo Ahn, linux-security-module On Fri, Jul 07, 2023 at 09:50:41AM -0700, Casey Schaufler wrote: Hi, I hope the week is going well for everyone. > On 7/7/2023 7:20 AM, Paul Moore wrote: > > On Fri, Jul 7, 2023 at 4:29???AM Leesoo Ahn <lsahn@wewakecorp.com> wrote: > >> 2023-07-06 ?????? 10:43??? Paul Moore ???(???) ??? ???: > >>> On Thu, Jul 6, 2023 at 1:20???AM Leesoo Ahn <lsahn@wewakecorp.com> wrote: > >>> > > >>> > Hello! Here is another weird behavior of lsm stacking.. > >>> > > >>> > test env > >>> > - Ubuntu 23.04 Ubuntu Kernel v6.2 w/ Stacking patch v38 > >>> > - boot param: lsm=apparmor,selinux > >>> > - AppArmor (Host) + SELinux (LXD Container Fedora 36) > >>> > > >>> > In the test environment mentioned above and applying selinux policy > >>> > enforcing by running "setenforce 1" within the container, executing the > >>> > following command on the host will result in "Permission denied" output. > >>> > >>> SELinux operates independently of containers, or kernel namespacing in > >>> general. When you load a SELinux policy it applies to all processes > >>> on the system, regardless of where they are in relation to the process > >>> which loaded the policy into the kernel. > >>> > >>> This behavior is independent of the LSM stacking work, you should be > >>> able to see the same behavior even in cases where SELinux is the only > >>> loaded LSM on the system. > >> Thank you for the reply! > >> > >> So as far as I understand, the environment of LSM Stacking, > >> AppArmor (Host) + SELinux (Container) couldn't provide features "using > >> SELinux policy inside the container shouldn't affect to the host side" > >> for now. > >> > >> If so, I wonder if you and Casey plan to design future features like > >> that, because my co-workers and I are considering taking LSM stacking of > >> AppArmor + SELinux in products that both policies must be working > >> separately. > > What you are looking for is a combination of LSM stacking and > > individual LSM namespacing. Sadly, I think the communications > > around LSM stacking have not been very clear on this and I worry > > that many people are going to be disappointed with LSM stacking > > for this very reason. > There have been many discussions regarding the viability of the > using different LSM policies in containers. Some of these > discussions have been quite lively. I have never claimed that LSM > stacking addresses all of the possible use cases for multiple > concurrent LSMs. If people are disappointed by how little they can > accomplish with what is currently being proposed I can only say that > we can't get on to the next phase until this work is complete. It seems pretty clear, to us anyway, that generic user expectations are that advanced security controls for Linux, ie beyond DAC, should provide the same compartmentalization and isolation that other resource namespaces bring to the table. The 10 years of experience we have had with building systems, and feedback we have received from collaborators with significant experience in critical infrastructure, drove the focus in TSEM on strictly partitioned and workload based security controls. We obviously had an advantage in that we came into this with the opportunity for a clean design, whereas the existing, particularly label based solutions, have the constraint of a single ground truth with respect to the inode label implemented in the extended attributes. Which is the fault of nobody, but rather a function of the fact that label based systems have a heritage from before anyone even thought about resource namespaces. Do to our objectives, and the approach we took, TSEM doesn't require support for 'stacking' with other LSM's, obviously other LSM's do need that support, not a criticism but an observation. That opened the door to implement what users would consider to be an independent security namespace. The take away, that I assume everyone interested in Linux security would be in agreement on, perhaps not, is that user expectations are to have independent and separately administered security control environments that don't interact with one another. > > While stacking of LSMs is largely done at the LSM layer, namespacing > > LSMs such that they can be customized for individual containers > > requires work to be done at the per-LSM level as each LSM is > > different. AppArmor already has a namespacing concept, but SELinux > > does not. Due to differences in the approach taken by the two LSMs, > > namespacing is much more of a challenge for SELinux, largely due to > > issues around filesystem labeling. We have not given up on the idea, > > but we have yet to arrive at a viable solution for namespacing > > SELinux. > I remain more optimistic than Paul about the options for supporting > generic LSM namespacing. I hope to explore a couple notions that I > have more fully, but as they depend on the current stacking work I > may not get to them very soon. I believe TSEM demonstrates that we already have the infrastructure at the LSM layer for generic namespacing. Of all the current LSM's, I believe we have the most sophisticated namespace implementation with respect to the functionality that it implements. We have implemented TSEM using both the standard Linux namespace infrastructure and as an independent namespace implementation using the LSM 'blob' infrastructure. FWIW, we have never looked back on the decision to implement LSM specific namespacing using the generic LSM 'blob' functionality. If there is a desire to provide some minimum level of generic security namespace functionality I could recitate a whole list of thoughts to consider but will leave that to another time. > > If you are interested in stacking SELinux and AppArmor, I believe the > > only practical solution is to run SELinux on the host system (initial > > namespace) and run AppArmor in the containers. Even in a world where > > SELinux is fully namespaced, it would likely still be necessary to run > > some type of SELinux policy on the host (initial namespace) in order > > to support SELinux policies in the containers. > SELinux policy is sufficiently flexible to support what would look > like different policies on the host system and in the container. I > think that the administration of such a system would be tricky, and > the policy would be very complex, but it could be done, for some use > cases at least. These reflections illuminate our motivation in developing TSEM, others may disagree, but a lot of experience in, and observation of, the security industry has led us to believe that security has to get simpler and easier to implement rather than more complex and arcane. We are probably at an interesting juncture in Linux development. The security controls we make available as a platform can either pursue a path where only highly skilled administrators and technology companies can implement them, or, we can provide mechanisms that work to increase the accessibility by development teams and ultimately the user community to advanced security controls. With TSEM, our design philosophy is that security controls need to flow from the development process in order to accomplish this latter objective. CI/CD is now considered a necessary and standard practice in the software industry, it doesn't seem like a stretch of the imagination that security controls should flow from that process as well. One of the requirements of this model is the ability to strictly scope security controls to the level of a workload nee security modeling namespace. Regardless of motivation, it would seem from this thread alone, that there is a user expectation, if not a necessary technical requirement, for Linux to provide infrastructure that enables strictly partitioned and independent security controls that don't require extensive reasoning as to what they might actually do in practice. Have a good week. As always, Dr. Greg The Quixote Project - Flailing at the Travails of Cybersecurity ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LSM Stacking] SELinux policy inside container affects a process on Host 2023-07-18 10:34 ` Dr. Greg @ 2023-07-18 17:20 ` Casey Schaufler 2023-07-19 18:45 ` Dr. Greg 0 siblings, 1 reply; 24+ messages in thread From: Casey Schaufler @ 2023-07-18 17:20 UTC (permalink / raw) To: Dr. Greg; +Cc: Paul Moore, Leesoo Ahn, linux-security-module, Casey Schaufler On 7/18/2023 3:34 AM, Dr. Greg wrote: > On Fri, Jul 07, 2023 at 09:50:41AM -0700, Casey Schaufler wrote: > > Hi, I hope the week is going well for everyone. > >> On 7/7/2023 7:20 AM, Paul Moore wrote: >>> On Fri, Jul 7, 2023 at 4:29???AM Leesoo Ahn <lsahn@wewakecorp.com> wrote: >>>> 2023-07-06 ?????? 10:43??? Paul Moore ???(???) ??? ???: >>>>> On Thu, Jul 6, 2023 at 1:20???AM Leesoo Ahn <lsahn@wewakecorp.com> wrote: >>>>> > >>>>> > Hello! Here is another weird behavior of lsm stacking.. >>>>> > >>>>> > test env >>>>> > - Ubuntu 23.04 Ubuntu Kernel v6.2 w/ Stacking patch v38 >>>>> > - boot param: lsm=apparmor,selinux >>>>> > - AppArmor (Host) + SELinux (LXD Container Fedora 36) >>>>> > >>>>> > In the test environment mentioned above and applying selinux policy >>>>> > enforcing by running "setenforce 1" within the container, executing the >>>>> > following command on the host will result in "Permission denied" output. >>>>> >>>>> SELinux operates independently of containers, or kernel namespacing in >>>>> general. When you load a SELinux policy it applies to all processes >>>>> on the system, regardless of where they are in relation to the process >>>>> which loaded the policy into the kernel. >>>>> >>>>> This behavior is independent of the LSM stacking work, you should be >>>>> able to see the same behavior even in cases where SELinux is the only >>>>> loaded LSM on the system. >>>> Thank you for the reply! >>>> >>>> So as far as I understand, the environment of LSM Stacking, >>>> AppArmor (Host) + SELinux (Container) couldn't provide features "using >>>> SELinux policy inside the container shouldn't affect to the host side" >>>> for now. >>>> >>>> If so, I wonder if you and Casey plan to design future features like >>>> that, because my co-workers and I are considering taking LSM stacking of >>>> AppArmor + SELinux in products that both policies must be working >>>> separately. >>> What you are looking for is a combination of LSM stacking and >>> individual LSM namespacing. Sadly, I think the communications >>> around LSM stacking have not been very clear on this and I worry >>> that many people are going to be disappointed with LSM stacking >>> for this very reason. >> There have been many discussions regarding the viability of the >> using different LSM policies in containers. Some of these >> discussions have been quite lively. I have never claimed that LSM >> stacking addresses all of the possible use cases for multiple >> concurrent LSMs. If people are disappointed by how little they can >> accomplish with what is currently being proposed I can only say that >> we can't get on to the next phase until this work is complete. > It seems pretty clear, to us anyway, that generic user expectations > are that advanced security controls for Linux, ie beyond DAC, should > provide the same compartmentalization and isolation that other > resource namespaces bring to the table. It would have been really nice if the developers of resource namespaces had addressed the "LSM question" when they created their schemes. But they didn't. Namespaces are not primarily security constructs. You need go no further than the group access problem of user namespaces to understand where security ranks on the priority of namespaces. > The 10 years of experience we > have had with building systems, and feedback we have received from > collaborators with significant experience in critical infrastructure, > drove the focus in TSEM on strictly partitioned and workload based > security controls. The 45 years of experience we have had with building systems at every level from network appliances, through user interface engines and multi-level secure supercomputers convince us that workload based controls can never provide anything beyond grandiose security theater. We have often claimed that isolation (partitioning, if you prefer) is easy, sharing is hard. Building a system security policy based on alleged "safe" existing behavior is at best naive. > > We obviously had an advantage in that we came into this with the > opportunity for a clean design, whereas the existing, particularly > label based solutions, have the constraint of a single ground truth > with respect to the inode label implemented in the extended > attributes. Which is the fault of nobody, but rather a function of > the fact that label based systems have a heritage from before anyone > even thought about resource namespaces. Resource namespaces are expensive and require extensive administration to be useful. As one of the early developers of the inode label based solutions you disparage so flippantly, I take umbrage with your characterization of the design process. Of course we thought of features which closely resemble user namespaces. They're great for isolation. They're not so great for implementing fixed security policy, which was the requirement and goal. > > Do to our objectives, and the approach we took, TSEM doesn't require > support for 'stacking' with other LSM's, obviously other LSM's do need > that support, not a criticism but an observation. That opened the > door to implement what users would consider to be an independent > security namespace. > > The take away, that I assume everyone interested in Linux security > would be in agreement on, perhaps not, is that user expectations are > to have independent and separately administered security control > environments that don't interact with one another. So long as the "environments" are completely isolated this makes perfect sense. What so many "users", and more importantly, software snake oil salesmen, seem incapable of coming to grips with, is that for an "environment" to be useful it is going to do some amount of resource sharing with the host and frequently with other "environments". That is where the lofty claims of isolation fall apart, and the real, painful work for security developers, begins. >>> While stacking of LSMs is largely done at the LSM layer, namespacing >>> LSMs such that they can be customized for individual containers >>> requires work to be done at the per-LSM level as each LSM is >>> different. AppArmor already has a namespacing concept, but SELinux >>> does not. Due to differences in the approach taken by the two LSMs, >>> namespacing is much more of a challenge for SELinux, largely due to >>> issues around filesystem labeling. We have not given up on the idea, >>> but we have yet to arrive at a viable solution for namespacing >>> SELinux. >> I remain more optimistic than Paul about the options for supporting >> generic LSM namespacing. I hope to explore a couple notions that I >> have more fully, but as they depend on the current stacking work I >> may not get to them very soon. > I believe TSEM demonstrates that we already have the infrastructure at > the LSM layer for generic namespacing. Of all the current LSM's, I > believe we have the most sophisticated namespace implementation with > respect to the functionality that it implements. > > We have implemented TSEM using both the standard Linux namespace > infrastructure and as an independent namespace implementation using > the LSM 'blob' infrastructure. FWIW, we have never looked back on the > decision to implement LSM specific namespacing using the generic LSM > 'blob' functionality. > > If there is a desire to provide some minimum level of generic security > namespace functionality I could recitate a whole list of thoughts to > consider but will leave that to another time. I have discovered a truly marvelous patch for this, which this email is too brief to contain. All kidding aside, there are a bunch of things we could do, but they all introduce issues with object sharing. > >>> If you are interested in stacking SELinux and AppArmor, I believe the >>> only practical solution is to run SELinux on the host system (initial >>> namespace) and run AppArmor in the containers. Even in a world where >>> SELinux is fully namespaced, it would likely still be necessary to run >>> some type of SELinux policy on the host (initial namespace) in order >>> to support SELinux policies in the containers. >> SELinux policy is sufficiently flexible to support what would look >> like different policies on the host system and in the container. I >> think that the administration of such a system would be tricky, and >> the policy would be very complex, but it could be done, for some use >> cases at least. > These reflections illuminate our motivation in developing TSEM, others > may disagree, but a lot of experience in, and observation of, the > security industry has led us to believe that security has to get > simpler and easier to implement rather than more complex and arcane. Evidence would indicate this is an errant conclusion. > We are probably at an interesting juncture in Linux development. The > security controls we make available as a platform can either pursue a > path where only highly skilled administrators and technology companies > can implement them, or, we can provide mechanisms that work to increase > the accessibility by development teams and ultimately the user > community to advanced security controls. Ever hear of the "Hillbilly Hummer"? No, you don't leave security policy development to end users. > > With TSEM, our design philosophy is that security controls need to > flow from the development process in order to accomplish this latter > objective. CI/CD is now considered a necessary and standard practice > in the software industry, it doesn't seem like a stretch of the > imagination that security controls should flow from that process as > well. > > One of the requirements of this model is the ability to strictly scope > security controls to the level of a workload nee security modeling > namespace. > > Regardless of motivation, it would seem from this thread alone, that > there is a user expectation, if not a necessary technical requirement, > for Linux to provide infrastructure that enables strictly partitioned > and independent security controls that don't require extensive > reasoning as to what they might actually do in practice. You really have missed the point. By a long way. The problem of security is not now, nor has it ever been, isolation. It is sharing. If it is appropriate for "users" to determine sharing, we have mode bits. If it is appropriate for "administrators" to determine sharing, we have mandatory access controls and namespaces. If sharing is completely inappropriate, we have virtualization. > > Have a good week. > > As always, > Dr. Greg > > The Quixote Project - Flailing at the Travails of Cybersecurity ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LSM Stacking] SELinux policy inside container affects a process on Host 2023-07-18 17:20 ` Casey Schaufler @ 2023-07-19 18:45 ` Dr. Greg 2023-07-20 0:21 ` Casey Schaufler 0 siblings, 1 reply; 24+ messages in thread From: Dr. Greg @ 2023-07-19 18:45 UTC (permalink / raw) To: Casey Schaufler; +Cc: Paul Moore, Leesoo Ahn, linux-security-module On Tue, Jul 18, 2023 at 10:20:40AM -0700, Casey Schaufler wrote: Good afternoon to everyone. > On 7/18/2023 3:34 AM, Dr. Greg wrote: > > On Fri, Jul 07, 2023 at 09:50:41AM -0700, Casey Schaufler wrote: > > > > Hi, I hope the week is going well for everyone. > > > >> On 7/7/2023 7:20 AM, Paul Moore wrote: > >>> On Fri, Jul 7, 2023 at 4:29???AM Leesoo Ahn <lsahn@wewakecorp.com> wrote: > >>>> 2023-07-06 ?????? 10:43??? Paul Moore ???(???) ??? ???: > >>>>> On Thu, Jul 6, 2023 at 1:20???AM Leesoo Ahn <lsahn@wewakecorp.com> wrote: > >>>>> > > >>>>> > Hello! Here is another weird behavior of lsm stacking.. > >>>>> > > >>>>> > test env > >>>>> > - Ubuntu 23.04 Ubuntu Kernel v6.2 w/ Stacking patch v38 > >>>>> > - boot param: lsm=apparmor,selinux > >>>>> > - AppArmor (Host) + SELinux (LXD Container Fedora 36) > >>>>> > > >>>>> > In the test environment mentioned above and applying selinux policy > >>>>> > enforcing by running "setenforce 1" within the container, executing the > >>>>> > following command on the host will result in "Permission denied" output. > >>>>> > >>>>> SELinux operates independently of containers, or kernel namespacing in > >>>>> general. When you load a SELinux policy it applies to all processes > >>>>> on the system, regardless of where they are in relation to the process > >>>>> which loaded the policy into the kernel. > >>>>> > >>>>> This behavior is independent of the LSM stacking work, you should be > >>>>> able to see the same behavior even in cases where SELinux is the only > >>>>> loaded LSM on the system. > >>>> Thank you for the reply! > >>>> > >>>> So as far as I understand, the environment of LSM Stacking, > >>>> AppArmor (Host) + SELinux (Container) couldn't provide features "using > >>>> SELinux policy inside the container shouldn't affect to the host side" > >>>> for now. > >>>> > >>>> If so, I wonder if you and Casey plan to design future features like > >>>> that, because my co-workers and I are considering taking LSM stacking of > >>>> AppArmor + SELinux in products that both policies must be working > >>>> separately. > >>> What you are looking for is a combination of LSM stacking and > >>> individual LSM namespacing. Sadly, I think the communications > >>> around LSM stacking have not been very clear on this and I worry > >>> that many people are going to be disappointed with LSM stacking > >>> for this very reason. > >> There have been many discussions regarding the viability of the > >> using different LSM policies in containers. Some of these > >> discussions have been quite lively. I have never claimed that LSM > >> stacking addresses all of the possible use cases for multiple > >> concurrent LSMs. If people are disappointed by how little they can > >> accomplish with what is currently being proposed I can only say that > >> we can't get on to the next phase until this work is complete. > > It seems pretty clear, to us anyway, that generic user expectations > > are that advanced security controls for Linux, ie beyond DAC, should > > provide the same compartmentalization and isolation that other > > resource namespaces bring to the table. > It would have been really nice if the developers of resource > namespaces had addressed the "LSM question" when they created their > schemes. But they didn't. Namespaces are not primarily security > constructs. You need go no further than the group access problem of > user namespaces to understand where security ranks on the priority > of namespaces. It may very well be the case that namespaces are the worst abomination that has ever been foisted on mankind with respect to security. Unfortunately, that doesn't negate the fact that the software industry has spoken and the notion of a 'container' or 'resource namespace', whatever parlance one chooses to use, is now deeply ingrained in how software is being developed and delivered and this will probably be the case for the foreseeable future. This thread was initiated by the fact that their is an expectation, that will only grow in the future, that security controls can be scoped to a subdivision less than that of an entire system and in a manner that doesn't cause one security policy to interfere with or complicate the implementation of another. If current industry experience is any example, the one causing the most problems will get turned off. Or administrators will be left trying to reason as to what security controls are actually being achieved, which is always hazardous. With respect to our work, if you believe that we are looking at a namespace as an isolation concept you have misunderstand our motivations, objectives and implementation. The LSM infrastructure represents the basis set of information that can be used to model the security behavior of a platform. If it does not, it cannot adequately enforce effective security controls, since by definition, it would have insufficient visibility into all security relevant behavior. There are at least three ways this information can be used: The LSM can be used to enforce a system wide security policy through mandatory access controls, your area of interest and endeavor. An equally valid concept is for developers to use this information to verify that the security behavior of workloads that they develop are consistent with what they desire. A third possible use case of the LSM, since it represents access to all of the information that describes the security state of a platform, is to drive machine learning based analysis and interpretation of the security status of a system. The latter two use cases benefit from the ability to reduce the scope and complexity of the model being analyzed, which is the intent of the TSEM security modeling namespaces. I'm just hazarding a guess here, no judgement implied, but I would assume you view phenomenological modeling, machine learning and artificial intelligence as irrelevant endeavors with respect to security? We have direct and constant dialogue with a group that has around 6000 virtual machines running 30,000+ containers at any given instant in time. Every VM is running, I believe, three CrowdStrike kernel modules and other supportive infrastructure that are feeding 'machine learning' telemetry into the cloud for security analysis. I also believe there are Kubernetes sidecars analysing container behavior in the mix as well. None of which is optional, given that the conversations surrounding the technology consists of; "Run this because our insurance says we have to". The beauty in Linux is that you can ignore all of this and run SeLinux, but to say that resoure namespaces, compartmentalization and modeling are irrelevant, flies in the face of how security is being done. > > The 10 years of experience we have had with building systems, and > > feedback we have received from collaborators with significant > > experience in critical infrastructure, drove the focus in TSEM on > > strictly partitioned and workload based security controls. > The 45 years of experience we have had with building systems at > every level from network appliances, through user interface engines > and multi-level secure supercomputers convince us that workload > based controls can never provide anything beyond grandiose security > theater. > > We have often claimed that isolation (partitioning, if you prefer) > is easy, sharing is hard. Building a system security policy based on > alleged "safe" existing behavior is at best naive. Personally, I've actually got two years on that, started with writing assembler code to modify the functionality of RDOS running on Data General Nova 2's, circa 1976. Edited microcode to fix the 'tired microcode' problems on DG Eclipses. Even built and ran a supercomputer center for about 6-7 years. Spent a ton of time in the last few years writing micro-controller code to implement hardware Trusted Modeling Agents, so I think I've been full circle as well. If we can put personal length issues aside, we can turn to the question of security controls tuned to the needs of a workload. Based on your comment above, I assume your position would be that 'Default deny, exception allow' security policies are inadequate or unsafe? There is probably no use drilling down too much further into technical details until we can reach that point of understanding. > > We obviously had an advantage in that we came into this with the > > opportunity for a clean design, whereas the existing, particularly > > label based solutions, have the constraint of a single ground truth > > with respect to the inode label implemented in the extended > > attributes. Which is the fault of nobody, but rather a function of > > the fact that label based systems have a heritage from before anyone > > even thought about resource namespaces. > Resource namespaces are expensive and require extensive administration > to be useful. As one of the early developers of the inode label based > solutions you disparage so flippantly, I take umbrage with your > characterization of the design process. > > Of course we thought of features which closely resemble user > namespaces. They're great for isolation. They're not so great for > implementing fixed security policy, which was the requirement and > goal. I wasn't being flippant or disparaging, please do not suggest malign intent where it does not exist. I will stand informed that you and others considered the notion of something equivalent to Linux namespaces or workloads and discarded them as useless, perhaps for very good reasons given the objectives you were attempting to achieve. Perhaps, unforunately, the rest of the world has gone in a different direction and now has expectations and needs that are influenced by the road that was chosen. Two comments: I find your observation that resource namespaces are expensive interesting. While they may not provide the degree of isolation you are interested in, one of the issues that drove their adoption was some degree of isolation with lower overhead than full virtualization. Secondly, I believe that an unjaded observer would not consider TSEM security modeling namespaces to require complex administrative overhead. Is there something about the usage examples and/or their description in the documentation that suggests the degree of complexity required to use them even approaches that of an OCI orchestrator? > > Do to our objectives, and the approach we took, TSEM doesn't require > > support for 'stacking' with other LSM's, obviously other LSM's do need > > that support, not a criticism but an observation. That opened the > > door to implement what users would consider to be an independent > > security namespace. > > > > The take away, that I assume everyone interested in Linux security > > would be in agreement on, perhaps not, is that user expectations are > > to have independent and separately administered security control > > environments that don't interact with one another. > So long as the "environments" are completely isolated this makes > perfect sense. What so many "users", and more importantly, software > snake oil salesmen, seem incapable of coming to grips with, is that > for an "environment" to be useful it is going to do some amount of > resource sharing with the host and frequently with other > "environments". That is where the lofty claims of isolation fall > apart, and the real, painful work for security developers, begins. First, we are not selling anything, we are attempting to contribute infrastructure to the common good to implement a security model that we have worked to significantly document the rationale for. Once again, TSEM 'namespaces' are not a mechanism for imposing isolation, they are about limiting the scope of acceptable security behaviors that can be exhibited by a process heirarchy. This allows a development team to impose a requirement that the workload block, through the use of mandatory controls, any security behavior that the application has not been unit tested to, without the need to engage systems administration support. Since the behaviors are workload specific there is less opportunity for the controls to 'break' the application. Which, based on our reasonably significant field experience and depending on the environment, results in an order being given to turn off the controls. None of this limits the ability of the system administrators to impose more rigid controls in pursuit of a whole system security policy if that is a desired goal of the architecture. With respect to modeling of security behavior, a namespace is a mechanism for reducing model complexity, which in turn increases the accuracy of the model prediction. If one doubts the importance of this concept in the modern enterprise security environment, I can go into stories about running uname, on a Linux box running an Oracle database implementation, setting off security policy alarms that bring in the security team and the need to write a formal security violation explanation. If there would be interest, I can post a link to a reasonably current review paper on the application of machine learning to system call analysis for Host Intrusion and Anomaly detection. It specifically calls out the need to focus on driving the model at workload scope in order to increase prediction accuracy. One of the forward looking objectives of TSEM namespaces is to drive models from the LSM level that, again by definition, has the most complete visibility into the security state of the system. > >>> While stacking of LSMs is largely done at the LSM layer, namespacing > >>> LSMs such that they can be customized for individual containers > >>> requires work to be done at the per-LSM level as each LSM is > >>> different. AppArmor already has a namespacing concept, but SELinux > >>> does not. Due to differences in the approach taken by the two LSMs, > >>> namespacing is much more of a challenge for SELinux, largely due to > >>> issues around filesystem labeling. We have not given up on the idea, > >>> but we have yet to arrive at a viable solution for namespacing > >>> SELinux. > >> I remain more optimistic than Paul about the options for > >> supporting generic LSM namespacing. I hope to explore a couple > >> notions that I have more fully, but as they depend on the current > >> stacking work I may not get to them very soon. > > I believe TSEM demonstrates that we already have the > > infrastructure at the LSM layer for generic namespacing. Of all > > the current LSM's, I believe we have the most sophisticated > > namespace implementation with respect to the functionality that it > > implements. > > > > We have implemented TSEM using both the standard Linux namespace > > infrastructure and as an independent namespace implementation using > > the LSM 'blob' infrastructure. FWIW, we have never looked back on the > > decision to implement LSM specific namespacing using the generic LSM > > 'blob' functionality. > > > > If there is a desire to provide some minimum level of generic security > > namespace functionality I could recitate a whole list of thoughts to > > consider but will leave that to another time. > I have discovered a truly marvelous patch for this, which this > email is too brief to contain. > > All kidding aside, there are a bunch of things we could do, but they all > introduce issues with object sharing. We have a TMA model implementation, that reads the SeLinux extended security attribute and role information and uses those in the computation of the allowed security state coefficients that would be representative of the MAC status of a workload. The TSEM documentation discusses the relationship between security state coefficients and positive AVC nodes in the 'Security Event Modeling' section, starting at line 204. My comments would have been framed around the experience and insights that work gave us with respect to the challenges associated with label based object sharing and possible responses to those issues that TSEM would facilitate. We don't blow smoke, but we are sensitive to the fact that people don't like to read much anymore. > >>> If you are interested in stacking SELinux and AppArmor, I believe the > >>> only practical solution is to run SELinux on the host system (initial > >>> namespace) and run AppArmor in the containers. Even in a world where > >>> SELinux is fully namespaced, it would likely still be necessary to run > >>> some type of SELinux policy on the host (initial namespace) in order > >>> to support SELinux policies in the containers. > >> SELinux policy is sufficiently flexible to support what would look > >> like different policies on the host system and in the container. I > >> think that the administration of such a system would be tricky, and > >> the policy would be very complex, but it could be done, for some use > >> cases at least. > > These reflections illuminate our motivation in developing TSEM, others > > may disagree, but a lot of experience in, and observation of, the > > security industry has led us to believe that security has to get > > simpler and easier to implement rather than more complex and arcane. > Evidence would indicate this is an errant conclusion. Interesting. So, by extentive reasoning, if we make security more complex, arcane and brittle; in an environment where professional security experience is increasingly limited, our systems will become more secure? I guess history will judge. > > We are probably at an interesting juncture in Linux development. The > > security controls we make available as a platform can either pursue a > > path where only highly skilled administrators and technology companies > > can implement them, or, we can provide mechanisms that work to increase > > the accessibility by development teams and ultimately the user > > community to advanced security controls. > Ever hear of the "Hillbilly Hummer"? No, you don't leave security > policy development to end users. No, the only Hillbilly thing we have here is a guy on the lake who has two 4x8 sheets of green treated plywood nailed together with 50 gallon plastic barrels on each corner pushed around by a five horse Evinrude. More directly to your point, you're misrepresenting our intentions, we are not suggesting we leave it to end users. As noted above, we have pretty solid feedback from groups who are deeply involved with infrastructure security that believe there are positive benefits to development teams being able to independently verify and protect the security of their workloads. If this works to increase the security posture of the systems in question, end users of the service would obviously seem to benefit. > > With TSEM, our design philosophy is that security controls need to > > flow from the development process in order to accomplish this latter > > objective. CI/CD is now considered a necessary and standard practice > > in the software industry, it doesn't seem like a stretch of the > > imagination that security controls should flow from that process as > > well. > > > > One of the requirements of this model is the ability to strictly scope > > security controls to the level of a workload nee security modeling > > namespace. > > > > Regardless of motivation, it would seem from this thread alone, that > > there is a user expectation, if not a necessary technical requirement, > > for Linux to provide infrastructure that enables strictly partitioned > > and independent security controls that don't require extensive > > reasoning as to what they might actually do in practice. > You really have missed the point. By a long way. The problem of > security is not now, nor has it ever been, isolation. It is > sharing. If it is appropriate for "users" to determine sharing, we > have mode bits. If it is appropriate for "administrators" to > determine sharing, we have mandatory access controls and > namespaces. If sharing is completely inappropriate, we have > virtualization. Hopefully, if people have elected to read this far, they will at least entertain the notion that our efforts are not as witless as has been suggested. Every technical issue involves shades of grey but TSEM is not about isolation, or sharing, for that matter. It is about defining whether or not a workload is acting consistently with what it was designed and intended to do and either acting in response or signaling that fact to others, in as precise a manner as can be implemented. It attempts to do this in what is, at least currently, within the context of the technology framework that industry has chosen to operate in. This of course leaves open the question if industry has chosen properly, which is something that neither one of us is going to do anything about. Best wishes for a productive remainder of the week. As always, Dr. Greg The Quixote Project - Flailing at the Travails of Cybersecurity ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LSM Stacking] SELinux policy inside container affects a process on Host 2023-07-19 18:45 ` Dr. Greg @ 2023-07-20 0:21 ` Casey Schaufler 2023-07-21 23:55 ` Dr. Greg 0 siblings, 1 reply; 24+ messages in thread From: Casey Schaufler @ 2023-07-20 0:21 UTC (permalink / raw) To: Dr. Greg; +Cc: Paul Moore, Leesoo Ahn, linux-security-module, Casey Schaufler On 7/19/2023 11:45 AM, Dr. Greg wrote: > On Tue, Jul 18, 2023 at 10:20:40AM -0700, Casey Schaufler wrote: > > Good afternoon to everyone. > >> On 7/18/2023 3:34 AM, Dr. Greg wrote: >>> On Fri, Jul 07, 2023 at 09:50:41AM -0700, Casey Schaufler wrote: >>> >>> Hi, I hope the week is going well for everyone. >>> >>>> On 7/7/2023 7:20 AM, Paul Moore wrote: >>>>> On Fri, Jul 7, 2023 at 4:29???AM Leesoo Ahn <lsahn@wewakecorp.com> wrote: >>>>>> 2023-07-06 ?????? 10:43??? Paul Moore ???(???) ??? ???: >>>>>>> On Thu, Jul 6, 2023 at 1:20???AM Leesoo Ahn <lsahn@wewakecorp.com> wrote: >>>>>>> > >>>>>>> > Hello! Here is another weird behavior of lsm stacking.. >>>>>>> > >>>>>>> > test env >>>>>>> > - Ubuntu 23.04 Ubuntu Kernel v6.2 w/ Stacking patch v38 >>>>>>> > - boot param: lsm=apparmor,selinux >>>>>>> > - AppArmor (Host) + SELinux (LXD Container Fedora 36) >>>>>>> > >>>>>>> > In the test environment mentioned above and applying selinux policy >>>>>>> > enforcing by running "setenforce 1" within the container, executing the >>>>>>> > following command on the host will result in "Permission denied" output. >>>>>>> >>>>>>> SELinux operates independently of containers, or kernel namespacing in >>>>>>> general. When you load a SELinux policy it applies to all processes >>>>>>> on the system, regardless of where they are in relation to the process >>>>>>> which loaded the policy into the kernel. >>>>>>> >>>>>>> This behavior is independent of the LSM stacking work, you should be >>>>>>> able to see the same behavior even in cases where SELinux is the only >>>>>>> loaded LSM on the system. >>>>>> Thank you for the reply! >>>>>> >>>>>> So as far as I understand, the environment of LSM Stacking, >>>>>> AppArmor (Host) + SELinux (Container) couldn't provide features "using >>>>>> SELinux policy inside the container shouldn't affect to the host side" >>>>>> for now. >>>>>> >>>>>> If so, I wonder if you and Casey plan to design future features like >>>>>> that, because my co-workers and I are considering taking LSM stacking of >>>>>> AppArmor + SELinux in products that both policies must be working >>>>>> separately. >>>>> What you are looking for is a combination of LSM stacking and >>>>> individual LSM namespacing. Sadly, I think the communications >>>>> around LSM stacking have not been very clear on this and I worry >>>>> that many people are going to be disappointed with LSM stacking >>>>> for this very reason. >>>> There have been many discussions regarding the viability of the >>>> using different LSM policies in containers. Some of these >>>> discussions have been quite lively. I have never claimed that LSM >>>> stacking addresses all of the possible use cases for multiple >>>> concurrent LSMs. If people are disappointed by how little they can >>>> accomplish with what is currently being proposed I can only say that >>>> we can't get on to the next phase until this work is complete. >>> It seems pretty clear, to us anyway, that generic user expectations >>> are that advanced security controls for Linux, ie beyond DAC, should >>> provide the same compartmentalization and isolation that other >>> resource namespaces bring to the table. >> It would have been really nice if the developers of resource >> namespaces had addressed the "LSM question" when they created their >> schemes. But they didn't. Namespaces are not primarily security >> constructs. You need go no further than the group access problem of >> user namespaces to understand where security ranks on the priority >> of namespaces. > It may very well be the case that namespaces are the worst abomination > that has ever been foisted on mankind with respect to security. Oh heavens, no. There are many things that are much worse. > > Unfortunately, that doesn't negate the fact that the software industry > has spoken and the notion of a 'container' or 'resource namespace', > whatever parlance one chooses to use, is now deeply ingrained in how > software is being developed and delivered and this will probably be > the case for the foreseeable future. Containers are a fad, like grid computing, Beowulf clusters and storage area networks. > This thread was initiated by the fact that their is an expectation, > that will only grow in the future, that security controls can be > scoped to a subdivision less than that of an entire system and in a > manner that doesn't cause one security policy to interfere with or > complicate the implementation of another. I dispute your "fact". I understand that some people believe that, but I also know that they haven't been told to expect that, at least not by the developers who are in a position to make it happen. > If current industry experience is any example, the one causing the > most problems will get turned off. Or administrators will be left > trying to reason as to what security controls are actually being > achieved, which is always hazardous. <snark - sorry> Horror of horrors! Users have no business understanding the security policy their system implements! You may as well let them write their own programs! </snark - sorry> > > With respect to our work, if you believe that we are looking at a > namespace as an isolation concept you have misunderstand our > motivations, objectives and implementation. > > The LSM infrastructure represents the basis set of information that > can be used to model the security behavior of a platform. If it does > not, it cannot adequately enforce effective security controls, since > by definition, it would have insufficient visibility into all security > relevant behavior. You have it backwards. The LSM infrastructure is driven by the needs of the security modules. If no one needed a hook for bind() we wouldn't have one. > > There are at least three ways this information can be used: > > The LSM can be used to enforce a system wide security policy through > mandatory access controls, your area of interest and endeavor. MAC has been an area of interest of mine for a long time, but is hardly the only one. Unfortunately, the other things I want to do require stackability. They don't require either/or with SELinux (or AppArmor, or Smack) but they do use cred blobs. > An equally valid concept is for developers to use this information > to verify that the security behavior of workloads that they develop > are consistent with what they desire. Err, no. That assumes that the information is sufficiently complete to identify any possible interesting behavior. There's no way I would claim the LSM infrastructure provides that. > A third possible use case of the LSM, since it represents access to > all of the information that describes the security state of a > platform, is to drive machine learning based analysis and > interpretation of the security status of a system. Nope. The claim that LSM provides access to "all of the information" is fallacious. It provides access to the information that existing security modules have asked for, and no more. > The latter two use cases benefit from the ability to reduce the scope > and complexity of the model being analyzed, which is the intent of the > TSEM security modeling namespaces. > > I'm just hazarding a guess here, no judgement implied, but I would > assume you view phenomenological modeling, machine learning and > artificial intelligence as irrelevant endeavors with respect to > security? Oh no, They are likely to be very relevant. Alas, I don't expect the general populous to listen to Artificial intelligence any better than they listen to Natural intelligence. I fully expect AI to provide significant insights, but the audience will be the security community, not the user community. > We have direct and constant dialogue with a group that has around 6000 > virtual machines running 30,000+ containers at any given instant in > time. Every VM is running, I believe, three CrowdStrike kernel > modules and other supportive infrastructure that are feeding 'machine > learning' telemetry into the cloud for security analysis. I also > believe there are Kubernetes sidecars analysing container behavior in > the mix as well. What is the AI looking for? How do you know if it is "security" you're analyzing, as opposed to teen-age buying patterns? > None of which is optional, given that the conversations surrounding > the technology consists of; "Run this because our insurance says we > have to". > > The beauty in Linux is that you can ignore all of this and run > SeLinux, but to say that resoure namespaces, compartmentalization and > modeling are irrelevant, flies in the face of how security is being > done. I often see cases where someone tries to implement a secure behavior using sophisticated mechanisms when a simple mechanism intended to address that specific issue is already in the system. That point that lots of people are using these mechanisms is valid, but in way too many cases far from the easiest or most reliable way to go about solving the problem. > >>> The 10 years of experience we have had with building systems, and >>> feedback we have received from collaborators with significant >>> experience in critical infrastructure, drove the focus in TSEM on >>> strictly partitioned and workload based security controls. >> The 45 years of experience we have had with building systems at >> every level from network appliances, through user interface engines >> and multi-level secure supercomputers convince us that workload >> based controls can never provide anything beyond grandiose security >> theater. >> >> We have often claimed that isolation (partitioning, if you prefer) >> is easy, sharing is hard. Building a system security policy based on >> alleged "safe" existing behavior is at best naive. > Personally, I've actually got two years on that, started with writing > assembler code to modify the functionality of RDOS running on Data > General Nova 2's, circa 1976. Edited microcode to fix the 'tired > microcode' problems on DG Eclipses. Even built and ran a > supercomputer center for about 6-7 years. Spent a ton of time in the > last few years writing micro-controller code to implement hardware > Trusted Modeling Agents, so I think I've been full circle as well. > > If we can put personal length issues aside, we can turn to the question > of security controls tuned to the needs of a workload. > > Based on your comment above, I assume your position would be that > 'Default deny, exception allow' security policies are inadequate or > unsafe? They are certainly prone to a particular kind of error. Program A accesses resource B, and the "policy" author doesn't know why. Rather than researching the reason that A accesses B, the policy is written to allow the access on the basis that A needs the access to do its job. Alas, giving A access to B also gives A access to C, which allows A to do nefarious things. Because no one ever contemplated the relationship between B and C, and A doesn't normally access C, the "policy" is flawed. ... And that's all I have time for today. > > There is probably no use drilling down too much further into technical > details until we can reach that point of understanding. > >>> We obviously had an advantage in that we came into this with the >>> opportunity for a clean design, whereas the existing, particularly >>> label based solutions, have the constraint of a single ground truth >>> with respect to the inode label implemented in the extended >>> attributes. Which is the fault of nobody, but rather a function of >>> the fact that label based systems have a heritage from before anyone >>> even thought about resource namespaces. >> Resource namespaces are expensive and require extensive administration >> to be useful. As one of the early developers of the inode label based >> solutions you disparage so flippantly, I take umbrage with your >> characterization of the design process. >> >> Of course we thought of features which closely resemble user >> namespaces. They're great for isolation. They're not so great for >> implementing fixed security policy, which was the requirement and >> goal. > I wasn't being flippant or disparaging, please do not suggest malign > intent where it does not exist. > > I will stand informed that you and others considered the notion of > something equivalent to Linux namespaces or workloads and discarded > them as useless, perhaps for very good reasons given the objectives you > were attempting to achieve. > > Perhaps, unforunately, the rest of the world has gone in a different > direction and now has expectations and needs that are influenced by > the road that was chosen. > > Two comments: > > I find your observation that resource namespaces are expensive > interesting. While they may not provide the degree of isolation you > are interested in, one of the issues that drove their adoption was > some degree of isolation with lower overhead than full virtualization. > > Secondly, I believe that an unjaded observer would not consider TSEM > security modeling namespaces to require complex administrative > overhead. Is there something about the usage examples and/or their > description in the documentation that suggests the degree of > complexity required to use them even approaches that of an OCI > orchestrator? > >>> Do to our objectives, and the approach we took, TSEM doesn't require >>> support for 'stacking' with other LSM's, obviously other LSM's do need >>> that support, not a criticism but an observation. That opened the >>> door to implement what users would consider to be an independent >>> security namespace. >>> >>> The take away, that I assume everyone interested in Linux security >>> would be in agreement on, perhaps not, is that user expectations are >>> to have independent and separately administered security control >>> environments that don't interact with one another. >> So long as the "environments" are completely isolated this makes >> perfect sense. What so many "users", and more importantly, software >> snake oil salesmen, seem incapable of coming to grips with, is that >> for an "environment" to be useful it is going to do some amount of >> resource sharing with the host and frequently with other >> "environments". That is where the lofty claims of isolation fall >> apart, and the real, painful work for security developers, begins. > First, we are not selling anything, we are attempting to contribute > infrastructure to the common good to implement a security model that > we have worked to significantly document the rationale for. > > Once again, TSEM 'namespaces' are not a mechanism for imposing > isolation, they are about limiting the scope of acceptable security > behaviors that can be exhibited by a process heirarchy. > > This allows a development team to impose a requirement that the > workload block, through the use of mandatory controls, any security > behavior that the application has not been unit tested to, without the > need to engage systems administration support. > > Since the behaviors are workload specific there is less opportunity > for the controls to 'break' the application. Which, based on our > reasonably significant field experience and depending on the > environment, results in an order being given to turn off the controls. > > None of this limits the ability of the system administrators to impose > more rigid controls in pursuit of a whole system security policy if > that is a desired goal of the architecture. > > With respect to modeling of security behavior, a namespace is a > mechanism for reducing model complexity, which in turn increases the > accuracy of the model prediction. > > If one doubts the importance of this concept in the modern enterprise > security environment, I can go into stories about running uname, on a > Linux box running an Oracle database implementation, setting off > security policy alarms that bring in the security team and the need to > write a formal security violation explanation. > > If there would be interest, I can post a link to a reasonably current > review paper on the application of machine learning to system call > analysis for Host Intrusion and Anomaly detection. It specifically > calls out the need to focus on driving the model at workload scope in > order to increase prediction accuracy. > > One of the forward looking objectives of TSEM namespaces is to drive > models from the LSM level that, again by definition, has the most > complete visibility into the security state of the system. > >>>>> While stacking of LSMs is largely done at the LSM layer, namespacing >>>>> LSMs such that they can be customized for individual containers >>>>> requires work to be done at the per-LSM level as each LSM is >>>>> different. AppArmor already has a namespacing concept, but SELinux >>>>> does not. Due to differences in the approach taken by the two LSMs, >>>>> namespacing is much more of a challenge for SELinux, largely due to >>>>> issues around filesystem labeling. We have not given up on the idea, >>>>> but we have yet to arrive at a viable solution for namespacing >>>>> SELinux. >>>> I remain more optimistic than Paul about the options for >>>> supporting generic LSM namespacing. I hope to explore a couple >>>> notions that I have more fully, but as they depend on the current >>>> stacking work I may not get to them very soon. >>> I believe TSEM demonstrates that we already have the >>> infrastructure at the LSM layer for generic namespacing. Of all >>> the current LSM's, I believe we have the most sophisticated >>> namespace implementation with respect to the functionality that it >>> implements. >>> >>> We have implemented TSEM using both the standard Linux namespace >>> infrastructure and as an independent namespace implementation using >>> the LSM 'blob' infrastructure. FWIW, we have never looked back on the >>> decision to implement LSM specific namespacing using the generic LSM >>> 'blob' functionality. >>> >>> If there is a desire to provide some minimum level of generic security >>> namespace functionality I could recitate a whole list of thoughts to >>> consider but will leave that to another time. >> I have discovered a truly marvelous patch for this, which this >> email is too brief to contain. >> >> All kidding aside, there are a bunch of things we could do, but they all >> introduce issues with object sharing. > We have a TMA model implementation, that reads the SeLinux extended > security attribute and role information and uses those in the > computation of the allowed security state coefficients that would be > representative of the MAC status of a workload. The TSEM > documentation discusses the relationship between security state > coefficients and positive AVC nodes in the 'Security Event Modeling' > section, starting at line 204. > > My comments would have been framed around the experience and insights > that work gave us with respect to the challenges associated with label > based object sharing and possible responses to those issues that TSEM > would facilitate. > > We don't blow smoke, but we are sensitive to the fact that people > don't like to read much anymore. > >>>>> If you are interested in stacking SELinux and AppArmor, I believe the >>>>> only practical solution is to run SELinux on the host system (initial >>>>> namespace) and run AppArmor in the containers. Even in a world where >>>>> SELinux is fully namespaced, it would likely still be necessary to run >>>>> some type of SELinux policy on the host (initial namespace) in order >>>>> to support SELinux policies in the containers. >>>> SELinux policy is sufficiently flexible to support what would look >>>> like different policies on the host system and in the container. I >>>> think that the administration of such a system would be tricky, and >>>> the policy would be very complex, but it could be done, for some use >>>> cases at least. >>> These reflections illuminate our motivation in developing TSEM, others >>> may disagree, but a lot of experience in, and observation of, the >>> security industry has led us to believe that security has to get >>> simpler and easier to implement rather than more complex and arcane. >> Evidence would indicate this is an errant conclusion. > Interesting. > > So, by extentive reasoning, if we make security more complex, arcane > and brittle; in an environment where professional security experience > is increasingly limited, our systems will become more secure? > > I guess history will judge. > >>> We are probably at an interesting juncture in Linux development. The >>> security controls we make available as a platform can either pursue a >>> path where only highly skilled administrators and technology companies >>> can implement them, or, we can provide mechanisms that work to increase >>> the accessibility by development teams and ultimately the user >>> community to advanced security controls. >> Ever hear of the "Hillbilly Hummer"? No, you don't leave security >> policy development to end users. > No, the only Hillbilly thing we have here is a guy on the lake who has > two 4x8 sheets of green treated plywood nailed together with 50 gallon > plastic barrels on each corner pushed around by a five horse Evinrude. > > More directly to your point, you're misrepresenting our intentions, we > are not suggesting we leave it to end users. > > As noted above, we have pretty solid feedback from groups who are > deeply involved with infrastructure security that believe there are > positive benefits to development teams being able to independently > verify and protect the security of their workloads. > > If this works to increase the security posture of the systems in > question, end users of the service would obviously seem to benefit. > >>> With TSEM, our design philosophy is that security controls need to >>> flow from the development process in order to accomplish this latter >>> objective. CI/CD is now considered a necessary and standard practice >>> in the software industry, it doesn't seem like a stretch of the >>> imagination that security controls should flow from that process as >>> well. >>> >>> One of the requirements of this model is the ability to strictly scope >>> security controls to the level of a workload nee security modeling >>> namespace. >>> >>> Regardless of motivation, it would seem from this thread alone, that >>> there is a user expectation, if not a necessary technical requirement, >>> for Linux to provide infrastructure that enables strictly partitioned >>> and independent security controls that don't require extensive >>> reasoning as to what they might actually do in practice. >> You really have missed the point. By a long way. The problem of >> security is not now, nor has it ever been, isolation. It is >> sharing. If it is appropriate for "users" to determine sharing, we >> have mode bits. If it is appropriate for "administrators" to >> determine sharing, we have mandatory access controls and >> namespaces. If sharing is completely inappropriate, we have >> virtualization. > Hopefully, if people have elected to read this far, they will at least > entertain the notion that our efforts are not as witless as has been > suggested. > > Every technical issue involves shades of grey but TSEM is not about > isolation, or sharing, for that matter. It is about defining whether > or not a workload is acting consistently with what it was designed and > intended to do and either acting in response or signaling that fact to > others, in as precise a manner as can be implemented. > > It attempts to do this in what is, at least currently, within the > context of the technology framework that industry has chosen to > operate in. This of course leaves open the question if industry has > chosen properly, which is something that neither one of us is going to > do anything about. > > Best wishes for a productive remainder of the week. > > As always, > Dr. Greg > > The Quixote Project - Flailing at the Travails of Cybersecurity ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LSM Stacking] SELinux policy inside container affects a process on Host 2023-07-20 0:21 ` Casey Schaufler @ 2023-07-21 23:55 ` Dr. Greg 0 siblings, 0 replies; 24+ messages in thread From: Dr. Greg @ 2023-07-21 23:55 UTC (permalink / raw) To: Casey Schaufler; +Cc: Paul Moore, Leesoo Ahn, linux-security-module On Wed, Jul 19, 2023 at 05:21:37PM -0700, Casey Schaufler wrote: I hope the week is ending well for everyone. > On 7/19/2023 11:45 AM, Dr. Greg wrote: > > On Tue, Jul 18, 2023 at 10:20:40AM -0700, Casey Schaufler wrote: > > > > Good afternoon to everyone. > > > >> On 7/18/2023 3:34 AM, Dr. Greg wrote: > >>> On Fri, Jul 07, 2023 at 09:50:41AM -0700, Casey Schaufler wrote: > >>> > >>> Hi, I hope the week is going well for everyone. > >>> > >>>> On 7/7/2023 7:20 AM, Paul Moore wrote: > >>>>> On Fri, Jul 7, 2023 at 4:29???AM Leesoo Ahn <lsahn@wewakecorp.com> wrote: > >>>>>> 2023-07-06 ?????? 10:43??? Paul Moore ???(???) ??? ???: > >>>>>>> On Thu, Jul 6, 2023 at 1:20???AM Leesoo Ahn <lsahn@wewakecorp.com> wrote: > >>>>>>> > > >>>>>>> > Hello! Here is another weird behavior of lsm stacking.. > >>>>>>> > > >>>>>>> > test env > >>>>>>> > - Ubuntu 23.04 Ubuntu Kernel v6.2 w/ Stacking patch v38 > >>>>>>> > - boot param: lsm=apparmor,selinux > >>>>>>> > - AppArmor (Host) + SELinux (LXD Container Fedora 36) > >>>>>>> > > >>>>>>> > In the test environment mentioned above and applying selinux policy > >>>>>>> > enforcing by running "setenforce 1" within the container, executing the > >>>>>>> > following command on the host will result in "Permission denied" output. > >>>>>>> > >>>>>>> SELinux operates independently of containers, or kernel namespacing in > >>>>>>> general. When you load a SELinux policy it applies to all processes > >>>>>>> on the system, regardless of where they are in relation to the process > >>>>>>> which loaded the policy into the kernel. > >>>>>>> > >>>>>>> This behavior is independent of the LSM stacking work, you should be > >>>>>>> able to see the same behavior even in cases where SELinux is the only > >>>>>>> loaded LSM on the system. > >>>>>> Thank you for the reply! > >>>>>> > >>>>>> So as far as I understand, the environment of LSM Stacking, > >>>>>> AppArmor (Host) + SELinux (Container) couldn't provide features "using > >>>>>> SELinux policy inside the container shouldn't affect to the host side" > >>>>>> for now. > >>>>>> > >>>>>> If so, I wonder if you and Casey plan to design future features like > >>>>>> that, because my co-workers and I are considering taking LSM stacking of > >>>>>> AppArmor + SELinux in products that both policies must be working > >>>>>> separately. > >>>>> What you are looking for is a combination of LSM stacking and > >>>>> individual LSM namespacing. Sadly, I think the communications > >>>>> around LSM stacking have not been very clear on this and I worry > >>>>> that many people are going to be disappointed with LSM stacking > >>>>> for this very reason. > >>>> There have been many discussions regarding the viability of the > >>>> using different LSM policies in containers. Some of these > >>>> discussions have been quite lively. I have never claimed that LSM > >>>> stacking addresses all of the possible use cases for multiple > >>>> concurrent LSMs. If people are disappointed by how little they can > >>>> accomplish with what is currently being proposed I can only say that > >>>> we can't get on to the next phase until this work is complete. > >>> It seems pretty clear, to us anyway, that generic user expectations > >>> are that advanced security controls for Linux, ie beyond DAC, should > >>> provide the same compartmentalization and isolation that other > >>> resource namespaces bring to the table. > >> It would have been really nice if the developers of resource > >> namespaces had addressed the "LSM question" when they created their > >> schemes. But they didn't. Namespaces are not primarily security > >> constructs. You need go no further than the group access problem of > >> user namespaces to understand where security ranks on the priority > >> of namespaces. > > It may very well be the case that namespaces are the worst abomination > > that has ever been foisted on mankind with respect to security. > Oh heavens, no. There are many things that are much worse. Noted with interest, hopefully none of it is inside of Linux. > > Unfortunately, that doesn't negate the fact that the software industry > > has spoken and the notion of a 'container' or 'resource namespace', > > whatever parlance one chooses to use, is now deeply ingrained in how > > software is being developed and delivered and this will probably be > > the case for the foreseeable future. > Containers are a fad, like grid computing, Beowulf clusters and > storage area networks. Interesting outlook. FWIW, on a strictly unrelated, non-technical front. My Dad is telling me the same thing, almost every day, about these automatic transmissions they are putting in cars. I'm hoping that what he thinks comes true before I have lost all the acumen that I developed double-clutching a 3-5-5 triple split Fuller LoadRanger on the tail of the 3208 Cat that I spent a fair amount of time driving, during a decidedly non-technical interlude in my professional career. The above offered, as a public service to any interests, who feel that TSEM shouldn't see the light of day because it, proudly, originates from what are decidedly hillbilly origins... :-) Besides security, it looks like I also personally fail, on a secondary technical front. I architected, designed and direct the maintenance over a pretty good sized SAN, that has been steadily advancing over the last 23 years since it was first built. It currently links three geographically dispersed data-centers at 32 GBPS storage target speeds to synchronously replicate petabytes of data on a day in and data out basis. Not sure how we would do all of that without the concept of a storage network. I guess time will tell on all of these fads. > > This thread was initiated by the fact that their is an expectation, > > that will only grow in the future, that security controls can be > > scoped to a subdivision less than that of an entire system and in a > > manner that doesn't cause one security policy to interfere with or > > complicate the implementation of another. > I dispute your "fact". I understand that some people believe that, > but I also know that they haven't been told to expect that, at least > not by the developers who are in a position to make it happen. All I can speak for are the groups that we are engaged with who indicate that they believe that workload specific security controls are a reasonable, if not necessary requirement, for how software development is evolving, and who have an interest in seeing what TSEM represents available on Linux. Our conversations in this forum would suggest you believe such ideas are completely misguided. From your perspective and experiences, that may not be an unreasonable on systems that are supporting adversarial parties. This is security, so no one wants to talk about who may be doing something and how. FWIW, the people who contemplate this as a useful advancement represent a formidable body of experience in the security industry. > > If current industry experience is any example, the one causing the > > most problems will get turned off. Or administrators will be left > > trying to reason as to what security controls are actually being > > achieved, which is always hazardous. > <snark - sorry> > Horror of horrors! Users have no business understanding the security > policy their system implements! You may as well let them write their > own programs! > </snark - sorry> I did 107 miles of cycling yesterday, in the glacial moraine lake country of West-Central Minnesota, trying to parse what the above means. The best that I can come up with is that only systems administrators, or perhaps security personnel, should understand what security controls are implemented and how. All the environments we have experience with suggest that everyone is on the same team; platform engineers, administrators, developers, security personnel, quality assurance et.al. They are all focused on having a solution be as secure as possible. Some have watched these conversations and don't understand why it would be unreasonable for a development team to be able to implement controls that could catch a possible defect in their application stack, before system wide controls would need to stop the behavior. > > With respect to our work, if you believe that we are looking at a > > namespace as an isolation concept you have misunderstand our > > motivations, objectives and implementation. > > > > The LSM infrastructure represents the basis set of information that > > can be used to model the security behavior of a platform. If it does > > not, it cannot adequately enforce effective security controls, since > > by definition, it would have insufficient visibility into all security > > relevant behavior. > You have it backwards. The LSM infrastructure is driven by the needs > of the security modules. If no one needed a hook for bind() we > wouldn't have one. You misinterpret my point, let me see if I can clarify. The LSM, over the course of its development, has developed a significant body of security inspection points, at the expense of a fair amount of pain as Paul Moore would seem to suggest, for what has been determined to be security significant actions, all to support the needs of various security enforcement systems. It may not represent all relevant security behavior, but it is the sum of what is available for Linux as a platform, you cannot get any better visibility, without adding more hooks, which seems to be increasingly problematic and conflict laden. So TSEM comes at this from the perspective of: "If life gives you lemons, make lemonade". We take all of the available information that these interception points can generate and use it to enable the application of mathematical models that range through the spectrum of deterministic, quasi-deterministic, and with an increasing relevance, machine learning models. All of this provides a pathway to security model resolution that represents a detection and interdiction strength that equals the sum of what all the other LSM security schemes can produce, put together. If additional hooks get added and they make sense from a modeling perspective, any security models implemented via TSEM will gain additional resolution. > > There are at least three ways this information can be used: > > > > The LSM can be used to enforce a system wide security policy through > > mandatory access controls, your area of interest and endeavor. > MAC has been an area of interest of mine for a long time, but is > hardly the only one. Unfortunately, the other things I want to do > require stackability. They don't require either/or with SELinux (or > AppArmor, or Smack) but they do use cred blobs. Presumably a security token bearing scheme, we will look forward to seeing it. > > An equally valid concept is for developers to use this information > > to verify that the security behavior of workloads that they develop > > are consistent with what they desire. > Err, no. That assumes that the information is sufficiently complete > to identify any possible interesting behavior. There's no way I > would claim the LSM infrastructure provides that. Again, with reference to the discussion above, it is the best that Linux can do as a platform. If TSEM's security model cannot detect an aberration, by definition, there would be no reason to expect that any of the other LSM based security controls could detect and act on the threat. A final point. TSEM models are exquisitely sensitive to deviations in the security behavior of a workload. You would presumably have little interest in taking the time to actually test TSEM with the Quixote utilities but doing so may be illuminating for you or others within the Linux security community. The contributing factor to this high sensitivity is the security state coefficient generation function that is used. The 'Event Modeling' section of the TSEM document, starting at line 704, goes into some detail on this aspect of the security model. From a big picture perspective, every corpus of executable code will have its own representation of any of the security behaviors that the LSM is capable of tracking. The TSEM documentation has practical examples of how this manifests itself in practice. > > A third possible use case of the LSM, since it represents access to > > all of the information that describes the security state of a > > platform, is to drive machine learning based analysis and > > interpretation of the security status of a system. > Nope. The claim that LSM provides access to "all of the information" > is fallacious. It provides access to the information that existing > security modules have asked for, and no more. Hopefully we we have taken that issue to task. > > The latter two use cases benefit from the ability to reduce the scope > > and complexity of the model being analyzed, which is the intent of the > > TSEM security modeling namespaces. > > > > I'm just hazarding a guess here, no judgement implied, but I would > > assume you view phenomenological modeling, machine learning and > > artificial intelligence as irrelevant endeavors with respect to > > security? > Oh no, They are likely to be very relevant. Alas, I don't expect the > general populous to listen to Artificial intelligence any better > than they listen to Natural intelligence. I fully expect AI to > provide significant insights, but the audience will be the security > community, not the user community. Once gain, nothing about TSEM involves the user community, unless of course, the user community means the development teams that are putting the application stacks on the platform. TSEM is designed to provide a mechanism for machine learning to have access to what by definition, is all of the relevant security behavior information that Linux has available to it as a platform. The primary user community will be data science teams. > > We have direct and constant dialogue with a group that has around 6000 > > virtual machines running 30,000+ containers at any given instant in > > time. Every VM is running, I believe, three CrowdStrike kernel > > modules and other supportive infrastructure that are feeding 'machine > > learning' telemetry into the cloud for security analysis. I also > > believe there are Kubernetes sidecars analysing container behavior in > > the mix as well. > What is the AI looking for? How do you know if it is "security" > you're analyzing, as opposed to teen-age buying patterns? I wouldn't have a clue as to what they are looking for, you would need to ask the CrowdStrike security engineering teams. Given how closely guarded security technology is, with machine learning models considered the most closely guarded secrets there are, it seems unlikely they would tell you. Their current 35.11 billion dollar valuation is dependent on their ability to detect anomalous platform security behavior, however they do it, if you believe their web-site, it is through event modeling and artifical intelligence schemes implemented in the 'cloud'. I suspect you would need to run a request up through your chain of command to Pat Gelsinger to try and get access to exactly what they are doing. Pat Gelsinger taking George Kurtz to lunch, or some similar momentous exchange, is where those types of deals for exchange of cooperation probably need to get done. You had suggested in a previous e-mail that there are software 'snake-oil' salesman out there, maybe that is what CrowdStrike represents, if so they are making a ton of money doing it. > > None of which is optional, given that the conversations surrounding > > the technology consists of; "Run this because our insurance says we > > have to". > > > > The beauty in Linux is that you can ignore all of this and run > > SeLinux, but to say that resoure namespaces, compartmentalization and > > modeling are irrelevant, flies in the face of how security is being > > done. > I often see cases where someone tries to implement a secure behavior > using sophisticated mechanisms when a simple mechanism intended to > address that specific issue is already in the system. That point > that lots of people are using these mechanisms is valid, but in way > too many cases far from the easiest or most reliable way to go about > solving the problem. You would probably disagree, but TSEM is about an easier way of doing things. > >>> The 10 years of experience we have had with building systems, and > >>> feedback we have received from collaborators with significant > >>> experience in critical infrastructure, drove the focus in TSEM on > >>> strictly partitioned and workload based security controls. > >> The 45 years of experience we have had with building systems at > >> every level from network appliances, through user interface engines > >> and multi-level secure supercomputers convince us that workload > >> based controls can never provide anything beyond grandiose security > >> theater. > >> > >> We have often claimed that isolation (partitioning, if you prefer) > >> is easy, sharing is hard. Building a system security policy based on > >> alleged "safe" existing behavior is at best naive. > > Personally, I've actually got two years on that, started with writing > > assembler code to modify the functionality of RDOS running on Data > > General Nova 2's, circa 1976. Edited microcode to fix the 'tired > > microcode' problems on DG Eclipses. Even built and ran a > > supercomputer center for about 6-7 years. Spent a ton of time in the > > last few years writing micro-controller code to implement hardware > > Trusted Modeling Agents, so I think I've been full circle as well. > > > > If we can put personal length issues aside, we can turn to the question > > of security controls tuned to the needs of a workload. > > > > Based on your comment above, I assume your position would be that > > 'Default deny, exception allow' security policies are inadequate or > > unsafe? > They are certainly prone to a particular kind of error. Program A > accesses resource B, and the "policy" author doesn't know > why. Rather than researching the reason that A accesses B, the > policy is written to allow the access on the basis that A needs the > access to do its job. Alas, giving A access to B also gives A access > to C, which allows A to do nefarious things. Because no one ever > contemplated the relationship between B and C, and A doesn't > normally access C, the "policy" is flawed. Yes, the perils of transitive security reasoning. TSEM isn't about that, TSEM is more about the security model that every firewall running on the planet implements. It is all, actually, pretty straight forward. Assume a deterministic or quasi-deterministic model (model inputs run through a leveling algorithm). There exists a finite field of security coefficients that will be generated for a workload based on the security coefficient generation algorithm in use. By default, all coefficients in the field will deny access to their associated event. Unit testing of the workload generates a sub-field of coefficients whose associated actions are permitted. This allows development teams to place a bounding set on the allowed security behavior of their workload. If you don't trust your developers to do complete CI/CD coverage you install additional controls as a secondary security boundary. There are always exceptions, but our experience is that development teams are starting to get pretty serious about the security of their stacks and their CI/CD code coverage. From our perspective, it doesn't seem right-headed for Linux to deny them access to the ability to leverage mandatory control schemes to improve their deliverable. > ... And that's all I have time for today. Indeed and we have probably hit the asymptotic limit of interest to anyone who may be following along at home. Best wishes for a pleasant summer weekend. As always, Dr. Greg The Quixote Project - Flailing at the Travails of Cybersecurity ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LSM Stacking] SELinux policy inside container affects a processon Host 2023-07-07 14:20 ` Paul Moore 2023-07-07 16:50 ` Casey Schaufler @ 2023-07-17 15:24 ` Leesoo Ahn 2023-07-17 15:51 ` Casey Schaufler 2023-07-28 1:54 ` [LSM Stacking] SELinux policy inside container affects a processon Host Leesoo Ahn 2 siblings, 1 reply; 24+ messages in thread From: Leesoo Ahn @ 2023-07-17 15:24 UTC (permalink / raw) To: Paul Moore; +Cc: Casey Schaufler, linux-security-module 23. 7. 7. 23:20에 Paul Moore 이(가) 쓴 글: > On Fri, Jul 7, 2023 at 4:29 AM Leesoo Ahn <lsahn@wewakecorp.com> wrote: > > 2023-07-06 오후 10:43에 Paul Moore 이(가) 쓴 글: [...] > > What you are looking for is a combination of LSM stacking and > individual LSM namespacing. Sadly, I think the communications around > LSM stacking have not been very clear on this and I worry that many > people are going to be disappointed with LSM stacking for this very > reason. > > While stacking of LSMs is largely done at the LSM layer, namespacing > LSMs such that they can be customized for individual containers > requires work to be done at the per-LSM level as each LSM is > different. AppArmor already has a namespacing concept, but SELinux > does not. Due to differences in the approach taken by the two LSMs, > namespacing is much more of a challenge for SELinux, largely due to > issues around filesystem labeling. We have not given up on the idea, > but we have yet to arrive at a viable solution for namespacing > SELinux. > > If you are interested in stacking SELinux and AppArmor, I believe the > only practical solution is to run SELinux on the host system (initial > namespace) and run AppArmor in the containers. Even in a world where > SELinux is fully namespaced, it would likely still be necessary to run > some type of SELinux policy on the host (initial namespace) in order > to support SELinux policies in the containers. Thank you for the reply. It really helped me to know the current status of them and what to do now. Just a little information for who is interested in the stacking that we decided to branch the LSM hooks by which lsm the current process is in instead of entirely calling them in order. Best regards, Leesoo ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LSM Stacking] SELinux policy inside container affects a processon Host 2023-07-17 15:24 ` [LSM Stacking] SELinux policy inside container affects a processon Host Leesoo Ahn @ 2023-07-17 15:51 ` Casey Schaufler 2023-07-24 2:29 ` [LSM Stacking] SELinux policy inside container affects aprocesson Host Leesoo Ahn 0 siblings, 1 reply; 24+ messages in thread From: Casey Schaufler @ 2023-07-17 15:51 UTC (permalink / raw) To: Leesoo Ahn, Paul Moore; +Cc: linux-security-module, Casey Schaufler On 7/17/2023 8:24 AM, Leesoo Ahn wrote: > 23. 7. 7. 23:20에 Paul Moore 이(가) 쓴 글: >> On Fri, Jul 7, 2023 at 4:29 AM Leesoo Ahn <lsahn@wewakecorp.com> wrote: >> > 2023-07-06 오후 10:43에 Paul Moore 이(가) 쓴 글: > [...] >> >> What you are looking for is a combination of LSM stacking and >> individual LSM namespacing. Sadly, I think the communications around >> LSM stacking have not been very clear on this and I worry that many >> people are going to be disappointed with LSM stacking for this very >> reason. >> >> While stacking of LSMs is largely done at the LSM layer, namespacing >> LSMs such that they can be customized for individual containers >> requires work to be done at the per-LSM level as each LSM is >> different. AppArmor already has a namespacing concept, but SELinux >> does not. Due to differences in the approach taken by the two LSMs, >> namespacing is much more of a challenge for SELinux, largely due to >> issues around filesystem labeling. We have not given up on the idea, >> but we have yet to arrive at a viable solution for namespacing >> SELinux. >> >> If you are interested in stacking SELinux and AppArmor, I believe the >> only practical solution is to run SELinux on the host system (initial >> namespace) and run AppArmor in the containers. Even in a world where >> SELinux is fully namespaced, it would likely still be necessary to run >> some type of SELinux policy on the host (initial namespace) in order >> to support SELinux policies in the containers. > > Thank you for the reply. It really helped me to know the current > status of them and what to do now. > > Just a little information for who is interested in the stacking that > we decided to branch the LSM hooks by which lsm the current process is > in instead of entirely calling them in order. Could you describe your approach more fully? > > Best regards, > Leesoo ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LSM Stacking] SELinux policy inside container affects aprocesson Host 2023-07-17 15:51 ` Casey Schaufler @ 2023-07-24 2:29 ` Leesoo Ahn 2023-07-24 21:35 ` Casey Schaufler 0 siblings, 1 reply; 24+ messages in thread From: Leesoo Ahn @ 2023-07-24 2:29 UTC (permalink / raw) To: Casey Schaufler; +Cc: linux-security-module 2023-07-18 오전 12:51에 Casey Schaufler 이(가) 쓴 글: > On 7/17/2023 8:24 AM, Leesoo Ahn wrote: > > 23. 7. 7. 23:20에 Paul Moore 이(가) 쓴 글: > >> On Fri, Jul 7, 2023 at 4:29 AM Leesoo Ahn <lsahn@wewakecorp.com> wrote: > >> > 2023-07-06 오후 10:43에 Paul Moore 이(가) 쓴 글: [...]> >> If you are interested in stacking SELinux and AppArmor, I believe the > >> only practical solution is to run SELinux on the host system (initial > >> namespace) and run AppArmor in the containers. Even in a world where > >> SELinux is fully namespaced, it would likely still be necessary to run > >> some type of SELinux policy on the host (initial namespace) in order > >> to support SELinux policies in the containers. > > > > Thank you for the reply. It really helped me to know the current > > status of them and what to do now. > > > > Just a little information for who is interested in the stacking that > > we decided to branch the LSM hooks by which lsm the current process is > > in instead of entirely calling them in order. > > Could you describe your approach more fully? As far as I know, the current stacking feature is implemented calling the entire hooks in order of 'lsm=' boot parameter. But our desire must be calling a proper hook at a time by a task's current LSM, for instance Apparmor 'or' SELinux instead of 'and'. And so we have been considering adding two new hooks which work as the same as the origin hooks but additionally branch to a proper hook function with the information of current LSM by calling lsm_task_ilsm(). The following changes are a part of our approach, ------ code part ------ #define call_int_hook_by_ilsm(FUNC, ILSM, IRC, ...) ({ \ int RC = IRC; \ do { \ struct security_hook_list *P; \ int id; \ \ id = (ILSM == LSMBLOB_INVALID) \ ? lsm_slotlist[0]->id \ : lsm_slotlist[ILSM]->id; \ hlist_for_each_entry(P, &security_hook_heads.FUNC, list) { \ if (P->lsmid->slot != LSMBLOB_NOT_NEEDED && id != P->lsmid->id) \ continue; \ RC = P->hook.FUNC(__VA_ARGS__); \ if (RC != 0) \ break; \ } \ } while (0); \ RC; \ }) [...] int ilsm = lsm_task_ilsm(current); ret = call_int_hook_by_ilsm(mmap_addr, ilsm, 0, addr); ------------ We are still worrying about the part of calling lsm_task_ilsm() with 'current', it seems dangerous in some unknown cases. What do you think about this approach, Casey? Best regards, Leesoo ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LSM Stacking] SELinux policy inside container affects aprocesson Host 2023-07-24 2:29 ` [LSM Stacking] SELinux policy inside container affects aprocesson Host Leesoo Ahn @ 2023-07-24 21:35 ` Casey Schaufler 2023-07-25 3:16 ` [LSM Stacking] SELinux policy inside container affects aprocessonHost Leesoo Ahn 0 siblings, 1 reply; 24+ messages in thread From: Casey Schaufler @ 2023-07-24 21:35 UTC (permalink / raw) To: Leesoo Ahn; +Cc: linux-security-module, Casey Schaufler On 7/23/2023 7:29 PM, Leesoo Ahn wrote: > 2023-07-18 오전 12:51에 Casey Schaufler 이(가) 쓴 글: >> On 7/17/2023 8:24 AM, Leesoo Ahn wrote: >> > 23. 7. 7. 23:20에 Paul Moore 이(가) 쓴 글: >> >> On Fri, Jul 7, 2023 at 4:29 AM Leesoo Ahn <lsahn@wewakecorp.com> >> wrote: >> >> > 2023-07-06 오후 10:43에 Paul Moore 이(가) 쓴 글: > [...]> >> If you are interested in stacking SELinux and AppArmor, I > believe the >> >> only practical solution is to run SELinux on the host system >> (initial >> >> namespace) and run AppArmor in the containers. Even in a world where >> >> SELinux is fully namespaced, it would likely still be necessary >> to run >> >> some type of SELinux policy on the host (initial namespace) in order >> >> to support SELinux policies in the containers. >> > >> > Thank you for the reply. It really helped me to know the current >> > status of them and what to do now. >> > >> > Just a little information for who is interested in the stacking that >> > we decided to branch the LSM hooks by which lsm the current >> process is >> > in instead of entirely calling them in order. >> >> Could you describe your approach more fully? > > As far as I know, the current stacking feature is implemented calling > the entire hooks in order of 'lsm=' boot parameter. But our desire > must be calling a proper hook at a time by a task's current LSM, for > instance Apparmor 'or' SELinux instead of 'and'. SELinux and Smack rely on the fact that they manage security attributes on all subjects and all objects. On a system where some objects are not labeled because they are being managed by AppArmor instead, you are going to have a security state that is muddled. How would you have a host system that uses SELinux handle files in a container that is using only AppArmor? If the host processes never look at the files in the container you could have a system that works the way you'd like. But how could you ensure that? > > And so we have been considering adding two new hooks which work as the > same as the origin hooks but additionally branch to a proper hook > function with the information of current LSM by calling lsm_task_ilsm(). > > The following changes are a part of our approach, > > ------ code part ------ > #define call_int_hook_by_ilsm(FUNC, ILSM, IRC, ...) ({ \ > int RC = IRC; \ > do { \ > struct security_hook_list *P; \ > int id; \ > \ > id = (ILSM == LSMBLOB_INVALID) \ > ? lsm_slotlist[0]->id \ > : lsm_slotlist[ILSM]->id; \ > hlist_for_each_entry(P, &security_hook_heads.FUNC, > list) { \ > if (P->lsmid->slot != LSMBLOB_NOT_NEEDED && id > != P->lsmid->id) \ > continue; \ > RC = P->hook.FUNC(__VA_ARGS__); \ > if (RC != 0) \ > break; \ > } \ > } while (0); \ > RC; \ > }) > > [...] > > int ilsm = lsm_task_ilsm(current); > ret = call_int_hook_by_ilsm(mmap_addr, ilsm, 0, addr); > ------------ > > We are still worrying about the part of calling lsm_task_ilsm() with > 'current', it seems dangerous in some unknown cases. > > What do you think about this approach, Casey? I will put aside the question of whether having processes with divergent security policies is reasonable for the moment. I know many people believe that it isn't, and I think that there's real danger in it. I'm not a fan of making the call_ macros any fancier than they are. I would rather see a local copy of the hook lists for processes that use a different set than the base system. > > Best regards, > Leesoo ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LSM Stacking] SELinux policy inside container affects aprocessonHost 2023-07-24 21:35 ` Casey Schaufler @ 2023-07-25 3:16 ` Leesoo Ahn 0 siblings, 0 replies; 24+ messages in thread From: Leesoo Ahn @ 2023-07-25 3:16 UTC (permalink / raw) To: Casey Schaufler; +Cc: linux-security-module 2023-07-25 오전 6:35에 Casey Schaufler 이(가) 쓴 글: > On 7/23/2023 7:29 PM, Leesoo Ahn wrote: > > 2023-07-18 오전 12:51에 Casey Schaufler 이(가) 쓴 글: > >> On 7/17/2023 8:24 AM, Leesoo Ahn wrote: > >> > 23. 7. 7. 23:20에 Paul Moore 이(가) 쓴 글: > >> >> On Fri, Jul 7, 2023 at 4:29 AM Leesoo Ahn <lsahn@wewakecorp.com> > >> wrote: > >> >> > 2023-07-06 오후 10:43에 Paul Moore 이(가) 쓴 글: > > [...]> >> If you are interested in stacking SELinux and AppArmor, I > > believe the > >> >> only practical solution is to run SELinux on the host system > >> (initial > >> >> namespace) and run AppArmor in the containers. Even in a world where > >> >> SELinux is fully namespaced, it would likely still be necessary > >> to run > >> >> some type of SELinux policy on the host (initial namespace) in order > >> >> to support SELinux policies in the containers. > >> > > >> > Thank you for the reply. It really helped me to know the current > >> > status of them and what to do now. > >> > > >> > Just a little information for who is interested in the stacking that > >> > we decided to branch the LSM hooks by which lsm the current > >> process is > >> > in instead of entirely calling them in order. > >> > >> Could you describe your approach more fully? > > > > As far as I know, the current stacking feature is implemented calling > > the entire hooks in order of 'lsm=' boot parameter. But our desire > > must be calling a proper hook at a time by a task's current LSM, for > > instance Apparmor 'or' SELinux instead of 'and'. > > SELinux and Smack rely on the fact that they manage security attributes > on all subjects and all objects. On a system where some objects are not > labeled because they are being managed by AppArmor instead, you are > going to have a security state that is muddled. How would you have a > host system that uses SELinux handle files in a container that is using > only AppArmor? I think we could deal with that using origin call_ macro only if the following cases that alloc a task, socket, make a file and so forth which do newing objects and subjects that must have both security context for preventing a security state that would be muddled. On the other hands, in a case of operations that like read, load, mmap are to call the customized call_ macro with ilsm to conditionally branch. [...] > I would rather see a local copy of the hook lists for processes that > use a different set than the base system. Could you explain the latter one, please? best regards, Leesoo ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LSM Stacking] SELinux policy inside container affects a processon Host 2023-07-07 14:20 ` Paul Moore 2023-07-07 16:50 ` Casey Schaufler 2023-07-17 15:24 ` [LSM Stacking] SELinux policy inside container affects a processon Host Leesoo Ahn @ 2023-07-28 1:54 ` Leesoo Ahn 2023-08-06 17:16 ` Dr. Greg 2 siblings, 1 reply; 24+ messages in thread From: Leesoo Ahn @ 2023-07-28 1:54 UTC (permalink / raw) To: Paul Moore; +Cc: Casey Schaufler, linux-security-module I hope you have a great day today 2023-07-07 오후 11:20에 Paul Moore 이(가) 쓴 글: > On Fri, Jul 7, 2023 at 4:29 AM Leesoo Ahn <lsahn@wewakecorp.com> wrote: [...] > > What you are looking for is a combination of LSM stacking and > individual LSM namespacing. Sadly, I think the communications around > LSM stacking have not been very clear on this and I worry that many > people are going to be disappointed with LSM stacking for this very > reason. > > While stacking of LSMs is largely done at the LSM layer, namespacing > LSMs such that they can be customized for individual containers > requires work to be done at the per-LSM level as each LSM is > different. AppArmor already has a namespacing concept, but SELinux > does not. Due to differences in the approach taken by the two LSMs, > namespacing is much more of a challenge for SELinux, largely due to > issues around filesystem labeling. We have not given up on the idea, > but we have yet to arrive at a viable solution for namespacing > SELinux. > > If you are interested in stacking SELinux and AppArmor, I believe the > only practical solution is to run SELinux on the host system (initial > namespace) and run AppArmor in the containers. Paul, I don't get that SELinux on the host system and run AppArmor in the containers is the only practical solution. Could you please explain that in more details? Best regards, Leesoo ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LSM Stacking] SELinux policy inside container affects a processon Host 2023-07-28 1:54 ` [LSM Stacking] SELinux policy inside container affects a processon Host Leesoo Ahn @ 2023-08-06 17:16 ` Dr. Greg 2023-08-06 19:25 ` Paul Moore 0 siblings, 1 reply; 24+ messages in thread From: Dr. Greg @ 2023-08-06 17:16 UTC (permalink / raw) To: Leesoo Ahn; +Cc: Paul Moore, Casey Schaufler, linux-security-module On Fri, Jul 28, 2023 at 10:54:23AM +0900, Leesoo Ahn wrote: > I hope you have a great day today Hi Leesoo, I hope your week is starting well. > 2023-07-07 ?????? 11:20??? Paul Moore ???(???) ??? ???: > >On Fri, Jul 7, 2023 at 4:29???AM Leesoo Ahn <lsahn@wewakecorp.com> wrote: > > [...] > > > > >What you are looking for is a combination of LSM stacking and > >individual LSM namespacing. Sadly, I think the communications around > >LSM stacking have not been very clear on this and I worry that many > >people are going to be disappointed with LSM stacking for this very > >reason. > > > >While stacking of LSMs is largely done at the LSM layer, namespacing > >LSMs such that they can be customized for individual containers > >requires work to be done at the per-LSM level as each LSM is > >different. AppArmor already has a namespacing concept, but SELinux > >does not. Due to differences in the approach taken by the two LSMs, > >namespacing is much more of a challenge for SELinux, largely due to > >issues around filesystem labeling. We have not given up on the idea, > >but we have yet to arrive at a viable solution for namespacing > >SELinux. > > > >If you are interested in stacking SELinux and AppArmor, I believe the > >only practical solution is to run SELinux on the host system (initial > >namespace) and run AppArmor in the containers. > Paul, I don't get that SELinux on the host system and run AppArmor > in the containers is the only practical solution. Could you please > explain that in more details? It appears that Paul is extremely busy, so I thought the 'Quixote Group' would try and offer some reflections that may help with your efforts. The most important issue in all of this is to understand that Linux LSM's 'stack', they don't 'nest'. If more than one LSM is enabled, their hooks will be called consecutively until one fails or they all succeed. There is currently no concept of an 'LSM namespace' that would allow the actions of one LSM to be isolated from a second LSM that is enabled. So if you are attempting to run SELinux and AppArmor on the same host, you need to reason through the effective security policy that results from the combination of the SELinux and AppArmor policies. We would certainly not profess to be the experts on LSM/SELinux that Paul is but I believe the point he is making is that, in his opinion, the only way to allow both policies to effectively co-habitate is to use SELinux enforcement on the host system and AppArmor enforcement in the container environment. Lets see if we can reason through a hypothetical example that would illustrate the issues involved. If SELinux 'goes first', which will probably be the case, there will be a need to have an SELinux policy in place that does not prohibit the interaction of subjects and objects in the container environment, otherwise you will get whatever the effective SELinux policy is. Once SELinux elects to not deny a security event, an AppArmor policy will have the opportunity to make security decisions for the processes running in the container environment. As Casey has noted previously in this thread, creating this type of environment will no doubt require some degree of sophistication and expertise in both SELinux and AppArmor policy development and implementation. Hopefully the above will help facilitate further understanding with respect to your efforts. > Best regards, > Leesoo Best wishes for a productive remainder of the week and the success of your work. As always, Dr. Greg The Quixote Project - Flailing at the Travails of Cybersecurity ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LSM Stacking] SELinux policy inside container affects a processon Host 2023-08-06 17:16 ` Dr. Greg @ 2023-08-06 19:25 ` Paul Moore 2023-08-08 6:40 ` Dr. Greg 0 siblings, 1 reply; 24+ messages in thread From: Paul Moore @ 2023-08-06 19:25 UTC (permalink / raw) To: Leesoo Ahn; +Cc: Casey Schaufler, linux-security-module, Dr. Greg On Sun, Aug 6, 2023 at 1:16 PM Dr. Greg <greg@enjellic.com> wrote: > On Fri, Jul 28, 2023 at 10:54:23AM +0900, Leesoo Ahn wrote: > > 2023-07-07 ?????? 11:20??? Paul Moore ???(???) ??? ???: > > >On Fri, Jul 7, 2023 at 4:29???AM Leesoo Ahn <lsahn@wewakecorp.com> wrote: > > > > [...] > > > > > > > >What you are looking for is a combination of LSM stacking and > > >individual LSM namespacing. Sadly, I think the communications around > > >LSM stacking have not been very clear on this and I worry that many > > >people are going to be disappointed with LSM stacking for this very > > >reason. > > > > > >While stacking of LSMs is largely done at the LSM layer, namespacing > > >LSMs such that they can be customized for individual containers > > >requires work to be done at the per-LSM level as each LSM is > > >different. AppArmor already has a namespacing concept, but SELinux > > >does not. Due to differences in the approach taken by the two LSMs, > > >namespacing is much more of a challenge for SELinux, largely due to > > >issues around filesystem labeling. We have not given up on the idea, > > >but we have yet to arrive at a viable solution for namespacing > > >SELinux. > > > > > >If you are interested in stacking SELinux and AppArmor, I believe the > > >only practical solution is to run SELinux on the host system (initial > > >namespace) and run AppArmor in the containers. > > > Paul, I don't get that SELinux on the host system and run AppArmor > > in the containers is the only practical solution. Could you please > > explain that in more details? > > It appears that Paul is extremely busy, so I thought the 'Quixote > Group' would try and offer some reflections that may help with your > efforts. My apologies, yes I am rather busy at the moment, but I also stopped following this thread a while ago as it didn't seem to be going anywhere meaningful. I happen to read this last email while I'm waiting in an airport, so let me try and provide a quick explanation about why running SELinux only in a container is a bad idea. As you probably know, the Linux kernel has no concept of a container, it only supports subsystem specific namespaces, e.g. mount namespace, network namespace, etc. SELinux does not provide a subsystem namespace, and it does not generally concern itself with other subsystem names. From a SELinux perspective there is no difference between a process running in the host namespace or a container/namespace; both are treated the same with access control decisions made based on the processes' SELinux domain, the type of the target resource, and the access requested. If one were to load a SELinux policy inside a container, even if it were allowed, the system would likely behave in unexpected ways as the container-loaded policy will take effect across the entire system, not just inside the container. -- paul-moore.com ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LSM Stacking] SELinux policy inside container affects a processon Host 2023-08-06 19:25 ` Paul Moore @ 2023-08-08 6:40 ` Dr. Greg 2023-08-08 14:32 ` Paul Moore 0 siblings, 1 reply; 24+ messages in thread From: Dr. Greg @ 2023-08-08 6:40 UTC (permalink / raw) To: Paul Moore; +Cc: Leesoo Ahn, Casey Schaufler, linux-security-module, Dr. Greg On Sun, Aug 06, 2023 at 03:25:32PM -0400, Paul Moore wrote: Good morning, I hope the week has started well for everyone. > On Sun, Aug 6, 2023 at 1:16???PM Dr. Greg <greg@enjellic.com> wrote: > > On Fri, Jul 28, 2023 at 10:54:23AM +0900, Leesoo Ahn wrote: > > > 2023-07-07 ?????? 11:20??? Paul Moore ???(???) ??? ???: > > > >On Fri, Jul 7, 2023 at 4:29???AM Leesoo Ahn <lsahn@wewakecorp.com> wrote: > > > > > > [...] > > > > > > > > > > >What you are looking for is a combination of LSM stacking and > > > >individual LSM namespacing. Sadly, I think the communications around > > > >LSM stacking have not been very clear on this and I worry that many > > > >people are going to be disappointed with LSM stacking for this very > > > >reason. > > > > > > > >While stacking of LSMs is largely done at the LSM layer, namespacing > > > >LSMs such that they can be customized for individual containers > > > >requires work to be done at the per-LSM level as each LSM is > > > >different. AppArmor already has a namespacing concept, but SELinux > > > >does not. Due to differences in the approach taken by the two LSMs, > > > >namespacing is much more of a challenge for SELinux, largely due to > > > >issues around filesystem labeling. We have not given up on the idea, > > > >but we have yet to arrive at a viable solution for namespacing > > > >SELinux. > > > > > > > >If you are interested in stacking SELinux and AppArmor, I believe the > > > >only practical solution is to run SELinux on the host system (initial > > > >namespace) and run AppArmor in the containers. > > > > > Paul, I don't get that SELinux on the host system and run AppArmor > > > in the containers is the only practical solution. Could you please > > > explain that in more details? > > > > It appears that Paul is extremely busy, so I thought the 'Quixote > > Group' would try and offer some reflections that may help with your > > efforts. > My apologies, yes I am rather busy at the moment, but I also stopped > following this thread a while ago as it didn't seem to be going > anywhere meaningful. I happen to read this last email while I'm > waiting in an airport, so let me try and provide a quick explanation > about why running SELinux only in a container is a bad idea. > > As you probably know, the Linux kernel has no concept of a container, > it only supports subsystem specific namespaces, e.g. mount namespace, > network namespace, etc. SELinux does not provide a subsystem > namespace, and it does not generally concern itself with other > subsystem names. From a SELinux perspective there is no difference > between a process running in the host namespace or a > container/namespace; both are treated the same with access control > decisions made based on the processes' SELinux domain, the type of the > target resource, and the access requested. > > If one were to load a SELinux policy inside a container, even if it > were allowed, the system would likely behave in unexpected ways as the > container-loaded policy will take effect across the entire system, not > just inside the container. All reasonable and consistent, with what we had previously written with respect to there being no notion of LSM namespacing. To further assist Leesoo and others who may be following this, you had suggested the following earlier in this thread: Paul> If you are interested in stacking SELinux and AppArmor, I Paul> believe the only practical solution is to run SELinux on the Paul> host system (initial namespace) and run AppArmor in the Paul> containers. Which would seem to apply that in a 'stacked' LSM configuration of SELinux and AppArmor, there would be a possibility of using the two LSM's without them 'colliding', the equivalent of what could be considered a 'nested' LSM implementation. Casey had also suggested in this thread that this would be possible at the risk of a system that would be difficult to reason about. Were our previous comments correct, that the path forward would be to have SELinux configured in a manner where it would not act on any of the subject/object interactions that occur in the container environment that is using AppArmor? If so, would the path forward be to implement an SELinux policy that would place the process initiating the namespace, and its descendants, in an unconfined domain with respect to the assets in the scope of the container? As always, Dr. Greg The Quixote Project - Flailing at the Travails of Cybersecurity ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LSM Stacking] SELinux policy inside container affects a processon Host 2023-08-08 6:40 ` Dr. Greg @ 2023-08-08 14:32 ` Paul Moore 0 siblings, 0 replies; 24+ messages in thread From: Paul Moore @ 2023-08-08 14:32 UTC (permalink / raw) To: Dr. Greg; +Cc: Leesoo Ahn, Casey Schaufler, linux-security-module On Tue, Aug 8, 2023 at 2:41 AM Dr. Greg <greg@enjellic.com> wrote: > On Sun, Aug 06, 2023 at 03:25:32PM -0400, Paul Moore wrote: > > On Sun, Aug 6, 2023 at 1:16???PM Dr. Greg <greg@enjellic.com> wrote: > > > On Fri, Jul 28, 2023 at 10:54:23AM +0900, Leesoo Ahn wrote: > > > > 2023-07-07 ?????? 11:20??? Paul Moore ???(???) ??? ???: > > > > >On Fri, Jul 7, 2023 at 4:29???AM Leesoo Ahn <lsahn@wewakecorp.com> wrote: > > > > > > > > [...] > > > > > > > > > > > > > >What you are looking for is a combination of LSM stacking and > > > > >individual LSM namespacing. Sadly, I think the communications around > > > > >LSM stacking have not been very clear on this and I worry that many > > > > >people are going to be disappointed with LSM stacking for this very > > > > >reason. > > > > > > > > > >While stacking of LSMs is largely done at the LSM layer, namespacing > > > > >LSMs such that they can be customized for individual containers > > > > >requires work to be done at the per-LSM level as each LSM is > > > > >different. AppArmor already has a namespacing concept, but SELinux > > > > >does not. Due to differences in the approach taken by the two LSMs, > > > > >namespacing is much more of a challenge for SELinux, largely due to > > > > >issues around filesystem labeling. We have not given up on the idea, > > > > >but we have yet to arrive at a viable solution for namespacing > > > > >SELinux. > > > > > > > > > >If you are interested in stacking SELinux and AppArmor, I believe the > > > > >only practical solution is to run SELinux on the host system (initial > > > > >namespace) and run AppArmor in the containers. > > > > > > > Paul, I don't get that SELinux on the host system and run AppArmor > > > > in the containers is the only practical solution. Could you please > > > > explain that in more details? > > > > > > It appears that Paul is extremely busy, so I thought the 'Quixote > > > Group' would try and offer some reflections that may help with your > > > efforts. > > > My apologies, yes I am rather busy at the moment, but I also stopped > > following this thread a while ago as it didn't seem to be going > > anywhere meaningful. I happen to read this last email while I'm > > waiting in an airport, so let me try and provide a quick explanation > > about why running SELinux only in a container is a bad idea. > > > > As you probably know, the Linux kernel has no concept of a container, > > it only supports subsystem specific namespaces, e.g. mount namespace, > > network namespace, etc. SELinux does not provide a subsystem > > namespace, and it does not generally concern itself with other > > subsystem names. From a SELinux perspective there is no difference > > between a process running in the host namespace or a > > container/namespace; both are treated the same with access control > > decisions made based on the processes' SELinux domain, the type of the > > target resource, and the access requested. > > > > If one were to load a SELinux policy inside a container, even if it > > were allowed, the system would likely behave in unexpected ways as the > > container-loaded policy will take effect across the entire system, not > > just inside the container. > > All reasonable and consistent, with what we had previously written > with respect to there being no notion of LSM namespacing. > > To further assist Leesoo and others who may be following this, you had > suggested the following earlier in this thread: > > Paul> If you are interested in stacking SELinux and AppArmor, I > Paul> believe the only practical solution is to run SELinux on the > Paul> host system (initial namespace) and run AppArmor in the > Paul> containers. > > Which would seem to apply that in a 'stacked' LSM configuration of > SELinux and AppArmor, there would be a possibility of using the two > LSM's without them 'colliding', the equivalent of what could be > considered a 'nested' LSM implementation. SELinux applies access control across the entire system, regardless of what namespaces may be configured on the system. Loading a SELinux policy in the host/initial-namespace during early boot helps ensure proper labeling of system entities and a better user experience; loading a SELinux policy in a container/namespace can lead to surprising and unpredictable results across the whole of the system. AppArmor is different in that it has support for containers/namespaces. Running SELinux on the host and AppArmor in a container isn't so much about preventing collisions, they are still simultaneously running and applying their security policies, it is more about ensuring the LSMs, the admins, and the users all see compatible views of the system. Please do not confuse any of the above as a 'nested' or namespaced LSM layer; the current in-progress LSM stacking is simply that: the ability to stack some combination of LSMs in a few prescribed configurations. Talking about 'nesting' or 'namespacing' at the LSM layer is confusing at best, and misleading at the worst. -- paul-moore.com ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [LSM Stacking] SELinux policy inside container affects a process on Host 2023-07-07 8:28 ` [LSM Stacking] SELinux policy inside container affects a process on Host Leesoo Ahn 2023-07-07 14:20 ` Paul Moore @ 2023-07-07 17:51 ` Dr. Greg 1 sibling, 0 replies; 24+ messages in thread From: Dr. Greg @ 2023-07-07 17:51 UTC (permalink / raw) To: Leesoo Ahn; +Cc: Paul Moore, Casey Schaufler, linux-security-module On Fri, Jul 07, 2023 at 05:28:36PM +0900, Leesoo Ahn wrote: Hi Leesoo, I hope the week has gone well for you. > 2023-07-06 ?????? 10:43??? Paul Moore ???(???) ??? ???: > >On Thu, Jul 6, 2023 at 1:20???AM Leesoo Ahn <lsahn@wewakecorp.com> wrote: > > > > > > Hello! Here is another weird behavior of lsm stacking.. > > > > > > test env > > > - Ubuntu 23.04 Ubuntu Kernel v6.2 w/ Stacking patch v38 > > > - boot param: lsm=apparmor,selinux > > > - AppArmor (Host) + SELinux (LXD Container Fedora 36) > > > > > > In the test environment mentioned above and applying selinux policy > > > enforcing by running "setenforce 1" within the container, executing the > > > following command on the host will result in "Permission denied" output. > >SELinux operates independently of containers, or kernel namespacing in > >general. When you load a SELinux policy it applies to all processes > >on the system, regardless of where they are in relation to the process > >which loaded the policy into the kernel. > > > >This behavior is independent of the LSM stacking work, you should be > >able to see the same behavior even in cases where SELinux is the only > >loaded LSM on the system. > Thank you for the reply! > > So as far as I understand, the environment of LSM Stacking, AppArmor > (Host) + SELinux (Container) couldn't provide features "using > SELinux policy inside the container shouldn't affect to the host > side" for now. > > If so, I wonder if you and Casey plan to design future features like > that, because my co-workers and I are considering taking LSM > stacking of AppArmor + SELinux in products that both policies must > be working separately. I see that Paul Moore has also replied and indicated that 'stacking' doesn't imply either/or separation of security policy in a string of LSM's. As he also noted, it does not apply isolation and application of security policy at the container or kernel resource namespace level. Just as an FYI, we will be releasing version 2 of our Trusted Security Event Modeling (TSEM) LSM over the weekend for review and inclusion in the upstream kernel. TSEM 'stacks' with the other LSM's, but was architected from the ground up to support the notion of security namespaces that operate exclusively from one another, with the express goal of allowing multiple and distinct security policies to be applied independently at what would be considered the 'container' level. Subordinate security modeling namespaces also act independently from the security model/policy that the 'root' modeling namespace is operating under. TSEM is based on a mathematical modeling architecture that is different from either the label or pathname based LSM's which allowed us to sidestep some of the issues that are challenging with respect to implementing full namespace support for those LSM's. There is a sizable stack of documentation with TSEM that goes further into all of this. We also release a rather significant body of userspace tooling that goes with the TSEM LSM to support running 'security containers', for lack of a better term. It obviously takes a while to develop a security eco-system but TSEM will hopefully offer security architects additional flexibility moving forward. > best regards, > Leesoo Have a good weekend. As always, Dr. Greg The Quixote Project - Flailing at the Travails of Cybersecurity ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2023-08-08 17:46 UTC | newest] Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-07-06 5:12 [LSM Stacking] SELinux policy inside container affects a process on Host Leesoo Ahn 2023-07-06 13:43 ` Paul Moore 2023-07-07 0:35 ` Serge E. Hallyn 2023-07-07 1:17 ` [LSM Stacking] SELinux policy inside container affects a processon Host Leesoo Ahn 2023-07-07 8:28 ` [LSM Stacking] SELinux policy inside container affects a process on Host Leesoo Ahn 2023-07-07 14:20 ` Paul Moore 2023-07-07 16:50 ` Casey Schaufler 2023-07-07 21:41 ` Paul Moore 2023-07-18 10:34 ` Dr. Greg 2023-07-18 17:20 ` Casey Schaufler 2023-07-19 18:45 ` Dr. Greg 2023-07-20 0:21 ` Casey Schaufler 2023-07-21 23:55 ` Dr. Greg 2023-07-17 15:24 ` [LSM Stacking] SELinux policy inside container affects a processon Host Leesoo Ahn 2023-07-17 15:51 ` Casey Schaufler 2023-07-24 2:29 ` [LSM Stacking] SELinux policy inside container affects aprocesson Host Leesoo Ahn 2023-07-24 21:35 ` Casey Schaufler 2023-07-25 3:16 ` [LSM Stacking] SELinux policy inside container affects aprocessonHost Leesoo Ahn 2023-07-28 1:54 ` [LSM Stacking] SELinux policy inside container affects a processon Host Leesoo Ahn 2023-08-06 17:16 ` Dr. Greg 2023-08-06 19:25 ` Paul Moore 2023-08-08 6:40 ` Dr. Greg 2023-08-08 14:32 ` Paul Moore 2023-07-07 17:51 ` [LSM Stacking] SELinux policy inside container affects a process on Host Dr. Greg
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.