Menu
▾
▴
linux-ima-devel
|
From: James B. <Jam...@Ha...> - 2017-07-25 20:31:50
|
On Tue, 2017-07-25 at 15:48 -0400, Mimi Zohar wrote: > On Tue, 2017-07-25 at 12:08 -0700, James Bottomley wrote: > > > > On Tue, 2017-07-25 at 14:04 -0500, Serge E. Hallyn wrote: > > > > > > On Tue, Jul 25, 2017 at 11:49:14AM -0700, James Bottomley wrote: > > > > > > > > > > > > On Tue, 2017-07-25 at 12:53 -0500, Serge E. Hallyn wrote: [...] > > > > the latter, it does seem that this should be a property of > > > > either the mount or user ns rather than its own separate ns. I > > > > could see a use where even a container might want multiple ima > > > > keyrings within the container (say containerised apache service > > > > with multiple tenants), so instinct tells me that mount ns is > > > > the correct granularity for this. > > > > > > I wonder whether we could use echo 1 > > > > /sys/kernel/security/ima/newns > > > as the trigger for requesting a new ima ns on the next > > > clone(CLONE_NEWNS). > > > > I could go with that, but what about the trigger being installing > > or updating the keyring? That's the only operation that needs > > namespace separation, so on mount ns clone, you get a pointer to > > the old ima_ns until you do something that requires a new key, > > which then triggers the copy of the namespace and installing it? > > It isn't just the keyrings that need to be namespaced, but the > measurement list and policy as well. OK, so trigger to do a just in time copy would be new key or new policy. The measurement list is basically just a has of a file taken at a policy point. Presumably it doesn't change if we install a new policy or key, so it sounds like it should be tied to the underlying mount point? I'm thinking if we set up a hundred mount ns each pointing to /var/container, we don't want /var/container/bin/something to have 100 separate measurements each with the same hash. > IMA-measurement, IMA-appraisal and IMA-audit are all policy based. > > As soon as the namespace starts, measurements should be added to the > namespace specific measurement list, not it's parent. Would the measurement in a child namespace yield a different measurement in the parent? I'm thinking not, because a measurement is just a hash. Now if the signature of the hash in the xattr needs a different key, obviously this differs, but the expensive part (computing the hash) shouldn't change. James > Mimi > > _______________________________________________ > Containers mailing list > Con...@li... > https://lists.linuxfoundation.org/mailman/listinfo/containers |
|
From: Mimi Z. <zo...@li...> - 2017-07-25 20:51:45
|
On Tue, 2017-07-25 at 13:31 -0700, James Bottomley wrote: > On Tue, 2017-07-25 at 15:48 -0400, Mimi Zohar wrote: > > On Tue, 2017-07-25 at 12:08 -0700, James Bottomley wrote: > > > > > > On Tue, 2017-07-25 at 14:04 -0500, Serge E. Hallyn wrote: > > > > > > > > On Tue, Jul 25, 2017 at 11:49:14AM -0700, James Bottomley wrote: > > > > > > > > > > > > > > > On Tue, 2017-07-25 at 12:53 -0500, Serge E. Hallyn wrote: > [...] > > > > > the latter, it does seem that this should be a property of > > > > > either the mount or user ns rather than its own separate ns. I > > > > > could see a use where even a container might want multiple ima > > > > > keyrings within the container (say containerised apache service > > > > > with multiple tenants), so instinct tells me that mount ns is > > > > > the correct granularity for this. > > > > > > > > I wonder whether we could use echo 1 > > > > > /sys/kernel/security/ima/newns > > > > as the trigger for requesting a new ima ns on the next > > > > clone(CLONE_NEWNS). > > > > > > I could go with that, but what about the trigger being installing > > > or updating the keyring? That's the only operation that needs > > > namespace separation, so on mount ns clone, you get a pointer to > > > the old ima_ns until you do something that requires a new key, > > > which then triggers the copy of the namespace and installing it? > > > > It isn't just the keyrings that need to be namespaced, but the > > measurement list and policy as well. > > OK, so trigger to do a just in time copy would be new key or new > policy. The kernel has support for an initial builtin policy, which can be later replaced. The builtin policies, if specified, begin measuring files very early in the boot process. Similarly for namespace, we would want to start measuring files as early as possible. > The measurement list is basically just a has of a file taken > at a policy point. Presumably it doesn't change if we install a new > policy or key, so it sounds like it should be tied to the underlying > mount point? I'm thinking if we set up a hundred mount ns each > pointing to /var/container, we don't want /var/container/bin/something > to have 100 separate measurements each with the same hash. > > > IMA-measurement, IMA-appraisal and IMA-audit are all policy based. > > > > As soon as the namespace starts, measurements should be added to the > > namespace specific measurement list, not it's parent. > > Would the measurement in a child namespace yield a different > measurement in the parent? I'm thinking not, because a measurement is > just a hash. Now if the signature of the hash in the xattr needs a > different key, obviously this differs, but the expensive part > (computing the hash) shouldn't change. Depending on the measurement list template format (eg. ima-ng, ima- sig, custom template format), the template data would contain the file hash, but in addition it might contain the file signature. As keys could be namespace specific, the file signatures could be different. Mimi |
|
From: Serge E. H. <se...@ha...> - 2017-07-25 20:46:23
|
On Tue, Jul 25, 2017 at 04:11:29PM -0400, Stefan Berger wrote: > On 07/25/2017 03:48 PM, Mimi Zohar wrote: > >On Tue, 2017-07-25 at 12:08 -0700, James Bottomley wrote: > >>On Tue, 2017-07-25 at 14:04 -0500, Serge E. Hallyn wrote: > >>>On Tue, Jul 25, 2017 at 11:49:14AM -0700, James Bottomley wrote: > >>>>On Tue, 2017-07-25 at 12:53 -0500, Serge E. Hallyn wrote: > >>>>>On Thu, Jul 20, 2017 at 06:50:29PM -0400, Mehmet Kayaalp wrote: > >>>>>> > >>>>>>From: Yuqiong Sun <su...@us...> > >>>>>> > >>>>>>Add new CONFIG_IMA_NS config option. Let clone() create a new > >>>>>>IMA namespace upon CLONE_NEWNS flag. Add ima_ns data structure > >>>>>>in nsproxy. ima_ns is allocated and freed upon IMA namespace > >>>>>>creation and exit. Currently, the ima_ns contains no useful IMA > >>>>>>data but only a dummy interface. This patch creates the > >>>>>>framework for namespacing the different aspects of IMA (eg. > >>>>>>IMA-audit, IMA-measurement, IMA-appraisal). > >>>>>> > >>>>>>Signed-off-by: Yuqiong Sun <su...@us...> > >>>>>> > >>>>>>Changelog: > >>>>>>* Use CLONE_NEWNS instead of a new CLONE_NEWIMA flag > >>>>>Hi, > >>>>> > >>>>>So this means that every mount namespace clone will clone a new > >>>>>IMA namespace. Is that really ok? > >>>>Based on what: space concerns (struct ima_ns is reasonably small)? > >>>>or whether tying it to the mount namespace is the correct thing to > >>>>do. On > >>>Mostly the latter. The other would be not so much space concerns as > >>>time concerns. Many things use new mounts namespaces, and we > >>>wouldn't want multiple IMA calls on all file accesses by all of > >>>those. > >>> > >>>>the latter, it does seem that this should be a property of either > >>>>the mount or user ns rather than its own separate ns. I could see > >>>>a use where even a container might want multiple ima keyrings > >>>>within the container (say containerised apache service with > >>>>multiple tenants), so instinct tells me that mount ns is the > >>>>correct granularity for this. > >>>I wonder whether we could use echo 1 > /sys/kernel/security/ima/newns > >>>as the trigger for requesting a new ima ns on the next > >>>clone(CLONE_NEWNS). > >>I could go with that, but what about the trigger being installing or > >>updating the keyring? That's the only operation that needs namespace > >>separation, so on mount ns clone, you get a pointer to the old ima_ns > >>until you do something that requires a new key, which then triggers the > >>copy of the namespace and installing it? > >It isn't just the keyrings that need to be namespaced, but the > >measurement list and policy as well. > > > >IMA-measurement, IMA-appraisal and IMA-audit are all policy based. > > > >As soon as the namespace starts, measurements should be added to the > >namespace specific measurement list, not it's parent. Shouldn't it be both? If not, then it seems to me this must be tied to user namespace. > IMA is about measuring things, logging what was executed, and > finally someone looking at the measurement log and detecting > 'things'. So at least one attack that needs to be prevented is a > malicious person opening an IMA namespace, executing something > malicious, and not leaving any trace on the host because all the > logs went into the measurement list of the IMA namespace, which > disappeared. That said, I am wondering whether there has to be a > minimum set of namespaces (PID, UTS) providing enough 'isolation' > that someone may actually open an IMA namespace and run their code. > To avoid leaving no traces one could argue to implement recursive > logging, so something that is logged inside the namespace will be > detected in all parent containers up to the init_ima_ns (host) > because it's logged (and TPM extended) there as well. The challenge > with that is that logging costs memory and that can be abused as > well until the machine needs a reboot... I guess the solution could > be requesting an IMA namespace in one way or another but requiring > several other namespace flags in the clone() to actually 'get' it. > Jumping namespaces with setns() may have to be restricted as well > once there is an IMA namespace. Wait. So if I create a new IMA namespace, the things I run in that namespace are not subject to the parent namespace policy? -serge |
|
From: Stefan B. <st...@li...> - 2017-07-25 21:35:56
|
On 07/25/2017 04:46 PM, Serge E. Hallyn wrote:
> On Tue, Jul 25, 2017 at 04:11:29PM -0400, Stefan Berger wrote:
>> On 07/25/2017 03:48 PM, Mimi Zohar wrote:
>>> On Tue, 2017-07-25 at 12:08 -0700, James Bottomley wrote:
>>>> On Tue, 2017-07-25 at 14:04 -0500, Serge E. Hallyn wrote:
>>>>> On Tue, Jul 25, 2017 at 11:49:14AM -0700, James Bottomley wrote:
>>>>>> On Tue, 2017-07-25 at 12:53 -0500, Serge E. Hallyn wrote:
>>>>>>> On Thu, Jul 20, 2017 at 06:50:29PM -0400, Mehmet Kayaalp wrote:
>>>>>>>> From: Yuqiong Sun <su...@us...>
>>>>>>>>
>>>>>>>> Add new CONFIG_IMA_NS config option. Let clone() create a new
>>>>>>>> IMA namespace upon CLONE_NEWNS flag. Add ima_ns data structure
>>>>>>>> in nsproxy. ima_ns is allocated and freed upon IMA namespace
>>>>>>>> creation and exit. Currently, the ima_ns contains no useful IMA
>>>>>>>> data but only a dummy interface. This patch creates the
>>>>>>>> framework for namespacing the different aspects of IMA (eg.
>>>>>>>> IMA-audit, IMA-measurement, IMA-appraisal).
>>>>>>>>
>>>>>>>> Signed-off-by: Yuqiong Sun <su...@us...>
>>>>>>>>
>>>>>>>> Changelog:
>>>>>>>> * Use CLONE_NEWNS instead of a new CLONE_NEWIMA flag
>>>>>>> Hi,
>>>>>>>
>>>>>>> So this means that every mount namespace clone will clone a new
>>>>>>> IMA namespace. Is that really ok?
>>>>>> Based on what: space concerns (struct ima_ns is reasonably small)?
>>>>>> or whether tying it to the mount namespace is the correct thing to
>>>>>> do. On
>>>>> Mostly the latter. The other would be not so much space concerns as
>>>>> time concerns. Many things use new mounts namespaces, and we
>>>>> wouldn't want multiple IMA calls on all file accesses by all of
>>>>> those.
>>>>>
>>>>>> the latter, it does seem that this should be a property of either
>>>>>> the mount or user ns rather than its own separate ns. I could see
>>>>>> a use where even a container might want multiple ima keyrings
>>>>>> within the container (say containerised apache service with
>>>>>> multiple tenants), so instinct tells me that mount ns is the
>>>>>> correct granularity for this.
>>>>> I wonder whether we could use echo 1 > /sys/kernel/security/ima/newns
>>>>> as the trigger for requesting a new ima ns on the next
>>>>> clone(CLONE_NEWNS).
>>>> I could go with that, but what about the trigger being installing or
>>>> updating the keyring? That's the only operation that needs namespace
>>>> separation, so on mount ns clone, you get a pointer to the old ima_ns
>>>> until you do something that requires a new key, which then triggers the
>>>> copy of the namespace and installing it?
>>> It isn't just the keyrings that need to be namespaced, but the
>>> measurement list and policy as well.
>>>
>>> IMA-measurement, IMA-appraisal and IMA-audit are all policy based.
>>>
>>> As soon as the namespace starts, measurements should be added to the
>>> namespace specific measurement list, not it's parent.
> Shouldn't it be both?
>
> If not, then it seems to me this must be tied to user namespace.
>
>> IMA is about measuring things, logging what was executed, and
>> finally someone looking at the measurement log and detecting
>> 'things'. So at least one attack that needs to be prevented is a
>> malicious person opening an IMA namespace, executing something
>> malicious, and not leaving any trace on the host because all the
>> logs went into the measurement list of the IMA namespace, which
>> disappeared. That said, I am wondering whether there has to be a
>> minimum set of namespaces (PID, UTS) providing enough 'isolation'
>> that someone may actually open an IMA namespace and run their code.
>> To avoid leaving no traces one could argue to implement recursive
>> logging, so something that is logged inside the namespace will be
>> detected in all parent containers up to the init_ima_ns (host)
>> because it's logged (and TPM extended) there as well. The challenge
>> with that is that logging costs memory and that can be abused as
>> well until the machine needs a reboot... I guess the solution could
>> be requesting an IMA namespace in one way or another but requiring
>> several other namespace flags in the clone() to actually 'get' it.
>> Jumping namespaces with setns() may have to be restricted as well
>> once there is an IMA namespace.
> Wait. So if I create a new IMA namespace, the things I run in
> that namespace are not subject to the parent namespace policy?
We would treat the IMA namespace policy independently of the host
policy. A user can sign his containers' files with his own keys, upload
the container to the cloud and run them with keys that are different
than those of the host. The keys (actually certs) would be found in the
container, same for the policy.
Stefan
>
> -serge
>
|
|
From: Mimi Z. <zo...@li...> - 2017-07-25 20:59:33
|
On Tue, 2017-07-25 at 15:46 -0500, Serge E. Hallyn wrote: > On Tue, Jul 25, 2017 at 04:11:29PM -0400, Stefan Berger wrote: > > On 07/25/2017 03:48 PM, Mimi Zohar wrote: > > >On Tue, 2017-07-25 at 12:08 -0700, James Bottomley wrote: > > >>On Tue, 2017-07-25 at 14:04 -0500, Serge E. Hallyn wrote: > > >>>On Tue, Jul 25, 2017 at 11:49:14AM -0700, James Bottomley wrote: > > >>>>On Tue, 2017-07-25 at 12:53 -0500, Serge E. Hallyn wrote: > > >>>>>On Thu, Jul 20, 2017 at 06:50:29PM -0400, Mehmet Kayaalp wrote: > > >>>>>> > > >>>>>>From: Yuqiong Sun <su...@us...> > > >>>>>> > > >>>>>>Add new CONFIG_IMA_NS config option. Let clone() create a new > > >>>>>>IMA namespace upon CLONE_NEWNS flag. Add ima_ns data structure > > >>>>>>in nsproxy. ima_ns is allocated and freed upon IMA namespace > > >>>>>>creation and exit. Currently, the ima_ns contains no useful IMA > > >>>>>>data but only a dummy interface. This patch creates the > > >>>>>>framework for namespacing the different aspects of IMA (eg. > > >>>>>>IMA-audit, IMA-measurement, IMA-appraisal). > > >>>>>> > > >>>>>>Signed-off-by: Yuqiong Sun <su...@us...> > > >>>>>> > > >>>>>>Changelog: > > >>>>>>* Use CLONE_NEWNS instead of a new CLONE_NEWIMA flag > > >>>>>Hi, > > >>>>> > > >>>>>So this means that every mount namespace clone will clone a new > > >>>>>IMA namespace. Is that really ok? > > >>>>Based on what: space concerns (struct ima_ns is reasonably small)? > > >>>>or whether tying it to the mount namespace is the correct thing to > > >>>>do. On > > >>>Mostly the latter. The other would be not so much space concerns as > > >>>time concerns. Many things use new mounts namespaces, and we > > >>>wouldn't want multiple IMA calls on all file accesses by all of > > >>>those. > > >>> > > >>>>the latter, it does seem that this should be a property of either > > >>>>the mount or user ns rather than its own separate ns. I could see > > >>>>a use where even a container might want multiple ima keyrings > > >>>>within the container (say containerised apache service with > > >>>>multiple tenants), so instinct tells me that mount ns is the > > >>>>correct granularity for this. > > >>>I wonder whether we could use echo 1 > /sys/kernel/security/ima/newns > > >>>as the trigger for requesting a new ima ns on the next > > >>>clone(CLONE_NEWNS). > > >>I could go with that, but what about the trigger being installing or > > >>updating the keyring? That's the only operation that needs namespace > > >>separation, so on mount ns clone, you get a pointer to the old ima_ns > > >>until you do something that requires a new key, which then triggers the > > >>copy of the namespace and installing it? > > >It isn't just the keyrings that need to be namespaced, but the > > >measurement list and policy as well. > > > > > >IMA-measurement, IMA-appraisal and IMA-audit are all policy based. > > > > > >As soon as the namespace starts, measurements should be added to the > > >namespace specific measurement list, not it's parent. > > Shouldn't it be both? The policy defines which files are measured. The namespace policy could be different than it's parent's policy, and the parent's policy could be different than the native policy. Basically, file measurements need to be added to the namespace measurement list, recursively, up to the native measurement list. Mimi > > If not, then it seems to me this must be tied to user namespace. > > > IMA is about measuring things, logging what was executed, and > > finally someone looking at the measurement log and detecting > > 'things'. So at least one attack that needs to be prevented is a > > malicious person opening an IMA namespace, executing something > > malicious, and not leaving any trace on the host because all the > > logs went into the measurement list of the IMA namespace, which > > disappeared. That said, I am wondering whether there has to be a > > minimum set of namespaces (PID, UTS) providing enough 'isolation' > > that someone may actually open an IMA namespace and run their code. > > To avoid leaving no traces one could argue to implement recursive > > logging, so something that is logged inside the namespace will be > > detected in all parent containers up to the init_ima_ns (host) > > because it's logged (and TPM extended) there as well. The challenge > > with that is that logging costs memory and that can be abused as > > well until the machine needs a reboot... I guess the solution could > > be requesting an IMA namespace in one way or another but requiring > > several other namespace flags in the clone() to actually 'get' it. > > Jumping namespaces with setns() may have to be restricted as well > > once there is an IMA namespace. > > Wait. So if I create a new IMA namespace, the things I run in > that namespace are not subject to the parent namespace policy? |
|
From: Serge E. H. <se...@ha...> - 2017-07-25 21:08:02
|
On Tue, Jul 25, 2017 at 04:57:57PM -0400, Mimi Zohar wrote: > On Tue, 2017-07-25 at 15:46 -0500, Serge E. Hallyn wrote: > > On Tue, Jul 25, 2017 at 04:11:29PM -0400, Stefan Berger wrote: > > > On 07/25/2017 03:48 PM, Mimi Zohar wrote: > > > >On Tue, 2017-07-25 at 12:08 -0700, James Bottomley wrote: > > > >>On Tue, 2017-07-25 at 14:04 -0500, Serge E. Hallyn wrote: > > > >>>On Tue, Jul 25, 2017 at 11:49:14AM -0700, James Bottomley wrote: > > > >>>>On Tue, 2017-07-25 at 12:53 -0500, Serge E. Hallyn wrote: > > > >>>>>On Thu, Jul 20, 2017 at 06:50:29PM -0400, Mehmet Kayaalp wrote: > > > >>>>>> > > > >>>>>>From: Yuqiong Sun <su...@us...> > > > >>>>>> > > > >>>>>>Add new CONFIG_IMA_NS config option. Let clone() create a new > > > >>>>>>IMA namespace upon CLONE_NEWNS flag. Add ima_ns data structure > > > >>>>>>in nsproxy. ima_ns is allocated and freed upon IMA namespace > > > >>>>>>creation and exit. Currently, the ima_ns contains no useful IMA > > > >>>>>>data but only a dummy interface. This patch creates the > > > >>>>>>framework for namespacing the different aspects of IMA (eg. > > > >>>>>>IMA-audit, IMA-measurement, IMA-appraisal). > > > >>>>>> > > > >>>>>>Signed-off-by: Yuqiong Sun <su...@us...> > > > >>>>>> > > > >>>>>>Changelog: > > > >>>>>>* Use CLONE_NEWNS instead of a new CLONE_NEWIMA flag > > > >>>>>Hi, > > > >>>>> > > > >>>>>So this means that every mount namespace clone will clone a new > > > >>>>>IMA namespace. Is that really ok? > > > >>>>Based on what: space concerns (struct ima_ns is reasonably small)? > > > >>>>or whether tying it to the mount namespace is the correct thing to > > > >>>>do. On > > > >>>Mostly the latter. The other would be not so much space concerns as > > > >>>time concerns. Many things use new mounts namespaces, and we > > > >>>wouldn't want multiple IMA calls on all file accesses by all of > > > >>>those. > > > >>> > > > >>>>the latter, it does seem that this should be a property of either > > > >>>>the mount or user ns rather than its own separate ns. I could see > > > >>>>a use where even a container might want multiple ima keyrings > > > >>>>within the container (say containerised apache service with > > > >>>>multiple tenants), so instinct tells me that mount ns is the > > > >>>>correct granularity for this. > > > >>>I wonder whether we could use echo 1 > /sys/kernel/security/ima/newns > > > >>>as the trigger for requesting a new ima ns on the next > > > >>>clone(CLONE_NEWNS). > > > >>I could go with that, but what about the trigger being installing or > > > >>updating the keyring? That's the only operation that needs namespace > > > >>separation, so on mount ns clone, you get a pointer to the old ima_ns > > > >>until you do something that requires a new key, which then triggers the > > > >>copy of the namespace and installing it? > > > >It isn't just the keyrings that need to be namespaced, but the > > > >measurement list and policy as well. > > > > > > > >IMA-measurement, IMA-appraisal and IMA-audit are all policy based. > > > > > > > >As soon as the namespace starts, measurements should be added to the > > > >namespace specific measurement list, not it's parent. > > > > Shouldn't it be both? > > The policy defines which files are measured. The namespace policy > could be different than it's parent's policy, and the parent's policy > could be different than the native policy. Basically, file > measurements need to be added to the namespace measurement list, > recursively, up to the native measurement list. Yes, but if a task t1 is in namespace ns2 which is a child of namespace ns1, and it accesses a file which ns1's policy says must be measured, then will ns1's required measurement happen (and be appended to the ns1 measurement list), whether or not ns2's policy requires it? |
|
From: Mimi Z. <zo...@li...> - 2017-07-25 21:29:13
|
On Tue, 2017-07-25 at 16:08 -0500, Serge E. Hallyn wrote:
> On Tue, Jul 25, 2017 at 04:57:57PM -0400, Mimi Zohar wrote:
> > On Tue, 2017-07-25 at 15:46 -0500, Serge E. Hallyn wrote:
> > > On Tue, Jul 25, 2017 at 04:11:29PM -0400, Stefan Berger wrote:
> > > > On 07/25/2017 03:48 PM, Mimi Zohar wrote:
> > > > >On Tue, 2017-07-25 at 12:08 -0700, James Bottomley wrote:
> > > > >>On Tue, 2017-07-25 at 14:04 -0500, Serge E. Hallyn wrote:
> > > > >>>On Tue, Jul 25, 2017 at 11:49:14AM -0700, James Bottomley wrote:
> > > > >>>>On Tue, 2017-07-25 at 12:53 -0500, Serge E. Hallyn wrote:
> > > > >>>>>On Thu, Jul 20, 2017 at 06:50:29PM -0400, Mehmet Kayaalp wrote:
> > > > >>>>>>
> > > > >>>>>>From: Yuqiong Sun <su...@us...>
> > > > >>>>>>
> > > > >>>>>>Add new CONFIG_IMA_NS config option. Let clone() create a new
> > > > >>>>>>IMA namespace upon CLONE_NEWNS flag. Add ima_ns data structure
> > > > >>>>>>in nsproxy. ima_ns is allocated and freed upon IMA namespace
> > > > >>>>>>creation and exit. Currently, the ima_ns contains no useful IMA
> > > > >>>>>>data but only a dummy interface. This patch creates the
> > > > >>>>>>framework for namespacing the different aspects of IMA (eg.
> > > > >>>>>>IMA-audit, IMA-measurement, IMA-appraisal).
> > > > >>>>>>
> > > > >>>>>>Signed-off-by: Yuqiong Sun <su...@us...>
> > > > >>>>>>
> > > > >>>>>>Changelog:
> > > > >>>>>>* Use CLONE_NEWNS instead of a new CLONE_NEWIMA flag
> > > > >>>>>Hi,
> > > > >>>>>
> > > > >>>>>So this means that every mount namespace clone will clone a new
> > > > >>>>>IMA namespace. Is that really ok?
> > > > >>>>Based on what: space concerns (struct ima_ns is reasonably small)?
> > > > >>>>or whether tying it to the mount namespace is the correct thing to
> > > > >>>>do. On
> > > > >>>Mostly the latter. The other would be not so much space concerns as
> > > > >>>time concerns. Many things use new mounts namespaces, and we
> > > > >>>wouldn't want multiple IMA calls on all file accesses by all of
> > > > >>>those.
> > > > >>>
> > > > >>>>the latter, it does seem that this should be a property of either
> > > > >>>>the mount or user ns rather than its own separate ns. I could see
> > > > >>>>a use where even a container might want multiple ima keyrings
> > > > >>>>within the container (say containerised apache service with
> > > > >>>>multiple tenants), so instinct tells me that mount ns is the
> > > > >>>>correct granularity for this.
> > > > >>>I wonder whether we could use echo 1 > /sys/kernel/security/ima/newns
> > > > >>>as the trigger for requesting a new ima ns on the next
> > > > >>>clone(CLONE_NEWNS).
> > > > >>I could go with that, but what about the trigger being installing or
> > > > >>updating the keyring? That's the only operation that needs namespace
> > > > >>separation, so on mount ns clone, you get a pointer to the old ima_ns
> > > > >>until you do something that requires a new key, which then triggers the
> > > > >>copy of the namespace and installing it?
> > > > >It isn't just the keyrings that need to be namespaced, but the
> > > > >measurement list and policy as well.
> > > > >
> > > > >IMA-measurement, IMA-appraisal and IMA-audit are all policy based.
> > > > >
> > > > >As soon as the namespace starts, measurements should be added to the
> > > > >namespace specific measurement list, not it's parent.
> > >
> > > Shouldn't it be both?
> >
> > The policy defines which files are measured. The namespace policy
> > could be different than it's parent's policy, and the parent's policy
> > could be different than the native policy. Basically, file
> > measurements need to be added to the namespace measurement list,
> > recursively, up to the native measurement list.
>
> Yes, but if a task t1 is in namespace ns2 which is a child of namespace ns1,
> and it accesses a file which ns1's policy says must be measured, then will
> ns1's required measurement happen (and be appended to the ns1 measurement
> list), whether or not ns2's policy requires it?
Yes, as the file needs to be measured only in the ns1 policy, the
measurement would exist in the ns1 measurement list, but not in the
ns2 measurement list. The pseudo code snippet below might help.
do {
.
.
/* calculate file hash based on xattr algorithm */
collect_measurement()
/* recursively added to each namespace based on policy */
ima_store_measurement()
/* Based on the specific namespace policy and keys. */
if (!once) {
once = 1;
result = ima_appraise_measurement()
}
ima_audit_measurement()
} while ((ns = ns->parent));
return result;
Mimi
|
|
From: Magalhaes, G. (B. R&D-CL) <gui...@hp...> - 2017-07-27 12:51:45
|
> -----Original Message----- > From: Mimi Zohar [mailto:zo...@li...] > Sent: terça-feira, 25 de julho de 2017 18:29 > To: Serge E. Hallyn <se...@ha...> > Cc: Mehmet Kayaalp <mka...@cs...>; Yuqiong Sun > <sun...@gm...>; containers <con...@li...- > foundation.org>; linux-kernel <lin...@vg...>; David Safford > <dav...@ge...>; James Bottomley > <Jam...@Ha...>; linux-security-module <linux- > sec...@vg...>; ima-devel <linux-ima- > de...@li...>; Yuqiong Sun <su...@us...> > Subject: Re: [Linux-ima-devel] [RFC PATCH 1/5] ima: extend clone() with IMA > namespace support > > On Tue, 2017-07-25 at 16:08 -0500, Serge E. Hallyn wrote: > > On Tue, Jul 25, 2017 at 04:57:57PM -0400, Mimi Zohar wrote: > > > On Tue, 2017-07-25 at 15:46 -0500, Serge E. Hallyn wrote: > > > > On Tue, Jul 25, 2017 at 04:11:29PM -0400, Stefan Berger wrote: > > > > > On 07/25/2017 03:48 PM, Mimi Zohar wrote: > > > > > >On Tue, 2017-07-25 at 12:08 -0700, James Bottomley wrote: > > > > > >>On Tue, 2017-07-25 at 14:04 -0500, Serge E. Hallyn wrote: > > > > > >>>On Tue, Jul 25, 2017 at 11:49:14AM -0700, James Bottomley wrote: > > > > > >>>>On Tue, 2017-07-25 at 12:53 -0500, Serge E. Hallyn wrote: > > > > > >>>>>On Thu, Jul 20, 2017 at 06:50:29PM -0400, Mehmet Kayaalp > wrote: > > > > > >>>>>> > > > > > >>>>>>From: Yuqiong Sun <su...@us...> > > > > > >>>>>> > > > > > >>>>>>Add new CONFIG_IMA_NS config option. Let clone() create a > > > > > >>>>>>new IMA namespace upon CLONE_NEWNS flag. Add ima_ns > data > > > > > >>>>>>structure in nsproxy. ima_ns is allocated and freed upon > > > > > >>>>>>IMA namespace creation and exit. Currently, the ima_ns > > > > > >>>>>>contains no useful IMA data but only a dummy interface. > > > > > >>>>>>This patch creates the framework for namespacing the > different aspects of IMA (eg. > > > > > >>>>>>IMA-audit, IMA-measurement, IMA-appraisal). > > > > > >>>>>> > > > > > >>>>>>Signed-off-by: Yuqiong Sun <su...@us...> > > > > > >>>>>> > > > > > >>>>>>Changelog: > > > > > >>>>>>* Use CLONE_NEWNS instead of a new CLONE_NEWIMA flag > > > > > >>>>>Hi, > > > > > >>>>> > > > > > >>>>>So this means that every mount namespace clone will clone a > > > > > >>>>>new IMA namespace. Is that really ok? > > > > > >>>>Based on what: space concerns (struct ima_ns is reasonably > small)? > > > > > >>>>or whether tying it to the mount namespace is the correct > > > > > >>>>thing to do. On > > > > > >>>Mostly the latter. The other would be not so much space > > > > > >>>concerns as time concerns. Many things use new mounts > > > > > >>>namespaces, and we wouldn't want multiple IMA calls on all > > > > > >>>file accesses by all of those. > > > > > >>> > > > > > >>>>the latter, it does seem that this should be a property of > > > > > >>>>either the mount or user ns rather than its own separate ns. > > > > > >>>>I could see a use where even a container might want multiple > > > > > >>>>ima keyrings within the container (say containerised apache > > > > > >>>>service with multiple tenants), so instinct tells me that > > > > > >>>>mount ns is the correct granularity for this. > > > > > >>>I wonder whether we could use echo 1 > > > > > > >>>/sys/kernel/security/ima/newns as the trigger for requesting > > > > > >>>a new ima ns on the next clone(CLONE_NEWNS). > > > > > >>I could go with that, but what about the trigger being > > > > > >>installing or updating the keyring? That's the only operation > > > > > >>that needs namespace separation, so on mount ns clone, you get > > > > > >>a pointer to the old ima_ns until you do something that > > > > > >>requires a new key, which then triggers the copy of the namespace > and installing it? > > > > > >It isn't just the keyrings that need to be namespaced, but the > > > > > >measurement list and policy as well. > > > > > > > > > > > >IMA-measurement, IMA-appraisal and IMA-audit are all policy > based. > > > > > > > > > > > >As soon as the namespace starts, measurements should be added > > > > > >to the namespace specific measurement list, not it's parent. > > > > > > > > Shouldn't it be both? > > > > > > The policy defines which files are measured. The namespace policy > > > could be different than it's parent's policy, and the parent's > > > policy could be different than the native policy. Basically, file > > > measurements need to be added to the namespace measurement list, > > > recursively, up to the native measurement list. > > > > Yes, but if a task t1 is in namespace ns2 which is a child of > > namespace ns1, and it accesses a file which ns1's policy says must be > > measured, then will ns1's required measurement happen (and be > appended > > to the ns1 measurement list), whether or not ns2's policy requires it? > > Yes, as the file needs to be measured only in the ns1 policy, the > measurement would exist in the ns1 measurement list, but not in the > ns2 measurement list. The pseudo code snippet below might help. This algorithm is potentially extending a PCR in TPM multiple times for a single file event under a given namespace and duplicating entries. Any concerns with performance and memory footprint? What is the reason to adding a measurement to multiple namespace measurement lists? How are these lists going to be used? For Remote Attestation we need a single list (the native one) which has the complete list of measurements and in the same order they were extended in the TPM. Additionally, when namespaces are released, would the measurement list under that namespace disappear? How to store this list considering the namespaces may have a short life and be reused thousands of times? Should the native measurement list have all measurements triggered in the whole system, including the ones made under other namespaces? Following the algorithm below, if the file is not in the policy of the 'native'/initial namespace, the measurement is not added to the native measurement list. Each measurement entry in the list could have new fields to identify the namespace. Since the namespaces can be reused, a timestamp or others fields could be added to uniquely identify the namespace id. Regarding namespace hierarchy and IMA policy, we could assume that if a given namespace has no policy set, the policy of that namespace parent is applied and then the native/initial namespace should always have a set policy. > > do { > . > . > > /* calculate file hash based on xattr algorithm */ > collect_measurement() > > /* recursively added to each namespace based on policy */ > ima_store_measurement() > > /* Based on the specific namespace policy and keys. */ > if (!once) { > once = 1; > result = ima_appraise_measurement() > } > > ima_audit_measurement() > > } while ((ns = ns->parent)); > > return result; > > Mimi > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most engaging > tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Linux-ima-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-ima-devel |
|
From: Mimi Z. <zo...@li...> - 2017-07-27 14:42:22
|
On Thu, 2017-07-27 at 12:51 +0000, Magalhaes, Guilherme (Brazil R&D-
CL) wrote:
>
>
> > On Tue, 2017-07-25 at 16:08 -0500, Serge E. Hallyn wrote:
> > > On Tue, Jul 25, 2017 at 04:57:57PM -0400, Mimi Zohar wrote:
> > > > On Tue, 2017-07-25 at 15:46 -0500, Serge E. Hallyn wrote:
> > > > > On Tue, Jul 25, 2017 at 04:11:29PM -0400, Stefan Berger wrote:
> > > > > > On 07/25/2017 03:48 PM, Mimi Zohar wrote:
> > > > > > >On Tue, 2017-07-25 at 12:08 -0700, James Bottomley wrote:
> > > > > > >>On Tue, 2017-07-25 at 14:04 -0500, Serge E. Hallyn wrote:
> > > > > > >>>On Tue, Jul 25, 2017 at 11:49:14AM -0700, James Bottomley wrote:
> > > > > > >>>>On Tue, 2017-07-25 at 12:53 -0500, Serge E. Hallyn wrote:
> > > > > > >>>>>On Thu, Jul 20, 2017 at 06:50:29PM -0400, Mehmet Kayaalp
> > wrote:
> > > > > > >>>>>>
> > > > > > >>>>>>From: Yuqiong Sun <su...@us...>
> > > > > > >>>>>>
> > > > > > >>>>>>Add new CONFIG_IMA_NS config option. Let clone() create a
> > > > > > >>>>>>new IMA namespace upon CLONE_NEWNS flag. Add ima_ns
> > data
> > > > > > >>>>>>structure in nsproxy. ima_ns is allocated and freed upon
> > > > > > >>>>>>IMA namespace creation and exit. Currently, the ima_ns
> > > > > > >>>>>>contains no useful IMA data but only a dummy interface.
> > > > > > >>>>>>This patch creates the framework for namespacing the
> > different aspects of IMA (eg.
> > > > > > >>>>>>IMA-audit, IMA-measurement, IMA-appraisal).
> > > > > > >>>>>>
> > > > > > >>>>>>Signed-off-by: Yuqiong Sun <su...@us...>
> > > > > > >>>>>>
> > > > > > >>>>>>Changelog:
> > > > > > >>>>>>* Use CLONE_NEWNS instead of a new CLONE_NEWIMA flag
> > > > > > >>>>>Hi,
> > > > > > >>>>>
> > > > > > >>>>>So this means that every mount namespace clone will clone a
> > > > > > >>>>>new IMA namespace. Is that really ok?
> > > > > > >>>>Based on what: space concerns (struct ima_ns is reasonably
> > small)?
> > > > > > >>>>or whether tying it to the mount namespace is the correct
> > > > > > >>>>thing to do. On
> > > > > > >>>Mostly the latter. The other would be not so much space
> > > > > > >>>concerns as time concerns. Many things use new mounts
> > > > > > >>>namespaces, and we wouldn't want multiple IMA calls on all
> > > > > > >>>file accesses by all of those.
> > > > > > >>>
> > > > > > >>>>the latter, it does seem that this should be a property of
> > > > > > >>>>either the mount or user ns rather than its own separate ns.
> > > > > > >>>>I could see a use where even a container might want multiple
> > > > > > >>>>ima keyrings within the container (say containerised apache
> > > > > > >>>>service with multiple tenants), so instinct tells me that
> > > > > > >>>>mount ns is the correct granularity for this.
> > > > > > >>>I wonder whether we could use echo 1 >
> > > > > > >>>/sys/kernel/security/ima/newns as the trigger for requesting
> > > > > > >>>a new ima ns on the next clone(CLONE_NEWNS).
> > > > > > >>I could go with that, but what about the trigger being
> > > > > > >>installing or updating the keyring? That's the only operation
> > > > > > >>that needs namespace separation, so on mount ns clone, you get
> > > > > > >>a pointer to the old ima_ns until you do something that
> > > > > > >>requires a new key, which then triggers the copy of the namespace
> > and installing it?
> > > > > > >It isn't just the keyrings that need to be namespaced, but the
> > > > > > >measurement list and policy as well.
> > > > > > >
> > > > > > >IMA-measurement, IMA-appraisal and IMA-audit are all policy
> > based.
> > > > > > >
> > > > > > >As soon as the namespace starts, measurements should be added
> > > > > > >to the namespace specific measurement list, not it's parent.
> > > > >
> > > > > Shouldn't it be both?
> > > >
> > > > The policy defines which files are measured. The namespace policy
> > > > could be different than it's parent's policy, and the parent's
> > > > policy could be different than the native policy. Basically, file
> > > > measurements need to be added to the namespace measurement list,
> > > > recursively, up to the native measurement list.
> > >
> > > Yes, but if a task t1 is in namespace ns2 which is a child of
> > > namespace ns1, and it accesses a file which ns1's policy says must be
> > > measured, then will ns1's required measurement happen (and be
> > appended
> > > to the ns1 measurement list), whether or not ns2's policy requires it?
> >
> > Yes, as the file needs to be measured only in the ns1 policy, the
> > measurement would exist in the ns1 measurement list, but not in the
> > ns2 measurement list. The pseudo code snippet below might help.
>
> This algorithm is potentially extending a PCR in TPM multiple times
> for a single file event under a given namespace and duplicating
> entries. Any concerns with performance and memory footprint?
Going forward we assume associated with each container will be a vTPM.
The namespace measurements will extend a vTPM. As the container comes
and goes the associated measurement list, keyring, and vTPM will come
and go as well. For this reason, based on policy, the same file
measurement might appear in multiple measurement lists.
> What is the reason to adding a measurement to multiple namespace
> measurement lists? How are these lists going to be used? For Remote
> Attestation we need a single list (the native one) which has the
> complete list of measurements and in the same order they were
> extended in the TPM. Additionally, when namespaces are released,
> would the measurement list under that namespace disappear? How to
> store this list considering the namespaces may have a short life and
> be reused thousands of times?
Different scenarios have different requirements. You're assuming that
only the system owner is interested in the measurement list, not the
container owner.
The current builtin measurement policies measure everything executed
on the system and anything accessed by real root. The namespace
policy would probably be similar, but instead of measuring files
accessed by real root, it would be files accessed by root in the
namespace.
> Should the native measurement list have all measurements triggered
> in the whole system, including the ones made under other namespaces?
> Following the algorithm below, if the file is not in the policy of
> the 'native'/initial namespace, the measurement is not added to the
> native measurement list.
Correct. The policy controls what is included measured, appraised,
and audited.
> Each measurement entry in the list could have new fields to identify
> the namespace. Since the namespaces can be reused, a timestamp or
> others fields could be added to uniquely identify the namespace id.
The more fields included in the measurement list, the more
measurements will be added to the measurement list. Wouldn't it be
enough to know that a certain file has been accessed/executed on the
system and base any analytics/forensics on the IMA-audit data.
> Regarding namespace hierarchy and IMA policy, we could assume that
> if a given namespace has no policy set, the policy of that namespace
> parent is applied and then the native/initial namespace should
> always have a set policy.
We shouldn't assume measure, appraise, or audit by default. Just like
it is up to the native system to define a policy or if there is a
policy, the "container" owner should define the policy, or if there is
a policy.
Mimi
> >
> > do {
> > .
> > .
> >
> > /* calculate file hash based on xattr algorithm */
> > collect_measurement()
> >
> > /* recursively added to each namespace based on policy */
> > ima_store_measurement()
> >
> > /* Based on the specific namespace policy and keys. */
> > if (!once) {
> > once = 1;
> > result = ima_appraise_measurement()
> > }
> >
> > ima_audit_measurement()
> >
> > } while ((ns = ns->parent));
> >
> > return result;
> >
> > Mimi
|
|
From: Magalhaes, G. (B. R&D-CL) <gui...@hp...> - 2017-07-27 17:18:33
|
> -----Original Message----- > From: Mimi Zohar [mailto:zo...@li...] > Sent: quinta-feira, 27 de julho de 2017 11:39 > To: Magalhaes, Guilherme (Brazil R&D-CL) > <gui...@hp...>; Serge E. Hallyn <se...@ha...> > Cc: Mehmet Kayaalp <mka...@cs...>; Yuqiong Sun > <sun...@gm...>; containers <con...@li...- > foundation.org>; linux-kernel <lin...@vg...>; David Safford > <dav...@ge...>; James Bottomley > <Jam...@Ha...>; linux-security-module <linux- > sec...@vg...>; ima-devel <linux-ima- > de...@li...>; Yuqiong Sun <su...@us...> > Subject: Re: [Linux-ima-devel] [RFC PATCH 1/5] ima: extend clone() with IMA > namespace support > > On Thu, 2017-07-27 at 12:51 +0000, Magalhaes, Guilherme (Brazil R&D- > CL) wrote: > > > > > > > On Tue, 2017-07-25 at 16:08 -0500, Serge E. Hallyn wrote: > > > > On Tue, Jul 25, 2017 at 04:57:57PM -0400, Mimi Zohar wrote: > > > > > On Tue, 2017-07-25 at 15:46 -0500, Serge E. Hallyn wrote: > > > > > > On Tue, Jul 25, 2017 at 04:11:29PM -0400, Stefan Berger wrote: > > > > > > > On 07/25/2017 03:48 PM, Mimi Zohar wrote: > > > > > > > >On Tue, 2017-07-25 at 12:08 -0700, James Bottomley wrote: > > > > > > > >>On Tue, 2017-07-25 at 14:04 -0500, Serge E. Hallyn wrote: > > > > > > > >>>On Tue, Jul 25, 2017 at 11:49:14AM -0700, James Bottomley > wrote: > > > > > > > >>>>On Tue, 2017-07-25 at 12:53 -0500, Serge E. Hallyn wrote: > > > > > > > >>>>>On Thu, Jul 20, 2017 at 06:50:29PM -0400, Mehmet Kayaalp > > > wrote: > > > > > > > >>>>>> > > > > > > > >>>>>>From: Yuqiong Sun <su...@us...> > > > > > > > >>>>>> > > > > > > > >>>>>>Add new CONFIG_IMA_NS config option. Let clone() create > a > > > > > > > >>>>>>new IMA namespace upon CLONE_NEWNS flag. Add > ima_ns > > > data > > > > > > > >>>>>>structure in nsproxy. ima_ns is allocated and freed upon > > > > > > > >>>>>>IMA namespace creation and exit. Currently, the ima_ns > > > > > > > >>>>>>contains no useful IMA data but only a dummy interface. > > > > > > > >>>>>>This patch creates the framework for namespacing the > > > different aspects of IMA (eg. > > > > > > > >>>>>>IMA-audit, IMA-measurement, IMA-appraisal). > > > > > > > >>>>>> > > > > > > > >>>>>>Signed-off-by: Yuqiong Sun <su...@us...> > > > > > > > >>>>>> > > > > > > > >>>>>>Changelog: > > > > > > > >>>>>>* Use CLONE_NEWNS instead of a new CLONE_NEWIMA > flag > > > > > > > >>>>>Hi, > > > > > > > >>>>> > > > > > > > >>>>>So this means that every mount namespace clone will clone > a > > > > > > > >>>>>new IMA namespace. Is that really ok? > > > > > > > >>>>Based on what: space concerns (struct ima_ns is reasonably > > > small)? > > > > > > > >>>>or whether tying it to the mount namespace is the correct > > > > > > > >>>>thing to do. On > > > > > > > >>>Mostly the latter. The other would be not so much space > > > > > > > >>>concerns as time concerns. Many things use new mounts > > > > > > > >>>namespaces, and we wouldn't want multiple IMA calls on all > > > > > > > >>>file accesses by all of those. > > > > > > > >>> > > > > > > > >>>>the latter, it does seem that this should be a property of > > > > > > > >>>>either the mount or user ns rather than its own separate ns. > > > > > > > >>>>I could see a use where even a container might want multiple > > > > > > > >>>>ima keyrings within the container (say containerised apache > > > > > > > >>>>service with multiple tenants), so instinct tells me that > > > > > > > >>>>mount ns is the correct granularity for this. > > > > > > > >>>I wonder whether we could use echo 1 > > > > > > > > >>>/sys/kernel/security/ima/newns as the trigger for requesting > > > > > > > >>>a new ima ns on the next clone(CLONE_NEWNS). > > > > > > > >>I could go with that, but what about the trigger being > > > > > > > >>installing or updating the keyring? That's the only operation > > > > > > > >>that needs namespace separation, so on mount ns clone, you > get > > > > > > > >>a pointer to the old ima_ns until you do something that > > > > > > > >>requires a new key, which then triggers the copy of the > namespace > > > and installing it? > > > > > > > >It isn't just the keyrings that need to be namespaced, but the > > > > > > > >measurement list and policy as well. > > > > > > > > > > > > > > > >IMA-measurement, IMA-appraisal and IMA-audit are all policy > > > based. > > > > > > > > > > > > > > > >As soon as the namespace starts, measurements should be > added > > > > > > > >to the namespace specific measurement list, not it's parent. > > > > > > > > > > > > Shouldn't it be both? > > > > > > > > > > The policy defines which files are measured. The namespace policy > > > > > could be different than it's parent's policy, and the parent's > > > > > policy could be different than the native policy. Basically, file > > > > > measurements need to be added to the namespace measurement > list, > > > > > recursively, up to the native measurement list. > > > > > > > > Yes, but if a task t1 is in namespace ns2 which is a child of > > > > namespace ns1, and it accesses a file which ns1's policy says must be > > > > measured, then will ns1's required measurement happen (and be > > > appended > > > > to the ns1 measurement list), whether or not ns2's policy requires it? > > > > > > Yes, as the file needs to be measured only in the ns1 policy, the > > > measurement would exist in the ns1 measurement list, but not in the > > > ns2 measurement list. The pseudo code snippet below might help. > > > > This algorithm is potentially extending a PCR in TPM multiple times > > for a single file event under a given namespace and duplicating > > entries. Any concerns with performance and memory footprint? > > Going forward we assume associated with each container will be a vTPM. > The namespace measurements will extend a vTPM. As the container comes > and goes the associated measurement list, keyring, and vTPM will come > and go as well. For this reason, based on policy, the same file > measurement might appear in multiple measurement lists. My concern is that the base of namespacing the measurement lists is on the integration of containers with vTPM. Associating vTPM with containers as they are today is not a simple integration since vTPM requires a VM and containers do not. I cannot envision this association right now, but it might be possible after some research to understand the existent possibilities. For example, Intel SGX or clear containers may help with this integration. However, these technologies have trade-offs which could restrict adoption. -- Guilherme > > > What is the reason to adding a measurement to multiple namespace > > measurement lists? How are these lists going to be used? For Remote > > Attestation we need a single list (the native one) which has the > > complete list of measurements and in the same order they were > > extended in the TPM. Additionally, when namespaces are released, > > would the measurement list under that namespace disappear? How to > > store this list considering the namespaces may have a short life and > > be reused thousands of times? > > Different scenarios have different requirements. You're assuming that > only the system owner is interested in the measurement list, not the > container owner. > > The current builtin measurement policies measure everything executed > on the system and anything accessed by real root. The namespace > policy would probably be similar, but instead of measuring files > accessed by real root, it would be files accessed by root in the > namespace. > > > Should the native measurement list have all measurements triggered > > in the whole system, including the ones made under other namespaces? > > Following the algorithm below, if the file is not in the policy of > > the 'native'/initial namespace, the measurement is not added to the > > native measurement list. > > Correct. The policy controls what is included measured, appraised, > and audited. > > > Each measurement entry in the list could have new fields to identify > > the namespace. Since the namespaces can be reused, a timestamp or > > others fields could be added to uniquely identify the namespace id. > > The more fields included in the measurement list, the more > measurements will be added to the measurement list. Wouldn't it be > enough to know that a certain file has been accessed/executed on the > system and base any analytics/forensics on the IMA-audit data. > > > Regarding namespace hierarchy and IMA policy, we could assume that > > if a given namespace has no policy set, the policy of that namespace > > parent is applied and then the native/initial namespace should > > always have a set policy. > > We shouldn't assume measure, appraise, or audit by default. Just like > it is up to the native system to define a policy or if there is a > policy, the "container" owner should define the policy, or if there is > a policy. > > Mimi > > > > > > > do { > > > . > > > . > > > > > > /* calculate file hash based on xattr algorithm */ > > > collect_measurement() > > > > > > /* recursively added to each namespace based on policy */ > > > ima_store_measurement() > > > > > > /* Based on the specific namespace policy and keys. */ > > > if (!once) { > > > once = 1; > > > result = ima_appraise_measurement() > > > } > > > > > > ima_audit_measurement() > > > > > > } while ((ns = ns->parent)); > > > > > > return result; > > > > > > Mimi |
|
From: Stefan B. <st...@li...> - 2017-07-27 17:52:12
|
On 07/27/2017 01:18 PM, Magalhaes, Guilherme (Brazil R&D-CL) wrote: > >> -----Original Message----- >> From: Mimi Zohar [mailto:zo...@li...] >> Sent: quinta-feira, 27 de julho de 2017 11:39 >> To: Magalhaes, Guilherme (Brazil R&D-CL) >> <gui...@hp...>; Serge E. Hallyn <se...@ha...> >> Cc: Mehmet Kayaalp <mka...@cs...>; Yuqiong Sun >> <sun...@gm...>; containers <con...@li...- >> foundation.org>; linux-kernel <lin...@vg...>; David Safford >> <dav...@ge...>; James Bottomley >> <Jam...@Ha...>; linux-security-module <linux- >> sec...@vg...>; ima-devel <linux-ima- >> de...@li...>; Yuqiong Sun <su...@us...> >> Subject: Re: [Linux-ima-devel] [RFC PATCH 1/5] ima: extend clone() with IMA >> namespace support >> >> On Thu, 2017-07-27 at 12:51 +0000, Magalhaes, Guilherme (Brazil R&D- >> CL) wrote: >>> >>>> On Tue, 2017-07-25 at 16:08 -0500, Serge E. Hallyn wrote: >>>>> On Tue, Jul 25, 2017 at 04:57:57PM -0400, Mimi Zohar wrote: >>>>>> On Tue, 2017-07-25 at 15:46 -0500, Serge E. Hallyn wrote: >>>>>>> On Tue, Jul 25, 2017 at 04:11:29PM -0400, Stefan Berger wrote: >>>>>>>> On 07/25/2017 03:48 PM, Mimi Zohar wrote: >>>>>>>>> On Tue, 2017-07-25 at 12:08 -0700, James Bottomley wrote: >>>>>>>>>> On Tue, 2017-07-25 at 14:04 -0500, Serge E. Hallyn wrote: >>>>>>>>>>> On Tue, Jul 25, 2017 at 11:49:14AM -0700, James Bottomley >> wrote: >>>>>>>>>>>> On Tue, 2017-07-25 at 12:53 -0500, Serge E. Hallyn wrote: >>>>>>>>>>>>> On Thu, Jul 20, 2017 at 06:50:29PM -0400, Mehmet Kayaalp >>>> wrote: >>>>>>>>>>>>>> From: Yuqiong Sun <su...@us...> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Add new CONFIG_IMA_NS config option. Let clone() create >> a >>>>>>>>>>>>>> new IMA namespace upon CLONE_NEWNS flag. Add >> ima_ns >>>> data >>>>>>>>>>>>>> structure in nsproxy. ima_ns is allocated and freed upon >>>>>>>>>>>>>> IMA namespace creation and exit. Currently, the ima_ns >>>>>>>>>>>>>> contains no useful IMA data but only a dummy interface. >>>>>>>>>>>>>> This patch creates the framework for namespacing the >>>> different aspects of IMA (eg. >>>>>>>>>>>>>> IMA-audit, IMA-measurement, IMA-appraisal). >>>>>>>>>>>>>> >>>>>>>>>>>>>> Signed-off-by: Yuqiong Sun <su...@us...> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Changelog: >>>>>>>>>>>>>> * Use CLONE_NEWNS instead of a new CLONE_NEWIMA >> flag >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> So this means that every mount namespace clone will clone >> a >>>>>>>>>>>>> new IMA namespace. Is that really ok? >>>>>>>>>>>> Based on what: space concerns (struct ima_ns is reasonably >>>> small)? >>>>>>>>>>>> or whether tying it to the mount namespace is the correct >>>>>>>>>>>> thing to do. On >>>>>>>>>>> Mostly the latter. The other would be not so much space >>>>>>>>>>> concerns as time concerns. Many things use new mounts >>>>>>>>>>> namespaces, and we wouldn't want multiple IMA calls on all >>>>>>>>>>> file accesses by all of those. >>>>>>>>>>> >>>>>>>>>>>> the latter, it does seem that this should be a property of >>>>>>>>>>>> either the mount or user ns rather than its own separate ns. >>>>>>>>>>>> I could see a use where even a container might want multiple >>>>>>>>>>>> ima keyrings within the container (say containerised apache >>>>>>>>>>>> service with multiple tenants), so instinct tells me that >>>>>>>>>>>> mount ns is the correct granularity for this. >>>>>>>>>>> I wonder whether we could use echo 1 > >>>>>>>>>>> /sys/kernel/security/ima/newns as the trigger for requesting >>>>>>>>>>> a new ima ns on the next clone(CLONE_NEWNS). >>>>>>>>>> I could go with that, but what about the trigger being >>>>>>>>>> installing or updating the keyring? That's the only operation >>>>>>>>>> that needs namespace separation, so on mount ns clone, you >> get >>>>>>>>>> a pointer to the old ima_ns until you do something that >>>>>>>>>> requires a new key, which then triggers the copy of the >> namespace >>>> and installing it? >>>>>>>>> It isn't just the keyrings that need to be namespaced, but the >>>>>>>>> measurement list and policy as well. >>>>>>>>> >>>>>>>>> IMA-measurement, IMA-appraisal and IMA-audit are all policy >>>> based. >>>>>>>>> As soon as the namespace starts, measurements should be >> added >>>>>>>>> to the namespace specific measurement list, not it's parent. >>>>>>> Shouldn't it be both? >>>>>> The policy defines which files are measured. The namespace policy >>>>>> could be different than it's parent's policy, and the parent's >>>>>> policy could be different than the native policy. Basically, file >>>>>> measurements need to be added to the namespace measurement >> list, >>>>>> recursively, up to the native measurement list. >>>>> Yes, but if a task t1 is in namespace ns2 which is a child of >>>>> namespace ns1, and it accesses a file which ns1's policy says must be >>>>> measured, then will ns1's required measurement happen (and be >>>> appended >>>>> to the ns1 measurement list), whether or not ns2's policy requires it? >>>> Yes, as the file needs to be measured only in the ns1 policy, the >>>> measurement would exist in the ns1 measurement list, but not in the >>>> ns2 measurement list. The pseudo code snippet below might help. >>> This algorithm is potentially extending a PCR in TPM multiple times >>> for a single file event under a given namespace and duplicating >>> entries. Any concerns with performance and memory footprint? >> Going forward we assume associated with each container will be a vTPM. >> The namespace measurements will extend a vTPM. As the container comes >> and goes the associated measurement list, keyring, and vTPM will come >> and go as well. For this reason, based on policy, the same file >> measurement might appear in multiple measurement lists. > My concern is that the base of namespacing the measurement lists is on the > integration of containers with vTPM. Associating vTPM with containers as > they are today is not a simple integration since vTPM requires a VM and > containers do not. There's a vTPM proxy driver in the kernel that enables spawning a frontend /dev/tpm%d and an anonymous backend file descriptor where a vTPM can listen on for TPM commands. I integrated this with 'swtpm' and I have been working on integrating this into runc. Currently each container started with runc can get one (or multiple) vTPMs and /dev/tpm0 [and /dev/tpmrm0 in case of TPM2] then appear inside the container. What is missing for integration with IMA namespacing are patches for: 1) IMA to use a tpm_chip to talk to rather than issue TPM commands with TPM_ANY_NUM as parameter to TPM driver functions 2) an ioctl for the vtpm proxy driver to attach a vtpm proxy instance's tpm_chip to an IMA namespace; this ioctl should be called after the creation of the IMA namespace (by container mgmt. stack [runc]) 3) - some way for the IMA namespace to release the vTPM proxy's 'tpm_chip' and other resources once the IMA namespace is deleted I have these patches in some form and would post them at a later stage of namespacing IMA. swtpm: https://github.com/stefanberger/swtpm libtpms: https://github.com/stefanberger/libtpms runc pull request: https://github.com/opencontainers/runc/pull/1082 Stefan |
|
From: Magalhaes, G. (B. R&D-CL) <gui...@hp...> - 2017-07-27 19:40:43
|
> -----Original Message----- > From: Stefan Berger [mailto:st...@li...] > Sent: quinta-feira, 27 de julho de 2017 14:50 > To: Magalhaes, Guilherme (Brazil R&D-CL) > <gui...@hp...>; Mimi Zohar > <zo...@li...>; Serge E. Hallyn <se...@ha...> > Cc: Mehmet Kayaalp <mka...@cs...>; Yuqiong Sun > <sun...@gm...>; containers <con...@li...- > foundation.org>; linux-kernel <lin...@vg...>; David Safford > <dav...@ge...>; James Bottomley > <Jam...@Ha...>; linux-security-module <linux- > sec...@vg...>; ima-devel <linux-ima- > de...@li...>; Yuqiong Sun <su...@us...> > Subject: Re: [Linux-ima-devel] [RFC PATCH 1/5] ima: extend clone() with IMA > namespace support > > On 07/27/2017 01:18 PM, Magalhaes, Guilherme (Brazil R&D-CL) wrote: > > > >> -----Original Message----- > >> From: Mimi Zohar [mailto:zo...@li...] > >> Sent: quinta-feira, 27 de julho de 2017 11:39 > >> To: Magalhaes, Guilherme (Brazil R&D-CL) > >> <gui...@hp...>; Serge E. Hallyn <se...@ha...> > >> Cc: Mehmet Kayaalp <mka...@cs...>; Yuqiong Sun > >> <sun...@gm...>; containers <con...@li...- > >> foundation.org>; linux-kernel <lin...@vg...>; David > Safford > >> <dav...@ge...>; James Bottomley > >> <Jam...@Ha...>; linux-security-module > <linux- > >> sec...@vg...>; ima-devel <linux-ima- > >> de...@li...>; Yuqiong Sun <su...@us...> > >> Subject: Re: [Linux-ima-devel] [RFC PATCH 1/5] ima: extend clone() with > IMA > >> namespace support > >> > >> On Thu, 2017-07-27 at 12:51 +0000, Magalhaes, Guilherme (Brazil R&D- > >> CL) wrote: > >>> > >>>> On Tue, 2017-07-25 at 16:08 -0500, Serge E. Hallyn wrote: > >>>>> On Tue, Jul 25, 2017 at 04:57:57PM -0400, Mimi Zohar wrote: > >>>>>> On Tue, 2017-07-25 at 15:46 -0500, Serge E. Hallyn wrote: > >>>>>>> On Tue, Jul 25, 2017 at 04:11:29PM -0400, Stefan Berger wrote: > >>>>>>>> On 07/25/2017 03:48 PM, Mimi Zohar wrote: > >>>>>>>>> On Tue, 2017-07-25 at 12:08 -0700, James Bottomley wrote: > >>>>>>>>>> On Tue, 2017-07-25 at 14:04 -0500, Serge E. Hallyn wrote: > >>>>>>>>>>> On Tue, Jul 25, 2017 at 11:49:14AM -0700, James Bottomley > >> wrote: > >>>>>>>>>>>> On Tue, 2017-07-25 at 12:53 -0500, Serge E. Hallyn wrote: > >>>>>>>>>>>>> On Thu, Jul 20, 2017 at 06:50:29PM -0400, Mehmet Kayaalp > >>>> wrote: > >>>>>>>>>>>>>> From: Yuqiong Sun <su...@us...> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Add new CONFIG_IMA_NS config option. Let clone() create > >> a > >>>>>>>>>>>>>> new IMA namespace upon CLONE_NEWNS flag. Add > >> ima_ns > >>>> data > >>>>>>>>>>>>>> structure in nsproxy. ima_ns is allocated and freed upon > >>>>>>>>>>>>>> IMA namespace creation and exit. Currently, the ima_ns > >>>>>>>>>>>>>> contains no useful IMA data but only a dummy interface. > >>>>>>>>>>>>>> This patch creates the framework for namespacing the > >>>> different aspects of IMA (eg. > >>>>>>>>>>>>>> IMA-audit, IMA-measurement, IMA-appraisal). > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Signed-off-by: Yuqiong Sun <su...@us...> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Changelog: > >>>>>>>>>>>>>> * Use CLONE_NEWNS instead of a new CLONE_NEWIMA > >> flag > >>>>>>>>>>>>> Hi, > >>>>>>>>>>>>> > >>>>>>>>>>>>> So this means that every mount namespace clone will clone > >> a > >>>>>>>>>>>>> new IMA namespace. Is that really ok? > >>>>>>>>>>>> Based on what: space concerns (struct ima_ns is reasonably > >>>> small)? > >>>>>>>>>>>> or whether tying it to the mount namespace is the correct > >>>>>>>>>>>> thing to do. On > >>>>>>>>>>> Mostly the latter. The other would be not so much space > >>>>>>>>>>> concerns as time concerns. Many things use new mounts > >>>>>>>>>>> namespaces, and we wouldn't want multiple IMA calls on all > >>>>>>>>>>> file accesses by all of those. > >>>>>>>>>>> > >>>>>>>>>>>> the latter, it does seem that this should be a property of > >>>>>>>>>>>> either the mount or user ns rather than its own separate ns. > >>>>>>>>>>>> I could see a use where even a container might want multiple > >>>>>>>>>>>> ima keyrings within the container (say containerised apache > >>>>>>>>>>>> service with multiple tenants), so instinct tells me that > >>>>>>>>>>>> mount ns is the correct granularity for this. > >>>>>>>>>>> I wonder whether we could use echo 1 > > >>>>>>>>>>> /sys/kernel/security/ima/newns as the trigger for requesting > >>>>>>>>>>> a new ima ns on the next clone(CLONE_NEWNS). > >>>>>>>>>> I could go with that, but what about the trigger being > >>>>>>>>>> installing or updating the keyring? That's the only operation > >>>>>>>>>> that needs namespace separation, so on mount ns clone, you > >> get > >>>>>>>>>> a pointer to the old ima_ns until you do something that > >>>>>>>>>> requires a new key, which then triggers the copy of the > >> namespace > >>>> and installing it? > >>>>>>>>> It isn't just the keyrings that need to be namespaced, but the > >>>>>>>>> measurement list and policy as well. > >>>>>>>>> > >>>>>>>>> IMA-measurement, IMA-appraisal and IMA-audit are all policy > >>>> based. > >>>>>>>>> As soon as the namespace starts, measurements should be > >> added > >>>>>>>>> to the namespace specific measurement list, not it's parent. > >>>>>>> Shouldn't it be both? > >>>>>> The policy defines which files are measured. The namespace policy > >>>>>> could be different than it's parent's policy, and the parent's > >>>>>> policy could be different than the native policy. Basically, file > >>>>>> measurements need to be added to the namespace measurement > >> list, > >>>>>> recursively, up to the native measurement list. > >>>>> Yes, but if a task t1 is in namespace ns2 which is a child of > >>>>> namespace ns1, and it accesses a file which ns1's policy says must be > >>>>> measured, then will ns1's required measurement happen (and be > >>>> appended > >>>>> to the ns1 measurement list), whether or not ns2's policy requires it? > >>>> Yes, as the file needs to be measured only in the ns1 policy, the > >>>> measurement would exist in the ns1 measurement list, but not in the > >>>> ns2 measurement list. The pseudo code snippet below might help. > >>> This algorithm is potentially extending a PCR in TPM multiple times > >>> for a single file event under a given namespace and duplicating > >>> entries. Any concerns with performance and memory footprint? > >> Going forward we assume associated with each container will be a vTPM. > >> The namespace measurements will extend a vTPM. As the container > comes > >> and goes the associated measurement list, keyring, and vTPM will come > >> and go as well. For this reason, based on policy, the same file > >> measurement might appear in multiple measurement lists. > > My concern is that the base of namespacing the measurement lists is on > the > > integration of containers with vTPM. Associating vTPM with containers as > > they are today is not a simple integration since vTPM requires a VM and > > containers do not. > > There's a vTPM proxy driver in the kernel that enables spawning a > frontend /dev/tpm%d and an anonymous backend file descriptor where a > vTPM can listen on for TPM commands. I integrated this with 'swtpm' and > I have been working on integrating this into runc. Currently each > container started with runc can get one (or multiple) vTPMs and > /dev/tpm0 [and /dev/tpmrm0 in case of TPM2] then appear inside the > container. > This is an interesting solution especially for nested namespaces with the recursive application of measurements and a having list per container. Following the TCG specs/requirements, what could we say about security guarantees of real TPMs Vs this vTPM implementation? -- Guilherme > What is missing for integration with IMA namespacing are patches for: > > 1) IMA to use a tpm_chip to talk to rather than issue TPM commands with > TPM_ANY_NUM as parameter to TPM driver functions > 2) an ioctl for the vtpm proxy driver to attach a vtpm proxy instance's > tpm_chip to an IMA namespace; this ioctl should be called after the > creation of the IMA namespace (by container mgmt. stack [runc]) > 3) - some way for the IMA namespace to release the vTPM proxy's > 'tpm_chip' and other resources once the IMA namespace is deleted > > I have these patches in some form and would post them at a later stage > of namespacing IMA. > > swtpm: https://github.com/stefanberger/swtpm > libtpms: https://github.com/stefanberger/libtpms > runc pull request: https://github.com/opencontainers/runc/pull/1082 > > Stefan |
|
From: Stefan B. <st...@li...> - 2017-07-27 20:52:10
|
On 07/27/2017 03:39 PM, Magalhaes, Guilherme (Brazil R&D-CL) wrote:
>
>> There's a vTPM proxy driver in the kernel that enables spawning a
>> frontend /dev/tpm%d and an anonymous backend file descriptor where a
>> vTPM can listen on for TPM commands. I integrated this with 'swtpm' and
>> I have been working on integrating this into runc. Currently each
>> container started with runc can get one (or multiple) vTPMs and
>> /dev/tpm0 [and /dev/tpmrm0 in case of TPM2] then appear inside the
>> container.
>>
> This is an interesting solution especially for nested namespaces with the
> recursive application of measurements and a having list per container.
>
> Following the TCG specs/requirements, what could we say about security
> guarantees of real TPMs Vs this vTPM implementation?
A non-root user may not be able to do access the (permanent) state of
the vTPM state files since the container management stack would restrict
access to the files using DAC. Access to runtime data is also prevented
since the vTPM would not run under the account of the non-root user.
To protect the vTPM's permanent state file from access by a root user it
comes down to preventing the root user from getting a hold of the key
used for encrypting that file. Encrypting the state of the vTPM is
probably the best we can do to approximate a temper-resistant chip, but
preventing the root user from accessing the key may be more challenging.
Preventing root from accessing runtime data could be achieved by using
XGS or a similar technology.
Stefan
|
|
From: Magalhaes, G. (B. R&D-CL) <gui...@hp...> - 2017-07-28 14:20:24
|
> > Each measurement entry in the list could have new fields to identify > > the namespace. Since the namespaces can be reused, a timestamp or > > others fields could be added to uniquely identify the namespace id. > > The more fields included in the measurement list, the more > measurements will be added to the measurement list. Wouldn't it be > enough to know that a certain file has been accessed/executed on the > system and base any analytics/forensics on the IMA-audit data. With the recursive application of policy through the namespace hierarchy, a measurement added to the parent namespace could be misleading since the file pathname makes sense in the current namespace but possibly not for the parent namespace. This is the reason why I believe some new field might be needed in the IMA template format to indicate or uniquely identify the namespace. -- Guilherme |
|
From: Mimi Z. <zo...@li...> - 2017-07-31 11:32:17
|
On Fri, 2017-07-28 at 14:19 +0000, Magalhaes, Guilherme (Brazil R&D- CL) wrote: > > > Each measurement entry in the list could have new fields to identify > > > the namespace. Since the namespaces can be reused, a timestamp or > > > others fields could be added to uniquely identify the namespace id. > > > > The more fields included in the measurement list, the more > > measurements will be added to the measurement list. Wouldn't it be > > enough to know that a certain file has been accessed/executed on the > > system and base any analytics/forensics on the IMA-audit data. > > With the recursive application of policy through the namespace hierarchy, > a measurement added to the parent namespace could be misleading since > the file pathname makes sense in the current namespace but possibly not > for the parent namespace. Fair enough. > This is the reason why I believe some new field > might be needed in the IMA template format to indicate or uniquely > identify the namespace. I would probably include information to uniquely identify the file (eg. UUID, mountpoint), not the namespace. Mimi |
|
From: Mehmet K. <mka...@li...> - 2017-08-01 17:21:38
|
> On Aug 1, 2017, at 1:17 PM, Tycho Andersen <ty...@do...> wrote:
>
> Hi Mehmet,
>
> On Thu, Jul 20, 2017 at 06:50:31PM -0400, Mehmet Kayaalp wrote:
>> --- a/security/integrity/ima/ima_ns.c
>> +++ b/security/integrity/ima/ima_ns.c
>> @@ -301,3 +301,24 @@ struct ns_status *ima_get_ns_status(struct ima_namespace *ns,
>>
>> return status;
>> }
>> +
>> +#define IMA_NS_STATUS_ACTIONS IMA_AUDIT
>> +#define IMA_NS_STATUS_FLAGS IMA_AUDITED
>> +
>
> Seems like these are defined in ima.h above in the patch, and
> re-defined here?
Yes, it should be in the ima.h only.
>> +unsigned long iint_flags(struct integrity_iint_cache *iint,
>> + struct ns_status *status)
>> +{
>> + if (!status)
>> + return iint->flags;
>> +
>> + return iint->flags & (status->flags & IMA_NS_STATUS_FLAGS);
>
> Just to confirm, is there any situation where:
>
> iint->flags & IMA_NS_STATUS_FLAGS != status->flags & IMA_NS_STATUS_FLAGS
>
> ? i.e. can this line just be:
>
> return status->flags & IMA_NS_STATUS_FLAGS;
>
As Guilherme had pointed out, the first & should be |.
Mehmet
|
|
From: Tycho A. <ty...@do...> - 2017-08-02 21:48:50
|
On Tue, Aug 01, 2017 at 01:25:31PM -0400, Mehmet Kayaalp wrote:
> >> +unsigned long iint_flags(struct integrity_iint_cache *iint,
> >> + struct ns_status *status)
> >> +{
> >> + if (!status)
> >> + return iint->flags;
> >> +
> >> + return iint->flags & (status->flags & IMA_NS_STATUS_FLAGS);
> >
> > Just to confirm, is there any situation where:
> >
> > iint->flags & IMA_NS_STATUS_FLAGS != status->flags & IMA_NS_STATUS_FLAGS
> >
> > ? i.e. can this line just be:
> >
> > return status->flags & IMA_NS_STATUS_FLAGS;
> >
>
> As Guilherme had pointed out, the first & should be |.
Sorry, that mail got filtered somehow, thanks. Per your discussion, I
guess the most defensive way is:
iint->flags & ~IMA_NS_STATUS_FLAGS | status->flags & IMA_NS_STATUS_FLAGS
in case something comes along and sets IMA_AUDITED on the root iint,
we don't want it to propagate to this ns' status unnecessarily.
Anyway, thanks!
Tycho
|
Thanks for helping keep SourceForge clean.
X