Re: IMA namespaces

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux Kernel]     [Linux Kernel Hardening]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux