IMA namespaces

IMA namespaces

[Denis Semakin]

Hello.
A few months ago we started a project dedicated to single IMA namespaces.
Last years there were a number of patch-sets about this problem, e.g.
the last one was from  Krzysztof Struczynski. But no one patch-set
wasn’t applied to the mainline.

Also there is a document (thanks Mimi) that describes the main goal,
architecture and design - “IMA Namespacing design considerations”.

As a result of investigations: Krzysztof’s patches were successfully
adopted for Linux kernel v5.10.30 and tested,
at least that allowed to study integrity and IMA a source code a
little bit. But that patch-set does not match “...design
considerations…”. Then we may take all patches as a base, use
“Considerations…” as architecture description and start to implement
but it is obvious that it does not make sense without community
(review, discussion, etc).

In practice I suggest using the git branch
next-namespacing-experimental for development purposes. Set this
branch to kernel v5.10.30 (it could be different but … I used that,
moreover v5.10.x is longterm). After that I and others could start to
send patches and discuss, it would be a normal development process.
For example it could finally help to decide how exactly a new IMA
namespace should be spawned by clone3() or by writing something to a
sysfs file. In my opinion clone3() should be used.

This is the beginning. Without this we cannot move further. I have no
intention to abandon this project. So let’s start.

Best regards,
Denis.

Re: IMA namespaces

[Stefan Berger]

On 9/1/21 8:00 AM, Denis Semakin wrote:
> Hello.
> A few months ago we started a project dedicated to single IMA namespaces.
> Last years there were a number of patch-sets about this problem, e.g.
> the last one was from  Krzysztof Struczynski. But no one patch-set
> wasn’t applied to the mainline.
>
> Also there is a document (thanks Mimi) that describes the main goal,
> architecture and design - “IMA Namespacing design considerations”.
>
> As a result of investigations: Krzysztof’s patches were successfully
> adopted for Linux kernel v5.10.30 and tested,
> at least that allowed to study integrity and IMA a source code a
> little bit. But that patch-set does not match “...design
> considerations…”. Then we may take all patches as a base, use
> “Considerations…” as architecture description and start to implement
> but it is obvious that it does not make sense without community
> (review, discussion, etc).

We are working on another design document, which is based on the initial 
one, that lists the following design requirements for IMA namespacing:

R1 Each container must have the possibility to spawn an independent IMA 
namespace
   (IMA-ns). Each IMA-ns must have the following properties:
   R1.1 An IMA-ns must have an independent IMA-policy with
       (i)  an initial default policy, and
       (ii) rules that provide the possibility to cause measurements and 
appraisal
           in IMA-ns child namespaces.
   R1.2 An IMA-ns must have independent IMA-measurement with
       (i)  its own measurement list and
       (ii) the possibility to measure and log files accessed in an 
IMA-ns child
            namespace per the IMA-policy.
   R1.3 An IMA-ns must have independent IMA-appraisal with
       (i)  its own set of keyrings and
       (ii) the possibility to appraise files accessed in an IMA-ns 
child namespace
            per the IMA-policy.
   R1.4 An IMA-ns must have independent IMA-audit with
       (i)  its own emission of audit messages distinguishable from 
those audit
            messages of other IMA-ns's and
       (ii) the possibility to audit files accessed in an IMA-ns child 
namespaces.
R2 As an additional requirement host root's actions in an IMA-ns must be 
measured
    and audited (in all IMA namespaces) in the IMA root namespace, 
independent of
    whether the IMA policy enables logging or auditing in child 
namespaces, if there
    is an IMA measurements or auditing policy in the IMA root namespace.
    The same may apply to a container root user whose actions in a 
child-IMA-ns need
    to be measured and audited if there is an IMA measurement or 
audition policy in
    the IMA-ns.
R3 An independent instance of SecurityFS must be accessible to each 
IMA-ns showing
    the IMA-policy, the IMA measurement list, and other information 
related to the
    'owning' IMA-ns.
R4 A container's root user must be able to
    (i)  load the IMA policy inside a container using SecurityFS of its 
IMA-ns and
    (ii) sign files inside a container.
R5 An independent vTPM instance should be connectable to each IMA-ns 
where the
    IMA-ns extends its measurements into the vTPM's PCRs.


Maybe we can discuss those until we can share the document with a wider 
audience.

    Stefan

Re: IMA namespaces

[Denis Semakin]

The new statements look very similar to previous. A couple of the
items are already under development.
What about new capabilities CAP_INTEGRITY_ADMIN and
CAP_SECURITY_XATTR_ADMIN which are mentioned in the first original
edition of "Considerations..."

Br,
Denis

On Wed, Oct 13, 2021 at 10:14 PM Stefan Berger <stefanb@linux.ibm.com> wrote:
>
>
> On 9/1/21 8:00 AM, Denis Semakin wrote:
> > Hello.
> > A few months ago we started a project dedicated to single IMA namespaces.
> > Last years there were a number of patch-sets about this problem, e.g.
> > the last one was from  Krzysztof Struczynski. But no one patch-set
> > wasn’t applied to the mainline.
> >
> > Also there is a document (thanks Mimi) that describes the main goal,
> > architecture and design - “IMA Namespacing design considerations”.
> >
> > As a result of investigations: Krzysztof’s patches were successfully
> > adopted for Linux kernel v5.10.30 and tested,
> > at least that allowed to study integrity and IMA a source code a
> > little bit. But that patch-set does not match “...design
> > considerations…”. Then we may take all patches as a base, use
> > “Considerations…” as architecture description and start to implement
> > but it is obvious that it does not make sense without community
> > (review, discussion, etc).
>
> We are working on another design document, which is based on the initial
> one, that lists the following design requirements for IMA namespacing:
>
> R1 Each container must have the possibility to spawn an independent IMA
> namespace
>    (IMA-ns). Each IMA-ns must have the following properties:
>    R1.1 An IMA-ns must have an independent IMA-policy with
>        (i)  an initial default policy, and
>        (ii) rules that provide the possibility to cause measurements and
> appraisal
>            in IMA-ns child namespaces.
>    R1.2 An IMA-ns must have independent IMA-measurement with
>        (i)  its own measurement list and
>        (ii) the possibility to measure and log files accessed in an
> IMA-ns child
>             namespace per the IMA-policy.
>    R1.3 An IMA-ns must have independent IMA-appraisal with
>        (i)  its own set of keyrings and
>        (ii) the possibility to appraise files accessed in an IMA-ns
> child namespace
>             per the IMA-policy.
>    R1.4 An IMA-ns must have independent IMA-audit with
>        (i)  its own emission of audit messages distinguishable from
> those audit
>             messages of other IMA-ns's and
>        (ii) the possibility to audit files accessed in an IMA-ns child
> namespaces.
> R2 As an additional requirement host root's actions in an IMA-ns must be
> measured
>     and audited (in all IMA namespaces) in the IMA root namespace,
> independent of
>     whether the IMA policy enables logging or auditing in child
> namespaces, if there
>     is an IMA measurements or auditing policy in the IMA root namespace.
>     The same may apply to a container root user whose actions in a
> child-IMA-ns need
>     to be measured and audited if there is an IMA measurement or
> audition policy in
>     the IMA-ns.
> R3 An independent instance of SecurityFS must be accessible to each
> IMA-ns showing
>     the IMA-policy, the IMA measurement list, and other information
> related to the
>     'owning' IMA-ns.
> R4 A container's root user must be able to
>     (i)  load the IMA policy inside a container using SecurityFS of its
> IMA-ns and
>     (ii) sign files inside a container.
> R5 An independent vTPM instance should be connectable to each IMA-ns
> where the
>     IMA-ns extends its measurements into the vTPM's PCRs.
>
>
> Maybe we can discuss those until we can share the document with a wider
> audience.
>
>     Stefan
>
>

Re: IMA namespaces

[Stefan Berger]

On 10/14/21 6:12 AM, Denis Semakin wrote:
> The new statements look very similar to previous. A couple of the
> items are already under development.
> What about new capabilities CAP_INTEGRITY_ADMIN and
> CAP_SECURITY_XATTR_ADMIN which are mentioned in the first original
> edition of "Considerations..."

They still exist but are part of the implementation rather than the high 
level requirement R4.

> Br,
> Denis
>
> On Wed, Oct 13, 2021 at 10:14 PM Stefan Berger <stefanb@linux.ibm.com> wrote:
>>
>> On 9/1/21 8:00 AM, Denis Semakin wrote:
>>> Hello.
>>> A few months ago we started a project dedicated to single IMA namespaces.
>>> Last years there were a number of patch-sets about this problem, e.g.
>>> the last one was from  Krzysztof Struczynski. But no one patch-set
>>> wasn’t applied to the mainline.
>>>
>>> Also there is a document (thanks Mimi) that describes the main goal,
>>> architecture and design - “IMA Namespacing design considerations”.
>>>
>>> As a result of investigations: Krzysztof’s patches were successfully
>>> adopted for Linux kernel v5.10.30 and tested,
>>> at least that allowed to study integrity and IMA a source code a
>>> little bit. But that patch-set does not match “...design
>>> considerations…”. Then we may take all patches as a base, use
>>> “Considerations…” as architecture description and start to implement
>>> but it is obvious that it does not make sense without community
>>> (review, discussion, etc).
>> We are working on another design document, which is based on the initial
>> one, that lists the following design requirements for IMA namespacing:
>>
>> R1 Each container must have the possibility to spawn an independent IMA
>> namespace
>>     (IMA-ns). Each IMA-ns must have the following properties:
>>     R1.1 An IMA-ns must have an independent IMA-policy with
>>         (i)  an initial default policy, and
>>         (ii) rules that provide the possibility to cause measurements and
>> appraisal
>>             in IMA-ns child namespaces.
>>     R1.2 An IMA-ns must have independent IMA-measurement with
>>         (i)  its own measurement list and
>>         (ii) the possibility to measure and log files accessed in an
>> IMA-ns child
>>              namespace per the IMA-policy.
>>     R1.3 An IMA-ns must have independent IMA-appraisal with
>>         (i)  its own set of keyrings and
>>         (ii) the possibility to appraise files accessed in an IMA-ns
>> child namespace
>>              per the IMA-policy.
>>     R1.4 An IMA-ns must have independent IMA-audit with
>>         (i)  its own emission of audit messages distinguishable from
>> those audit
>>              messages of other IMA-ns's and
>>         (ii) the possibility to audit files accessed in an IMA-ns child
>> namespaces.
>> R2 As an additional requirement host root's actions in an IMA-ns must be
>> measured
>>      and audited (in all IMA namespaces) in the IMA root namespace,
>> independent of
>>      whether the IMA policy enables logging or auditing in child
>> namespaces, if there
>>      is an IMA measurements or auditing policy in the IMA root namespace.
>>      The same may apply to a container root user whose actions in a
>> child-IMA-ns need
>>      to be measured and audited if there is an IMA measurement or
>> audition policy in
>>      the IMA-ns.
>> R3 An independent instance of SecurityFS must be accessible to each
>> IMA-ns showing
>>      the IMA-policy, the IMA measurement list, and other information
>> related to the
>>      'owning' IMA-ns.
>> R4 A container's root user must be able to
>>      (i)  load the IMA policy inside a container using SecurityFS of its
>> IMA-ns and
>>      (ii) sign files inside a container.
>> R5 An independent vTPM instance should be connectable to each IMA-ns
>> where the
>>      IMA-ns extends its measurements into the vTPM's PCRs.
>>
>>
>> Maybe we can discuss those until we can share the document with a wider
>> audience.
>>
>>      Stefan
>>
>>