| Message ID | 20200818152037.11869-1-krzysztof.struczynski@huawei.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | ima: Introduce IMA namespace | expand |
On Tue, Aug 18, 2020 at 05:20:07PM +0200, krzysztof.struczynski@huawei.com wrote: > From: Krzysztof Struczynski <krzysztof.struczynski@huawei.com> > > IMA has not been designed to work with containers. It handles every > process in the same way, and it cannot distinguish if a process belongs to > a container or not. > > Containers use namespaces to make it appear to the processes in the > containers that they have their own isolated instance of the global > resource. For IMA as well, it is desirable to let processes in the > containers have IMA functionality independent from other containers: > separate policy rules, measurement list, additional appraisal keys to > verify the container image, separate audit logs. > > As previous work done in this area, this patch series introduces the IMA > namespace, which is a separate instance of IMA to handle a subset of > processes that belong to a container. > > The IMA namespace is created using clone3() or unshare() system calls. It > is important to configure the namespace before any process appears in it, > so that the new policy rules apply to the very first process in the > namespace. To achieve that, the intermediate namespace ima_ns_for_children > is used. It stores the configuration and becomes active on the next fork > or when the first process enters it using the setns() system call. The > similar process is used for the time namespace. > > The IMA namespace can be configured using the new securityfs directory > entries that allow the user to set the policy rules, x509 certificate for > appraisal and pass IMA configuration parameters normally included in the > kernel command line parameters. It is intended to extend the clone_args to > allow configuration from clone3() syscall. Not to be the downer right away but just as an fyi, if this patchset makes it, clone3() will not allow to be extended with any real second-level pointers. That will see a hard NAK from me and several other maintainers. Christian
On Tue, 2020-08-18 at 17:20 +0200, krzysztof.struczynski@huawei.com wrote: > The measurement list remains global, with the assumption that there > is only one TPM in the system. Each IMA namespace has a unique ID, > that allows to track measurements per IMA namespace. Processes in one > namespace, have access only to the measurements from that namespace. > The exception is made for the initial IMA namespace, whose processes > have access to all entries. So I think this can work in the use case where the system owner is responsible for doing the logging and attestation and the tenants just trust the owner without requiring an attestation. However, in a multi- tenant system you need a way for the attestation to be per-container (because the combined list of who executed what would be a security leak between tenants). Since we can't virtualise the PCRs without introducing a vtpm this is going to require a vtpm infrastructure like that used for virtual machines and then we can do IMA logging per container. I don't think the above has to be in your first patch set, we just have to have an idea of how it could be done to show that nothing in this patch set precludes a follow on from doing this. James
On Tue, Aug 18, 2020 at 05:20:07PM +0200, krzysztof.struczynski@huawei.com wrote: > From: Krzysztof Struczynski <krzysztof.struczynski@huawei.com> > > IMA has not been designed to work with containers. It handles every > process in the same way, and it cannot distinguish if a process belongs to > a container or not. > > Containers use namespaces to make it appear to the processes in the > containers that they have their own isolated instance of the global > resource. For IMA as well, it is desirable to let processes in the IMA is brought up on a regular basis with "we want to have this" for years and then non-one seems to really care enough. I'm highly skeptical of the value of ~2500 lines of code even if it includes a bunch of namespace boilerplate. It's yet another namespace, and yet another security framework. Why does IMA need to be a separate namespace? Keyrings are tied to user namespaces why can't IMA be? I believe Eric has even pointed that out before. Eric, thoughts? Christian
> From: James Bottomley [mailto:James.Bottomley@HansenPartnership.com] > On Tue, 2020-08-18 at 17:20 +0200, krzysztof.struczynski@huawei.com > wrote: > > The measurement list remains global, with the assumption that there > > is only one TPM in the system. Each IMA namespace has a unique ID, > > that allows to track measurements per IMA namespace. Processes in one > > namespace, have access only to the measurements from that namespace. > > The exception is made for the initial IMA namespace, whose processes > > have access to all entries. > > So I think this can work in the use case where the system owner is > responsible for doing the logging and attestation and the tenants just > trust the owner without requiring an attestation. However, in a multi- > tenant system you need a way for the attestation to be per-container > (because the combined list of who executed what would be a security > leak between tenants). Since we can't virtualise the PCRs without > introducing a vtpm this is going to require a vtpm infrastructure like > that used for virtual machines and then we can do IMA logging per > container. I agree and wonder if we should decouple the attestation trust model, which depends on the specific use case (e.g. multi/single tenant, public/private cloud), from the IMA logic of linking the measurements to the container. Indeed, attestation from within the container might require anchoring to a vTPM/vPCR and the current measurement tagging mechanism can support several ways of anchoring them to a (virtual) root of trust. > I don't think the above has to be in your first patch set, we just have > to have an idea of how it could be done to show that nothing in this > patch set precludes a follow on from doing this. Given that virtualizing trust anchors seems like a separate problem in which industry consensus is not easy to reach for all use cases, an anchoring mechanism should probably be a separate IMA feature. > > James
> From: Christian Brauner [mailto:christian.brauner@ubuntu.com] > On Tue, Aug 18, 2020 at 05:20:07PM +0200, krzysztof.struczynski@huawei.com > wrote: > > From: Krzysztof Struczynski <krzysztof.struczynski@huawei.com> > > > > IMA has not been designed to work with containers. It handles every > > process in the same way, and it cannot distinguish if a process belongs to > > a container or not. > > > > Containers use namespaces to make it appear to the processes in the > > containers that they have their own isolated instance of the global > > resource. For IMA as well, it is desirable to let processes in the > > containers have IMA functionality independent from other containers: > > separate policy rules, measurement list, additional appraisal keys to > > verify the container image, separate audit logs. > > > > As previous work done in this area, this patch series introduces the IMA > > namespace, which is a separate instance of IMA to handle a subset of > > processes that belong to a container. > > > > The IMA namespace is created using clone3() or unshare() system calls. It > > is important to configure the namespace before any process appears in it, > > so that the new policy rules apply to the very first process in the > > namespace. To achieve that, the intermediate namespace > ima_ns_for_children > > is used. It stores the configuration and becomes active on the next fork > > or when the first process enters it using the setns() system call. The > > similar process is used for the time namespace. > > > > The IMA namespace can be configured using the new securityfs directory > > entries that allow the user to set the policy rules, x509 certificate for > > appraisal and pass IMA configuration parameters normally included in the > > kernel command line parameters. It is intended to extend the clone_args to > > allow configuration from clone3() syscall. > > Not to be the downer right away but just as an fyi, if this patchset > makes it, clone3() will not allow to be extended with any real > second-level pointers. That will see a hard NAK from me and several > other maintainers. Ok, that's a good point. It can be done without the second-level pointers but if that's not desirable then IMA namespace creation via a direct clone3() call can be removed. It will make the process less flexible but it will still work with unshare() and clone3() or unshare() and setns() calls. > > Christian
> From: Christian Brauner [mailto:christian.brauner@ubuntu.com] > On Tue, Aug 18, 2020 at 05:20:07PM +0200, krzysztof.struczynski@huawei.com > wrote: > > From: Krzysztof Struczynski <krzysztof.struczynski@huawei.com> > > > > IMA has not been designed to work with containers. It handles every > > process in the same way, and it cannot distinguish if a process belongs to > > a container or not. > > > > Containers use namespaces to make it appear to the processes in the > > containers that they have their own isolated instance of the global > > resource. For IMA as well, it is desirable to let processes in the > > IMA is brought up on a regular basis with "we want to have this" for > years and then non-one seems to really care enough. > > I'm highly skeptical of the value of ~2500 lines of code even if it > includes a bunch of namespace boilerplate. It's yet another namespace, > and yet another security framework. > Why does IMA need to be a separate namespace? Keyrings are tied to user > namespaces why can't IMA be? I believe Eric has even pointed that out > before. The user namespace has its well defined purpose to isolate security-related identifiers and attributes, particularly UIDs and GIDs. I think that IMA goals are different. A user may want to isolate e.g. UIDs but not to create a separate IML or define the new IMA policies. On the other hand, especially in the single-tenant environment, the user may want to have a per container IML, but no UID/GID mapping is required. IMA policy defines subject-based rules (uid, euid, subj_*, ...), but also object-based rules. IMA has to be pre-configured, e.g. all actions of the process have to be appraised/measured/audited according to the pre-defined policy, appraisal key has to be available before the process is created, etc. If IMA is tied to the user namespace, when is a good moment to do it? What's the argument against adding a new namespace? > > Eric, thoughts? > > Christian
On Fri, 2020-08-21 at 15:13 +0000, Krzysztof Struczynski wrote: > > From: James Bottomley [mailto:James.Bottomley@HansenPartnership.com] > > On Tue, 2020-08-18 at 17:20 +0200, krzysztof.struczynski@huawei.com > > wrote: > > > The measurement list remains global, with the assumption that there > > > is only one TPM in the system. Each IMA namespace has a unique ID, > > > that allows to track measurements per IMA namespace. Processes in one > > > namespace, have access only to the measurements from that namespace. > > > The exception is made for the initial IMA namespace, whose processes > > > have access to all entries. > > > > So I think this can work in the use case where the system owner is > > responsible for doing the logging and attestation and the tenants just > > trust the owner without requiring an attestation. However, in a multi- > > tenant system you need a way for the attestation to be per-container > > (because the combined list of who executed what would be a security > > leak between tenants). Since we can't virtualise the PCRs without > > introducing a vtpm this is going to require a vtpm infrastructure like > > that used for virtual machines and then we can do IMA logging per > > container. > > I agree and wonder if we should decouple the attestation trust model, > which depends on the specific use case (e.g. multi/single tenant, > public/private cloud), from the IMA logic of linking the measurements to > the container. Indeed, attestation from within the container might require > anchoring to a vTPM/vPCR and the current measurement tagging mechanism can > support several ways of anchoring them to a (virtual) root of trust. > > > I don't think the above has to be in your first patch set, we just have > > to have an idea of how it could be done to show that nothing in this > > patch set precludes a follow on from doing this. > > Given that virtualizing trust anchors seems like a separate problem in > which industry consensus is not easy to reach for all use cases, an > anchoring mechanism should probably be a separate IMA feature. Other trust anchors for "trusted keys" has been discussed, but I wasn't aware of any discussion about other trust anchors for the IMA measurement list. The IMA measurement list is very much tied to a TPM. Including container measurements in the host measurement list, will unnecessarily cause the host measurement list to grow. The decision of what should and shouldn't be included in the host measurement list shouldn't be defined by the container. Mimi
On Tue, 2020-08-18 at 18:49 +0200, Christian Brauner wrote: > On Tue, Aug 18, 2020 at 05:20:07PM +0200, krzysztof.struczynski@huawei.com wrote: > > From: Krzysztof Struczynski <krzysztof.struczynski@huawei.com> > > > > IMA has not been designed to work with containers. It handles every > > process in the same way, and it cannot distinguish if a process belongs to > > a container or not. > > > > Containers use namespaces to make it appear to the processes in the > > containers that they have their own isolated instance of the global > > resource. For IMA as well, it is desirable to let processes in the > > IMA is brought up on a regular basis with "we want to have this" for > years and then non-one seems to really care enough. There is a lot of interest in IMA namespacing, but the question always comes back to how to enable it. Refer to https://kernsec.org/wiki/index.php/IMA_Namespacing_design_considerations for Stefan's analysis. I understand "containers" is not a kernel construct, but from my very limited perspective, IMA namespacing only makes sense in the context of a "container". The container owner may want to know which files have been accessed/executed (measurements, remote attestation) and/or constrain which files may be accessed/executed based on signatures (appraisal). > > I'm highly skeptical of the value of ~2500 lines of code even if it > includes a bunch of namespace boilerplate. It's yet another namespace, > and yet another security framework. > Why does IMA need to be a separate namespace? Keyrings are tied to user > namespaces why can't IMA be? In the context of a container, the measurement list and IMA/EVM keyrings need to be setup before the first file is measured, signature verified, or file hash included in the audit log. > I believe Eric has even pointed that out > before. > > Eric, thoughts? Any help with the above scenario would very be much appreciated. Mimi
On Wed, Sep 02, 2020 at 02:53:17PM -0400, Mimi Zohar wrote: Good morning, I hope the week is ending well for everyone. > On Fri, 2020-08-21 at 15:13 +0000, Krzysztof Struczynski wrote: > > > From: James Bottomley [mailto:James.Bottomley@HansenPartnership.com] > > > On Tue, 2020-08-18 at 17:20 +0200, krzysztof.struczynski@huawei.com > > > wrote: > > > > The measurement list remains global, with the assumption that there > > > > is only one TPM in the system. Each IMA namespace has a unique ID, > > > > that allows to track measurements per IMA namespace. Processes in one > > > > namespace, have access only to the measurements from that namespace. > > > > The exception is made for the initial IMA namespace, whose processes > > > > have access to all entries. > > > > > > So I think this can work in the use case where the system owner is > > > responsible for doing the logging and attestation and the tenants just > > > trust the owner without requiring an attestation. However, in a multi- > > > tenant system you need a way for the attestation to be per-container > > > (because the combined list of who executed what would be a security > > > leak between tenants). Since we can't virtualise the PCRs without > > > introducing a vtpm this is going to require a vtpm infrastructure like > > > that used for virtual machines and then we can do IMA logging per > > > container. > > > > I agree and wonder if we should decouple the attestation trust model, > > which depends on the specific use case (e.g. multi/single tenant, > > public/private cloud), from the IMA logic of linking the measurements to > > the container. Indeed, attestation from within the container might require > > anchoring to a vTPM/vPCR and the current measurement tagging mechanism can > > support several ways of anchoring them to a (virtual) root of trust. > > > > > I don't think the above has to be in your first patch set, we just have > > > to have an idea of how it could be done to show that nothing in this > > > patch set precludes a follow on from doing this. > > > > Given that virtualizing trust anchors seems like a separate problem in > > which industry consensus is not easy to reach for all use cases, an > > anchoring mechanism should probably be a separate IMA feature. > Other trust anchors for "trusted keys" has been discussed, but I wasn't > aware of any discussion about other trust anchors for the IMA > measurement list. The IMA measurement list is very much tied to a TPM. > > Including container measurements in the host measurement list, will > unnecessarily cause the host measurement list to grow. The decision of > what should and shouldn't be included in the host measurement list > shouldn't be defined by the container. We have been shipping, and more importantly maintaining in the wild, systems with a namespaced IMA implementation for 4+ years now. We presented the foundations for all of this at the 2015 Linux Security Summit in Seattle. For the purposes of further conversation, I should clarify and indicate that we have been shipping and maintaining what a namespaced IMA implementation turns into when all of the engineering challenges have been addressed with respect to workability issues, particularly in regards to keeping the resultant system from being too fragile to be effectively deployed and maintained. If practical experience is worth anything, I don't believe that namespacing the current IMA implementation is the optimum path forward. With respect to developing operationally relevant trusted platforms, the objective needs to be modeling the behavior of namespaces spawned from a known root behavior. The current IMA implementation provides a great deal of relevant infrastructure, but as these conversations have suggested, namespacing the current implementation is problematic given how entangled it has become with existing kernel infrastructure. What is needed is something far simpler that delegates, on the basis of a namespace, security policy to something other then the kernel, consistent with what we have learned about policy over the last 29+ years of Linux development. With respect to roots of trust, I don't think TPM's/fTPM's, virtual or otherwise, are going to be the relevant technology moving forward, although they will be part of the picture. Mimi has another post down thread that I will provide some more direct reflections on all of this for whatever value they may have. > Mimi Have a good day. Dr. Greg As always, Dr. Greg Wettstein, Ph.D, Worker Autonomously self-defensive Enjellic Systems Development, LLC IOT platforms and edge devices. 4206 N. 19th Ave. Fargo, ND 58102 PH: 701-281-1686 EMAIL: dg@enjellic.com ------------------------------------------------------------------------------ "I had far rather walk, as I do, in daily terror of eternity, than feel that this was only a children's game in which all of the contestants would get equally worthless prizes in the end." -- T. S. Elliot
On Wed, Sep 02, 2020 at 03:54:58PM -0400, Mimi Zohar wrote: Good morning, I hope the weekend is going well for everyone. A follow on to my previous e-mail regarding what 'namespaced IMA' should look like. > On Tue, 2020-08-18 at 18:49 +0200, Christian Brauner wrote: > > On Tue, Aug 18, 2020 at 05:20:07PM +0200, krzysztof.struczynski@huawei.com wrote: > > > From: Krzysztof Struczynski <krzysztof.struczynski@huawei.com> > > > IMA has not been designed to work with containers. It handles > > > every process in the same way, and it cannot distinguish if a > > > process belongs to a container or not. > > > > > > Containers use namespaces to make it appear to the processes in > > > the containers that they have their own isolated instance of the > > > global resource. For IMA as well, it is desirable to let > > > processes in the > > IMA is brought up on a regular basis with "we want to have this" for > > years and then non-one seems to really care enough. I don't think it is a matter of lack of interest or not caring. The challenge becomes whether or not a business case exists for expending the resources and navigating the challenges needed to advance infrastructure for inclusion in the kernel. > There is a lot of interest in IMA namespacing, but the question > always comes back to how to enable it. Refer to > https://kernsec.org/wiki/index.php/IMA_Namespacing_design_considerations > for Stefan's analysis. As I noted in my previous e-mail, I believe the path forward is not to figure out how to address the rather complex and invasive issue of how to namespace IMA, but instead, needs to be what a flexible 'next-generation' architecture for platform behavioral assessment looks like. In a larger context, I believe the future for security is going to involve at a minimum the kernel, and more likely, something tightly coupled to the kernel, making active decisions on whether or not a behavior that the kernel is contemplating mediating is consistent with platform or container security policy. To frame this a bit, the well understood role of the kernel with respect to security is to mediate 'Turing Events', or Actor/Subject (A/S) interactions. Both DAC and MAC are based on this concept with the interface between an Actor and Subject being a security 'gate'. Given this model, the most simplistic and direct path forward is to provide a namespace capable method of exporting a description of the identity parameters that characterize the entities involved in an A/S interaction. The kernel, or as I previously suggested as more likely moving forward, a closely linked entity can then make a decision as to whether or not the behavior should be allowed. FWIW, as an example of the minimal impact of this method, here is the diffstat of such an implementation: --------------------------------------------------------------------------- arch/x86/entry/syscalls/syscall_32.tbl | 2 + arch/x86/entry/syscalls/syscall_64.tbl | 2 + fs/proc/array.c | 7 + fs/proc/namespaces.c | 4 + include/linux/ima.h | 27 + include/linux/nsproxy.h | 2 + include/linux/proc_ns.h | 2 + include/linux/sched.h | 3 + include/linux/syscalls.h | 6 + include/uapi/asm-generic/unistd.h | 7 +- include/uapi/linux/sched.h | 1 + kernel/fork.c | 5 +- kernel/nsproxy.c | 18 +- kernel/sys_ni.c | 4 + security/Kconfig | 1 + security/Makefile | 2 + Security/ai/Kconfig | 12 + security/ai/Makefile | 3 + security/ai/ai.c | 137 ++ security/integrity/iint.c | 5 + security/integrity/ima/Makefile | 2 +- security/integrity/ima/ima.h | 17 + security/integrity/ima/ima_api.c | 37 +- security/integrity/ima/ima_fs.c | 10 + security/integrity/ima/ima_identity.c | 2204 +++++++++++++++++++++++++++++ security/integrity/ima/ima_init.c | 6 +- security/integrity/ima/ima_main.c | 7 + security/integrity/ima/ima_policy.c | 74 +- security/integrity/ima/ima_queue.c | 10 +- security/integrity/ima/ima_template.c | 6 + security/integrity/ima/ima_template_lib.c | 71 + security/integrity/ima/ima_template_lib.h | 10 + security/integrity/integrity.h | 4 +- security/security.c | 1 + 34 files changed, 2684 insertions(+), 25 deletions(-) --------------------------------------------------------------------------- As can be seen, this was built out in the context of the IMA sub-system with the majority of the changes being encapsulated in one file. This includes all of the infrastructure needed for a Trusted Execution Environment (TEE) to enforce kernel security policy decisions. In addition to a container specific representation of the current behavioral state, each namespace exports via a sysfs pseudo-file, the following behavioral definition for each A/S interaction. exchange pid{1} event{cboot:/home/greg/runc} actor{uid=0, euid=0, suid=0, gid=0, egid=0, sgid=0, fsuid=0, fsgid=0, cap=0x3fffffffff} subject{uid=50, gid=50, mode=0100755, name_length=15, name=f0da604ff3f0a3e16163bc9d2f99bb9bcd70397d211b746d0104299972cc5505, s_id=sda1, s_uuid=1bfef8aaa45f4bcaa846640ae4547ddc, digest=791a7cf8dec2afe302836b974b3c0f7b0a5983f76d857aa97658ce09d54f60f8} Which provides the framework for implementing any number of policy decisions, of which integrity is only one element. We had initially used SGX to implement a TEE based enforcement engine, but given the direction of hardware support, we have largely shelved our SGX development efforts in favor of using a micro-controller based approach. Given what appears to be the direction for mobile devices, a collection of specialized harware linked by an OS, the notion of a separate entity making security policy decisions seems relevant. > I understand "containers" is not a kernel construct, but from my very > limited perspective, IMA namespacing only makes sense in the context of > a "container". The container owner may want to know which files have > been accessed/executed (measurements, remote attestation) and/or > constrain which files may be accessed/executed based on signatures > (appraisal). Trying to implement supportable and field maintainable 'trusted computing' is a fools errand without the notion of containerization of platform behavior. This is true whether the target is the cloud or endpoint/IOT class devices. It seems well understood, that while containers are not a first class kernel entity, the kernel takes responsibility for implementing compartmentalization of resources. It would seem that security event characterizations are consistent with that model. In addition, none of this works without developer support. Framing behavior assessment in the form of containers means that behavioral trajectory definitions for the containers can be a byproduct of standard DEVOP's pipelines. > > I'm highly skeptical of the value of ~2500 lines of code even if > > it includes a bunch of namespace boilerplate. It's yet another > > namespace, and yet another security framework. Why does IMA need > > to be a separate namespace? Keyrings are tied to user namespaces > > why can't IMA be? > In the context of a container, the measurement list and IMA/EVM > keyrings need to be setup before the first file is measured, > signature verified, or file hash included in the audit log. As I've noted previously, namespacing IMA is problematic, what is needed is something far simpler and more flexible that provides a framework for implementing policy outside of the kernel, or if in the kernel, in a highly customizable fashion. I think that it would be found that user namespaces bring too much baggage to the table. The most effective path forward in this venue would seem to be to bring forward the most simplistic, flexiable and uncomplicated mechanism possible. In this model, classic IMA would serve as a trust root on whose shoulders a security orchestration framework stands. > > I believe Eric has even pointed that out before. > > > > Eric, thoughts? > Any help with the above scenario would very be much appreciated. Hopefully the conversation will benefit from actual field experience with doing this sort of thing in a supportable fashion. The concept of 'trusted computing' has been around since the days when Dave Grawrock designed TXT, which is heavily linked to the heritage of IMA. The fact that effective solutions in widespread practice have not emerged, in the face of demonstrated need, suggests the need to develop new solution strategies. Just to be clear, we are not campaigning or advocating what we have done but are simply providing background for discussion. We haven't campaigned this approach given how complex the kernel development has become, particurlarly with respect to security infrastructure. Candidly, given the politics of security technology being viewed as 'constraining' user rights, I think that a lot of forthcoming security technology may end up being out of tree moving forward. > Mimi Best wishes for a productive week to everyone. Dr. Greg As always, Dr. Greg Wettstein, Ph.D, Worker Autonomously self-defensive Enjellic Systems Development, LLC IOT platforms and edge devices. 4206 N. 19th Ave. Fargo, ND 58102 PH: 701-281-1686 EMAIL: dg@enjellic.com ------------------------------------------------------------------------------ "A large number of the world's technical challenges have been solved. The far greater challenge lies in conveying an understanding of this to the world." -- Dr. Greg Wettstein Resurrection
On Mon, 2020-09-07 at 12:50 +0100, Luke Hinds wrote: > > Candidly, given the politics of security technology being viewed as > > 'constraining' user rights, I think that a lot of forthcoming security > > technology may end up being out of tree moving forward. > > > > I think it's prudent to look forward and plan diligently, but I would > not want perfect to be the enemy of good. Agreed. This isn't an abstract problem, but one that has already come up and, hopefully, has been addressed appropriately. > > I approach this more from a user's perspective. We are using IMA in > https://keylime.dev to measure a host and would like to measure > within a container too. It's the most common request we hear from our > users. > > Perhaps we all collaborate on a proposal extending Stefans work here: > https://kernsec.org/wiki/index.php/IMA_Namespacing_design_considerati > ons > > I have seen around 3-4 patches now get submitted, so work has been > done before, and as above, users are present too. We could then have > some consensus on how this should look and later patches might have > more success at landing. > > Would anyone be interested in this and have recommendations on how we > could approach this? When Roberto Sassu and Krzysztof Struczynski contacted me about the status of Stefan Berger's patch set, based on Yuqiong Sun's work, I was under the impression that they would be rebasing it on the latest kernel and going forward from there. Obviously things changed. I pointed out to them resolving the "IMA namespacing" issue would be the first thing that needs to be addressed. So here we are. Definitely, let's have this discussion. Mimi
On Mon, Sep 07, 2020 at 12:50:07PM +0100, Luke Hinds wrote: Good morning, I hope the week is going well for everyone. > On Sun, Sep 6, 2020 at 6:15 PM Dr. Greg <greg@enjellic.com> wrote: > > Just to be clear, we are not campaigning or advocating what we have > > done but are simply providing background for discussion. We haven't > > campaigned this approach given how complex the kernel development has > > become, particurlarly with respect to security infrastructure. > > > > Candidly, given the politics of security technology being viewed as > > 'constraining' user rights, I think that a lot of forthcoming security > > technology may end up being out of tree moving forward. > I think it's prudent to look forward and plan diligently, but I would not > want perfect to be the enemy of good. > > I approach this more from a user's perspective. We are using IMA in > https://keylime.dev to measure a host and would like to measure > within a container too. It's the most common request we hear from > our users. > > Perhaps we all collaborate on a proposal extending Stefans work here: > https://kernsec.org/wiki/index.php/IMA_Namespacing_design_considerations > > I have seen around 3-4 patches now get submitted, so work has been > done before, and as above, users are present too. We could then have > some consensus on how this should look and later patches might have > more success at landing. > > Would anyone be interested in this and have recommendations on how > we could approach this? Obviously everyone is interested in sharpening their own knives so the first challenge will be defining where this theme of measurement and attestation needs to go. Our focus in all of this is from a platform behavior modeling perspective. Our objective is to design platforms/containers that are capable of self-disciplining themselves in the event that they exhibit behavior inconsistent with the wishes of their designer. Container measurement trivially falls out of this model. With respect to measurement namespaces, the first problem to be addressed is what takes custody and responsibility for the measurement events. In classic IMA this is, of course, a TPM. In our model we use a Trusted Execution Environment (TEE) as this entity. The TEE makes a decision as to whether or not the kernel should label a context of execution as being a 'bad actor' if it indicates a desire to exhibit a behavior inconsistent with a previously defined model. As I noted previously we have an SGX based solution that provides this infrastructure but have designed and are moving to a micro-controller based alternative, given the fact that SGX is now moving to a 'cloud only' solution. One of the pain points in all of this appears to be whether or not a measurement stream from a container should feed into the root measurement of the platform or be fed into a measurement/monitoring domain that can be attested against the root measurement of the platform. Based on our experiences the latter model is the only one that is feasible or makes sense from an attestation perspective. So it would seem that a generic approach to directing the target of the measurement events would be the first objective. If there is interest we can make a copy of our patch available as it supports both models. > - Luke Have a good day. Dr. Greg As always, Dr. Greg Wettstein, Ph.D, Worker Autonomously self-defensive Enjellic Systems Development, LLC IOT platforms and edge devices. 4206 N. 19th Ave. Fargo, ND 58102 PH: 701-281-1686 EMAIL: dg@enjellic.com ------------------------------------------------------------------------------ "I created a hack to make the division come out right ... I was relieved because I thought I was coding wrong. Did you? It took a guy (Thomas Nicely) with a Ph.D. doing heavy research in computational number theory to find it, yet you found it while working on a game in QuickBasic?" -- Slashdot
> From: Mimi Zohar [mailto:zohar@linux.ibm.com] > Sent: Wednesday, September 2, 2020 8:53 PM > > > So I think this can work in the use case where the system owner is > > > responsible for doing the logging and attestation and the tenants just > > > trust the owner without requiring an attestation. However, in a multi- > > > tenant system you need a way for the attestation to be per-container > > > (because the combined list of who executed what would be a security > > > leak between tenants). Since we can't virtualise the PCRs without > > > introducing a vtpm this is going to require a vtpm infrastructure like > > > that used for virtual machines and then we can do IMA logging per > > > container. > > > > I agree and wonder if we should decouple the attestation trust model, > > which depends on the specific use case (e.g. multi/single tenant, > > public/private cloud), from the IMA logic of linking the measurements to > > the container. Indeed, attestation from within the container might require > > anchoring to a vTPM/vPCR and the current measurement tagging mechanism > can > > support several ways of anchoring them to a (virtual) root of trust. > > > > > I don't think the above has to be in your first patch set, we just have > > > to have an idea of how it could be done to show that nothing in this > > > patch set precludes a follow on from doing this. > > > > Given that virtualizing trust anchors seems like a separate problem in > > which industry consensus is not easy to reach for all use cases, an > > anchoring mechanism should probably be a separate IMA feature. > > Other trust anchors for "trusted keys" has been discussed, but I wasn't > aware of any discussion about other trust anchors for the IMA > measurement list. The IMA measurement list is very much tied to a TPM. > Agreed. I wouldn't consider anything else than the TPM in the IMA measurement list context. The anchoring mechanism mentioned above pertained to the possible extensions of the TPM anchor in the containerized environment, like the vTPM. > Including container measurements in the host measurement list, will > unnecessarily cause the host measurement list to grow. The decision of > what should and shouldn't be included in the host measurement list > shouldn't be defined by the container. > The container has no impact on the measurement list entries other than the ones related to the processes running within the container. This in turn, the same as for the original IMA, is defined by the (container's) policy, loaded on the container's creation. Best regards, Krzysztof > Mimi > >
> From: Mimi Zohar [mailto:zohar@linux.ibm.com] > Sent: Tuesday, September 8, 2020 4:03 PM > > > Candidly, given the politics of security technology being viewed as > > > 'constraining' user rights, I think that a lot of forthcoming security > > > technology may end up being out of tree moving forward. > > > > > > > I think it's prudent to look forward and plan diligently, but I would > > not want perfect to be the enemy of good. > > Agreed. This isn't an abstract problem, but one that has already come > up and, hopefully, has been addressed appropriately. > > > > > I approach this more from a user's perspective. We are using IMA in > > https://keylime.dev to measure a host and would like to measure > > within a container too. It's the most common request we hear from our > > users. > > > > Perhaps we all collaborate on a proposal extending Stefans work here: > > https://kernsec.org/wiki/index.php/IMA_Namespacing_design_considerati > > ons > > > > I have seen around 3-4 patches now get submitted, so work has been > > done before, and as above, users are present too. We could then have > > some consensus on how this should look and later patches might have > > more success at landing. > > > > Would anyone be interested in this and have recommendations on how we > > could approach this? > > When Roberto Sassu and Krzysztof Struczynski contacted me about the > status of Stefan Berger's patch set, based on Yuqiong Sun's work, I was > under the impression that they would be rebasing it on the latest > kernel and going forward from there. Obviously things changed. I > pointed out to them resolving the "IMA namespacing" issue would be the > first thing that needs to be addressed. So here we are. > The concept of the IMA namespace as a separate namespace, not attached to the user or mount namespace, remains the same as in the last set of Stefan's patches. The creation and configuration mechanism changed, partially because of the changes in the upstream kernel like extension of the CLONE_ flags, that facilitated other solutions. The main inspiration in this regard was the new time namespace. The implemented mechanism is intended to make the configuration of the IMA namespace as similar as possible to the upstream IMA implementation and allows to configure the new IMA namespace before any process enters that namespace, so the very first actions can be measured/appraised/audited. In this implementation many design points formulated by Stefan still stand. The significant difference in the presented design is the threat model. The actions of the host's root and any other user within the container are measured/appraised/audited according to the container's policy. However, every action that affects objects in the root namespace, is detected when processes from the root namespace access them. Best regards, Krzysztof > Definitely, let's have this discussion. > > Mimi
> From: Krzysztof Struczynski > Sent: Monday, September 14, 2020 2:08 PM > > When Roberto Sassu and Krzysztof Struczynski contacted me about the > > status of Stefan Berger's patch set, based on Yuqiong Sun's work, I was > > under the impression that they would be rebasing it on the latest > > kernel and going forward from there. Obviously things changed. I > > pointed out to them resolving the "IMA namespacing" issue would be the > > first thing that needs to be addressed. So here we are. > > > > The concept of the IMA namespace as a separate namespace, not attached to > the user or mount namespace, remains the same as in the last set of > Stefan's patches. The creation and configuration mechanism changed, > partially because of the changes in the upstream kernel like extension of > the CLONE_ flags, that facilitated other solutions. The main inspiration > in this regard was the new time namespace. > > The implemented mechanism is intended to make the configuration of the > IMA > namespace as similar as possible to the upstream IMA implementation and > allows to configure the new IMA namespace before any process enters that > namespace, so the very first actions can be measured/appraised/audited. > > In this implementation many design points formulated by Stefan still stand. > The significant difference in the presented design is the threat model. > The actions of the host's root and any other user within the container are > measured/appraised/audited according to the container's policy. However, > every action that affects objects in the root namespace, is detected when > processes from the root namespace access them. Do you think that the above proposal addresses the aforementioned "IMA namespacing" issue? If it doesn't, would you please clarify what are the main, outstanding problems? > > Definitely, let's have this discussion. Shall we continue the discussion here, or in addition use a format similar to the Stefan's "drawing board": https://kernsec.org/wiki/index.php/IMA_Namespacing_design_considerations Best regards, Krzysztof Struczynski
On Mon, Oct 19, 2020 at 09:30:27AM +0000, Krzysztof Struczynski wrote: Good morning, I hope this note finds the weekend going well for everyone. > > The concept of the IMA namespace as a separate namespace, not > > attached to the user or mount namespace, remains the same as in > > the last set of Stefan's patches. The creation and configuration > > mechanism changed, partially because of the changes in the > > upstream kernel like extension of the CLONE_ flags, that > > facilitated other solutions. The main inspiration in this regard > > was the new time namespace. > > > > The implemented mechanism is intended to make the configuration of > > the IMA namespace as similar as possible to the upstream IMA > > implementation and allows to configure the new IMA namespace > > before any process enters that namespace, so the very first > > actions can be measured/appraised/audited. > > > > In this implementation many design points formulated by Stefan > > still stand. The significant difference in the presented design > > is the threat model. The actions of the host's root and any other > > user within the container are measured/appraised/audited according > > to the container's policy. However, every action that affects > > objects in the root namespace, is detected when processes from the > > root namespace access them. > Do you think that the above proposal addresses the aforementioned > "IMA namespacing" issue? If it doesn't, would you please clarify > what are the main, outstanding problems? From our perspective, a significant objective of the namespacing discussion needs to be considerations regarding how additional growth and sophistication of IMA as a sub-system will occur. IMA, if taken to its limit, resolves into the notion of modeling the behavior of a hardware platform, its operating system and the supported application stack. We believe the most important issue with respect to namespacing is to provide an opportunity to allow more sophisticated and capable models to be developed and implemented, without having the process unduely constrained by the realities of kernel development. Coupled with this issue is the fact that it doesn't seem reasonable to believe that TPM's are going to be the venue or root of trust for this modeling, for a variety of reasons, perhaps most principally the fact that they are a 'blackbox' that have not enjoyed universal trust. This is perhaps particularly relevant now that they are being implemented in firmware rather then actual hardware. The sophistication and security capabilities of micro-controllers that are being developed for the IOT security space make a case for developing open-source/architecture security co-processors that implement the modeling and root of trust for independent modeling/IMA namespaces. TPM's also implicitly constrain the modeling to be a function based on linear extension summing. It seems pretty clear that stochastic as well as deterministic models will be needed, particularly for more dynamic systems. So the optimum approach would seem to be for the namespace to have the option of implementing its own policy or to provide a mechanism for forwarding all of the Turing event characteristics to an entity that can implement the desired integrity or model policy. All of this would also seem to be consistent with the direction of the mobile market, which appears to be moving toward a model of an operating system that binds together multiple co-processors or functional units. IMA, in this model, is a separate functional entity resonsible for interpreting and disciplining kernel behavior. > > > Definitely, let's have this discussion. > Shall we continue the discussion here, or in addition use a format similar > to the Stefan's "drawing board": > https://kernsec.org/wiki/index.php/IMA_Namespacing_design_considerations It has always been said that code speaks louder then words. So we are working through the process of cleaning up our implementation of the approach described above so that people can at least take a look at the architecture we are proposing. We don't have any belief that it would be suitable to survive the gauntlet of the kernel development process but we will offer it as a proof of concept of where we think all of this will, can and needs to end up going. We were able to bolt all of this on top of standard IMA in a reasonably straight forward fashion. Our initial implementation of an external modeling engine was based on SGX, which was remarkably useful for this purpose, albeit not well understood. Given the trajectory that technology has been placed on, we now have an implementation based on an ARM micro-controller as the external modeling/policy engine. While not quite as flexible as the SGX based approach it has a number of its own advantages, most principally ubiquity of implementation. Both approaches required no modification of the namespaced IMA implementation which we believe speaks to the flexibility of the approach. > Best regards, > Krzysztof Struczynski Hopefully the above reflections are helpful in steering progress of discussions, if not the price was certainly right. Best wishes for a productive week to everyone. Dr. Greg As always, Dr. Greg Wettstein, Ph.D, Worker Autonomously self-defensive Enjellic Systems Development, LLC IOT platforms and edge devices. 4206 N. 19th Ave. Fargo, ND 58102 PH: 701-281-1686 EMAIL: greg@enjellic.com ------------------------------------------------------------------------------ "Attendants at a service station in Eunice, Louisiana, handed more than $100 to a naked man who claimed to have a gun in his pocket." -- Unknown
From: Krzysztof Struczynski <krzysztof.struczynski@huawei.com> IMA has not been designed to work with containers. It handles every process in the same way, and it cannot distinguish if a process belongs to a container or not. Containers use namespaces to make it appear to the processes in the containers that they have their own isolated instance of the global resource. For IMA as well, it is desirable to let processes in the containers have IMA functionality independent from other containers: separate policy rules, measurement list, additional appraisal keys to verify the container image, separate audit logs. As previous work done in this area, this patch series introduces the IMA namespace, which is a separate instance of IMA to handle a subset of processes that belong to a container. The IMA namespace is created using clone3() or unshare() system calls. It is important to configure the namespace before any process appears in it, so that the new policy rules apply to the very first process in the namespace. To achieve that, the intermediate namespace ima_ns_for_children is used. It stores the configuration and becomes active on the next fork or when the first process enters it using the setns() system call. The similar process is used for the time namespace. The IMA namespace can be configured using the new securityfs directory entries that allow the user to set the policy rules, x509 certificate for appraisal and pass IMA configuration parameters normally included in the kernel command line parameters. It is intended to extend the clone_args to allow configuration from clone3() syscall. To inform other containers about an action made by a given container, a linked list of IMA namespaces has been implemented. The state/policy of those containers is evaluated to see if read-write violations (ToMToU, open-writer) should be recorded in the respective measurement list. Any change to the files shared across containers is recorded in the namespaced inode's integrity cache when the file is freed. To isolate the measurement list and the appraisal keys, the following decisions were made: The measurement list remains global, with the assumption that there is only one TPM in the system. Each IMA namespace has a unique ID, that allows to track measurements per IMA namespace. Processes in one namespace, have access only to the measurements from that namespace. The exception is made for the initial IMA namespace, whose processes have access to all entries. The appraisal keys of all IMA namespaces are stored in the IMA system keyring. Each key is linked to the respective IMA namespace using the key domain tag. The process that belongs to one IMA namespace, cannot add/replace/modify a key that belongs to another IMA namespace. To give access to the IMA securityfs directory entries to the container's owner, read and write (when needed) permissions are given to the "other" users not in the file's group 'o'. The access to the files is controlled by IMA, and given only to the user that has SYS_ADMIN capabilities in the user namespace owning the IMA namespace. The processes from one IMA namespace have access to the data from that namespace only. This mechanism can be changed in the future. The one alternative is to create per IMA namespace entries, similar to the AppArmour file system. This work is inspired by Stefan Berger's, Mehmet Kayaalp's, Yuqiong Sun's and Mimi Zohar's series of patches: https://lore.kernel.org/patchwork/cover/899419/ Patches are logically divided into 5 groups. That order is not yet reflected in the commit order. This will be fixed as soon as possible. 1. Base mechanism for the IMA namespace; patches: 1-3, 6-8, 15 Add a new IMA namespace. Add a new CLONE_NEWIMA flag. Create and configure IMA analogously to the time namespace, using the intermediate ima_ns_for_children. Add the IMA namespace to the IMA subsystem API. Create a list of active IMA namespaces. Add a reader counter to the integrity inode data to detect violations correctly. 2. Policy; patches: 4, 5, 9, 18, 20-22 Replace global policy data with the per IMA namespace policies. Record read-write violations (ToMToU, open-writer) across namespaces. Record modifications to the files shared across containers when the files are freed. Set the owning user namespace of the IMA namespace, to the user namespace of the first process born into the new IMA namespace. Remap IDs in the policy rules, if the rules were loaded before the user namespace mapping was defined. 3. IMA-measurement; patches: 10-14, 17, 29 Link measurement list entries to the respective IMA namespaces using the IMA namespace ID. Include the namespace ID in the digest entry lookup. Add a new measurement list template that includes IMA namespace ID. Add a dummy boot aggregate entry for non-root IMA namespaces. Show the measurement list data only for the IMA namespace the process belongs to, unless it is the root IMA namespace. 4. IMA-appraisal; patches: 23-28 Modify keyring search mechanism to include the key domain tag in the search criteria for both, direct lookup and the iterative search. Allow to set the key domain tag separately from the key type using the KEY_ALLOC* flags. Add the key domain to the IMA namespace, so that the key is linked to the namespace. Add the key domain tag to the integrity module's API. Use the new API to load the IMA namespace's key to the system IMA keyring. 5. Configuration; patches: 16, 19, 30 Add the new entries in the IMA securityfs directory. Parse and validate configuration data. Apply the new configuration when the first process is born in the new IMA namespace. Extend read/write permissions to the IMA securityfs entries to the other users not in the file's group 'o'. Allow access only to the users that have the SYS_ADMIN caps in the user namespace owning the given IMA namespace. Krzysztof Struczynski (30): ima: Introduce ima namespace ima: Add a list of the installed ima namespaces ima: Bind ima namespace to the file descriptor ima: Add ima policy related data to the ima namespace ima: Add methods for parsing ima policy configuration string ima: Add ima namespace to the ima subsystem APIs ima: Extend the APIs in the integrity subsystem ima: Add integrity inode related data to the ima namespace ima: Enable per ima namespace policy settings ima: Add ima namespace ID to the ima ML related structures ima: Keep track of the measurment list per ima namespace ima: Check ima namespace ID during digest entry lookup ima: Add a new ima template that includes namespace ID ima: Add per namespace view of the measurement list ima: Add a reader counter to the integrity inode data ima: Extend permissions to the ima securityfs entries ima: Add the violation counter to the namespace ima: Change the owning user namespace of the ima namespace if necessary ima: Configure the new ima namespace from securityfs ima: Parse per ima namespace policy file user namespace: Add function that checks if the UID map is defined ima: Remap IDs of subject based rules if necessary keys: Add domain tag to the keyring search criteria keys: Include key domain tag in the iterative search keys: Allow to set key domain tag separately from the key type ima: Add key domain to the ima namespace integrity: Add key domain tag to the search criteria ima: Load per ima namespace x509 certificate ima: Add dummy boot aggregate to per ima namespace measurement list ima: Set ML template per ima namespace crypto/asymmetric_keys/asymmetric_type.c | 20 +- fs/file_table.c | 6 +- fs/proc/namespaces.c | 4 + include/linux/digsig.h | 11 +- include/linux/fs.h | 3 + include/linux/ima.h | 99 ++- include/linux/integrity.h | 31 + include/linux/key-type.h | 1 + include/linux/key.h | 27 +- include/linux/nsproxy.h | 3 + include/linux/proc_ns.h | 5 +- include/linux/user_namespace.h | 7 + include/uapi/linux/sched.h | 1 + init/Kconfig | 12 + kernel/fork.c | 24 +- kernel/kexec_file.c | 7 + kernel/nsproxy.c | 34 +- kernel/ucount.c | 1 + kernel/user_namespace.c | 11 + lib/digsig.c | 11 +- security/integrity/digsig.c | 46 +- security/integrity/digsig_asymmetric.c | 20 +- security/integrity/iint.c | 126 +++- security/integrity/ima/Makefile | 1 + security/integrity/ima/ima.h | 134 +++- security/integrity/ima/ima_api.c | 31 +- security/integrity/ima/ima_appraise.c | 105 ++- security/integrity/ima/ima_asymmetric_keys.c | 12 +- security/integrity/ima/ima_fs.c | 272 ++++++- security/integrity/ima/ima_init.c | 47 +- security/integrity/ima/ima_kexec.c | 4 +- security/integrity/ima/ima_main.c | 323 +++++++-- security/integrity/ima/ima_ns.c | 718 +++++++++++++++++++ security/integrity/ima/ima_policy.c | 397 +++++++--- security/integrity/ima/ima_queue.c | 69 +- security/integrity/ima/ima_queue_keys.c | 11 +- security/integrity/ima/ima_template.c | 44 +- security/integrity/ima/ima_template_lib.c | 13 + security/integrity/ima/ima_template_lib.h | 2 + security/integrity/integrity.h | 42 +- security/keys/key.c | 20 + security/keys/keyring.c | 25 +- security/security.c | 2 +- 43 files changed, 2405 insertions(+), 377 deletions(-) create mode 100644 security/integrity/ima/ima_ns.c base-commit: fc80c51fd4b23ec007e88d4c688f2cac1b8648e7 prerequisite-patch-id: 409c4abf4ee18e7d43eda995ff0db7879d3d0f5c