IMA Namespacing design considerations

Namespacing IMA

Our goals are to enable IMA-measurement, IMA-appraisal, and IMA-audit inside a container using Linux namespaces. The intention is to introduce an IMA namespace.

Background

IMA-measurement is about logging files that were read or executables that were started on a machine. Current IMA supports for example measuring root's activities in the TCB, such as which programs were started by root. Which files are measured can be configured using an IMA policy.

IMA-appraisal is about only allowing files to be accessed that have been properly signed. This allows to lock down a machine if only signed files are allowed to be read or executed. Which files are appraised can be configured using an IMA policy. File signatures are found in the security.ima extended attribute. The keys for verifying the signature are found in IMA specific keyrings .ima or _ima.

IMA-audit is about reporting accesses to files and generating audit records of file hash measurements. Which file activity is audited can be configured using an IMA policy. The audit records can be used to augment existing security analytics software and be used for system forensics.

IMA Namespacing Considerations

When namespacing IMA we certainly want to prevent the abuse of namespaces by users doing things that go undetected. A primary concern are activities of root in the TCB. Since root has all the rights on the system he could try to abuse his power by spawning new IMA namespaces and do things there that affect the TCB but now would go undetected due to weaknesses in the IMA namespacing implementation. The following enumeration of IMA namespacing design points is supposed to guide the implementation and prevent such problems:

Support for IMA in namespaces should enable the following:

 - IMA policy for container (similar to the host):
   - there should be an initial default policy for every IMA namespace that measures activities inside the container
   - the policy can be overwritten once with a user-defined policy that may activate appraisal; this policy would be independent of that of the host
   - CAP_SYS_ADMIN is currently gating the setting of the IMA policy; 
     - setting the policy should be possibly without the almighty CAP_SYS_ADMIN
     - we may want to gate this with a new capability CAP_INTEGRITY_ADMIN that allows a user to set the IMA policy during container runtime
 
 - IMA policy extensions due to namespacing:
   - an IMA policy should allow rules that define whether activities in (all) child namespaces is to be measured (huge logs on the host)
     and audited or 'not'; a use case for not measuring may be found in cloud environments where containers come and go and the log on the
     host could possibly eat up a lot of memory
   - to prevent (host) root from spawning new IMA namespaces and doing things undetected in the TCB, all activities of root must be measured and audited
     in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces
 
 - IMA-measurement:
   - to prevent (host) root from spawning new IMA namespaces and doing things undetected in the TCB, all activities of root must be measured and audited
     in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces
   - activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace
 
 - IMA-audit:
   - to prevent (host) root from spawning new IMA namespaces and doing things undetected in the TCB, all activities of root must be measured and audited
     in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces
   - activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace
 
 - IMA-appraisal and keys:
   - each IMA namespace should have its own keyring so that each container can have its files signed with different keys
     - the keys (certificates) for verifying signatures may be found inside containers
   - it should be possible to enforce that only certified keys are loaded onto a keyring, similar to .ima on the host
     - the CA public key used for verifying that public keys (certificates) used for verifying signatures may be found inside the container
       or could be known to the container management stack
 
 - IMA-appraisal and namespacing:
   - If IMA-appraisal is active on the host (per policy rules on the host), what is supposed to happen when (host) root executes files in a
    (nested) IMA namespace where an empty IMA policy has been set? We would measure and audit root's activities as described above.
    What about appraising? Would we traverse all the IMA namespaces back to the init_ima_ns and evaluate signatures against the appraisal policy
    set there and assume we would always find the keys in the init_user_ns?
 
    Maybe the following would be a solution for appraising file accesses by (host) root with the key used for signature verification
    assumed in the init_user_ns; this is a step after evaluating the file access with the current IMA namespace's policy and the currently
    active USER namespace where the key can be found
 
    for imans from current-IMA-NS backwards up to and including init_ima_ns:
        if policy(imans) has appraisal rules for this file:
            if file appraisal fails
               fail access
            else
               allow access
            break
 
    or simplified (again after evaluating file access with the current IMA namespace's policy and the currently
    active USER namespace where the key can be found)
 
    Appraise with policy of init_ima_ns and key found in .ima or _ima keyring of init_user_ns.
 
 - TPM and measurements:
   - The IMA namespace that holds the logs should be configurable to extend PCRs; since the single TPM of the host cannot be shared by containers,
     each IMA namespace would have to be associated with its own TPM instance (vTPM); measurement in the initial IMA namespace are extended into
     the hardware TPM as done already
   - Each IMA namespace should only have access to the sysfs entries of its own TPM instance; ideally, sysfs would only show a single TPM device
     entry when viewed from an IMA namespace; an alternative may be that all devices are shown but refuse read/write access to their files if it
     is initiated from the 'wrong' IMA namespace
 
 - Extended attribute security.ima:
   - A container should be able to set the security.ima extended attribute
      - this should be possibly without the almighty CAP_SYS_ADMIN;
      - we may want to gate this with a new capability CAP_SECURITY_XATTR_ADMIN that allows setting security extended attributes inside a container, 
        possibly only during container build-time
 
 - Extended attribute security.ima and bind mounting
   - It may be necessary that different namespaces be able to sign the same bind-mounted file with different keys
     (I am thinking of bind-mounted files that the container management stack modifies and that may need to be signed for the container to be
      able to access them.)
     - Extended attributes, such as security.ima) may need to be virtualizeable (security.ima vs. security.ima@uid=1000 etc.)
 
 - SecurityFS:
   - every IMA namespace should have (read/write) access to the entries that are associated with its IMA namespace
   - the organization of IMA's securityfs directory structure should reflect the child-parent relationship of IMA namespaces;
     - there should be a directory called 'namespaces' where each child namespace would have a directory with the name of the IMA
       namespace's inode ('IMANS:4768263432') that leads to the files holding the information about that namespace

Possible abuse-scenarios may include switching through the namespaces (UTS, PID, IPC, NET, USER, CGROUP, MNT). I am not sure what is supposed to happen other than logging the activity active in the current IMA namespace:

What should happen with IMA logging, appraisal, and auditing if we setns() through all available
- PID namespaces and send signals: log, appraise, and audit file activity following IMA policy with special handling for (host) root
- IPC namespaces and send messages via IPC: same as for PID
- UTS namespaces and setting hostname:  same as for PID
- NET namespaces and sending network traffic: same as for PID
- CGROUP namespaces and configuring cgroups: same as for PID
- USER: should now the keys of this USER namespace be active or the keys of the original user namespace used during the clone()? [we may need
  to adapt the current implementation...] other than that, same as for PID?
- MNT namespaces and access files or execute program: same as for PID; if active IMA namespace policy requires file appraisal, files would need
  to be signed with key from keyring in current USER namespace