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 [off-list ref] wrote:

quoted

On 9/1/21 8:00 AM, Denis Semakin wrote:

quoted

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