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@xxxxxxxxxxxxx> 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 > >
