http://kernsec.org/wiki/api.php?action=feedcontributions&user=Stefanb&feedformat=atomLinux Kernel Security Subsystem - User contributions [en]2024-03-29T05:17:06ZUser contributionsMediaWiki 1.36.1http://kernsec.org/wiki/index.php?title=IMA_Namespacing_design_considerations&diff=3985IMA Namespacing design considerations2019-03-01T16:52:56Z<p>Stefanb: /* Standalone IMA namespace versus IMA namespace attached to MOUNT namespace or USER namespace */</p>
<hr />
<div>== Namespacing IMA ==<br />
<br />
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.<br />
<br />
=== Background ===<br />
<br />
IMA-measurement extends the concept of “trusted boot”[1] to the running OS. Based on policy, as files are accessed, executed, mmapped a hash of the file data is calculated and used to extend TPM[2], if enabled, and added to the IMA measurement list. The current builtin IMA-measurement Trusted Computing Base (TCB) policies measures all files read by root or executed/mmapped by any user. It also measures all kernel modules and firmware, when they are loaded, as well as the IMA policy itself. <br />
<br />
IMA-appraisal: extends the concept of “secure boot”[3] to the running OS. Based on policy, as files are accessed, executed, mmapped the file hash is calculated and used to verify the known good value as stored in the security.ima xattr. Stored in the security.ima xattr could be either a file hash or a signature. The keys for verifying the file data signature are found in IMA specific keyrings .ima or _ima. <br />
<br />
IMA-audit: adds system audit records containing the file hash to the system audit log. The IMA-audit records can be used to augment existing security analytics software and be used for system forensics.<br />
<br />
Namespacing each of these features requires not only adding IMA namespacing support, but requires some additional kernel changes. Our goals are to ultimately enable IMA-measurement, IMA-appraisal, and IMA-audit inside a container using Linux namespaces. Namespacing these different aspects of IMA is a major under taking and needs to be staged in manageable pieces.<br />
<br />
=== IMA Namespacing Considerations ===<br />
<br />
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:<br />
<br />
<br />
Support for IMA in namespaces should enable the following:<br />
<br />
- IMA policy for container (similar to the host):<br />
- there should be an initial default policy for every IMA namespace that measures activities inside the container<br />
- the uid in policy rules are relative to the uid's of the user namespace that is active; uid=0 refers to root inside the user namespace<br />
- like the existing builtin policies can be replaced with a custom policy once, the namespace policy can be replaced with a user-defined<br />
custom policy once. Both the initial and custom namespace IMA policies would be independent of that of the host policy.<br />
- CAP_SYS_ADMIN is currently gating the setting of the IMA policy; <br />
- setting the policy should be possibly without the almighty CAP_SYS_ADMIN<br />
- 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<br />
<br />
- IMA policy extensions due to namespacing:<br />
- an IMA policy should allow rules that define whether activities in (all) child namespaces is to be measured (huge logs on the host)<br />
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<br />
host could possibly eat up a lot of memory<br />
- to prevent (host) root from spawning new IMA namespaces and doing things undetected in the TCB, all activities of root must be <br />
''measured and audited'' in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- The existing builtin policies assume policy rules are based on the global “uid” or “fowner”, not based on the namespaced “uid” or “fowner”.<br />
Instead of explicitly including specific “uid” or “fowner” rules for each container, allow rules to be specified in terms of the namespaced<br />
“uid” or “fowner”. For example, “measure func=FILE_CHECK mask=^MAY_READ uid=0 ns” means measure all files opened for read by root in the<br />
namespace and “appraise fowner=0 ns” means appraise all files owned by root in the namespace.<br />
- The measurement list size is currently unbounded. Additional rules, which measure files opened by root in the namespace or appraise files<br />
owned by root in the namespace, will add additional system memory pressures. <br />
<br />
- IMA-measurement:<br />
- to prevent (host) root from spawning new IMA namespaces and doing things undetected in the TCB, all activities of root must be<br />
''measured'' and audited in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-audit:<br />
- to prevent (host) root from spawning new IMA namespaces and doing things undetected in the TCB, all activities of root must be<br />
measured and ''audited'' in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-appraisal and keys:<br />
- each IMA namespace should have its own keyring so that each container can have its files signed with different keys<br />
- the keys (certificates) for verifying signatures may be found inside containers<br />
- it should be possible to enforce that only certified keys are loaded onto a keyring, similar to .ima on the host<br />
- the CA public key used for verifying that public keys (certificates) used for verifying signatures may be found inside the container<br />
or could be known to the container management stack<br />
<br />
- IMA-appraisal and namespacing:<br />
- 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<br />
(nested) IMA namespace where an empty IMA policy has been set? We would measure and audit root's activities as described above.<br />
What about appraising? Would we traverse all the IMA namespaces back to the init_ima_ns and evaluate signatures against the appraisal<br />
policy set there and assume we would always find the keys in the init_user_ns?<br />
<br />
Maybe the following would be a solution for appraising file accesses by (host) root with the key used for signature verification<br />
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<br />
active USER namespace where the key can be found<br />
<br />
for imans from current-IMA-NS backwards up to and including init_ima_ns:<br />
if policy(imans) has appraisal rules for this file:<br />
if file appraisal fails<br />
fail access<br />
else<br />
allow access<br />
break<br />
<br />
or simplified (again after evaluating file access with the current IMA namespace's policy and the currently<br />
active USER namespace where the key can be found)<br />
<br />
Appraise with policy of init_ima_ns and key found in .ima or _ima keyring of init_user_ns.<br />
<br />
- TPM and measurements:<br />
- The IMA namespace that holds the logs should be configurable to extend PCRs; since the single TPM of the host cannot be shared by <br />
containers, each IMA namespace would have to be associated with its own TPM instance (vTPM); measurement in the initial IMA namespace<br />
are extended into the hardware TPM as done already<br />
- Each IMA namespace should only have access to the sysfs entries of its own TPM instance; ideally, sysfs would only show a single TPM<br />
device entry when viewed from an IMA namespace; an alternative may be that all devices are shown but refuse read/write access to their<br />
files if it is initiated from the 'wrong' IMA namespace<br />
<br />
- Extended attribute security.ima:<br />
- A container should be able to set the security.ima extended attribute<br />
- this should be possibly without the almighty CAP_SYS_ADMIN;<br />
- we may want to gate this with a new capability CAP_SECURITY_XATTR_ADMIN that allows setting security extended attributes inside a<br />
container, possibly only during container build-time<br />
<br />
- Extended attribute security.ima and bind mounting<br />
- It may be necessary that different namespaces be able to sign the same bind-mounted file with different keys<br />
(I am thinking of bind-mounted files that the container management stack modifies and that may need to be signed for the container to<br />
be able to access them.)<br />
- Extended attributes, such as security.ima) may need to be virtualizeable (security.ima vs. security.ima@uid=1000 etc.)<br />
<br />
- SecurityFS:<br />
- every IMA namespace should have (read/write) access to the entries that are associated with its IMA namespace<br />
- the organization of IMA's securityfs directory structure should reflect the child-parent relationship of IMA namespaces;<br />
- there should be a directory called 'namespaces' where each child namespace would have a directory with the name of the IMA<br />
namespace's inode ('IMANS:4768263432') that leads to the files holding the information about that namespace<br />
<br />
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:<br />
<br />
What should happen with IMA logging, appraisal, and auditing if we setns() through all available<br />
- PID namespaces and send signals: log, appraise, and audit file activity following IMA policy with special handling for (host) root<br />
- IPC namespaces and send messages via IPC: same as for PID<br />
- UTS namespaces and setting hostname: same as for PID<br />
- NET namespaces and sending network traffic: same as for PID<br />
- CGROUP namespaces and configuring cgroups: same as for PID<br />
- 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<br />
to adapt the current implementation...] other than that, same as for PID?<br />
- MNT namespaces and access files or execute program: same as for PID; if active IMA namespace policy requires file appraisal, files would need<br />
to be signed with key from keyring in current USER namespace<br />
<br />
=== IMA namespaces and IMA policy semantics ===<br />
<br />
The following shows IMA policy rules and their semantics when applied to IMA namespaces:<br />
<br />
1) audit FUNC=BPRM_CHECK<br />
2) audit FUNC=BPRM_CHECK ns<br />
3) measure func=BPRM_CHECK<br />
<br />
The interpretation of these IMA policy rules is as follows:<br />
<br />
1) Files executed in the IMA namespace that has this policy rule and its child namespaces are audited once<br />
2) Files executed in a child namespace of the IMA namespace that has this policy rule are audited, even if already audited in the IMA namespace that has this policy rule or another namespace<br />
3) Files executed in the IMA namespace that has this policy rule and its child namespaces are measured once<br />
<br />
Note: Initially, the init_ima_ns will be the only IMA namespace that will have a policy.<br />
<br />
== Standalone IMA namespace versus IMA namespace attached to MOUNT namespace or USER namespace ==<br />
<br />
1) The first set of posted patches '''attached the IMA namespace to the MOUNT namespace''' and shared the CLONE_NEWNS flag. Whenever a new mount namespace was created, it also created a new IMA namespace. Similarly, a setns() on a MOUNT namespace would also join the conjoint IMA namespace. File measurements and appraisal of an IMA policy would work on the files in the MOUNT namespace. The key used for the appraisal would be in the currently setns()'d USER namespace (the current implementation of IMA would need to be fixed in that regard). This proposed implementation of conjoint MOUNT and IMA namespaces was rejected.<br />
<br />
2) Another choice is to '''attach the IMA namespace to the USER namespace'''. An IMA file measurement and appraisal policy would become activated when the conjoint USER and IMA namespaces are joined using setns() for example. Side effects of this include that joining a USER namespace activates an IMA policy, that, if appraisal is active, start appraising file accesses, which may include file access denials.<br />
<br />
3) The last choice is to have IMA be a '''stand-alone namespace''' that is spawned using its own CLONE flag or by writing to a (securityfs) file. An IMA file measurement and appraisal policy would be activated when the IMA namespace is joined using setns() for example. If the appropriate set of MOUNT namespaces and USER namespace, providing file signatures and keys for signature verification respectively, is also joined, then only file appraisal will result in working file accesses, otherwise file accesses may be denied.<br />
<br />
The last two choices have their advantages and disadvantages. In order to avoid side effects on existing USER namespaces, the 3rd choice seems better suited. Though a system with IMA appraisal active in IMA namespaces will have restrictions when switching through MNT and possibly USER namespaces using setns(). Restrictions are related to file appraisal and possibly file access denials as well as file measurements.</div>Stefanbhttp://kernsec.org/wiki/index.php?title=IMA_Namespacing_design_considerations&diff=3973IMA Namespacing design considerations2018-04-30T19:14:43Z<p>Stefanb: /* IMA Namespacing Considerations */</p>
<hr />
<div>== Namespacing IMA ==<br />
<br />
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.<br />
<br />
=== Background ===<br />
<br />
IMA-measurement extends the concept of “trusted boot”[1] to the running OS. Based on policy, as files are accessed, executed, mmapped a hash of the file data is calculated and used to extend TPM[2], if enabled, and added to the IMA measurement list. The current builtin IMA-measurement Trusted Computing Base (TCB) policies measures all files read by root or executed/mmapped by any user. It also measures all kernel modules and firmware, when they are loaded, as well as the IMA policy itself. <br />
<br />
IMA-appraisal: extends the concept of “secure boot”[3] to the running OS. Based on policy, as files are accessed, executed, mmapped the file hash is calculated and used to verify the known good value as stored in the security.ima xattr. Stored in the security.ima xattr could be either a file hash or a signature. The keys for verifying the file data signature are found in IMA specific keyrings .ima or _ima. <br />
<br />
IMA-audit: adds system audit records containing the file hash to the system audit log. The IMA-audit records can be used to augment existing security analytics software and be used for system forensics.<br />
<br />
Namespacing each of these features requires not only adding IMA namespacing support, but requires some additional kernel changes. Our goals are to ultimately enable IMA-measurement, IMA-appraisal, and IMA-audit inside a container using Linux namespaces. Namespacing these different aspects of IMA is a major under taking and needs to be staged in manageable pieces.<br />
<br />
=== IMA Namespacing Considerations ===<br />
<br />
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:<br />
<br />
<br />
Support for IMA in namespaces should enable the following:<br />
<br />
- IMA policy for container (similar to the host):<br />
- there should be an initial default policy for every IMA namespace that measures activities inside the container<br />
- the uid in policy rules are relative to the uid's of the user namespace that is active; uid=0 refers to root inside the user namespace<br />
- like the existing builtin policies can be replaced with a custom policy once, the namespace policy can be replaced with a user-defined<br />
custom policy once. Both the initial and custom namespace IMA policies would be independent of that of the host policy.<br />
- CAP_SYS_ADMIN is currently gating the setting of the IMA policy; <br />
- setting the policy should be possibly without the almighty CAP_SYS_ADMIN<br />
- 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<br />
<br />
- IMA policy extensions due to namespacing:<br />
- an IMA policy should allow rules that define whether activities in (all) child namespaces is to be measured (huge logs on the host)<br />
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<br />
host could possibly eat up a lot of memory<br />
- to prevent (host) root from spawning new IMA namespaces and doing things undetected in the TCB, all activities of root must be <br />
''measured and audited'' in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- The existing builtin policies assume policy rules are based on the global “uid” or “fowner”, not based on the namespaced “uid” or “fowner”.<br />
Instead of explicitly including specific “uid” or “fowner” rules for each container, allow rules to be specified in terms of the namespaced<br />
“uid” or “fowner”. For example, “measure func=FILE_CHECK mask=^MAY_READ uid=0 ns” means measure all files opened for read by root in the<br />
namespace and “appraise fowner=0 ns” means appraise all files owned by root in the namespace.<br />
- The measurement list size is currently unbounded. Additional rules, which measure files opened by root in the namespace or appraise files<br />
owned by root in the namespace, will add additional system memory pressures. <br />
<br />
- IMA-measurement:<br />
- to prevent (host) root from spawning new IMA namespaces and doing things undetected in the TCB, all activities of root must be<br />
''measured'' and audited in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-audit:<br />
- to prevent (host) root from spawning new IMA namespaces and doing things undetected in the TCB, all activities of root must be<br />
measured and ''audited'' in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-appraisal and keys:<br />
- each IMA namespace should have its own keyring so that each container can have its files signed with different keys<br />
- the keys (certificates) for verifying signatures may be found inside containers<br />
- it should be possible to enforce that only certified keys are loaded onto a keyring, similar to .ima on the host<br />
- the CA public key used for verifying that public keys (certificates) used for verifying signatures may be found inside the container<br />
or could be known to the container management stack<br />
<br />
- IMA-appraisal and namespacing:<br />
- 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<br />
(nested) IMA namespace where an empty IMA policy has been set? We would measure and audit root's activities as described above.<br />
What about appraising? Would we traverse all the IMA namespaces back to the init_ima_ns and evaluate signatures against the appraisal<br />
policy set there and assume we would always find the keys in the init_user_ns?<br />
<br />
Maybe the following would be a solution for appraising file accesses by (host) root with the key used for signature verification<br />
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<br />
active USER namespace where the key can be found<br />
<br />
for imans from current-IMA-NS backwards up to and including init_ima_ns:<br />
if policy(imans) has appraisal rules for this file:<br />
if file appraisal fails<br />
fail access<br />
else<br />
allow access<br />
break<br />
<br />
or simplified (again after evaluating file access with the current IMA namespace's policy and the currently<br />
active USER namespace where the key can be found)<br />
<br />
Appraise with policy of init_ima_ns and key found in .ima or _ima keyring of init_user_ns.<br />
<br />
- TPM and measurements:<br />
- The IMA namespace that holds the logs should be configurable to extend PCRs; since the single TPM of the host cannot be shared by <br />
containers, each IMA namespace would have to be associated with its own TPM instance (vTPM); measurement in the initial IMA namespace<br />
are extended into the hardware TPM as done already<br />
- Each IMA namespace should only have access to the sysfs entries of its own TPM instance; ideally, sysfs would only show a single TPM<br />
device entry when viewed from an IMA namespace; an alternative may be that all devices are shown but refuse read/write access to their<br />
files if it is initiated from the 'wrong' IMA namespace<br />
<br />
- Extended attribute security.ima:<br />
- A container should be able to set the security.ima extended attribute<br />
- this should be possibly without the almighty CAP_SYS_ADMIN;<br />
- we may want to gate this with a new capability CAP_SECURITY_XATTR_ADMIN that allows setting security extended attributes inside a<br />
container, possibly only during container build-time<br />
<br />
- Extended attribute security.ima and bind mounting<br />
- It may be necessary that different namespaces be able to sign the same bind-mounted file with different keys<br />
(I am thinking of bind-mounted files that the container management stack modifies and that may need to be signed for the container to<br />
be able to access them.)<br />
- Extended attributes, such as security.ima) may need to be virtualizeable (security.ima vs. security.ima@uid=1000 etc.)<br />
<br />
- SecurityFS:<br />
- every IMA namespace should have (read/write) access to the entries that are associated with its IMA namespace<br />
- the organization of IMA's securityfs directory structure should reflect the child-parent relationship of IMA namespaces;<br />
- there should be a directory called 'namespaces' where each child namespace would have a directory with the name of the IMA<br />
namespace's inode ('IMANS:4768263432') that leads to the files holding the information about that namespace<br />
<br />
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:<br />
<br />
What should happen with IMA logging, appraisal, and auditing if we setns() through all available<br />
- PID namespaces and send signals: log, appraise, and audit file activity following IMA policy with special handling for (host) root<br />
- IPC namespaces and send messages via IPC: same as for PID<br />
- UTS namespaces and setting hostname: same as for PID<br />
- NET namespaces and sending network traffic: same as for PID<br />
- CGROUP namespaces and configuring cgroups: same as for PID<br />
- 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<br />
to adapt the current implementation...] other than that, same as for PID?<br />
- MNT namespaces and access files or execute program: same as for PID; if active IMA namespace policy requires file appraisal, files would need<br />
to be signed with key from keyring in current USER namespace<br />
<br />
=== IMA namespaces and IMA policy semantics ===<br />
<br />
The following shows IMA policy rules and their semantics when applied to IMA namespaces:<br />
<br />
1) audit FUNC=BPRM_CHECK<br />
2) audit FUNC=BPRM_CHECK ns<br />
3) measure func=BPRM_CHECK<br />
<br />
The interpretation of these IMA policy rules is as follows:<br />
<br />
1) Files executed in the IMA namespace that has this policy rule and its child namespaces are audited once<br />
2) Files executed in a child namespace of the IMA namespace that has this policy rule are audited, even if already audited in the IMA namespace that has this policy rule or another namespace<br />
3) Files executed in the IMA namespace that has this policy rule and its child namespaces are measured once<br />
<br />
Note: Initially, the init_ima_ns will be the only IMA namespace that will have a policy.<br />
<br />
== Standalone IMA namespace versus IMA namespace attached to MOUNT namespace or USER namespace ==<br />
<br />
1) The first set of posted patches '''attached the IMA namespace to the MOUNT namespace''' and shared the CLONE_NEWNS flag. Whenever a new mount namespace was created, it also created a new IMA namespace. Similarly, a setns() on a MOUNT namespace would also join the conjoint IMA namespace. File measurements and appraisal of an IMA policy would work on the files in the MOUNT namespace. The key used for the appraisal would be in the currently setns()'d USER namespace (the current implementation of IMA would need to be fixed in that regard). This proposed implementation of conjoint MOUNT and IMA namespaces was rejected.<br />
<br />
2) Another choice is to '''attach the IMA namespace to the USER namespace'''. An IMA file measurement and appraisal policy would become activated when the conjoint USER and IMA namespaces are joined using setns() for example. Side effects of this include that joining a USER namespace activates an IMA policy, that, if appraisal is active, start appraising file accesses, which may include file access denials.<br />
<br />
3) The last choice is to have IMA be a '''stand-alone namespace''' that is spawned using its own CLONE flag or by writing to a (securityfs) file. An IMA file measurement and appraisal policy would be activated when the IMA namespace is joint using setns() for example. If the appropriate set of MOUNT namespaces and USER namespace, providing file signatures and keys for signature verification respectively, is also joined, then only file appraisal will result in working file accesses, otherwise file accesses may be denied.<br />
<br />
The last two choices have their advantages and disadvantages. In order to avoid side effects on existing USER namespaces, the 3rd choice seems better suited. Though a system with IMA appraisal active in IMA namespaces will have restrictions when switching through MNT and possibly USER namespaces using setns(). Restrictions are related to file appraisal and possibly file access denials as well as file measurements.</div>Stefanbhttp://kernsec.org/wiki/index.php?title=IMA_Namespacing_design_considerations&diff=3972IMA Namespacing design considerations2018-04-30T19:12:44Z<p>Stefanb: /* IMA Namespacing Considerations */</p>
<hr />
<div>== Namespacing IMA ==<br />
<br />
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.<br />
<br />
=== Background ===<br />
<br />
IMA-measurement extends the concept of “trusted boot”[1] to the running OS. Based on policy, as files are accessed, executed, mmapped a hash of the file data is calculated and used to extend TPM[2], if enabled, and added to the IMA measurement list. The current builtin IMA-measurement Trusted Computing Base (TCB) policies measures all files read by root or executed/mmapped by any user. It also measures all kernel modules and firmware, when they are loaded, as well as the IMA policy itself. <br />
<br />
IMA-appraisal: extends the concept of “secure boot”[3] to the running OS. Based on policy, as files are accessed, executed, mmapped the file hash is calculated and used to verify the known good value as stored in the security.ima xattr. Stored in the security.ima xattr could be either a file hash or a signature. The keys for verifying the file data signature are found in IMA specific keyrings .ima or _ima. <br />
<br />
IMA-audit: adds system audit records containing the file hash to the system audit log. The IMA-audit records can be used to augment existing security analytics software and be used for system forensics.<br />
<br />
Namespacing each of these features requires not only adding IMA namespacing support, but requires some additional kernel changes. Our goals are to ultimately enable IMA-measurement, IMA-appraisal, and IMA-audit inside a container using Linux namespaces. Namespacing these different aspects of IMA is a major under taking and needs to be staged in manageable pieces.<br />
<br />
=== IMA Namespacing Considerations ===<br />
<br />
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:<br />
<br />
<br />
Support for IMA in namespaces should enable the following:<br />
<br />
- IMA policy for container (similar to the host):<br />
- there should be an initial default policy for every IMA namespace that measures activities inside the container<br />
- the uid in policy rules are relative to the uid's of the user namespace that is active; uid=0 refers to root inside the user namespace<br />
- like the existing builtin policies can be replaced with a custom policy once, the namespace policy can be replaced with a user-defined<br />
custom policy once. Both the initial and custom namespace IMA policies would be independent of that of the host policy.<br />
- CAP_SYS_ADMIN is currently gating the setting of the IMA policy; <br />
- setting the policy should be possibly without the almighty CAP_SYS_ADMIN<br />
- 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<br />
<br />
- IMA policy extensions due to namespacing:<br />
- an IMA policy should allow rules that define whether activities in (all) child namespaces is to be measured (huge logs on the host)<br />
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<br />
host could possibly eat up a lot of memory<br />
- to prevent (host) root from spawning new IMA namespaces and doing things undetected in the TCB, all activities of root must be <br />
''measured and audited'' in all IMA namespaces independent of whether the policy enables logging or auditing in child namespacee<br />
- The existing builtin policies assume policy rules are based on the global “uid” or “fowner”, not based on the namespaced “uid” or “fowner”.<br />
Instead of explicitly including specific “uid” or “fowner” rules for each container, allow rules to be specified in terms of the namespaced<br />
“uid” or “fowner”. For example, “measure func=FILE_CHECK mask=^MAY_READ uid=0 ns” means measure all files opened for read by root in the<br />
namespace and “appraise fowner=0 ns” means appraise all files owned by root in the namespace.<br />
- The measurement list size is currently unbounded. Additional rules, which measure files opened by root in the namespace or appraise files<br />
owned by root in the namespace, will add additional system memory pressures. <br />
<br />
- IMA-measurement:<br />
- to prevent (host) root from spawning new IMA namespaces and doing things undetected in the TCB, all activities of root must be<br />
''measured'' and audited in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-audit:<br />
- to prevent (host) root from spawning new IMA namespaces and doing things undetected in the TCB, all activities of root must be<br />
measured and ''audited'' in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-appraisal and keys:<br />
- each IMA namespace should have its own keyring so that each container can have its files signed with different keys<br />
- the keys (certificates) for verifying signatures may be found inside containers<br />
- it should be possible to enforce that only certified keys are loaded onto a keyring, similar to .ima on the host<br />
- the CA public key used for verifying that public keys (certificates) used for verifying signatures may be found inside the container<br />
or could be known to the container management stack<br />
<br />
- IMA-appraisal and namespacing:<br />
- 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<br />
(nested) IMA namespace where an empty IMA policy has been set? We would measure and audit root's activities as described above.<br />
What about appraising? Would we traverse all the IMA namespaces back to the init_ima_ns and evaluate signatures against the appraisal<br />
policy set there and assume we would always find the keys in the init_user_ns?<br />
<br />
Maybe the following would be a solution for appraising file accesses by (host) root with the key used for signature verification<br />
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<br />
active USER namespace where the key can be found<br />
<br />
for imans from current-IMA-NS backwards up to and including init_ima_ns:<br />
if policy(imans) has appraisal rules for this file:<br />
if file appraisal fails<br />
fail access<br />
else<br />
allow access<br />
break<br />
<br />
or simplified (again after evaluating file access with the current IMA namespace's policy and the currently<br />
active USER namespace where the key can be found)<br />
<br />
Appraise with policy of init_ima_ns and key found in .ima or _ima keyring of init_user_ns.<br />
<br />
- TPM and measurements:<br />
- The IMA namespace that holds the logs should be configurable to extend PCRs; since the single TPM of the host cannot be shared by <br />
containers, each IMA namespace would have to be associated with its own TPM instance (vTPM); measurement in the initial IMA namespace<br />
are extended into the hardware TPM as done already<br />
- Each IMA namespace should only have access to the sysfs entries of its own TPM instance; ideally, sysfs would only show a single TPM<br />
device entry when viewed from an IMA namespace; an alternative may be that all devices are shown but refuse read/write access to their<br />
files if it is initiated from the 'wrong' IMA namespace<br />
<br />
- Extended attribute security.ima:<br />
- A container should be able to set the security.ima extended attribute<br />
- this should be possibly without the almighty CAP_SYS_ADMIN;<br />
- we may want to gate this with a new capability CAP_SECURITY_XATTR_ADMIN that allows setting security extended attributes inside a<br />
container, possibly only during container build-time<br />
<br />
- Extended attribute security.ima and bind mounting<br />
- It may be necessary that different namespaces be able to sign the same bind-mounted file with different keys<br />
(I am thinking of bind-mounted files that the container management stack modifies and that may need to be signed for the container to<br />
be able to access them.)<br />
- Extended attributes, such as security.ima) may need to be virtualizeable (security.ima vs. security.ima@uid=1000 etc.)<br />
<br />
- SecurityFS:<br />
- every IMA namespace should have (read/write) access to the entries that are associated with its IMA namespace<br />
- the organization of IMA's securityfs directory structure should reflect the child-parent relationship of IMA namespaces;<br />
- there should be a directory called 'namespaces' where each child namespace would have a directory with the name of the IMA<br />
namespace's inode ('IMANS:4768263432') that leads to the files holding the information about that namespace<br />
<br />
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:<br />
<br />
What should happen with IMA logging, appraisal, and auditing if we setns() through all available<br />
- PID namespaces and send signals: log, appraise, and audit file activity following IMA policy with special handling for (host) root<br />
- IPC namespaces and send messages via IPC: same as for PID<br />
- UTS namespaces and setting hostname: same as for PID<br />
- NET namespaces and sending network traffic: same as for PID<br />
- CGROUP namespaces and configuring cgroups: same as for PID<br />
- 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<br />
to adapt the current implementation...] other than that, same as for PID?<br />
- MNT namespaces and access files or execute program: same as for PID; if active IMA namespace policy requires file appraisal, files would need<br />
to be signed with key from keyring in current USER namespace<br />
<br />
=== IMA namespaces and IMA policy semantics ===<br />
<br />
The following shows IMA policy rules and their semantics when applied to IMA namespaces:<br />
<br />
1) audit FUNC=BPRM_CHECK<br />
2) audit FUNC=BPRM_CHECK ns<br />
3) measure func=BPRM_CHECK<br />
<br />
The interpretation of these IMA policy rules is as follows:<br />
<br />
1) Files executed in the IMA namespace that has this policy rule and its child namespaces are audited once<br />
2) Files executed in a child namespace of the IMA namespace that has this policy rule are audited, even if already audited in the IMA namespace that has this policy rule or another namespace<br />
3) Files executed in the IMA namespace that has this policy rule and its child namespaces are measured once<br />
<br />
Note: Initially, the init_ima_ns will be the only IMA namespace that will have a policy.<br />
<br />
== Standalone IMA namespace versus IMA namespace attached to MOUNT namespace or USER namespace ==<br />
<br />
1) The first set of posted patches '''attached the IMA namespace to the MOUNT namespace''' and shared the CLONE_NEWNS flag. Whenever a new mount namespace was created, it also created a new IMA namespace. Similarly, a setns() on a MOUNT namespace would also join the conjoint IMA namespace. File measurements and appraisal of an IMA policy would work on the files in the MOUNT namespace. The key used for the appraisal would be in the currently setns()'d USER namespace (the current implementation of IMA would need to be fixed in that regard). This proposed implementation of conjoint MOUNT and IMA namespaces was rejected.<br />
<br />
2) Another choice is to '''attach the IMA namespace to the USER namespace'''. An IMA file measurement and appraisal policy would become activated when the conjoint USER and IMA namespaces are joined using setns() for example. Side effects of this include that joining a USER namespace activates an IMA policy, that, if appraisal is active, start appraising file accesses, which may include file access denials.<br />
<br />
3) The last choice is to have IMA be a '''stand-alone namespace''' that is spawned using its own CLONE flag or by writing to a (securityfs) file. An IMA file measurement and appraisal policy would be activated when the IMA namespace is joint using setns() for example. If the appropriate set of MOUNT namespaces and USER namespace, providing file signatures and keys for signature verification respectively, is also joined, then only file appraisal will result in working file accesses, otherwise file accesses may be denied.<br />
<br />
The last two choices have their advantages and disadvantages. In order to avoid side effects on existing USER namespaces, the 3rd choice seems better suited. Though a system with IMA appraisal active in IMA namespaces will have restrictions when switching through MNT and possibly USER namespaces using setns(). Restrictions are related to file appraisal and possibly file access denials as well as file measurements.</div>Stefanbhttp://kernsec.org/wiki/index.php?title=IMA_Namespacing_design_considerations&diff=3971IMA Namespacing design considerations2018-04-30T19:12:21Z<p>Stefanb: /* IMA Namespacing Considerations */</p>
<hr />
<div>== Namespacing IMA ==<br />
<br />
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.<br />
<br />
=== Background ===<br />
<br />
IMA-measurement extends the concept of “trusted boot”[1] to the running OS. Based on policy, as files are accessed, executed, mmapped a hash of the file data is calculated and used to extend TPM[2], if enabled, and added to the IMA measurement list. The current builtin IMA-measurement Trusted Computing Base (TCB) policies measures all files read by root or executed/mmapped by any user. It also measures all kernel modules and firmware, when they are loaded, as well as the IMA policy itself. <br />
<br />
IMA-appraisal: extends the concept of “secure boot”[3] to the running OS. Based on policy, as files are accessed, executed, mmapped the file hash is calculated and used to verify the known good value as stored in the security.ima xattr. Stored in the security.ima xattr could be either a file hash or a signature. The keys for verifying the file data signature are found in IMA specific keyrings .ima or _ima. <br />
<br />
IMA-audit: adds system audit records containing the file hash to the system audit log. The IMA-audit records can be used to augment existing security analytics software and be used for system forensics.<br />
<br />
Namespacing each of these features requires not only adding IMA namespacing support, but requires some additional kernel changes. Our goals are to ultimately enable IMA-measurement, IMA-appraisal, and IMA-audit inside a container using Linux namespaces. Namespacing these different aspects of IMA is a major under taking and needs to be staged in manageable pieces.<br />
<br />
=== IMA Namespacing Considerations ===<br />
<br />
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:<br />
<br />
<br />
Support for IMA in namespaces should enable the following:<br />
<br />
- IMA policy for container (similar to the host):<br />
- there should be an initial default policy for every IMA namespace that measures activities inside the container<br />
- the uid in policy rules are relative to the uid's of the user namespace that is active; uid=0 refers to root inside the user namespace<br />
- like the existing builtin policies can be replaced with a custom policy once, the namespace policy can be replaced with a user-defined<br />
custom policy once. Both the initial and custom namespace IMA policies would be independent of that of the host policy.<br />
- CAP_SYS_ADMIN is currently gating the setting of the IMA policy; <br />
- setting the policy should be possibly without the almighty CAP_SYS_ADMIN<br />
- 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<br />
<br />
- IMA policy extensions due to namespacing:<br />
- an IMA policy should allow rules that define whether activities in (all) child namespaces is to be measured (huge logs on the host)<br />
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<br />
host could possibly eat up a lot of memory<br />
- to prevent (host) root from spawning new IMA namespaces and doing things undetected in the TCB, all activities of root must be <br />
''measured and audited'' in all IMA namespaces independent of whether the policy enables logging or auditing in child namespacee<br />
- The existing builtin policies assume policy rules are based on the global “uid” or “fowner”, not based on the namespaced “uid” or “fowner”.<br />
Instead of explicitly including specific “uid” or “fowner” rules for each container, allow rules to be specified in terms of the namespaced<br />
“uid” or “fowner”. For example, “measure func=FILE_CHECK mask=^MAY_READ uid=0 ns” means measure all files opened for read by root in the<br />
namespace and “appraise fowner=0 ns” means appraise all files owned by root in the namespace.<br />
- The measurement list size is currently unbounded. Additional rules, which measure files opened by root in the namespace or appraise files<br />
owned by root in the namespace, will add additional system memory pressures. <br />
<br />
- IMA-measurement:<br />
- to prevent (host) root from spawning new IMA namespaces and doing things undetected in the TCB, all activities of root must be<br />
''measured'' and audited in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-audit:<br />
- to prevent (host) root from spawning new IMA namespaces and doing things undetected in the TCB, all activities of root must be<br />
measured and ''audited'' in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-appraisal and keys:<br />
- each IMA namespace should have its own keyring so that each container can have its files signed with different keys<br />
- the keys (certificates) for verifying signatures may be found inside containers<br />
- it should be possible to enforce that only certified keys are loaded onto a keyring, similar to .ima on the host<br />
- the CA public key used for verifying that public keys (certificates) used for verifying signatures may be found inside the container<br />
or could be known to the container management stack<br />
<br />
- IMA-appraisal and namespacing:<br />
- 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<br />
(nested) IMA namespace where an empty IMA policy has been set? We would measure and audit root's activities as described above.<br />
What about appraising? Would we traverse all the IMA namespaces back to the init_ima_ns and evaluate signatures against the appraisal<br />
policy set there and assume we would always find the keys in the init_user_ns?<br />
<br />
Maybe the following would be a solution for appraising file accesses by (host) root with the key used for signature verification<br />
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<br />
active USER namespace where the key can be found<br />
<br />
for imans from current-IMA-NS backwards up to and including init_ima_ns:<br />
if policy(imans) has appraisal rules for this file:<br />
if file appraisal fails<br />
fail access<br />
else<br />
allow access<br />
break<br />
<br />
or simplified (again after evaluating file access with the current IMA namespace's policy and the currently<br />
active USER namespace where the key can be found)<br />
<br />
Appraise with policy of init_ima_ns and key found in .ima or _ima keyring of init_user_ns.<br />
<br />
- TPM and measurements:<br />
- The IMA namespace that holds the logs should be configurable to extend PCRs; since the single TPM of the host cannot be shared by <br />
containers, each IMA namespace would have to be associated with its own TPM instance (vTPM); measurement in the initial IMA namespace<br />
are extended into the hardware TPM as done already<br />
- Each IMA namespace should only have access to the sysfs entries of its own TPM instance; ideally, sysfs would only show a single TPM<br />
device entry when viewed from an IMA namespace; an alternative may be that all devices are shown but refuse read/write access to their<br />
files if it is initiated from the 'wrong' IMA namespace<br />
<br />
- Extended attribute security.ima:<br />
- A container should be able to set the security.ima extended attribute<br />
- this should be possibly without the almighty CAP_SYS_ADMIN;<br />
- we may want to gate this with a new capability CAP_SECURITY_XATTR_ADMIN that allows setting security extended attributes inside a<br />
container, possibly only during container build-time<br />
<br />
- Extended attribute security.ima and bind mounting<br />
- It may be necessary that different namespaces be able to sign the same bind-mounted file with different keys<br />
(I am thinking of bind-mounted files that the container management stack modifies and that may need to be signed for the container to<br />
be able to access them.)<br />
- Extended attributes, such as security.ima) may need to be virtualizeable (security.ima vs. security.ima@uid=1000 etc.)<br />
<br />
- SecurityFS:<br />
- every IMA namespace should have (read/write) access to the entries that are associated with its IMA namespace<br />
- the organization of IMA's securityfs directory structure should reflect the child-parent relationship of IMA namespaces;<br />
- there should be a directory called 'namespaces' where each child namespace would have a directory with the name of the IMA<br />
namespace's inode ('IMANS:4768263432') that leads to the files holding the information about that namespace<br />
<br />
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:<br />
<br />
What should happen with IMA logging, appraisal, and auditing if we setns() through all available<br />
- PID namespaces and send signals: log, appraise, and audit file activity following IMA policy with special handling for (host) root<br />
- IPC namespaces and send messages via IPC: same as for PID<br />
- UTS namespaces and setting hostname: same as for PID<br />
- NET namespaces and sending network traffic: same as for PID<br />
- CGROUP namespaces and configuring cgroups: same as for PID<br />
- 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<br />
to adapt the current implementation...] other than that, same as for PID?<br />
- MNT namespaces and access files or execute program: same as for PID; if active IMA namespace policy requires file appraisal, files would need<br />
to be signed with key from keyring in current USER namespace<br />
<br />
=== IMA namespaces and IMA policy semantics ===<br />
<br />
The following shows IMA policy rules and their semantics when applied to IMA namespaces:<br />
<br />
1) audit FUNC=BPRM_CHECK<br />
2) audit FUNC=BPRM_CHECK ns<br />
3) measure func=BPRM_CHECK<br />
<br />
The interpretation of these IMA policy rules is as follows:<br />
<br />
1) Files executed in the IMA namespace that has this policy rule and its child namespaces are audited once<br />
2) Files executed in a child namespace of the IMA namespace that has this policy rule are audited, even if already audited in the IMA namespace that has this policy rule or another namespace<br />
3) Files executed in the IMA namespace that has this policy rule and its child namespaces are measured once<br />
<br />
Note: Initially, the init_ima_ns will be the only IMA namespace that will have a policy.<br />
<br />
== Standalone IMA namespace versus IMA namespace attached to MOUNT namespace or USER namespace ==<br />
<br />
1) The first set of posted patches '''attached the IMA namespace to the MOUNT namespace''' and shared the CLONE_NEWNS flag. Whenever a new mount namespace was created, it also created a new IMA namespace. Similarly, a setns() on a MOUNT namespace would also join the conjoint IMA namespace. File measurements and appraisal of an IMA policy would work on the files in the MOUNT namespace. The key used for the appraisal would be in the currently setns()'d USER namespace (the current implementation of IMA would need to be fixed in that regard). This proposed implementation of conjoint MOUNT and IMA namespaces was rejected.<br />
<br />
2) Another choice is to '''attach the IMA namespace to the USER namespace'''. An IMA file measurement and appraisal policy would become activated when the conjoint USER and IMA namespaces are joined using setns() for example. Side effects of this include that joining a USER namespace activates an IMA policy, that, if appraisal is active, start appraising file accesses, which may include file access denials.<br />
<br />
3) The last choice is to have IMA be a '''stand-alone namespace''' that is spawned using its own CLONE flag or by writing to a (securityfs) file. An IMA file measurement and appraisal policy would be activated when the IMA namespace is joint using setns() for example. If the appropriate set of MOUNT namespaces and USER namespace, providing file signatures and keys for signature verification respectively, is also joined, then only file appraisal will result in working file accesses, otherwise file accesses may be denied.<br />
<br />
The last two choices have their advantages and disadvantages. In order to avoid side effects on existing USER namespaces, the 3rd choice seems better suited. Though a system with IMA appraisal active in IMA namespaces will have restrictions when switching through MNT and possibly USER namespaces using setns(). Restrictions are related to file appraisal and possibly file access denials as well as file measurements.</div>Stefanbhttp://kernsec.org/wiki/index.php?title=IMA_Namespacing_design_considerations&diff=3970IMA Namespacing design considerations2018-04-30T17:57:54Z<p>Stefanb: /* Namespacing IMA */</p>
<hr />
<div>== Namespacing IMA ==<br />
<br />
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.<br />
<br />
=== Background ===<br />
<br />
IMA-measurement extends the concept of “trusted boot”[1] to the running OS. Based on policy, as files are accessed, executed, mmapped a hash of the file data is calculated and used to extend TPM[2], if enabled, and added to the IMA measurement list. The current builtin IMA-measurement Trusted Computing Base (TCB) policies measures all files read by root or executed/mmapped by any user. It also measures all kernel modules and firmware, when they are loaded, as well as the IMA policy itself. <br />
<br />
IMA-appraisal: extends the concept of “secure boot”[3] to the running OS. Based on policy, as files are accessed, executed, mmapped the file hash is calculated and used to verify the known good value as stored in the security.ima xattr. Stored in the security.ima xattr could be either a file hash or a signature. The keys for verifying the file data signature are found in IMA specific keyrings .ima or _ima. <br />
<br />
IMA-audit: adds system audit records containing the file hash to the system audit log. The IMA-audit records can be used to augment existing security analytics software and be used for system forensics.<br />
<br />
Namespacing each of these features requires not only adding IMA namespacing support, but requires some additional kernel changes. Our goals are to ultimately enable IMA-measurement, IMA-appraisal, and IMA-audit inside a container using Linux namespaces. Namespacing these different aspects of IMA is a major under taking and needs to be staged in manageable pieces.<br />
<br />
=== IMA Namespacing Considerations ===<br />
<br />
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:<br />
<br />
<br />
Support for IMA in namespaces should enable the following:<br />
<br />
- IMA policy for container (similar to the host):<br />
- there should be an initial default policy for every IMA namespace that measures activities inside the container<br />
- the policy can be overwritten once with a user-defined policy that may activate appraisal; this policy would be independent of that of<br />
the host<br />
- CAP_SYS_ADMIN is currently gating the setting of the IMA policy; <br />
- setting the policy should be possibly without the almighty CAP_SYS_ADMIN<br />
- 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<br />
<br />
- IMA policy extensions due to namespacing:<br />
- an IMA policy should allow rules that define whether activities in (all) child namespaces is to be measured (huge logs on the host)<br />
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<br />
host could possibly eat up a lot of memory<br />
- to prevent (host) root from spawning new IMA namespaces and doing things undetected in the TCB, all activities of root must be <br />
''measured and audited'' in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
<br />
- IMA-measurement:<br />
- to prevent (host) root from spawning new IMA namespaces and doing things undetected in the TCB, all activities of root must be<br />
''measured'' and audited in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-audit:<br />
- to prevent (host) root from spawning new IMA namespaces and doing things undetected in the TCB, all activities of root must be<br />
measured and ''audited'' in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-appraisal and keys:<br />
- each IMA namespace should have its own keyring so that each container can have its files signed with different keys<br />
- the keys (certificates) for verifying signatures may be found inside containers<br />
- it should be possible to enforce that only certified keys are loaded onto a keyring, similar to .ima on the host<br />
- the CA public key used for verifying that public keys (certificates) used for verifying signatures may be found inside the container<br />
or could be known to the container management stack<br />
<br />
- IMA-appraisal and namespacing:<br />
- 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<br />
(nested) IMA namespace where an empty IMA policy has been set? We would measure and audit root's activities as described above.<br />
What about appraising? Would we traverse all the IMA namespaces back to the init_ima_ns and evaluate signatures against the appraisal<br />
policy set there and assume we would always find the keys in the init_user_ns?<br />
<br />
Maybe the following would be a solution for appraising file accesses by (host) root with the key used for signature verification<br />
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<br />
active USER namespace where the key can be found<br />
<br />
for imans from current-IMA-NS backwards up to and including init_ima_ns:<br />
if policy(imans) has appraisal rules for this file:<br />
if file appraisal fails<br />
fail access<br />
else<br />
allow access<br />
break<br />
<br />
or simplified (again after evaluating file access with the current IMA namespace's policy and the currently<br />
active USER namespace where the key can be found)<br />
<br />
Appraise with policy of init_ima_ns and key found in .ima or _ima keyring of init_user_ns.<br />
<br />
- TPM and measurements:<br />
- The IMA namespace that holds the logs should be configurable to extend PCRs; since the single TPM of the host cannot be shared by <br />
containers, each IMA namespace would have to be associated with its own TPM instance (vTPM); measurement in the initial IMA namespace<br />
are extended into the hardware TPM as done already<br />
- Each IMA namespace should only have access to the sysfs entries of its own TPM instance; ideally, sysfs would only show a single TPM<br />
device entry when viewed from an IMA namespace; an alternative may be that all devices are shown but refuse read/write access to their<br />
files if it is initiated from the 'wrong' IMA namespace<br />
<br />
- Extended attribute security.ima:<br />
- A container should be able to set the security.ima extended attribute<br />
- this should be possibly without the almighty CAP_SYS_ADMIN;<br />
- we may want to gate this with a new capability CAP_SECURITY_XATTR_ADMIN that allows setting security extended attributes inside a<br />
container, possibly only during container build-time<br />
<br />
- Extended attribute security.ima and bind mounting<br />
- It may be necessary that different namespaces be able to sign the same bind-mounted file with different keys<br />
(I am thinking of bind-mounted files that the container management stack modifies and that may need to be signed for the container to<br />
be able to access them.)<br />
- Extended attributes, such as security.ima) may need to be virtualizeable (security.ima vs. security.ima@uid=1000 etc.)<br />
<br />
- SecurityFS:<br />
- every IMA namespace should have (read/write) access to the entries that are associated with its IMA namespace<br />
- the organization of IMA's securityfs directory structure should reflect the child-parent relationship of IMA namespaces;<br />
- there should be a directory called 'namespaces' where each child namespace would have a directory with the name of the IMA<br />
namespace's inode ('IMANS:4768263432') that leads to the files holding the information about that namespace<br />
<br />
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:<br />
<br />
What should happen with IMA logging, appraisal, and auditing if we setns() through all available<br />
- PID namespaces and send signals: log, appraise, and audit file activity following IMA policy with special handling for (host) root<br />
- IPC namespaces and send messages via IPC: same as for PID<br />
- UTS namespaces and setting hostname: same as for PID<br />
- NET namespaces and sending network traffic: same as for PID<br />
- CGROUP namespaces and configuring cgroups: same as for PID<br />
- 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<br />
to adapt the current implementation...] other than that, same as for PID?<br />
- MNT namespaces and access files or execute program: same as for PID; if active IMA namespace policy requires file appraisal, files would need<br />
to be signed with key from keyring in current USER namespace<br />
<br />
=== IMA namespaces and IMA policy semantics ===<br />
<br />
The following shows IMA policy rules and their semantics when applied to IMA namespaces:<br />
<br />
1) audit FUNC=BPRM_CHECK<br />
2) audit FUNC=BPRM_CHECK ns<br />
3) measure func=BPRM_CHECK<br />
<br />
The interpretation of these IMA policy rules is as follows:<br />
<br />
1) Files executed in the IMA namespace that has this policy rule and its child namespaces are audited once<br />
2) Files executed in a child namespace of the IMA namespace that has this policy rule are audited, even if already audited in the IMA namespace that has this policy rule or another namespace<br />
3) Files executed in the IMA namespace that has this policy rule and its child namespaces are measured once<br />
<br />
Note: Initially, the init_ima_ns will be the only IMA namespace that will have a policy.<br />
<br />
== Standalone IMA namespace versus IMA namespace attached to MOUNT namespace or USER namespace ==<br />
<br />
1) The first set of posted patches '''attached the IMA namespace to the MOUNT namespace''' and shared the CLONE_NEWNS flag. Whenever a new mount namespace was created, it also created a new IMA namespace. Similarly, a setns() on a MOUNT namespace would also join the conjoint IMA namespace. File measurements and appraisal of an IMA policy would work on the files in the MOUNT namespace. The key used for the appraisal would be in the currently setns()'d USER namespace (the current implementation of IMA would need to be fixed in that regard). This proposed implementation of conjoint MOUNT and IMA namespaces was rejected.<br />
<br />
2) Another choice is to '''attach the IMA namespace to the USER namespace'''. An IMA file measurement and appraisal policy would become activated when the conjoint USER and IMA namespaces are joined using setns() for example. Side effects of this include that joining a USER namespace activates an IMA policy, that, if appraisal is active, start appraising file accesses, which may include file access denials.<br />
<br />
3) The last choice is to have IMA be a '''stand-alone namespace''' that is spawned using its own CLONE flag or by writing to a (securityfs) file. An IMA file measurement and appraisal policy would be activated when the IMA namespace is joint using setns() for example. If the appropriate set of MOUNT namespaces and USER namespace, providing file signatures and keys for signature verification respectively, is also joined, then only file appraisal will result in working file accesses, otherwise file accesses may be denied.<br />
<br />
The last two choices have their advantages and disadvantages. In order to avoid side effects on existing USER namespaces, the 3rd choice seems better suited. Though a system with IMA appraisal active in IMA namespaces will have restrictions when switching through MNT and possibly USER namespaces using setns(). Restrictions are related to file appraisal and possibly file access denials as well as file measurements.</div>Stefanbhttp://kernsec.org/wiki/index.php?title=IMA_Namespacing_design_considerations&diff=3969IMA Namespacing design considerations2018-04-30T17:54:55Z<p>Stefanb: /* Background */</p>
<hr />
<div>== Namespacing IMA ==<br />
<br />
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.<br />
<br />
=== Background ===<br />
<br />
IMA-measurement extends the concept of “trusted boot”[1] to the running OS. Based on policy, as files are accessed, executed, mmapped a hash of the file data is calculated and used to extend TPM[2], if enabled, and added to the IMA measurement list. The current builtin IMA-measurement Trusted Computing Base (TCB) policies measures all files read by root or executed/mmapped by any user. It also measures all kernel modules and firmware, when they are loaded, as well as the IMA policy itself. <br />
<br />
IMA-appraisal: extends the concept of “secure boot”[3] to the running OS. Based on policy, as files are accessed, executed, mmapped the file hash is calculated and used to verify the known good value as stored in the security.ima xattr. Stored in the security.ima xattr could be either a file hash or a signature. The keys for verifying the file data signature are found in IMA specific keyrings .ima or _ima. <br />
<br />
IMA-audit: adds system audit records containing the file hash to the system audit log. The IMA-audit records can be used to augment existing security analytics software and be used for system forensics.<br />
<br />
Namespacing each of these features requires not only adding IMA namespacing support, but requires some additional kernel changes.<br />
<br />
=== IMA Namespacing Considerations ===<br />
<br />
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:<br />
<br />
<br />
Support for IMA in namespaces should enable the following:<br />
<br />
- IMA policy for container (similar to the host):<br />
- there should be an initial default policy for every IMA namespace that measures activities inside the container<br />
- the policy can be overwritten once with a user-defined policy that may activate appraisal; this policy would be independent of that of<br />
the host<br />
- CAP_SYS_ADMIN is currently gating the setting of the IMA policy; <br />
- setting the policy should be possibly without the almighty CAP_SYS_ADMIN<br />
- 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<br />
<br />
- IMA policy extensions due to namespacing:<br />
- an IMA policy should allow rules that define whether activities in (all) child namespaces is to be measured (huge logs on the host)<br />
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<br />
host could possibly eat up a lot of memory<br />
- to prevent (host) root from spawning new IMA namespaces and doing things undetected in the TCB, all activities of root must be <br />
''measured and audited'' in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
<br />
- IMA-measurement:<br />
- to prevent (host) root from spawning new IMA namespaces and doing things undetected in the TCB, all activities of root must be<br />
''measured'' and audited in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-audit:<br />
- to prevent (host) root from spawning new IMA namespaces and doing things undetected in the TCB, all activities of root must be<br />
measured and ''audited'' in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-appraisal and keys:<br />
- each IMA namespace should have its own keyring so that each container can have its files signed with different keys<br />
- the keys (certificates) for verifying signatures may be found inside containers<br />
- it should be possible to enforce that only certified keys are loaded onto a keyring, similar to .ima on the host<br />
- the CA public key used for verifying that public keys (certificates) used for verifying signatures may be found inside the container<br />
or could be known to the container management stack<br />
<br />
- IMA-appraisal and namespacing:<br />
- 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<br />
(nested) IMA namespace where an empty IMA policy has been set? We would measure and audit root's activities as described above.<br />
What about appraising? Would we traverse all the IMA namespaces back to the init_ima_ns and evaluate signatures against the appraisal<br />
policy set there and assume we would always find the keys in the init_user_ns?<br />
<br />
Maybe the following would be a solution for appraising file accesses by (host) root with the key used for signature verification<br />
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<br />
active USER namespace where the key can be found<br />
<br />
for imans from current-IMA-NS backwards up to and including init_ima_ns:<br />
if policy(imans) has appraisal rules for this file:<br />
if file appraisal fails<br />
fail access<br />
else<br />
allow access<br />
break<br />
<br />
or simplified (again after evaluating file access with the current IMA namespace's policy and the currently<br />
active USER namespace where the key can be found)<br />
<br />
Appraise with policy of init_ima_ns and key found in .ima or _ima keyring of init_user_ns.<br />
<br />
- TPM and measurements:<br />
- The IMA namespace that holds the logs should be configurable to extend PCRs; since the single TPM of the host cannot be shared by <br />
containers, each IMA namespace would have to be associated with its own TPM instance (vTPM); measurement in the initial IMA namespace<br />
are extended into the hardware TPM as done already<br />
- Each IMA namespace should only have access to the sysfs entries of its own TPM instance; ideally, sysfs would only show a single TPM<br />
device entry when viewed from an IMA namespace; an alternative may be that all devices are shown but refuse read/write access to their<br />
files if it is initiated from the 'wrong' IMA namespace<br />
<br />
- Extended attribute security.ima:<br />
- A container should be able to set the security.ima extended attribute<br />
- this should be possibly without the almighty CAP_SYS_ADMIN;<br />
- we may want to gate this with a new capability CAP_SECURITY_XATTR_ADMIN that allows setting security extended attributes inside a<br />
container, possibly only during container build-time<br />
<br />
- Extended attribute security.ima and bind mounting<br />
- It may be necessary that different namespaces be able to sign the same bind-mounted file with different keys<br />
(I am thinking of bind-mounted files that the container management stack modifies and that may need to be signed for the container to<br />
be able to access them.)<br />
- Extended attributes, such as security.ima) may need to be virtualizeable (security.ima vs. security.ima@uid=1000 etc.)<br />
<br />
- SecurityFS:<br />
- every IMA namespace should have (read/write) access to the entries that are associated with its IMA namespace<br />
- the organization of IMA's securityfs directory structure should reflect the child-parent relationship of IMA namespaces;<br />
- there should be a directory called 'namespaces' where each child namespace would have a directory with the name of the IMA<br />
namespace's inode ('IMANS:4768263432') that leads to the files holding the information about that namespace<br />
<br />
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:<br />
<br />
What should happen with IMA logging, appraisal, and auditing if we setns() through all available<br />
- PID namespaces and send signals: log, appraise, and audit file activity following IMA policy with special handling for (host) root<br />
- IPC namespaces and send messages via IPC: same as for PID<br />
- UTS namespaces and setting hostname: same as for PID<br />
- NET namespaces and sending network traffic: same as for PID<br />
- CGROUP namespaces and configuring cgroups: same as for PID<br />
- 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<br />
to adapt the current implementation...] other than that, same as for PID?<br />
- MNT namespaces and access files or execute program: same as for PID; if active IMA namespace policy requires file appraisal, files would need<br />
to be signed with key from keyring in current USER namespace<br />
<br />
=== IMA namespaces and IMA policy semantics ===<br />
<br />
The following shows IMA policy rules and their semantics when applied to IMA namespaces:<br />
<br />
1) audit FUNC=BPRM_CHECK<br />
2) audit FUNC=BPRM_CHECK ns<br />
3) measure func=BPRM_CHECK<br />
<br />
The interpretation of these IMA policy rules is as follows:<br />
<br />
1) Files executed in the IMA namespace that has this policy rule and its child namespaces are audited once<br />
2) Files executed in a child namespace of the IMA namespace that has this policy rule are audited, even if already audited in the IMA namespace that has this policy rule or another namespace<br />
3) Files executed in the IMA namespace that has this policy rule and its child namespaces are measured once<br />
<br />
Note: Initially, the init_ima_ns will be the only IMA namespace that will have a policy.<br />
<br />
== Standalone IMA namespace versus IMA namespace attached to MOUNT namespace or USER namespace ==<br />
<br />
1) The first set of posted patches '''attached the IMA namespace to the MOUNT namespace''' and shared the CLONE_NEWNS flag. Whenever a new mount namespace was created, it also created a new IMA namespace. Similarly, a setns() on a MOUNT namespace would also join the conjoint IMA namespace. File measurements and appraisal of an IMA policy would work on the files in the MOUNT namespace. The key used for the appraisal would be in the currently setns()'d USER namespace (the current implementation of IMA would need to be fixed in that regard). This proposed implementation of conjoint MOUNT and IMA namespaces was rejected.<br />
<br />
2) Another choice is to '''attach the IMA namespace to the USER namespace'''. An IMA file measurement and appraisal policy would become activated when the conjoint USER and IMA namespaces are joined using setns() for example. Side effects of this include that joining a USER namespace activates an IMA policy, that, if appraisal is active, start appraising file accesses, which may include file access denials.<br />
<br />
3) The last choice is to have IMA be a '''stand-alone namespace''' that is spawned using its own CLONE flag or by writing to a (securityfs) file. An IMA file measurement and appraisal policy would be activated when the IMA namespace is joint using setns() for example. If the appropriate set of MOUNT namespaces and USER namespace, providing file signatures and keys for signature verification respectively, is also joined, then only file appraisal will result in working file accesses, otherwise file accesses may be denied.<br />
<br />
The last two choices have their advantages and disadvantages. In order to avoid side effects on existing USER namespaces, the 3rd choice seems better suited. Though a system with IMA appraisal active in IMA namespaces will have restrictions when switching through MNT and possibly USER namespaces using setns(). Restrictions are related to file appraisal and possibly file access denials as well as file measurements.</div>Stefanbhttp://kernsec.org/wiki/index.php?title=IMA_Namespacing_design_considerations&diff=3963IMA Namespacing design considerations2018-04-20T13:22:16Z<p>Stefanb: /* IMA namespaces and IMA policy semantics */</p>
<hr />
<div>== Namespacing IMA ==<br />
<br />
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.<br />
<br />
=== Background ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== IMA Namespacing Considerations ===<br />
<br />
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:<br />
<br />
<br />
Support for IMA in namespaces should enable the following:<br />
<br />
- IMA policy for container (similar to the host):<br />
- there should be an initial default policy for every IMA namespace that measures activities inside the container<br />
- the policy can be overwritten once with a user-defined policy that may activate appraisal; this policy would be independent of that of<br />
the host<br />
- CAP_SYS_ADMIN is currently gating the setting of the IMA policy; <br />
- setting the policy should be possibly without the almighty CAP_SYS_ADMIN<br />
- 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<br />
<br />
- IMA policy extensions due to namespacing:<br />
- an IMA policy should allow rules that define whether activities in (all) child namespaces is to be measured (huge logs on the host)<br />
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<br />
host could possibly eat up a lot of memory<br />
- to prevent (host) root from spawning new IMA namespaces and doing things undetected in the TCB, all activities of root must be <br />
''measured and audited'' in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
<br />
- IMA-measurement:<br />
- to prevent (host) root from spawning new IMA namespaces and doing things undetected in the TCB, all activities of root must be<br />
''measured'' and audited in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-audit:<br />
- to prevent (host) root from spawning new IMA namespaces and doing things undetected in the TCB, all activities of root must be<br />
measured and ''audited'' in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-appraisal and keys:<br />
- each IMA namespace should have its own keyring so that each container can have its files signed with different keys<br />
- the keys (certificates) for verifying signatures may be found inside containers<br />
- it should be possible to enforce that only certified keys are loaded onto a keyring, similar to .ima on the host<br />
- the CA public key used for verifying that public keys (certificates) used for verifying signatures may be found inside the container<br />
or could be known to the container management stack<br />
<br />
- IMA-appraisal and namespacing:<br />
- 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<br />
(nested) IMA namespace where an empty IMA policy has been set? We would measure and audit root's activities as described above.<br />
What about appraising? Would we traverse all the IMA namespaces back to the init_ima_ns and evaluate signatures against the appraisal<br />
policy set there and assume we would always find the keys in the init_user_ns?<br />
<br />
Maybe the following would be a solution for appraising file accesses by (host) root with the key used for signature verification<br />
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<br />
active USER namespace where the key can be found<br />
<br />
for imans from current-IMA-NS backwards up to and including init_ima_ns:<br />
if policy(imans) has appraisal rules for this file:<br />
if file appraisal fails<br />
fail access<br />
else<br />
allow access<br />
break<br />
<br />
or simplified (again after evaluating file access with the current IMA namespace's policy and the currently<br />
active USER namespace where the key can be found)<br />
<br />
Appraise with policy of init_ima_ns and key found in .ima or _ima keyring of init_user_ns.<br />
<br />
- TPM and measurements:<br />
- The IMA namespace that holds the logs should be configurable to extend PCRs; since the single TPM of the host cannot be shared by <br />
containers, each IMA namespace would have to be associated with its own TPM instance (vTPM); measurement in the initial IMA namespace<br />
are extended into the hardware TPM as done already<br />
- Each IMA namespace should only have access to the sysfs entries of its own TPM instance; ideally, sysfs would only show a single TPM<br />
device entry when viewed from an IMA namespace; an alternative may be that all devices are shown but refuse read/write access to their<br />
files if it is initiated from the 'wrong' IMA namespace<br />
<br />
- Extended attribute security.ima:<br />
- A container should be able to set the security.ima extended attribute<br />
- this should be possibly without the almighty CAP_SYS_ADMIN;<br />
- we may want to gate this with a new capability CAP_SECURITY_XATTR_ADMIN that allows setting security extended attributes inside a<br />
container, possibly only during container build-time<br />
<br />
- Extended attribute security.ima and bind mounting<br />
- It may be necessary that different namespaces be able to sign the same bind-mounted file with different keys<br />
(I am thinking of bind-mounted files that the container management stack modifies and that may need to be signed for the container to<br />
be able to access them.)<br />
- Extended attributes, such as security.ima) may need to be virtualizeable (security.ima vs. security.ima@uid=1000 etc.)<br />
<br />
- SecurityFS:<br />
- every IMA namespace should have (read/write) access to the entries that are associated with its IMA namespace<br />
- the organization of IMA's securityfs directory structure should reflect the child-parent relationship of IMA namespaces;<br />
- there should be a directory called 'namespaces' where each child namespace would have a directory with the name of the IMA<br />
namespace's inode ('IMANS:4768263432') that leads to the files holding the information about that namespace<br />
<br />
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:<br />
<br />
What should happen with IMA logging, appraisal, and auditing if we setns() through all available<br />
- PID namespaces and send signals: log, appraise, and audit file activity following IMA policy with special handling for (host) root<br />
- IPC namespaces and send messages via IPC: same as for PID<br />
- UTS namespaces and setting hostname: same as for PID<br />
- NET namespaces and sending network traffic: same as for PID<br />
- CGROUP namespaces and configuring cgroups: same as for PID<br />
- 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<br />
to adapt the current implementation...] other than that, same as for PID?<br />
- MNT namespaces and access files or execute program: same as for PID; if active IMA namespace policy requires file appraisal, files would need<br />
to be signed with key from keyring in current USER namespace<br />
<br />
=== IMA namespaces and IMA policy semantics ===<br />
<br />
The following shows IMA policy rules and their semantics when applied to IMA namespaces:<br />
<br />
1) audit FUNC=BPRM_CHECK<br />
2) audit FUNC=BPRM_CHECK ns<br />
3) measure func=BPRM_CHECK<br />
<br />
The interpretation of these IMA policy rules is as follows:<br />
<br />
1) Files executed in the IMA namespace that has this policy rule and its child namespaces are audited once<br />
2) Files executed in a child namespace of the IMA namespace that has this policy rule are audited, even if already audited in the IMA namespace that has this policy rule or another namespace<br />
3) Files executed in the IMA namespace that has this policy rule and its child namespaces are measured once<br />
<br />
Note: Initially, the init_ima_ns will be the only IMA namespace that will have a policy.<br />
<br />
== Standalone IMA namespace versus IMA namespace attached to MOUNT namespace or USER namespace ==<br />
<br />
1) The first set of posted patches '''attached the IMA namespace to the MOUNT namespace''' and shared the CLONE_NEWNS flag. Whenever a new mount namespace was created, it also created a new IMA namespace. Similarly, a setns() on a MOUNT namespace would also join the conjoint IMA namespace. File measurements and appraisal of an IMA policy would work on the files in the MOUNT namespace. The key used for the appraisal would be in the currently setns()'d USER namespace (the current implementation of IMA would need to be fixed in that regard). This proposed implementation of conjoint MOUNT and IMA namespaces was rejected.<br />
<br />
2) Another choice is to '''attach the IMA namespace to the USER namespace'''. An IMA file measurement and appraisal policy would become activated when the conjoint USER and IMA namespaces are joined using setns() for example. Side effects of this include that joining a USER namespace activates an IMA policy, that, if appraisal is active, start appraising file accesses, which may include file access denials.<br />
<br />
3) The last choice is to have IMA be a '''stand-alone namespace''' that is spawned using its own CLONE flag or by writing to a (securityfs) file. An IMA file measurement and appraisal policy would be activated when the IMA namespace is joint using setns() for example. If the appropriate set of MOUNT namespaces and USER namespace, providing file signatures and keys for signature verification respectively, is also joined, then only file appraisal will result in working file accesses, otherwise file accesses may be denied.<br />
<br />
The last two choices have their advantages and disadvantages. In order to avoid side effects on existing USER namespaces, the 3rd choice seems better suited. Though a system with IMA appraisal active in IMA namespaces will have restrictions when switching through MNT and possibly USER namespaces using setns(). Restrictions are related to file appraisal and possibly file access denials as well as file measurements.</div>Stefanbhttp://kernsec.org/wiki/index.php?title=IMA_Namespacing_design_considerations&diff=3962IMA Namespacing design considerations2018-04-20T13:21:56Z<p>Stefanb: /* IMA namespaces and IMA policy semantics */</p>
<hr />
<div>== Namespacing IMA ==<br />
<br />
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.<br />
<br />
=== Background ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== IMA Namespacing Considerations ===<br />
<br />
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:<br />
<br />
<br />
Support for IMA in namespaces should enable the following:<br />
<br />
- IMA policy for container (similar to the host):<br />
- there should be an initial default policy for every IMA namespace that measures activities inside the container<br />
- the policy can be overwritten once with a user-defined policy that may activate appraisal; this policy would be independent of that of<br />
the host<br />
- CAP_SYS_ADMIN is currently gating the setting of the IMA policy; <br />
- setting the policy should be possibly without the almighty CAP_SYS_ADMIN<br />
- 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<br />
<br />
- IMA policy extensions due to namespacing:<br />
- an IMA policy should allow rules that define whether activities in (all) child namespaces is to be measured (huge logs on the host)<br />
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<br />
host could possibly eat up a lot of memory<br />
- to prevent (host) root from spawning new IMA namespaces and doing things undetected in the TCB, all activities of root must be <br />
''measured and audited'' in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
<br />
- IMA-measurement:<br />
- to prevent (host) root from spawning new IMA namespaces and doing things undetected in the TCB, all activities of root must be<br />
''measured'' and audited in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-audit:<br />
- to prevent (host) root from spawning new IMA namespaces and doing things undetected in the TCB, all activities of root must be<br />
measured and ''audited'' in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-appraisal and keys:<br />
- each IMA namespace should have its own keyring so that each container can have its files signed with different keys<br />
- the keys (certificates) for verifying signatures may be found inside containers<br />
- it should be possible to enforce that only certified keys are loaded onto a keyring, similar to .ima on the host<br />
- the CA public key used for verifying that public keys (certificates) used for verifying signatures may be found inside the container<br />
or could be known to the container management stack<br />
<br />
- IMA-appraisal and namespacing:<br />
- 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<br />
(nested) IMA namespace where an empty IMA policy has been set? We would measure and audit root's activities as described above.<br />
What about appraising? Would we traverse all the IMA namespaces back to the init_ima_ns and evaluate signatures against the appraisal<br />
policy set there and assume we would always find the keys in the init_user_ns?<br />
<br />
Maybe the following would be a solution for appraising file accesses by (host) root with the key used for signature verification<br />
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<br />
active USER namespace where the key can be found<br />
<br />
for imans from current-IMA-NS backwards up to and including init_ima_ns:<br />
if policy(imans) has appraisal rules for this file:<br />
if file appraisal fails<br />
fail access<br />
else<br />
allow access<br />
break<br />
<br />
or simplified (again after evaluating file access with the current IMA namespace's policy and the currently<br />
active USER namespace where the key can be found)<br />
<br />
Appraise with policy of init_ima_ns and key found in .ima or _ima keyring of init_user_ns.<br />
<br />
- TPM and measurements:<br />
- The IMA namespace that holds the logs should be configurable to extend PCRs; since the single TPM of the host cannot be shared by <br />
containers, each IMA namespace would have to be associated with its own TPM instance (vTPM); measurement in the initial IMA namespace<br />
are extended into the hardware TPM as done already<br />
- Each IMA namespace should only have access to the sysfs entries of its own TPM instance; ideally, sysfs would only show a single TPM<br />
device entry when viewed from an IMA namespace; an alternative may be that all devices are shown but refuse read/write access to their<br />
files if it is initiated from the 'wrong' IMA namespace<br />
<br />
- Extended attribute security.ima:<br />
- A container should be able to set the security.ima extended attribute<br />
- this should be possibly without the almighty CAP_SYS_ADMIN;<br />
- we may want to gate this with a new capability CAP_SECURITY_XATTR_ADMIN that allows setting security extended attributes inside a<br />
container, possibly only during container build-time<br />
<br />
- Extended attribute security.ima and bind mounting<br />
- It may be necessary that different namespaces be able to sign the same bind-mounted file with different keys<br />
(I am thinking of bind-mounted files that the container management stack modifies and that may need to be signed for the container to<br />
be able to access them.)<br />
- Extended attributes, such as security.ima) may need to be virtualizeable (security.ima vs. security.ima@uid=1000 etc.)<br />
<br />
- SecurityFS:<br />
- every IMA namespace should have (read/write) access to the entries that are associated with its IMA namespace<br />
- the organization of IMA's securityfs directory structure should reflect the child-parent relationship of IMA namespaces;<br />
- there should be a directory called 'namespaces' where each child namespace would have a directory with the name of the IMA<br />
namespace's inode ('IMANS:4768263432') that leads to the files holding the information about that namespace<br />
<br />
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:<br />
<br />
What should happen with IMA logging, appraisal, and auditing if we setns() through all available<br />
- PID namespaces and send signals: log, appraise, and audit file activity following IMA policy with special handling for (host) root<br />
- IPC namespaces and send messages via IPC: same as for PID<br />
- UTS namespaces and setting hostname: same as for PID<br />
- NET namespaces and sending network traffic: same as for PID<br />
- CGROUP namespaces and configuring cgroups: same as for PID<br />
- 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<br />
to adapt the current implementation...] other than that, same as for PID?<br />
- MNT namespaces and access files or execute program: same as for PID; if active IMA namespace policy requires file appraisal, files would need<br />
to be signed with key from keyring in current USER namespace<br />
<br />
=== IMA namespaces and IMA policy semantics ===<br />
<br />
The following shows IMA policy rules and their semantics when applied to IMA namespaces:<br />
<br />
1) audit FUNC=BPRM_CHECK<br />
2) audit FUNC=BPRM_CHECK ns<br />
3) measure func=BPRM_CHECK<br />
<br />
The interpretation of these IMA policy rules is as follows:<br />
<br />
1) Files executed in the IMA namespace that has this policy rule and its child namespaces are audited once<br />
2) Files executed in a child namespace of the IMA namespace that has this policy rule are audited, even if already audited in the IMA namespace that has this policy rule or another namespace<br />
3) Files executed in the IMA namespace that has this policy rule and its child namespaces are measured once<br />
<br />
Note: Initially, the init_ima_ns will be the only IMA namespace that will have a policy.<br />
<br />
== Standalone IMA namespace versus IMA namespace attached to MOUNT namespace or USER namespace ==<br />
<br />
1) The first set of posted patches '''attached the IMA namespace to the MOUNT namespace''' and shared the CLONE_NEWNS flag. Whenever a new mount namespace was created, it also created a new IMA namespace. Similarly, a setns() on a MOUNT namespace would also join the conjoint IMA namespace. File measurements and appraisal of an IMA policy would work on the files in the MOUNT namespace. The key used for the appraisal would be in the currently setns()'d USER namespace (the current implementation of IMA would need to be fixed in that regard). This proposed implementation of conjoint MOUNT and IMA namespaces was rejected.<br />
<br />
2) Another choice is to '''attach the IMA namespace to the USER namespace'''. An IMA file measurement and appraisal policy would become activated when the conjoint USER and IMA namespaces are joined using setns() for example. Side effects of this include that joining a USER namespace activates an IMA policy, that, if appraisal is active, start appraising file accesses, which may include file access denials.<br />
<br />
3) The last choice is to have IMA be a '''stand-alone namespace''' that is spawned using its own CLONE flag or by writing to a (securityfs) file. An IMA file measurement and appraisal policy would be activated when the IMA namespace is joint using setns() for example. If the appropriate set of MOUNT namespaces and USER namespace, providing file signatures and keys for signature verification respectively, is also joined, then only file appraisal will result in working file accesses, otherwise file accesses may be denied.<br />
<br />
The last two choices have their advantages and disadvantages. In order to avoid side effects on existing USER namespaces, the 3rd choice seems better suited. Though a system with IMA appraisal active in IMA namespaces will have restrictions when switching through MNT and possibly USER namespaces using setns(). Restrictions are related to file appraisal and possibly file access denials as well as file measurements.</div>Stefanbhttp://kernsec.org/wiki/index.php?title=IMA_Namespacing_design_considerations&diff=3961IMA Namespacing design considerations2018-04-20T13:21:32Z<p>Stefanb: /* Namespacing IMA */</p>
<hr />
<div>== Namespacing IMA ==<br />
<br />
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.<br />
<br />
=== Background ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== IMA Namespacing Considerations ===<br />
<br />
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:<br />
<br />
<br />
Support for IMA in namespaces should enable the following:<br />
<br />
- IMA policy for container (similar to the host):<br />
- there should be an initial default policy for every IMA namespace that measures activities inside the container<br />
- the policy can be overwritten once with a user-defined policy that may activate appraisal; this policy would be independent of that of<br />
the host<br />
- CAP_SYS_ADMIN is currently gating the setting of the IMA policy; <br />
- setting the policy should be possibly without the almighty CAP_SYS_ADMIN<br />
- 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<br />
<br />
- IMA policy extensions due to namespacing:<br />
- an IMA policy should allow rules that define whether activities in (all) child namespaces is to be measured (huge logs on the host)<br />
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<br />
host could possibly eat up a lot of memory<br />
- to prevent (host) root from spawning new IMA namespaces and doing things undetected in the TCB, all activities of root must be <br />
''measured and audited'' in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
<br />
- IMA-measurement:<br />
- to prevent (host) root from spawning new IMA namespaces and doing things undetected in the TCB, all activities of root must be<br />
''measured'' and audited in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-audit:<br />
- to prevent (host) root from spawning new IMA namespaces and doing things undetected in the TCB, all activities of root must be<br />
measured and ''audited'' in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-appraisal and keys:<br />
- each IMA namespace should have its own keyring so that each container can have its files signed with different keys<br />
- the keys (certificates) for verifying signatures may be found inside containers<br />
- it should be possible to enforce that only certified keys are loaded onto a keyring, similar to .ima on the host<br />
- the CA public key used for verifying that public keys (certificates) used for verifying signatures may be found inside the container<br />
or could be known to the container management stack<br />
<br />
- IMA-appraisal and namespacing:<br />
- 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<br />
(nested) IMA namespace where an empty IMA policy has been set? We would measure and audit root's activities as described above.<br />
What about appraising? Would we traverse all the IMA namespaces back to the init_ima_ns and evaluate signatures against the appraisal<br />
policy set there and assume we would always find the keys in the init_user_ns?<br />
<br />
Maybe the following would be a solution for appraising file accesses by (host) root with the key used for signature verification<br />
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<br />
active USER namespace where the key can be found<br />
<br />
for imans from current-IMA-NS backwards up to and including init_ima_ns:<br />
if policy(imans) has appraisal rules for this file:<br />
if file appraisal fails<br />
fail access<br />
else<br />
allow access<br />
break<br />
<br />
or simplified (again after evaluating file access with the current IMA namespace's policy and the currently<br />
active USER namespace where the key can be found)<br />
<br />
Appraise with policy of init_ima_ns and key found in .ima or _ima keyring of init_user_ns.<br />
<br />
- TPM and measurements:<br />
- The IMA namespace that holds the logs should be configurable to extend PCRs; since the single TPM of the host cannot be shared by <br />
containers, each IMA namespace would have to be associated with its own TPM instance (vTPM); measurement in the initial IMA namespace<br />
are extended into the hardware TPM as done already<br />
- Each IMA namespace should only have access to the sysfs entries of its own TPM instance; ideally, sysfs would only show a single TPM<br />
device entry when viewed from an IMA namespace; an alternative may be that all devices are shown but refuse read/write access to their<br />
files if it is initiated from the 'wrong' IMA namespace<br />
<br />
- Extended attribute security.ima:<br />
- A container should be able to set the security.ima extended attribute<br />
- this should be possibly without the almighty CAP_SYS_ADMIN;<br />
- we may want to gate this with a new capability CAP_SECURITY_XATTR_ADMIN that allows setting security extended attributes inside a<br />
container, possibly only during container build-time<br />
<br />
- Extended attribute security.ima and bind mounting<br />
- It may be necessary that different namespaces be able to sign the same bind-mounted file with different keys<br />
(I am thinking of bind-mounted files that the container management stack modifies and that may need to be signed for the container to<br />
be able to access them.)<br />
- Extended attributes, such as security.ima) may need to be virtualizeable (security.ima vs. security.ima@uid=1000 etc.)<br />
<br />
- SecurityFS:<br />
- every IMA namespace should have (read/write) access to the entries that are associated with its IMA namespace<br />
- the organization of IMA's securityfs directory structure should reflect the child-parent relationship of IMA namespaces;<br />
- there should be a directory called 'namespaces' where each child namespace would have a directory with the name of the IMA<br />
namespace's inode ('IMANS:4768263432') that leads to the files holding the information about that namespace<br />
<br />
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:<br />
<br />
What should happen with IMA logging, appraisal, and auditing if we setns() through all available<br />
- PID namespaces and send signals: log, appraise, and audit file activity following IMA policy with special handling for (host) root<br />
- IPC namespaces and send messages via IPC: same as for PID<br />
- UTS namespaces and setting hostname: same as for PID<br />
- NET namespaces and sending network traffic: same as for PID<br />
- CGROUP namespaces and configuring cgroups: same as for PID<br />
- 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<br />
to adapt the current implementation...] other than that, same as for PID?<br />
- MNT namespaces and access files or execute program: same as for PID; if active IMA namespace policy requires file appraisal, files would need<br />
to be signed with key from keyring in current USER namespace<br />
<br />
=== IMA namespaces and IMA policy semantics ===<br />
<br />
The following shows a IMA policy rules and their semantics when applied to IMA namespaces:<br />
<br />
1) audit FUNC=BPRM_CHECK<br />
2) audit FUNC=BPRM_CHECK ns<br />
3) measure func=BPRM_CHECK<br />
<br />
The interpretation of these IMA policy rules is as follows:<br />
<br />
1) Files executed in the IMA namespace that has this policy rule and its child namespaces are audited once<br />
2) Files executed in a child namespace of the IMA namespace that has this policy rule are audited, even if already audited in the IMA namespace that has this policy rule or another namespace<br />
3) Files executed in the IMA namespace that has this policy rule and its child namespaces are measured once<br />
<br />
Note: Initially, the init_ima_ns will be the only IMA namespace that will have a policy.<br />
<br />
== Standalone IMA namespace versus IMA namespace attached to MOUNT namespace or USER namespace ==<br />
<br />
1) The first set of posted patches '''attached the IMA namespace to the MOUNT namespace''' and shared the CLONE_NEWNS flag. Whenever a new mount namespace was created, it also created a new IMA namespace. Similarly, a setns() on a MOUNT namespace would also join the conjoint IMA namespace. File measurements and appraisal of an IMA policy would work on the files in the MOUNT namespace. The key used for the appraisal would be in the currently setns()'d USER namespace (the current implementation of IMA would need to be fixed in that regard). This proposed implementation of conjoint MOUNT and IMA namespaces was rejected.<br />
<br />
2) Another choice is to '''attach the IMA namespace to the USER namespace'''. An IMA file measurement and appraisal policy would become activated when the conjoint USER and IMA namespaces are joined using setns() for example. Side effects of this include that joining a USER namespace activates an IMA policy, that, if appraisal is active, start appraising file accesses, which may include file access denials.<br />
<br />
3) The last choice is to have IMA be a '''stand-alone namespace''' that is spawned using its own CLONE flag or by writing to a (securityfs) file. An IMA file measurement and appraisal policy would be activated when the IMA namespace is joint using setns() for example. If the appropriate set of MOUNT namespaces and USER namespace, providing file signatures and keys for signature verification respectively, is also joined, then only file appraisal will result in working file accesses, otherwise file accesses may be denied.<br />
<br />
The last two choices have their advantages and disadvantages. In order to avoid side effects on existing USER namespaces, the 3rd choice seems better suited. Though a system with IMA appraisal active in IMA namespaces will have restrictions when switching through MNT and possibly USER namespaces using setns(). Restrictions are related to file appraisal and possibly file access denials as well as file measurements.</div>Stefanbhttp://kernsec.org/wiki/index.php?title=IMA_Namespacing_design_considerations&diff=3960IMA Namespacing design considerations2018-04-12T13:34:51Z<p>Stefanb: Reformatting of text in boxes to fit on printed landscape page</p>
<hr />
<div>== Namespacing IMA ==<br />
<br />
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.<br />
<br />
=== Background ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== IMA Namespacing Considerations ===<br />
<br />
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:<br />
<br />
<br />
Support for IMA in namespaces should enable the following:<br />
<br />
- IMA policy for container (similar to the host):<br />
- there should be an initial default policy for every IMA namespace that measures activities inside the container<br />
- the policy can be overwritten once with a user-defined policy that may activate appraisal; this policy would be independent of that of<br />
the host<br />
- CAP_SYS_ADMIN is currently gating the setting of the IMA policy; <br />
- setting the policy should be possibly without the almighty CAP_SYS_ADMIN<br />
- 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<br />
<br />
- IMA policy extensions due to namespacing:<br />
- an IMA policy should allow rules that define whether activities in (all) child namespaces is to be measured (huge logs on the host)<br />
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<br />
host could possibly eat up a lot of memory<br />
- to prevent (host) root from spawning new IMA namespaces and doing things undetected in the TCB, all activities of root must be <br />
''measured and audited'' in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
<br />
- IMA-measurement:<br />
- to prevent (host) root from spawning new IMA namespaces and doing things undetected in the TCB, all activities of root must be<br />
''measured'' and audited in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-audit:<br />
- to prevent (host) root from spawning new IMA namespaces and doing things undetected in the TCB, all activities of root must be<br />
measured and ''audited'' in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-appraisal and keys:<br />
- each IMA namespace should have its own keyring so that each container can have its files signed with different keys<br />
- the keys (certificates) for verifying signatures may be found inside containers<br />
- it should be possible to enforce that only certified keys are loaded onto a keyring, similar to .ima on the host<br />
- the CA public key used for verifying that public keys (certificates) used for verifying signatures may be found inside the container<br />
or could be known to the container management stack<br />
<br />
- IMA-appraisal and namespacing:<br />
- 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<br />
(nested) IMA namespace where an empty IMA policy has been set? We would measure and audit root's activities as described above.<br />
What about appraising? Would we traverse all the IMA namespaces back to the init_ima_ns and evaluate signatures against the appraisal<br />
policy set there and assume we would always find the keys in the init_user_ns?<br />
<br />
Maybe the following would be a solution for appraising file accesses by (host) root with the key used for signature verification<br />
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<br />
active USER namespace where the key can be found<br />
<br />
for imans from current-IMA-NS backwards up to and including init_ima_ns:<br />
if policy(imans) has appraisal rules for this file:<br />
if file appraisal fails<br />
fail access<br />
else<br />
allow access<br />
break<br />
<br />
or simplified (again after evaluating file access with the current IMA namespace's policy and the currently<br />
active USER namespace where the key can be found)<br />
<br />
Appraise with policy of init_ima_ns and key found in .ima or _ima keyring of init_user_ns.<br />
<br />
- TPM and measurements:<br />
- The IMA namespace that holds the logs should be configurable to extend PCRs; since the single TPM of the host cannot be shared by <br />
containers, each IMA namespace would have to be associated with its own TPM instance (vTPM); measurement in the initial IMA namespace<br />
are extended into the hardware TPM as done already<br />
- Each IMA namespace should only have access to the sysfs entries of its own TPM instance; ideally, sysfs would only show a single TPM<br />
device entry when viewed from an IMA namespace; an alternative may be that all devices are shown but refuse read/write access to their<br />
files if it is initiated from the 'wrong' IMA namespace<br />
<br />
- Extended attribute security.ima:<br />
- A container should be able to set the security.ima extended attribute<br />
- this should be possibly without the almighty CAP_SYS_ADMIN;<br />
- we may want to gate this with a new capability CAP_SECURITY_XATTR_ADMIN that allows setting security extended attributes inside a<br />
container, possibly only during container build-time<br />
<br />
- Extended attribute security.ima and bind mounting<br />
- It may be necessary that different namespaces be able to sign the same bind-mounted file with different keys<br />
(I am thinking of bind-mounted files that the container management stack modifies and that may need to be signed for the container to<br />
be able to access them.)<br />
- Extended attributes, such as security.ima) may need to be virtualizeable (security.ima vs. security.ima@uid=1000 etc.)<br />
<br />
- SecurityFS:<br />
- every IMA namespace should have (read/write) access to the entries that are associated with its IMA namespace<br />
- the organization of IMA's securityfs directory structure should reflect the child-parent relationship of IMA namespaces;<br />
- there should be a directory called 'namespaces' where each child namespace would have a directory with the name of the IMA<br />
namespace's inode ('IMANS:4768263432') that leads to the files holding the information about that namespace<br />
<br />
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:<br />
<br />
What should happen with IMA logging, appraisal, and auditing if we setns() through all available<br />
- PID namespaces and send signals: log, appraise, and audit file activity following IMA policy with special handling for (host) root<br />
- IPC namespaces and send messages via IPC: same as for PID<br />
- UTS namespaces and setting hostname: same as for PID<br />
- NET namespaces and sending network traffic: same as for PID<br />
- CGROUP namespaces and configuring cgroups: same as for PID<br />
- 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<br />
to adapt the current implementation...] other than that, same as for PID?<br />
- MNT namespaces and access files or execute program: same as for PID; if active IMA namespace policy requires file appraisal, files would need<br />
to be signed with key from keyring in current USER namespace<br />
<br />
== Standalone IMA namespace versus IMA namespace attached to MOUNT namespace or USER namespace ==<br />
<br />
1) The first set of posted patches '''attached the IMA namespace to the MOUNT namespace''' and shared the CLONE_NEWNS flag. Whenever a new mount namespace was created, it also created a new IMA namespace. Similarly, a setns() on a MOUNT namespace would also join the conjoint IMA namespace. File measurements and appraisal of an IMA policy would work on the files in the MOUNT namespace. The key used for the appraisal would be in the currently setns()'d USER namespace (the current implementation of IMA would need to be fixed in that regard). This proposed implementation of conjoint MOUNT and IMA namespaces was rejected.<br />
<br />
2) Another choice is to '''attach the IMA namespace to the USER namespace'''. An IMA file measurement and appraisal policy would become activated when the conjoint USER and IMA namespaces are joined using setns() for example. Side effects of this include that joining a USER namespace activates an IMA policy, that, if appraisal is active, start appraising file accesses, which may include file access denials.<br />
<br />
3) The last choice is to have IMA be a '''stand-alone namespace''' that is spawned using its own CLONE flag or by writing to a (securityfs) file. An IMA file measurement and appraisal policy would be activated when the IMA namespace is joint using setns() for example. If the appropriate set of MOUNT namespaces and USER namespace, providing file signatures and keys for signature verification respectively, is also joined, then only file appraisal will result in working file accesses, otherwise file accesses may be denied.<br />
<br />
The last two choices have their advantages and disadvantages. In order to avoid side effects on existing USER namespaces, the 3rd choice seems better suited. Though a system with IMA appraisal active in IMA namespaces will have restrictions when switching through MNT and possibly USER namespaces using setns(). Restrictions are related to file appraisal and possibly file access denials as well as file measurements.</div>Stefanbhttp://kernsec.org/wiki/index.php?title=IMA_Namespacing_design_considerations&diff=3959IMA Namespacing design considerations2018-03-19T14:28:00Z<p>Stefanb: /* Standalone IMA namespace versus IMA namespace attached to MOUNT namespace or USER namespace */</p>
<hr />
<div>== Namespacing IMA ==<br />
<br />
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.<br />
<br />
=== Background ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== IMA Namespacing Considerations ===<br />
<br />
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:<br />
<br />
<br />
Support for IMA in namespaces should enable the following:<br />
<br />
- IMA policy for container (similar to the host):<br />
- there should be an initial default policy for every IMA namespace that measures activities inside the container<br />
- 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<br />
- CAP_SYS_ADMIN is currently gating the setting of the IMA policy; <br />
- setting the policy should be possibly without the almighty CAP_SYS_ADMIN<br />
- 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<br />
<br />
- IMA policy extensions due to namespacing:<br />
- an IMA policy should allow rules that define whether activities in (all) child namespaces is to be measured (huge logs on the host)<br />
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<br />
host could possibly eat up a lot of memory<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
<br />
- IMA-measurement:<br />
- 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<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-audit:<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-appraisal and keys:<br />
- each IMA namespace should have its own keyring so that each container can have its files signed with different keys<br />
- the keys (certificates) for verifying signatures may be found inside containers<br />
- it should be possible to enforce that only certified keys are loaded onto a keyring, similar to .ima on the host<br />
- the CA public key used for verifying that public keys (certificates) used for verifying signatures may be found inside the container<br />
or could be known to the container management stack<br />
<br />
- IMA-appraisal and namespacing:<br />
- 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<br />
(nested) IMA namespace where an empty IMA policy has been set? We would measure and audit root's activities as described above.<br />
What about appraising? Would we traverse all the IMA namespaces back to the init_ima_ns and evaluate signatures against the appraisal policy<br />
set there and assume we would always find the keys in the init_user_ns?<br />
<br />
Maybe the following would be a solution for appraising file accesses by (host) root with the key used for signature verification<br />
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<br />
active USER namespace where the key can be found<br />
<br />
for imans from current-IMA-NS backwards up to and including init_ima_ns:<br />
if policy(imans) has appraisal rules for this file:<br />
if file appraisal fails<br />
fail access<br />
else<br />
allow access<br />
break<br />
<br />
or simplified (again after evaluating file access with the current IMA namespace's policy and the currently<br />
active USER namespace where the key can be found)<br />
<br />
Appraise with policy of init_ima_ns and key found in .ima or _ima keyring of init_user_ns.<br />
<br />
- TPM and measurements:<br />
- 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,<br />
each IMA namespace would have to be associated with its own TPM instance (vTPM); measurement in the initial IMA namespace are extended into<br />
the hardware TPM as done already<br />
- 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<br />
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<br />
is initiated from the 'wrong' IMA namespace<br />
<br />
- Extended attribute security.ima:<br />
- A container should be able to set the security.ima extended attribute<br />
- this should be possibly without the almighty CAP_SYS_ADMIN;<br />
- we may want to gate this with a new capability CAP_SECURITY_XATTR_ADMIN that allows setting security extended attributes inside a container, <br />
possibly only during container build-time<br />
<br />
- Extended attribute security.ima and bind mounting<br />
- It may be necessary that different namespaces be able to sign the same bind-mounted file with different keys<br />
(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<br />
able to access them.)<br />
- Extended attributes, such as security.ima) may need to be virtualizeable (security.ima vs. security.ima@uid=1000 etc.)<br />
<br />
- SecurityFS:<br />
- every IMA namespace should have (read/write) access to the entries that are associated with its IMA namespace<br />
- the organization of IMA's securityfs directory structure should reflect the child-parent relationship of IMA namespaces;<br />
- there should be a directory called 'namespaces' where each child namespace would have a directory with the name of the IMA<br />
namespace's inode ('IMANS:4768263432') that leads to the files holding the information about that namespace<br />
<br />
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:<br />
<br />
What should happen with IMA logging, appraisal, and auditing if we setns() through all available<br />
- PID namespaces and send signals: log, appraise, and audit file activity following IMA policy with special handling for (host) root<br />
- IPC namespaces and send messages via IPC: same as for PID<br />
- UTS namespaces and setting hostname: same as for PID<br />
- NET namespaces and sending network traffic: same as for PID<br />
- CGROUP namespaces and configuring cgroups: same as for PID<br />
- 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<br />
to adapt the current implementation...] other than that, same as for PID?<br />
- MNT namespaces and access files or execute program: same as for PID; if active IMA namespace policy requires file appraisal, files would need<br />
to be signed with key from keyring in current USER namespace<br />
<br />
== Standalone IMA namespace versus IMA namespace attached to MOUNT namespace or USER namespace ==<br />
<br />
1) The first set of posted patches '''attached the IMA namespace to the MOUNT namespace''' and shared the CLONE_NEWNS flag. Whenever a new mount namespace was created, it also created a new IMA namespace. Similarly, a setns() on a MOUNT namespace would also join the conjoint IMA namespace. File measurements and appraisal of an IMA policy would work on the files in the MOUNT namespace. The key used for the appraisal would be in the currently setns()'d USER namespace (the current implementation of IMA would need to be fixed in that regard). This proposed implementation of conjoint MOUNT and IMA namespaces was rejected.<br />
<br />
2) Another choice is to '''attach the IMA namespace to the USER namespace'''. An IMA file measurement and appraisal policy would become activated when the conjoint USER and IMA namespaces are joined using setns() for example. Side effects of this include that joining a USER namespace activates an IMA policy, that, if appraisal is active, start appraising file accesses, which may include file access denials.<br />
<br />
3) The last choice is to have IMA be a '''stand-alone namespace''' that is spawned using its own CLONE flag. An IMA file measurement and appraisal policy would be activated when the IMA namespace is joint using setns() for example. If the appropriate set of MOUNT namespaces and USER namespace, providing file signatures and keys for signature verification respectively, is also joined, then only file appraisal will result in working file accesses, otherwise file accesses may be denied.<br />
<br />
The last two choices have their advantages and disadvantages. In order to avoid side effects on existing USER namespaces, the 3rd choice seems better suited. Though a system with IMA appraisal active in IMA namespaces will have restrictions when switching through MNT and possibly USER namespaces using setns(). Restrictions are related to file appraisal and possibly file access denials as well as file measurements.</div>Stefanbhttp://kernsec.org/wiki/index.php?title=IMA_Namespacing_design_considerations&diff=3958IMA Namespacing design considerations2018-03-19T14:24:24Z<p>Stefanb: </p>
<hr />
<div>== Namespacing IMA ==<br />
<br />
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.<br />
<br />
=== Background ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== IMA Namespacing Considerations ===<br />
<br />
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:<br />
<br />
<br />
Support for IMA in namespaces should enable the following:<br />
<br />
- IMA policy for container (similar to the host):<br />
- there should be an initial default policy for every IMA namespace that measures activities inside the container<br />
- 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<br />
- CAP_SYS_ADMIN is currently gating the setting of the IMA policy; <br />
- setting the policy should be possibly without the almighty CAP_SYS_ADMIN<br />
- 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<br />
<br />
- IMA policy extensions due to namespacing:<br />
- an IMA policy should allow rules that define whether activities in (all) child namespaces is to be measured (huge logs on the host)<br />
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<br />
host could possibly eat up a lot of memory<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
<br />
- IMA-measurement:<br />
- 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<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-audit:<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-appraisal and keys:<br />
- each IMA namespace should have its own keyring so that each container can have its files signed with different keys<br />
- the keys (certificates) for verifying signatures may be found inside containers<br />
- it should be possible to enforce that only certified keys are loaded onto a keyring, similar to .ima on the host<br />
- the CA public key used for verifying that public keys (certificates) used for verifying signatures may be found inside the container<br />
or could be known to the container management stack<br />
<br />
- IMA-appraisal and namespacing:<br />
- 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<br />
(nested) IMA namespace where an empty IMA policy has been set? We would measure and audit root's activities as described above.<br />
What about appraising? Would we traverse all the IMA namespaces back to the init_ima_ns and evaluate signatures against the appraisal policy<br />
set there and assume we would always find the keys in the init_user_ns?<br />
<br />
Maybe the following would be a solution for appraising file accesses by (host) root with the key used for signature verification<br />
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<br />
active USER namespace where the key can be found<br />
<br />
for imans from current-IMA-NS backwards up to and including init_ima_ns:<br />
if policy(imans) has appraisal rules for this file:<br />
if file appraisal fails<br />
fail access<br />
else<br />
allow access<br />
break<br />
<br />
or simplified (again after evaluating file access with the current IMA namespace's policy and the currently<br />
active USER namespace where the key can be found)<br />
<br />
Appraise with policy of init_ima_ns and key found in .ima or _ima keyring of init_user_ns.<br />
<br />
- TPM and measurements:<br />
- 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,<br />
each IMA namespace would have to be associated with its own TPM instance (vTPM); measurement in the initial IMA namespace are extended into<br />
the hardware TPM as done already<br />
- 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<br />
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<br />
is initiated from the 'wrong' IMA namespace<br />
<br />
- Extended attribute security.ima:<br />
- A container should be able to set the security.ima extended attribute<br />
- this should be possibly without the almighty CAP_SYS_ADMIN;<br />
- we may want to gate this with a new capability CAP_SECURITY_XATTR_ADMIN that allows setting security extended attributes inside a container, <br />
possibly only during container build-time<br />
<br />
- Extended attribute security.ima and bind mounting<br />
- It may be necessary that different namespaces be able to sign the same bind-mounted file with different keys<br />
(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<br />
able to access them.)<br />
- Extended attributes, such as security.ima) may need to be virtualizeable (security.ima vs. security.ima@uid=1000 etc.)<br />
<br />
- SecurityFS:<br />
- every IMA namespace should have (read/write) access to the entries that are associated with its IMA namespace<br />
- the organization of IMA's securityfs directory structure should reflect the child-parent relationship of IMA namespaces;<br />
- there should be a directory called 'namespaces' where each child namespace would have a directory with the name of the IMA<br />
namespace's inode ('IMANS:4768263432') that leads to the files holding the information about that namespace<br />
<br />
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:<br />
<br />
What should happen with IMA logging, appraisal, and auditing if we setns() through all available<br />
- PID namespaces and send signals: log, appraise, and audit file activity following IMA policy with special handling for (host) root<br />
- IPC namespaces and send messages via IPC: same as for PID<br />
- UTS namespaces and setting hostname: same as for PID<br />
- NET namespaces and sending network traffic: same as for PID<br />
- CGROUP namespaces and configuring cgroups: same as for PID<br />
- 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<br />
to adapt the current implementation...] other than that, same as for PID?<br />
- MNT namespaces and access files or execute program: same as for PID; if active IMA namespace policy requires file appraisal, files would need<br />
to be signed with key from keyring in current USER namespace<br />
<br />
== Standalone IMA namespace versus IMA namespace attached to MOUNT namespace or USER namespace ==<br />
<br />
The first set of posted patches attached the IMA namespace to the MOUNT namespace and shared the CLONE_NEWNS flag. Whenever a new mount namespace was created, it also created a new IMA namespace. Similarly, a setns() on a MOUNT namespace would also join the conjoint IMA namespace. File measurements and appraisal of an IMA policy would work on the files in the MOUNT namespace. The key used for the appraisal would be in the currently setns()'d USER namespace (currently implementation of IMA would need to be fixed in that regard). This proposed implementation was rejected.<br />
<br />
Another choice is to attach the IMA namespace to the USER namespace. An IMA file measurement and appraisal policy would become activated when the conjoint USER and IMA namespaces are joint using setns() for example. Side effects of this include that joining a USER namespace activates an IMA policy, that, if appraisal is active, start appraising file accesses.<br />
<br />
The last choice is to have IMA be a stand-alone namespace that is spawned using its own CLONE flag. An IMA file measurement and appraisal policy would be activated when the IMA namespace is joint using setns() for example. If the appropriate set of MOUNT namespaces and USER namespace, providing file signatures and keys for signature verification respectively, is also joined, then only file appraisal will result in working file accesses.<br />
<br />
The last two choices have their advantages and disadvantages. In order to avoid side effects on existing USER namespaces, the 3rd choice seems better suited. Though a system with IMA appraisal active in IMA namespaces will have restrictions when switching through MNT and possibly USER namespaces using setns(). Restrictions are related to file appraisal and possibly file access denials as well as file measurements.</div>Stefanbhttp://kernsec.org/wiki/index.php?title=IMA_Namespacing_design_considerations&diff=3957IMA Namespacing design considerations2018-03-19T13:42:03Z<p>Stefanb: /* IMA Namespacing Considerations */</p>
<hr />
<div>== Namespacing IMA ==<br />
<br />
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.<br />
<br />
=== Background ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== IMA Namespacing Considerations ===<br />
<br />
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:<br />
<br />
<br />
Support for IMA in namespaces should enable the following:<br />
<br />
- IMA policy for container (similar to the host):<br />
- there should be an initial default policy for every IMA namespace that measures activities inside the container<br />
- 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<br />
- CAP_SYS_ADMIN is currently gating the setting of the IMA policy; <br />
- setting the policy should be possibly without the almighty CAP_SYS_ADMIN<br />
- 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<br />
<br />
- IMA policy extensions due to namespacing:<br />
- an IMA policy should allow rules that define whether activities in (all) child namespaces is to be measured (huge logs on the host)<br />
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<br />
host could possibly eat up a lot of memory<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
<br />
- IMA-measurement:<br />
- 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<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-audit:<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-appraisal and keys:<br />
- each IMA namespace should have its own keyring so that each container can have its files signed with different keys<br />
- the keys (certificates) for verifying signatures may be found inside containers<br />
- it should be possible to enforce that only certified keys are loaded onto a keyring, similar to .ima on the host<br />
- the CA public key used for verifying that public keys (certificates) used for verifying signatures may be found inside the container<br />
or could be known to the container management stack<br />
<br />
- IMA-appraisal and namespacing:<br />
- 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<br />
(nested) IMA namespace where an empty IMA policy has been set? We would measure and audit root's activities as described above.<br />
What about appraising? Would we traverse all the IMA namespaces back to the init_ima_ns and evaluate signatures against the appraisal policy<br />
set there and assume we would always find the keys in the init_user_ns?<br />
<br />
Maybe the following would be a solution for appraising file accesses by (host) root with the key used for signature verification<br />
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<br />
active USER namespace where the key can be found<br />
<br />
for imans from current-IMA-NS backwards up to and including init_ima_ns:<br />
if policy(imans) has appraisal rules for this file:<br />
if file appraisal fails<br />
fail access<br />
else<br />
allow access<br />
break<br />
<br />
or simplified (again after evaluating file access with the current IMA namespace's policy and the currently<br />
active USER namespace where the key can be found)<br />
<br />
Appraise with policy of init_ima_ns and key found in .ima or _ima keyring of init_user_ns.<br />
<br />
- TPM and measurements:<br />
- 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,<br />
each IMA namespace would have to be associated with its own TPM instance (vTPM); measurement in the initial IMA namespace are extended into<br />
the hardware TPM as done already<br />
- 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<br />
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<br />
is initiated from the 'wrong' IMA namespace<br />
<br />
- Extended attribute security.ima:<br />
- A container should be able to set the security.ima extended attribute<br />
- this should be possibly without the almighty CAP_SYS_ADMIN;<br />
- we may want to gate this with a new capability CAP_SECURITY_XATTR_ADMIN that allows setting security extended attributes inside a container, <br />
possibly only during container build-time<br />
<br />
- Extended attribute security.ima and bind mounting<br />
- It may be necessary that different namespaces be able to sign the same bind-mounted file with different keys<br />
(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<br />
able to access them.)<br />
- Extended attributes, such as security.ima) may need to be virtualizeable (security.ima vs. security.ima@uid=1000 etc.)<br />
<br />
- SecurityFS:<br />
- every IMA namespace should have (read/write) access to the entries that are associated with its IMA namespace<br />
- the organization of IMA's securityfs directory structure should reflect the child-parent relationship of IMA namespaces;<br />
- there should be a directory called 'namespaces' where each child namespace would have a directory with the name of the IMA<br />
namespace's inode ('IMANS:4768263432') that leads to the files holding the information about that namespace<br />
<br />
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:<br />
<br />
What should happen with IMA logging, appraisal, and auditing if we setns() through all available<br />
- PID namespaces and send signals: log, appraise, and audit file activity following IMA policy with special handling for (host) root<br />
- IPC namespaces and send messages via IPC: same as for PID<br />
- UTS namespaces and setting hostname: same as for PID<br />
- NET namespaces and sending network traffic: same as for PID<br />
- CGROUP namespaces and configuring cgroups: same as for PID<br />
- 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<br />
to adapt the current implementation...] other than that, same as for PID?<br />
- MNT namespaces and access files or execute program: same as for PID; if active IMA namespace policy requires file appraisal, files would need<br />
to be signed with key from keyring in current USER namespace</div>Stefanbhttp://kernsec.org/wiki/index.php?title=IMA_Namespacing_design_considerations&diff=3956IMA Namespacing design considerations2018-03-19T13:41:49Z<p>Stefanb: /* IMA Namespacing Considerations */</p>
<hr />
<div>== Namespacing IMA ==<br />
<br />
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.<br />
<br />
=== Background ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== IMA Namespacing Considerations ===<br />
<br />
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:<br />
<br />
<br />
Support for IMA in namespaces should enable the following:<br />
<br />
- IMA policy for container (similar to the host):<br />
- there should be an initial default policy for every IMA namespace that measures activities inside the container<br />
- the policy can be overwritten once with a user-defined policy that may activate appraisal; this policy would be indepebdent of that of the host<br />
- CAP_SYS_ADMIN is currently gating the setting of the IMA policy; <br />
- setting the policy should be possibly without the almighty CAP_SYS_ADMIN<br />
- 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<br />
<br />
- IMA policy extensions due to namespacing:<br />
- an IMA policy should allow rules that define whether activities in (all) child namespaces is to be measured (huge logs on the host)<br />
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<br />
host could possibly eat up a lot of memory<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
<br />
- IMA-measurement:<br />
- 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<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-audit:<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-appraisal and keys:<br />
- each IMA namespace should have its own keyring so that each container can have its files signed with different keys<br />
- the keys (certificates) for verifying signatures may be found inside containers<br />
- it should be possible to enforce that only certified keys are loaded onto a keyring, similar to .ima on the host<br />
- the CA public key used for verifying that public keys (certificates) used for verifying signatures may be found inside the container<br />
or could be known to the container management stack<br />
<br />
- IMA-appraisal and namespacing:<br />
- 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<br />
(nested) IMA namespace where an empty IMA policy has been set? We would measure and audit root's activities as described above.<br />
What about appraising? Would we traverse all the IMA namespaces back to the init_ima_ns and evaluate signatures against the appraisal policy<br />
set there and assume we would always find the keys in the init_user_ns?<br />
<br />
Maybe the following would be a solution for appraising file accesses by (host) root with the key used for signature verification<br />
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<br />
active USER namespace where the key can be found<br />
<br />
for imans from current-IMA-NS backwards up to and including init_ima_ns:<br />
if policy(imans) has appraisal rules for this file:<br />
if file appraisal fails<br />
fail access<br />
else<br />
allow access<br />
break<br />
<br />
or simplified (again after evaluating file access with the current IMA namespace's policy and the currently<br />
active USER namespace where the key can be found)<br />
<br />
Appraise with policy of init_ima_ns and key found in .ima or _ima keyring of init_user_ns.<br />
<br />
- TPM and measurements:<br />
- 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,<br />
each IMA namespace would have to be associated with its own TPM instance (vTPM); measurement in the initial IMA namespace are extended into<br />
the hardware TPM as done already<br />
- 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<br />
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<br />
is initiated from the 'wrong' IMA namespace<br />
<br />
- Extended attribute security.ima:<br />
- A container should be able to set the security.ima extended attribute<br />
- this should be possibly without the almighty CAP_SYS_ADMIN;<br />
- we may want to gate this with a new capability CAP_SECURITY_XATTR_ADMIN that allows setting security extended attributes inside a container, <br />
possibly only during container build-time<br />
<br />
- Extended attribute security.ima and bind mounting<br />
- It may be necessary that different namespaces be able to sign the same bind-mounted file with different keys<br />
(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<br />
able to access them.)<br />
- Extended attributes, such as security.ima) may need to be virtualizeable (security.ima vs. security.ima@uid=1000 etc.)<br />
<br />
- SecurityFS:<br />
- every IMA namespace should have (read/write) access to the entries that are associated with its IMA namespace<br />
- the organization of IMA's securityfs directory structure should reflect the child-parent relationship of IMA namespaces;<br />
- there should be a directory called 'namespaces' where each child namespace would have a directory with the name of the IMA<br />
namespace's inode ('IMANS:4768263432') that leads to the files holding the information about that namespace<br />
<br />
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:<br />
<br />
What should happen with IMA logging, appraisal, and auditing if we setns() through all available<br />
- PID namespaces and send signals: log, appraise, and audit file activity following IMA policy with special handling for (host) root<br />
- IPC namespaces and send messages via IPC: same as for PID<br />
- UTS namespaces and setting hostname: same as for PID<br />
- NET namespaces and sending network traffic: same as for PID<br />
- CGROUP namespaces and configuring cgroups: same as for PID<br />
- 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<br />
to adapt the current implementation...] other than that, same as for PID?<br />
- MNT namespaces and access files or execute program: same as for PID; if active IMA namespace policy requires file appraisal, files would need<br />
to be signed with key from keyring in current USER namespace</div>Stefanbhttp://kernsec.org/wiki/index.php?title=IMA_Namespacing_design_considerations&diff=3955IMA Namespacing design considerations2018-03-17T15:58:34Z<p>Stefanb: /* IMA Namespacing Considerations */</p>
<hr />
<div>== Namespacing IMA ==<br />
<br />
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.<br />
<br />
=== Background ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== IMA Namespacing Considerations ===<br />
<br />
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:<br />
<br />
<br />
Support for IMA in namespaces should enable the following:<br />
<br />
- IMA policy for container (similar to the host):<br />
- there should be an initial default policy for every IMA namespace that measures activities inside the container<br />
- the policy can be overwritten once with a user-defined policy that may activate appraisal<br />
- CAP_SYS_ADMIN is currently gating the setting of the IMA policy; <br />
- setting the policy should be possibly without the almighty CAP_SYS_ADMIN<br />
- 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<br />
<br />
- IMA policy extensions due to namespacing:<br />
- an IMA policy should allow rules that define whether activities in (all) child namespaces is to be measured (huge logs on the host)<br />
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<br />
host could possibly eat up a lot of memory<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
<br />
- IMA-measurement:<br />
- 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<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-audit:<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-appraisal and keys:<br />
- each IMA namespace should have its own keyring so that each container can have its files signed with different keys<br />
- the keys (certificates) for verifying signatures may be found inside containers<br />
- it should be possible to enforce that only certified keys are loaded onto a keyring, similar to .ima on the host<br />
- the CA public key used for verifying that public keys (certificates) used for verifying signatures may be found inside the container<br />
or could be known to the container management stack<br />
<br />
- IMA-appraisal and namespacing:<br />
- 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<br />
(nested) IMA namespace where an empty IMA policy has been set? We would measure and audit root's activities as described above.<br />
What about appraising? Would we traverse all the IMA namespaces back to the init_ima_ns and evaluate signatures against the appraisal policy<br />
set there and assume we would always find the keys in the init_user_ns?<br />
<br />
Maybe the following would be a solution for appraising file accesses by (host) root with the key used for signature verification<br />
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<br />
active USER namespace where the key can be found<br />
<br />
for imans from current-IMA-NS backwards up to and including init_ima_ns:<br />
if policy(imans) has appraisal rules for this file:<br />
if file appraisal fails<br />
fail access<br />
else<br />
allow access<br />
break<br />
<br />
or simplified (again after evaluating file access with the current IMA namespace's policy and the currently<br />
active USER namespace where the key can be found)<br />
<br />
Appraise with policy of init_ima_ns and key found in .ima or _ima keyring of init_user_ns.<br />
<br />
- TPM and measurements:<br />
- 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,<br />
each IMA namespace would have to be associated with its own TPM instance (vTPM); measurement in the initial IMA namespace are extended into<br />
the hardware TPM as done already<br />
- 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<br />
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<br />
is initiated from the 'wrong' IMA namespace<br />
<br />
- Extended attribute security.ima:<br />
- A container should be able to set the security.ima extended attribute<br />
- this should be possibly without the almighty CAP_SYS_ADMIN;<br />
- we may want to gate this with a new capability CAP_SECURITY_XATTR_ADMIN that allows setting security extended attributes inside a container, <br />
possibly only during container build-time<br />
<br />
- Extended attribute security.ima and bind mounting<br />
- It may be necessary that different namespaces be able to sign the same bind-mounted file with different keys<br />
(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<br />
able to access them.)<br />
- Extended attributes, such as security.ima) may need to be virtualizeable (security.ima vs. security.ima@uid=1000 etc.)<br />
<br />
- SecurityFS:<br />
- every IMA namespace should have (read/write) access to the entries that are associated with its IMA namespace<br />
- the organization of IMA's securityfs directory structure should reflect the child-parent relationship of IMA namespaces;<br />
- there should be a directory called 'namespaces' where each child namespace would have a directory with the name of the IMA<br />
namespace's inode ('IMANS:4768263432') that leads to the files holding the information about that namespace<br />
<br />
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:<br />
<br />
What should happen with IMA logging, appraisal, and auditing if we setns() through all available<br />
- PID namespaces and send signals: log, appraise, and audit file activity following IMA policy with special handling for (host) root<br />
- IPC namespaces and send messages via IPC: same as for PID<br />
- UTS namespaces and setting hostname: same as for PID<br />
- NET namespaces and sending network traffic: same as for PID<br />
- CGROUP namespaces and configuring cgroups: same as for PID<br />
- 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<br />
to adapt the current implementation...] other than that, same as for PID?<br />
- MNT namespaces and access files or execute program: same as for PID; if active IMA namespace policy requires file appraisal, files would need<br />
to be signed with key from keyring in current USER namespace</div>Stefanbhttp://kernsec.org/wiki/index.php?title=IMA_Namespacing_design_considerations&diff=3954IMA Namespacing design considerations2018-03-17T13:44:29Z<p>Stefanb: /* IMA Namespacing Considerations */</p>
<hr />
<div>== Namespacing IMA ==<br />
<br />
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.<br />
<br />
=== Background ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== IMA Namespacing Considerations ===<br />
<br />
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:<br />
<br />
<br />
Support for IMA in namespaces should enable the following:<br />
<br />
- IMA policy for container (similar to the host):<br />
- there should be an initial default policy for every IMA namespace that measures activities inside the container<br />
- the policy can be overwritten once with a user-defined policy that may activate appraisal<br />
- CAP_SYS_ADMIN is currently gating the setting of the IMA policy; <br />
- setting the policy should be possibly without the almighty CAP_SYS_ADMIN<br />
- 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<br />
<br />
- IMA policy extensions due to namespacing:<br />
- an IMA policy should allow rules that define whether activities in (all) child namespaces is to be measured (huge logs on the host)<br />
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<br />
host could possibly eat up a lot of memory<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
<br />
- IMA-measurement:<br />
- 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<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-audit:<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-appraisal and keys:<br />
- each IMA namespace should have its own keyring so that each container can have its files signed with different keys<br />
- the keys (certificates) for verifying signatures may be found inside containers<br />
- it should be possible to enforce that only certified keys are loaded onto a keyring, similar to .ima on the host<br />
- the CA public key used for verifying that public keys (certificates) used for verifying signatures may be found inside the container<br />
or could be known to the container management stack<br />
<br />
- IMA-appraisal and namespacing:<br />
- 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<br />
(nested) IMA namespace where an empty IMA policy has been set? We would measure and audit root's activities as described above.<br />
What about appraising? Would we traverse all the IMA namespaces back to the init_ima_ns and evaluate signatures against the appraisal policy<br />
set there and assume we would always find the keys in the init_user_ns?<br />
<br />
Maybe the following would be a solution for appraising file accesses by (host) root with the key used for signature verification<br />
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<br />
active USER namespace where the key can be found<br />
<br />
for imans from current-IMA-NS backwards up to and including init_ima_ns:<br />
if policy(imans) has appraisal rules for this file:<br />
if file appraisal fails<br />
fail access<br />
else<br />
allow access<br />
break<br />
<br />
or simplified (again after evaluating file access with the current IMA namespace's policy and the currently<br />
active USER namespace where the key can be found)<br />
<br />
Appraise with policy of init_ima_ns and key found in .ima or _ima keyring of init_user_ns.<br />
<br />
- TPM and measurements:<br />
- 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,<br />
each IMA namespace would have to be associated with its own TPM instance (vTPM); measurement in the initial IMA namespace are extended into<br />
the hardware TPM as done already<br />
- 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<br />
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<br />
is initiated from the 'wrong' IMA namespace<br />
<br />
- Extended attribute security.ima:<br />
- A container should be able to set the security.ima extended attribute<br />
- this should be possibly without the almighty CAP_SYS_ADMIN;<br />
- we may want to gate this with a new capability CAP_SECURITY_XATTR_ADMIN that allows setting security extended attributes inside a container, <br />
possibly only during container build-time<br />
<br />
- Extended attribute security.ima and bind mounting<br />
- It may be necessary that different namespaces be able to sign the same bind-mounted file with different keys<br />
(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<br />
able to access them.)<br />
- Extended attributes, such as security.ima) may need to be virtualizeable (security.ima vs. security.ima@uid=1000 etc.)<br />
<br />
- SecurityFS:<br />
- every IMA namespace should have (read/write) access to the entries that are associated with its IMA namespace<br />
- the organization of IMA's securityfs directory structure should reflect the child-parent relationship of IMA namespaces;<br />
- there should be a directory called 'namespaces' where each child namespace would have a directory with the name of the IMA<br />
namespace's inode ('IMANS:4768263432') that leads to the files holding the information about that namespace<br />
<br />
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:<br />
<br />
What should happen with IMA logging, appraisal, and auditing if we setns() through all available<br />
- PID namespaces and send signals: log, appraise, and audit file activity following IMA policy with special handling for (host) root<br />
- IPC namespaces and send messages via IPC: same as for PID<br />
- UTS namespaces and setting hostname: same as for PID<br />
- NET namespaces and sending network traffic: same as for PID<br />
- CGROUP namespaces and configuring cgroups: same as for PID<br />
- 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<br />
to adapt the current implementation...] other than that, same as for PID?<br />
- MNT namespaces and access files or execute program: same as for PID</div>Stefanbhttp://kernsec.org/wiki/index.php?title=IMA_Namespacing_design_considerations&diff=3953IMA Namespacing design considerations2018-03-17T13:44:11Z<p>Stefanb: /* IMA Namespacing Considerations */</p>
<hr />
<div>== Namespacing IMA ==<br />
<br />
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.<br />
<br />
=== Background ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== IMA Namespacing Considerations ===<br />
<br />
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:<br />
<br />
<br />
Support for IMA in namespaces should enable the following:<br />
<br />
- IMA policy for container (similar to the host):<br />
- there should be an initial default policy for every IMA namespace that measures activities inside the container<br />
- the policy can be overwritten once with a user-defined policy that may activate appraisal<br />
- CAP_SYS_ADMIN is currently gating the setting of the IMA policy; <br />
- setting the policy should be possibly without the almighty CAP_SYS_ADMIN<br />
- 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<br />
<br />
- IMA policy extensions due to namespacing:<br />
- an IMA policy should allow rules that define whether activities in (all) child namespaces is to be measured (huge logs on the host)<br />
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<br />
host could possibly eat up a lot of memory<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
<br />
- IMA-measurement:<br />
- 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<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-audit:<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-appraisal and keys:<br />
- each IMA namespace should have its own keyring so that each container can have its files signed with different keys<br />
- the keys (certificates) for verifying signatures may be found inside containers<br />
- it should be possible to enforce that only certified keys are loaded onto a keyring, similar to .ima on the host<br />
- the CA public key used for verifying that public keys (certificates) used for verifying signatures may be found inside the container<br />
or could be known to the container management stack<br />
<br />
- IMA-appraisal and namespacing:<br />
- 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<br />
(nested) IMA namespace where an empty IMA policy has been set? We would measure and audit root's activities as described above.<br />
What about appraising? Would we traverse all the IMA namespaces back to the init_ima_ns and evaluate signatures against the appraisal policy<br />
set there and assume we would always find the keys in the init_user_ns?<br />
<br />
Maybe the following would be a solution for appraising file accesses by (host) root with the key used for signature verification<br />
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<br />
active USER namespace where the key can be found<br />
<br />
for imans from current-IMA-NS backwards up to and including init_ima_ns:<br />
if policy(imans) has appraisal rules for this file:<br />
if file appraisal fails<br />
fail access<br />
else<br />
allow access<br />
break<br />
<br />
or simplified (again after evaluating file access with the current IMA namespace's policy and the currently<br />
active USER namespace where the key can be found)<br />
<br />
Appraise with policy of init_ima_ns and key found in .ima or _ima keyring of init_user_ns.<br />
<br />
- TPM and measurements:<br />
- 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,<br />
each IMA namespace would have to be associated with its own TPM instance (vTPM); measurement in the initial IMA namespace are extended into<br />
the hardware TPM as done already<br />
- 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<br />
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<br />
is initiated from the 'wrong' IMA namespace<br />
<br />
- Extended attribute security.ima:<br />
- A container should be able to set the security.ima extended attribute<br />
- this should be possibly without the almighty CAP_SYS_ADMIN;<br />
- we may want to gate this with a new capability CAP_SECURITY_XATTR_ADMIN that allows setting security extended attributes inside a container, <br />
possibly only during container build-time<br />
<br />
- Extended attribute security.ima and bind mounting<br />
- It may be necessary that different namespaces be able to sign the same bind-mounted file with different keys<br />
(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<br />
able to access them.)<br />
- Extended attributes, such as security.ima) may need to be virtualizeable (security.ima vs. security.ima@uid=1000 etc.)<br />
<br />
- SecurityFS:<br />
- every IMA namespace should have (read/write) access to the entries that are associated with its IMA namespace<br />
- the organization of IMA's securityfs directory structure should reflect the child-parent relationship of IMA namespaces;<br />
- there should be a directory called 'namespaces' where each child namespace would have a directory with the name of the IMA<br />
namespace's inode ('IMANS:4768263432') that leads to the files holding the information about that namespace<br />
<br />
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:<br />
<br />
What should happen with IMA logging, appraisal, and auditing if we setns() through all available<br />
- PID namespaces and send signals: log, appraise, and audit file activity following IMA policy with special handling for (host) root<br />
- IPC namespaces and send messages via IPC: same as for PID<br />
- UTS namespaces and setting hostname: same as for PID<br />
- NET namespaces and sending network traffic: same as for PID<br />
- CGROUP namespaces and configuring cgroups: same as for PID<br />
- 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<br />
to adapt the current implementation...] other than that, same as for PID?<br />
- MNT namespaces and access files or execute program: same as for PID</div>Stefanbhttp://kernsec.org/wiki/index.php?title=IMA_Namespacing_design_considerations&diff=3952IMA Namespacing design considerations2018-03-15T18:41:26Z<p>Stefanb: /* IMA Namespacing Considerations */</p>
<hr />
<div>== Namespacing IMA ==<br />
<br />
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.<br />
<br />
=== Background ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== IMA Namespacing Considerations ===<br />
<br />
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:<br />
<br />
<br />
Support for IMA in namespaces should enable the following:<br />
<br />
- IMA policy for container (similar to the host):<br />
- there should be an initial default policy for every IMA namespace that measures activities inside the container<br />
- the policy can be overwritten once with a user-defined policy that may activate appraisal<br />
- CAP_SYS_ADMIN is currently gating the setting of the IMA policy; <br />
- setting the policy should be possibly without the almighty CAP_SYS_ADMIN<br />
- 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<br />
<br />
- IMA policy extensions due to namespacing:<br />
- an IMA policy should allow rules that define whether activities in (all) child namespaces is to be measured (huge logs on the host)<br />
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<br />
host could possibly eat up a lot of memory<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
<br />
- IMA-measurement:<br />
- 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<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-audit:<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-appraisal and keys:<br />
- each IMA namespace should have its own keyring so that each container can have its files signed with different keys<br />
- the keys (certificates) for verifying signatures may be found inside containers<br />
- it should be possible to enforce that only certified keys are loaded onto a keyring, similar to .ima on the host<br />
- the CA public key used for verifying that public keys (certificates) used for verifying signatures may be found inside the container<br />
or could be known to the container management stack<br />
<br />
- IMA-appraisal and namespacing:<br />
- 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<br />
(nested) IMA namespace where an empty IMA policy has been set? We would measure and audit root's activities as described above.<br />
What about appraising? Would we traverse all the IMA namespaces back to the init_ima_ns and evaluate signatures against the appraisal policy<br />
set there and assume we would always find the keys in the init_user_ns?<br />
<br />
Maybe the following would be a solution for appraising file accesses by (host) root with the key used for signature verification<br />
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<br />
active USER namespace where the key can be found<br />
<br />
for imans from current-IMA-NS backwards up to and including init_ima_ns:<br />
if policy(imans) has appraisal rules for this file:<br />
if file appraisal fails<br />
fail access<br />
else<br />
allow access<br />
break<br />
<br />
or simplified (again after evaluating file access with the current IMA namespace's policy and the currently<br />
active USER namespace where the key can be found)<br />
<br />
Appraise with policy of init_ima_ns and key found in .ima or _ima keyring of init_user_ns.<br />
<br />
- TPM and measurements:<br />
- 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,<br />
each IMA namespace would have to be associated with its own TPM instance (vTPM); measurement in the initial IMA namespace are extended into<br />
the hardware TPM as done already<br />
<br />
- Extended attribute security.ima:<br />
- A container should be able to set the security.ima extended attribute<br />
- this should be possibly without the almighty CAP_SYS_ADMIN;<br />
- we may want to gate this with a new capability CAP_SECURITY_XATTR_ADMIN that allows setting security extended attributes inside a container, <br />
possibly only during container build-time<br />
<br />
- Extended attribute security.ima and bind mounting<br />
- It may be necessary that different namespaces be able to sign the same bind-mounted file with different keys<br />
(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<br />
able to access them.)<br />
- Extended attributes, such as security.ima) may need to be virtualizeable (security.ima vs. security.ima@uid=1000 etc.)<br />
<br />
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:<br />
<br />
What should happen with IMA logging, appraisal, and auditing if we setns() through all available<br />
- PID namespaces and send signals: log, appraise, and audit file activity following IMA policy with special handling for (host) root<br />
- IPC namespaces and send messages via IPC: same as for PID<br />
- UTS namespaces and setting hostname: same as for PID<br />
- NET namespaces and sending network traffic: same as for PID<br />
- CGROUP namespaces and configuring cgroups: same as for PID<br />
- 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<br />
to adapt the current implementation...] other than that, same as for PID?<br />
- MNT namespaces and access files or execute program: same as for PID</div>Stefanbhttp://kernsec.org/wiki/index.php?title=IMA_Namespacing_design_considerations&diff=3951IMA Namespacing design considerations2018-03-15T17:58:00Z<p>Stefanb: /* IMA Namespacing Considerations */</p>
<hr />
<div>== Namespacing IMA ==<br />
<br />
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.<br />
<br />
=== Background ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== IMA Namespacing Considerations ===<br />
<br />
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:<br />
<br />
<br />
Support for IMA in namespaces should enable the following:<br />
<br />
- IMA policy for container (similar to the host):<br />
- there should be an initial default policy for every IMA namespace that measures activities inside the container<br />
- the policy can be overwritten once with a user-defined policy that may activate appraisal<br />
- CAP_SYS_ADMIN is currently gating the setting of the IMA policy; <br />
- setting the policy should be possibly without the almighty CAP_SYS_ADMIN<br />
- 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<br />
<br />
- IMA policy extensions due to namespacing:<br />
- an IMA policy should allow rules that define whether activities in (all) child namespaces is to be measured (huge logs on the host)<br />
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<br />
host could possibly eat up a lot of memory<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
<br />
- IMA-measurement:<br />
- 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<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-audit:<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-appraisal and keys:<br />
- each IMA namespace should have its own keyring so that each container can have its files signed with different keys<br />
- the keys (certificates) for verifying signatures may be found inside containers<br />
- it should be possible to enforce that only certified keys are loaded onto a keyring, similar to .ima on the host<br />
- the CA public key used for verifying that public keys (certificates) used for verifying signatures may be found inside the container<br />
or could be known to the container management stack<br />
<br />
- IMA-appraisal and namespacing:<br />
- 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<br />
(nested) IMA namespace where an empty IMA policy has been set? We would measure and audit root's activities as described above.<br />
What about appraising? Would we traverse all the IMA namespaces back to the init_ima_ns and evaluate signatures against the appraisal policy<br />
set there and assume we would always find the keys in the init_user_ns?<br />
<br />
Maybe the following would be a solution for appraising file accesses by (host) root with the key used for signature verification<br />
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<br />
active USER namespace where the key can be found<br />
<br />
for imans from current-IMA-NS backwards up to and including init_ima_ns:<br />
if policy(imans) has appraisal rules for this file:<br />
if file appraisal fails<br />
fail access<br />
else<br />
allow access<br />
break<br />
<br />
or simplified (again after evaluating file access with the current IMA namespace's policy and the currently<br />
active USER namespace where the key can be found)<br />
<br />
Appraise with policy of init_ima_ns and key found in .ima or _ima keyring of init_user_ns.<br />
<br />
- TPM and measurements:<br />
- 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,<br />
each IMA namespace would have to be associated with its own TPM instance (vTPM); measurement in the initial IMA namespace are extended into<br />
the hardware TPM as done already<br />
<br />
- Extended attribute security.ima:<br />
- A container should be able to set the security.ima extended attribute<br />
- this should be possibly without the almighty CAP_SYS_ADMIN;<br />
- we may want to gate this with a new capability CAP_SECURITY_XATTR_ADMIN that allows setting security extended attributes inside a container, <br />
possibly only during container build-time<br />
<br />
- Extended attribute security.ima and bind mounting<br />
- It may be necessary that different namespaces be able to sign the same bind-mounted file with different keys<br />
(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<br />
able to access them.)<br />
- Extended attributes, such as seucrity.ima) may need to be virtualizeable (security.ima vs. security.ima@uid=1000 etc.)<br />
<br />
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:<br />
<br />
What should happen with IMA logging, appraisal, and auditing if we setns() through all available<br />
- PID namespaces and send signals: log, appraise, and audit file activity following IMA policy with special handling for (host) root<br />
- IPC namespaces and send messages via IPC: same as for PID<br />
- UTS namespaces and setting hostname: same as for PID<br />
- NET namespaces and sending network traffic: same as for PID<br />
- CGROUP namespaces and configuring cgroups: same as for PID<br />
- 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<br />
to adapt the current implementation...] other than that, same as for PID?<br />
- MNT namespaces and access files or execute program: same as for PID</div>Stefanbhttp://kernsec.org/wiki/index.php?title=IMA_Namespacing_design_considerations&diff=3950IMA Namespacing design considerations2018-03-15T17:57:08Z<p>Stefanb: </p>
<hr />
<div>== Namespacing IMA ==<br />
<br />
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.<br />
<br />
=== Background ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== IMA Namespacing Considerations ===<br />
<br />
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:<br />
<br />
<br />
Support for IMA in namespaces should enable the following:<br />
<br />
- IMA policy for container (similar to the host):<br />
- there should be an initial default policy for every IMA namespace that measures activities inside the container<br />
- the policy can be overwritten once with a user-defined policy that may activate appraisal<br />
- CAP_SYS_ADMIN is currently gating the setting of the IMA policy; <br />
- setting the policy should be possibly without the almighty CAP_SYS_ADMIN<br />
- 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<br />
<br />
- IMA policy extensions due to namespacing:<br />
- an IMA policy should allow rules that define whether activities in (all) child namespaces is to be measured (huge logs on the host)<br />
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<br />
host could possibly eat up a lot of memory<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
<br />
- IMA-measurement:<br />
- 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<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-audit:<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-appraisal and keys:<br />
- each IMA namespace should have its own keyring so that each container can have its files signed with different keys<br />
- the keys (certificates) for verifying signatures may be found inside containers<br />
- it should be possible to enforce that only certified keys are loaded onto a keyring, similar to .ima on the host<br />
- the CA public key used for verifying that public keys (certificates) used for verifying signatures may be found inside the container<br />
or could be known to the container management stack<br />
<br />
- IMA-appraisal and namespacing:<br />
- 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<br />
(nested) IMA namespace where an empty IMA policy has been set? We would measure and audit root's activities as described above.<br />
What about appraising? Would we traverse all the IMA namespaces back to the init_ima_ns and evaluate signatures against the appraisal policy<br />
set there and assume we would always find the keys in the init_user_ns?<br />
<br />
Maybe the following would be a solution for appraising file accesses by (host) root with the key used for signature verification<br />
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<br />
active USER namespace where the key can be found<br />
<br />
for imans from current-IMA-NS backwards up to and including init_ima_ns:<br />
if policy(imans) has appraisal rules for this file:<br />
if file appraisal fails<br />
fail access<br />
else<br />
allow access<br />
break<br />
<br />
or simplified (again after evaluating file access with the current IMA namespace's policy and the currently<br />
active USER namespace where the key can be found)<br />
<br />
Appraise with policy of init_ima_ns and key found in .ima or _ima keyring of init_user_ns.<br />
<br />
- TPM and measurements:<br />
- 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,<br />
each IMA namespace would have to be associated with its own TPM instance (vTPM); measurement in the initial IMA namespace are extended into<br />
the hardware TPM as done already<br />
<br />
- Extended attribute security.ima:<br />
- A container should be able to set the security.ima extended attribute<br />
- this should be possibly without the almighty CAP_SYS_ADMIN;<br />
- we may want to gate this with a new capability CAP_SECURITY_XATTR_ADMIN that allows setting security extended attributes inside a container, <br />
possibly only during container build-time<br />
<br />
- Extended attribute security.ima and bind mounting<br />
- It may be necessary that different namespaces be able to sign the same bind-mounted file with different keys<br />
(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<br />
able to access them.)<br />
- Extended attributes, such as seucrity.ima) may need to be virtualizeable (security.ima vs. security.ima@uid=1000 etc.)<br />
<br />
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:<br />
<br />
What should happen with IMA logging, appraisal, and auditing if we setns() through all available<br />
- PID namespaces and send signals: log, appraise, and audit file activity following IMA policy with special handling for (host) root<br />
- IPC namespaces and send messages via IPC: same as for PID<br />
- UTS namespaces and setting hostname: same as for PID<br />
- NET namespaces and sending network traffic: same as for PID<br />
- CGROUP namespaces and configuring cgroups: same as for PID<br />
- 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?<br />
- MNT namespaces and access files or execute program: same as for PID</div>Stefanbhttp://kernsec.org/wiki/index.php?title=IMA_Namespacing_design_considerations&diff=3949IMA Namespacing design considerations2018-03-15T17:52:39Z<p>Stefanb: </p>
<hr />
<div>== Namespacing IMA ==<br />
<br />
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.<br />
<br />
=== Background ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== IMA Namespacing Considerations ===<br />
<br />
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:<br />
<br />
<br />
Support for IMA in namespaces should enable the following:<br />
<br />
- IMA policy for container (similar to the host):<br />
- there should be an initial default policy for every IMA namespace that measures activities inside the container<br />
- the policy can be overwritten once with a user-defined policy that may activate appraisal<br />
- CAP_SYS_ADMIN is currently gating the setting of the IMA policy; <br />
- setting the policy should be possibly without the almighty CAP_SYS_ADMIN<br />
- 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<br />
<br />
- IMA policy extensions due to namespacing:<br />
- an IMA policy should allow rules that define whether activities in (all) child namespaces is to be measured (huge logs on the host)<br />
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<br />
host could possibly eat up a lot of memory<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
<br />
- IMA-measurement:<br />
- 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<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-audit:<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-appraisal and keys:<br />
- each IMA namespace should have its own keyring so that each container can have its files signed with different keys<br />
- the keys (certificates) for verifying signatures may be found inside containers<br />
- it should be possible to enforce that only certified keys are loaded onto a keyring, similar to .ima on the host<br />
- the CA public key used for verifying that public keys (certificates) used for verifying signatures may be found inside the container<br />
or could be known to the container management stack<br />
<br />
- IMA-appraisal and namespacing:<br />
- 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<br />
(nested) IMA namespace where an empty IMA policy has been set? We would measure and audit root's activities as described above.<br />
What about appraising? Would we traverse all the IMA namespaces back to the init_ima_ns and evaluate signatures against the appraisal policy<br />
set there and assume we would always find the keys in the init_user_ns?<br />
<br />
Maybe the following would be a solution for appraising file accesses by (host) root with the key used for signature verification<br />
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<br />
active USER namespace where the key can be found<br />
<br />
for imans from current-IMA-NS backwards up to and including init_ima_ns:<br />
if policy(imans) has appraisal rules for this file:<br />
if file appraisal fails<br />
fail access<br />
else<br />
allow access<br />
break<br />
<br />
or simplified (again after evaluating file access with the current IMA namespace's policy and the currently<br />
active USER namespace where the key can be found)<br />
<br />
Appraise with policy of init_ima_ns and key found in .ima or _ima keyring of init_user_ns.<br />
<br />
- TPM and measurements:<br />
- 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,<br />
each IMA namespace would have to be associated with its own TPM instance (vTPM); measurement in the initial IMA namespace are extended into<br />
the hardware TPM as done already<br />
<br />
- Extended attribute security.ima:<br />
- A container should be able to set the security.ima extended attribute<br />
- this should be possibly without the almighty CAP_SYS_ADMIN;<br />
- we may want to gate this with a new capability CAP_SECURITY_XATTR_ADMIN that allows setting security extended attributes inside a container, <br />
possibly only during container build-time<br />
<br />
- Extended attribute security.ima and bind mounting<br />
- It may be necessary that different namespaces be able to sign the same bind-mounted file with different keys<br />
(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<br />
able to access them.)<br />
- Extended attributes, such as seucrity.ima) may need to be virtualizeable (security.ima vs. security.ima@uid=1000 etc.)</div>Stefanbhttp://kernsec.org/wiki/index.php?title=IMA_Namespacing_design_considerations&diff=3948IMA Namespacing design considerations2018-03-15T17:52:01Z<p>Stefanb: /* IMA Namespacing Considerations */</p>
<hr />
<div>== Namespacing IMA ==<br />
<br />
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.<br />
<br />
=== Background ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== IMA Namespacing Considerations ===<br />
<br />
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:<br />
<br />
<br />
Support for IMA in namespaces should enable the following:<br />
<br />
- IMA policy for container (similar to the host):<br />
- there should be an initial default policy for every IMA namespace that measures activities inside the container<br />
- the policy can be overwritten once with a user-defined policy that may activate appraisal<br />
- CAP_SYS_ADMIN is currently gating the setting of the IMA policy; <br />
- setting the policy should be possibly without the almighty CAP_SYS_ADMIN<br />
- 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<br />
<br />
- IMA policy extensions due to namespacing:<br />
- an IMA policy should allow rules that define whether activities in (all) child namespaces is to be measured (huge logs on the host)<br />
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<br />
host could possibly eat up a lot of memory<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
<br />
- IMA-measurement:<br />
- 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<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-audit:<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-appraisal and keys:<br />
- each IMA namespace should have its own keyring so that each container can have its files signed with different keys<br />
- the keys (certificates) for verifying signatures may be found inside containers<br />
- it should be possible to enforce that only certified keys are loaded onto a keyring, similar to .ima on the host<br />
- the CA public key used for verifying that public keys (certificates) used for verifying signatures may be found inside the container<br />
or could be known to the container management stack<br />
<br />
- IMA-appraisal and namespacing:<br />
- 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<br />
(nested) IMA namespace where an empty IMA policy has been set? We would measure and audit root's activities as described above.<br />
What about appraising? Would we traverse all the IMA namespaces back to the init_ima_ns and evaluate signatures against the appraisal policy<br />
set there and assume we would always find the keys in the init_user_ns?<br />
<br />
Maybe the following would be a solution for appraising file accesses by (host) root with the key used for signature verification<br />
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<br />
active USER namespace where the key can be found<br />
<br />
for imans from current-IMA-NS backwards up to and including init_ima_ns:<br />
if policy(imans) has appraisal rules for this file:<br />
if file appraisal fails<br />
fail access<br />
else<br />
allow access<br />
break<br />
<br />
or simplified (again after evaluating file access with the current IMA namespace's policy and the currently<br />
active USER namespace where the key can be found)<br />
<br />
Appraise with policy of init_ima_ns and key found in .ima or _ima keyring of init_user_ns.<br />
<br />
- TPM and measurements:<br />
- 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,<br />
each IMA namespace would have to be associated with its own TPM instance (vTPM); measurement in the initial IMA namespace are extended into<br />
the hardware TPM as done already<br />
<br />
- Extended attribute security.ima:<br />
- A container should be able to set the security.ima extended attribute<br />
- this should be possibly without the almighty CAP_SYS_ADMIN;<br />
- we may want to gate this with a new capability CAP_SECURITY_XATTR_ADMIN that allows setting security extended attributes inside a container, <br />
possibly only during container build-time<br />
<br />
- Extended attribute security.ima and bind mounting<br />
- It may be necessary that different namespaces be able to sign the same bind-mounted file with different keys<br />
(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<br />
able to access them.)<br />
- Extended attributes, such as seucrity.ima) may need to be virtualizeable (security.ima vs. security.ima@uid=1000 etc.)<br />
<br />
== MNT and IMA Namespaces tied together ==<br />
<br />
Let's assume we tie MNT and IMA namespaces together, then there are other scenarios with switching through the other namespaces (UTS, PID, IPC, NET, USER, CGROUP). I am not sure what is supposed to happen other than logging the activity active in the current IMA namespace:<br />
<br />
What should happen with IMA logging, appraisal, and auditing if we setns() through all available<br />
- PID namespaces and send signals: log, appraise, and audit file activity following IMA policy<br />
- IPC namespaces and send messages via IPC: same as for PID<br />
- UTS namespaces and setting hostname: same as for PID<br />
- NET namespaces and sending network traffic: same as for PID?<br />
- CGROUP namespaces and configuring cgroups: same as for PID?<br />
- USER: should now the keys of this USER namespace be active or the keys of the original user namespace used during the clone()? other than that, same as for PID?<br />
<br />
== Independent IMA Namespace ==<br />
<br />
If we create an IMA namespace independently from any other mount namespace, what are we to gain from this or loose? The above ab-use case shows some problem associated with it. Do we have a solution for the item "IMA-appraisal and namespacing" above? In the worst case, would it matter if root spawned a new IMA namespace, set a NULL policy, and only have its activities measured and audited but not appraised?</div>Stefanbhttp://kernsec.org/wiki/index.php?title=IMA_Namespacing_design_considerations&diff=3947IMA Namespacing design considerations2018-03-15T17:48:56Z<p>Stefanb: /* IMA Namespacing Considerations */</p>
<hr />
<div>== Namespacing IMA ==<br />
<br />
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.<br />
<br />
=== Background ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== IMA Namespacing Considerations ===<br />
<br />
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:<br />
<br />
<br />
Support for IMA in namespaces should enable the following:<br />
<br />
- IMA policy for container (similar to the host):<br />
- there should be an initial default policy for every IMA namespace that measures activities inside the container<br />
- the policy can be overwritten once with a user-defined policy that may activate appraisal<br />
- CAP_SYS_ADMIN is currently gating the setting of the IMA policy; <br />
- setting the policy should be possibly without the almighty CAP_SYS_ADMIN<br />
- 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<br />
<br />
- IMA policy extensions due to namespacing:<br />
- an IMA policy should allow rules that define whether activities in (all) child namespaces is to be measured (huge logs on the host)<br />
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<br />
host could possibly eat up a lot of memory<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
<br />
- IMA-measurement:<br />
- 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<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-audit:<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-appraisal and keys:<br />
- each IMA namespace should have its own keyring so that each container can have its files signed with different keys<br />
- the keys (certificates) for verifying signatures may be found inside containers<br />
- it should be possible to enforce that only certified keys are loaded onto a keyring, similar to .ima on the host<br />
- the CA public key used for verifying that public keys (certificates) used for verifying signatures may be found inside the container<br />
or could be known to the container management stack<br />
<br />
- IMA-appraisal and namespacing:<br />
- 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<br />
(nested) IMA namespace where an empty IMA policy has been set? We would measure and audit root's activities as described above.<br />
What about appraising? Would we traverse all the IMA namespaces back to the init_ima_ns and evaluate signatures against the appraisal policy<br />
set there and assume we would always find the keys in the init_user_ns?<br />
<br />
Maybe the following would be a solution for appraising file accesses by (host) root with the key used for signature verification<br />
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<br />
active USER namespace where the key can be found<br />
<br />
for imans from current-IMA-NS backwards up to and including init_ima_ns:<br />
if policy(imans) has appraisal rules for this file:<br />
if file appraisal fails<br />
fail access<br />
else<br />
allow access<br />
break<br />
<br />
or simplified (again after evaluating file access with the current IMA namespace's policy and the currently<br />
active USER namespace where the key can be found)<br />
<br />
Appraise with policy of init_ima_ns and key found in .ima or _ima keyring of init_user_ns.<br />
<br />
- TPM and measurements:<br />
- 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,<br />
each IMA namespace would have to be associated with its own TPM instance (vTPM); measurement in the initial IMA namespace are extended into<br />
the hardware TPM as done already<br />
<br />
- Extended attribute security.ima:<br />
- A container should be able to set the security.ima extended attribute<br />
- this should be possibly without the almighty CAP_SYS_ADMIN;<br />
- we may want to gate this with a new capability CAP_SECURITY_XATTR_ADMIN that allows setting security extended attributes inside a container, <br />
possibly only during container build-time<br />
<br />
- Extended attribute security.ima and bind mounting<br />
- It may be necessary that different namespaces be able to sign the same bind-mounted file with different keys<br />
(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<br />
able to access them.)<br />
- Extended attributes, such as seucrity.ima) may need to be virtualizeable (security.ima vs. security.ima@uid=1000 etc.)<br />
<br />
<br />
A concrete 'ab-use' case that we have to to avoid is the following:<br />
<br />
Root creates a container that shares the host's mount namespace but creates a new IMA namespace with an empty policy: it would be unexpected if there was an IMA policy active on the host that enforces file appraisal but in this case the IMA policy is not enforced since a (hypothetical) IMA namespace of the host was not joined because only the mount namespace of the host was joined and a new IMA namespace was created. Now we have two choices here: We tie the mount and IMA namespaces together via single clone flag (as proposed in RFC patches) and joining the mount namespace automatically joins the associated IMA namespace (single setns()). This eliminates being able to create independent IMA namespace. Or we make user space responsible for it and say if a mount namespace is joined, find the associated IMA namespace and join both of them (2 setns() calls). Well, I think the former would be preferred over the latter.<br />
<br />
So either we tie the IMA namespace to some other existing namespace, preferably mount namespace, or we have it be independently created (new clone flag or by writing into a sysfs/securityfs file).<br />
<br />
== MNT and IMA Namespaces tied together ==<br />
<br />
Let's assume we tie MNT and IMA namespaces together, then there are other scenarios with switching through the other namespaces (UTS, PID, IPC, NET, USER, CGROUP). I am not sure what is supposed to happen other than logging the activity active in the current IMA namespace:<br />
<br />
What should happen with IMA logging, appraisal, and auditing if we setns() through all available<br />
- PID namespaces and send signals: log, appraise, and audit file activity following IMA policy<br />
- IPC namespaces and send messages via IPC: same as for PID<br />
- UTS namespaces and setting hostname: same as for PID<br />
- NET namespaces and sending network traffic: same as for PID?<br />
- CGROUP namespaces and configuring cgroups: same as for PID?<br />
- USER: should now the keys of this USER namespace be active or the keys of the original user namespace used during the clone()? other than that, same as for PID?<br />
<br />
== Independent IMA Namespace ==<br />
<br />
If we create an IMA namespace independently from any other mount namespace, what are we to gain from this or loose? The above ab-use case shows some problem associated with it. Do we have a solution for the item "IMA-appraisal and namespacing" above? In the worst case, would it matter if root spawned a new IMA namespace, set a NULL policy, and only have its activities measured and audited but not appraised?</div>Stefanbhttp://kernsec.org/wiki/index.php?title=IMA_Namespacing_design_considerations&diff=3946IMA Namespacing design considerations2018-03-15T17:29:52Z<p>Stefanb: /* IMA Namespacing Considerations */</p>
<hr />
<div>== Namespacing IMA ==<br />
<br />
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.<br />
<br />
=== Background ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== IMA Namespacing Considerations ===<br />
<br />
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:<br />
<br />
<br />
Support for IMA in namespaces should enable the following:<br />
<br />
- IMA policy for container (similar to the host):<br />
- there should be an initial default policy for every IMA namespace that measures activities inside the container<br />
- the policy can be overwritten once with a user-defined policy that may activate appraisal<br />
- CAP_SYS_ADMIN is currently gating the setting of the IMA policy; <br />
- setting the policy should be possibly without the almighty CAP_SYS_ADMIN<br />
- 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<br />
<br />
- IMA policy extensions due to namespacing:<br />
- an IMA policy should allow rules that define whether activities in (all) child namespaces is to be measured (huge logs on the host)<br />
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<br />
host could possibly eat up a lot of memory<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
<br />
- IMA-measurement:<br />
- 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<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-audit:<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-appraisal and keys:<br />
- each IMA namespace should have its own keyring so that each container can have its files signed with different keys<br />
- the keys (certificates) for verifying signatures may be found inside containers<br />
- it should be possible to enforce that only certified keys are loaded onto a keyring, similar to .ima on the host<br />
- the CA public key used for verifying that public keys (certificates) used for verifying signatures may be found inside the container<br />
or could be known to the container management stack<br />
<br />
- IMA-appraisal and namespacing:<br />
- 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<br />
(nested) IMA namespace where an empty IMA policy has been set? We would measure and audit root's activities as described above.<br />
What about appraising? Would we traverse all the IMA namespaces back to the init_ima_ns and evaluate signatures against the appraisal policy<br />
set there and assume we would always find the keys in the init_user_ns?<br />
<br />
Maybe the following would be a solution for appraising file accesses by (host) root with the key used for signature verification<br />
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<br />
active USER namespace where the key can be found<br />
<br />
for imans from current-IMA-NS backwards up to and including init_ima_ns:<br />
if policy(imans) has appraisal rules for this file:<br />
if file appraisal fails<br />
fail access<br />
else<br />
allow access<br />
break<br />
<br />
or simplified (again after evaluating file access with the current IMA namespace's policy and the currently<br />
active USER namespace where the key can be found)<br />
<br />
Appraise with policy of init_ima_ns and key found in .ima or _ima keyring in init_user_ns.<br />
<br />
- TPM and measurements:<br />
- 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,<br />
each IMA namespace would have to be associated with its own TPM instance (vTPM); measurement in the initial IMA namespace are extended into<br />
the hardware TPM as done already<br />
<br />
- Extended attribute security.ima:<br />
- A container should be able to set the security.ima extended attribute<br />
- this should be possibly without the almighty CAP_SYS_ADMIN;<br />
- we may want to gate this with a new capability CAP_SECURITY_XATTR_ADMIN that allows setting security extended attributes inside a container, <br />
possibly only during container build-time<br />
<br />
- Extended attribute security.ima and bind mounting<br />
- It may be necessary that different namespaces be able to sign the same bind-mounted file with different keys<br />
(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<br />
able to access them.)<br />
- Extended attributes, such as seucrity.ima) may need to be virtualizeable (security.ima vs. security.ima@uid=1000 etc.)<br />
<br />
<br />
A concrete 'ab-use' case that we have to to avoid is the following:<br />
<br />
Root creates a container that shares the host's mount namespace but creates a new IMA namespace with an empty policy: it would be unexpected if there was an IMA policy active on the host that enforces file appraisal but in this case the IMA policy is not enforced since a (hypothetical) IMA namespace of the host was not joined because only the mount namespace of the host was joined and a new IMA namespace was created. Now we have two choices here: We tie the mount and IMA namespaces together via single clone flag (as proposed in RFC patches) and joining the mount namespace automatically joins the associated IMA namespace (single setns()). This eliminates being able to create independent IMA namespace. Or we make user space responsible for it and say if a mount namespace is joined, find the associated IMA namespace and join both of them (2 setns() calls). Well, I think the former would be preferred over the latter.<br />
<br />
So either we tie the IMA namespace to some other existing namespace, preferably mount namespace, or we have it be independently created (new clone flag or by writing into a sysfs/securityfs file).<br />
<br />
== MNT and IMA Namespaces tied together ==<br />
<br />
Let's assume we tie MNT and IMA namespaces together, then there are other scenarios with switching through the other namespaces (UTS, PID, IPC, NET, USER, CGROUP). I am not sure what is supposed to happen other than logging the activity active in the current IMA namespace:<br />
<br />
What should happen with IMA logging, appraisal, and auditing if we setns() through all available<br />
- PID namespaces and send signals: log, appraise, and audit file activity following IMA policy<br />
- IPC namespaces and send messages via IPC: same as for PID<br />
- UTS namespaces and setting hostname: same as for PID<br />
- NET namespaces and sending network traffic: same as for PID?<br />
- CGROUP namespaces and configuring cgroups: same as for PID?<br />
- USER: should now the keys of this USER namespace be active or the keys of the original user namespace used during the clone()? other than that, same as for PID?<br />
<br />
== Independent IMA Namespace ==<br />
<br />
If we create an IMA namespace independently from any other mount namespace, what are we to gain from this or loose? The above ab-use case shows some problem associated with it. Do we have a solution for the item "IMA-appraisal and namespacing" above? In the worst case, would it matter if root spawned a new IMA namespace, set a NULL policy, and only have its activities measured and audited but not appraised?</div>Stefanbhttp://kernsec.org/wiki/index.php?title=IMA_Namespacing_design_considerations&diff=3945IMA Namespacing design considerations2018-03-15T17:29:00Z<p>Stefanb: /* IMA Namespacing Considerations */</p>
<hr />
<div>== Namespacing IMA ==<br />
<br />
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.<br />
<br />
=== Background ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== IMA Namespacing Considerations ===<br />
<br />
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:<br />
<br />
<br />
Support for IMA in namespaces should enable the following:<br />
<br />
- IMA policy for container (similar to the host):<br />
- there should be an initial default policy for every IMA namespace that measures activities inside the container<br />
- the policy can be overwritten once with a user-defined policy that may activate appraisal<br />
- CAP_SYS_ADMIN is currently gating the setting of the IMA policy; <br />
- setting the policy should be possibly without the almighty CAP_SYS_ADMIN<br />
- 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<br />
<br />
- IMA policy extensions due to namespacing:<br />
- an IMA policy should allow rules that define whether activities in (all) child namespaces is to be measured (huge logs on the host)<br />
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<br />
host could possibly eat up a lot of memory<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
<br />
- IMA-measurement:<br />
- 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<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-audit:<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-appraisal and keys:<br />
- each IMA namespace should have its own keyring so that each container can have its files signed with different keys<br />
- the keys (certificates) for verifying signatures may be found inside containers<br />
- it should be possible to enforce that only certified keys are loaded onto a keyring, similar to .ima on the host<br />
- the CA public key used for verifying that public keys (certificates) used for verifying signatures may be found inside the container<br />
or could be known to the container management stack<br />
<br />
- IMA-appraisal and namespacing:<br />
- 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<br />
(nested) IMA namespace where an empty IMA policy has been set? We would measure and audit root's activities as described above.<br />
What about appraising? Would we traverse all the IMA namespaces back to the init_ima_ns and evaluate signatures against the appraisal policy<br />
set there and assume we would always find the keys in the init_user_ns?<br />
<br />
Maybe the following would be a solution for appraising file accesses by (host) root with the key used for signature verification<br />
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<br />
active USER namespace where the key can be found<br />
<br />
for imans from current-IMA-NS backwards up to and including init_ima_ns:<br />
if policy(imans) has appraisal rules for this file:<br />
if file appraisal fails<br />
fail access<br />
else<br />
allow access<br />
break<br />
<br />
or simplified (again after evaluating file access with the current IMA namespace's policy and the currently<br />
active USER namespace where the key can be found)<br />
<br />
Appraise with policy if init_ima_ns and key found in .ima or _ima keyring in init_user_ns.<br />
<br />
- TPM and measurements:<br />
- 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,<br />
each IMA namespace would have to be associated with its own TPM instance (vTPM); measurement in the initial IMA namespace are extended into<br />
the hardware TPM as done already<br />
<br />
- Extended attribute security.ima:<br />
- A container should be able to set the security.ima extended attribute<br />
- this should be possibly without the almighty CAP_SYS_ADMIN;<br />
- we may want to gate this with a new capability CAP_SECURITY_XATTR_ADMIN that allows setting security extended attributes inside a container, <br />
possibly only during container build-time<br />
<br />
- Extended attribute security.ima and bind mounting<br />
- It may be necessary that different namespaces be able to sign the same bind-mounted file with different keys<br />
(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<br />
able to access them.)<br />
- Extended attributes, such as seucrity.ima) may need to be virtualizeable (security.ima vs. security.ima@uid=1000 etc.)<br />
<br />
<br />
A concrete 'ab-use' case that we have to to avoid is the following:<br />
<br />
Root creates a container that shares the host's mount namespace but creates a new IMA namespace with an empty policy: it would be unexpected if there was an IMA policy active on the host that enforces file appraisal but in this case the IMA policy is not enforced since a (hypothetical) IMA namespace of the host was not joined because only the mount namespace of the host was joined and a new IMA namespace was created. Now we have two choices here: We tie the mount and IMA namespaces together via single clone flag (as proposed in RFC patches) and joining the mount namespace automatically joins the associated IMA namespace (single setns()). This eliminates being able to create independent IMA namespace. Or we make user space responsible for it and say if a mount namespace is joined, find the associated IMA namespace and join both of them (2 setns() calls). Well, I think the former would be preferred over the latter.<br />
<br />
So either we tie the IMA namespace to some other existing namespace, preferably mount namespace, or we have it be independently created (new clone flag or by writing into a sysfs/securityfs file).<br />
<br />
== MNT and IMA Namespaces tied together ==<br />
<br />
Let's assume we tie MNT and IMA namespaces together, then there are other scenarios with switching through the other namespaces (UTS, PID, IPC, NET, USER, CGROUP). I am not sure what is supposed to happen other than logging the activity active in the current IMA namespace:<br />
<br />
What should happen with IMA logging, appraisal, and auditing if we setns() through all available<br />
- PID namespaces and send signals: log, appraise, and audit file activity following IMA policy<br />
- IPC namespaces and send messages via IPC: same as for PID<br />
- UTS namespaces and setting hostname: same as for PID<br />
- NET namespaces and sending network traffic: same as for PID?<br />
- CGROUP namespaces and configuring cgroups: same as for PID?<br />
- USER: should now the keys of this USER namespace be active or the keys of the original user namespace used during the clone()? other than that, same as for PID?<br />
<br />
== Independent IMA Namespace ==<br />
<br />
If we create an IMA namespace independently from any other mount namespace, what are we to gain from this or loose? The above ab-use case shows some problem associated with it. Do we have a solution for the item "IMA-appraisal and namespacing" above? In the worst case, would it matter if root spawned a new IMA namespace, set a NULL policy, and only have its activities measured and audited but not appraised?</div>Stefanbhttp://kernsec.org/wiki/index.php?title=IMA_Namespacing_design_considerations&diff=3944IMA Namespacing design considerations2018-03-15T17:28:25Z<p>Stefanb: /* IMA Namespacing Considerations */</p>
<hr />
<div>== Namespacing IMA ==<br />
<br />
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.<br />
<br />
=== Background ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== IMA Namespacing Considerations ===<br />
<br />
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:<br />
<br />
<br />
Support for IMA in namespaces should enable the following:<br />
<br />
- IMA policy for container (similar to the host):<br />
- there should be an initial default policy for every IMA namespace that measures activities inside the container<br />
- the policy can be overwritten once with a user-defined policy that may activate appraisal<br />
- CAP_SYS_ADMIN is currently gating the setting of the IMA policy; <br />
- setting the policy should be possibly without the almighty CAP_SYS_ADMIN<br />
- 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<br />
<br />
- IMA policy extensions due to namespacing:<br />
- an IMA policy should allow rules that define whether activities in (all) child namespaces is to be measured (huge logs on the host)<br />
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<br />
host could possibly eat up a lot of memory<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
<br />
- IMA-measurement:<br />
- 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<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-audit:<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-appraisal and keys:<br />
- each IMA namespace should have its own keyring so that each container can have its files signed with different keys<br />
- the keys (certificates) for verifying signatures may be found inside containers<br />
- it should be possible to enforce that only certified keys are loaded onto a keyring, similar to .ima on the host<br />
- the CA public key used for verifying that public keys (certificates) used for verifying signatures may be found inside the container<br />
or could be known to the container management stack<br />
<br />
- IMA-appraisal and namespacing:<br />
- 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<br />
(nested) IMA namespace where an empty IMA policy has been set? We would measure and audit root's activities as described above.<br />
What about appraising? Would we traverse all the IMA namespaces back to the init_ima_ns and evaluate signatures against the appraisal policy<br />
set there and assume we would always find the keys in the init_user_ns?<br />
<br />
Maybe the following would be a solution for appraising file accesses by (host) root with the key used for signature verification<br />
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<br />
active USER namespace where the key can be found<br />
<br />
for imans from current-IMA-NS backwards up to and including init_ima_ns:<br />
if policy(imans) has appraisal rules for this file:<br />
if file appraisal fails<br />
fail access<br />
else<br />
allow access<br />
break<br />
<br />
or simplified (again after evaluating file access with the current IMA namespace's policy and the currently<br />
active USER namespace where the key can be found)<br />
<br />
Appraise with policy if init_ima_ns and key found in .ima or _ima keyring in init_user_ns.<br />
<br />
- TPM and measurements:<br />
- 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,<br />
each IMA namespace would have to be associated with its own TPM instance (vTPM); measurement in the initial IMA namespace are extended into<br />
the hardware TPM as done already<br />
<br />
- Extended attribute security.ima:<br />
- A container should be able to set the security.ima extended attribute<br />
- this should be possibly without the almighty CAP_SYS_ADMIN;<br />
- we may want to gate this with a new capability CAP_SECURITY_XATTR_ADMIN that allows setting security extended attributes inside a container, <br />
possibly only during container build-time<br />
<br />
- Extended attribute security.ima and bind mounting<br />
- It may be necessary that different namespaces be able to sign the same bind-mounted file with different keys<br />
(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<br />
able to access them.)<br />
- Extended attributes, such as seucrity.ima) may need to be virtualizeable (security.ima vs. security.ima@uid=1000 etc.)<br />
<br />
<br />
A concrete 'ab-use' case that we have to to avoid is the following:<br />
<br />
Root creates a container that shares the host's mount namespace but creates a new IMA namespace with an empty policy: it would be unexpected if there was an IMA policy active on the host that enforces file appraisal but in this case the IMA policy is not enforced since a (hypothetical) IMA namespace of the host was not joined because only the mount namespace of the host was joined and a new IMA namespace was created. Now we have two choices here: We tie the mount and IMA namespaces together via single clone flag (as proposed in RFC patches) and joining the mount namespace automatically joins the associated IMA namespace (single setns()). This eliminates being able to create independent IMA namespace. Or we make user space responsible for it and say if a mount namespace is joined, find the associated IMA namespace and join both of them (2 setns() calls). Well, I think the former would be preferred over the latter.<br />
<br />
So either we tie the IMA namespace to some other existing namespace, preferably mount namespace, or we have it be independently created (new clone flag or by writing into a sysfs/securityfs file).<br />
<br />
== MNT and IMA Namespaces tied together ==<br />
<br />
Let's assume we tie MNT and IMA namespaces together, then there are other scenarios with switching through the other namespaces (UTS, PID, IPC, NET, USER, CGROUP). I am not sure what is supposed to happen other than logging the activity active in the current IMA namespace:<br />
<br />
What should happen with IMA logging, appraisal, and auditing if we setns() through all available<br />
- PID namespaces and send signals: log, appraise, and audit file activity following IMA policy<br />
- IPC namespaces and send messages via IPC: same as for PID<br />
- UTS namespaces and setting hostname: same as for PID<br />
- NET namespaces and sending network traffic: same as for PID?<br />
- CGROUP namespaces and configuring cgroups: same as for PID?<br />
- USER: should now the keys of this USER namespace be active or the keys of the original user namespace used during the clone()? other than that, same as for PID?<br />
<br />
== Independent IMA Namespace ==<br />
<br />
If we create an IMA namespace independently from any other mount namespace, what are we to gain from this or loose? The above ab-use case shows some problem associated with it. Do we have a solution for the item "IMA-appraisal and namespacing" above? In the worst case, would it matter if root spawned a new IMA namespace, set a NULL policy, and only have its activities measured and audited but not appraised?</div>Stefanbhttp://kernsec.org/wiki/index.php?title=IMA_Namespacing_design_considerations&diff=3943IMA Namespacing design considerations2018-03-15T17:23:54Z<p>Stefanb: /* IMA Namespacing Considerations */</p>
<hr />
<div>== Namespacing IMA ==<br />
<br />
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.<br />
<br />
=== Background ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== IMA Namespacing Considerations ===<br />
<br />
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:<br />
<br />
<br />
Support for IMA in namespaces should enable the following:<br />
<br />
- IMA policy for container (similar to the host):<br />
- there should be an initial default policy for every IMA namespace that measures activities inside the container<br />
- the policy can be overwritten once with a user-defined policy that may activate appraisal<br />
- CAP_SYS_ADMIN is currently gating the setting of the IMA policy; <br />
- setting the policy should be possibly without the almighty CAP_SYS_ADMIN<br />
- 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<br />
<br />
- IMA policy extensions due to namespacing:<br />
- an IMA policy should allow rules that define whether activities in (all) child namespaces is to be measured (huge logs on the host)<br />
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<br />
host could possibly eat up a lot of memory<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
<br />
- IMA-measurement:<br />
- 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<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-audit:<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-appraisal and keys:<br />
- each IMA namespace should have its own keyring so that each container can have its files signed with different keys<br />
- the keys (certificates) for verifying signatures may be found inside containers<br />
- it should be possible to enforce that only certified keys are loaded onto a keyring, similar to .ima on the host<br />
- the CA public key used for verifying that public keys (certificates) used for verifying signatures may be found inside the container<br />
or could be known to the container management stack<br />
<br />
- IMA-appraisal and namespacing:<br />
- 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<br />
(nested) IMA namespace where an empty IMA policy has been set? We would measure and audit root's activities as described above.<br />
What about appraising? Would we traverse all the IMA namespaces back to the init_ima_ns and evaluate signatures against the appraisal policy<br />
set there and assume we would always find the keys in the init_user_ns?<br />
Maybe the following would be a solution for appraising file accesses by (host) root with the key used for signature verification<br />
assumed in the init_user_ns:<br />
<br />
for imans from current-IMA-NS backwards up to and including init_ima_ns:<br />
if policy(imans) has appraisal rules for this file:<br />
if file appraisal fails<br />
fail access<br />
else<br />
allow access<br />
break<br />
<br />
- TPM and measurements:<br />
- 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,<br />
each IMA namespace would have to be associated with its own TPM instance (vTPM); measurement in the initial IMA namespace are extended into<br />
the hardware TPM as done already<br />
<br />
- Extended attribute security.ima:<br />
- A container should be able to set the security.ima extended attribute<br />
- this should be possibly without the almighty CAP_SYS_ADMIN;<br />
- we may want to gate this with a new capability CAP_SECURITY_XATTR_ADMIN that allows setting security extended attributes inside a container, <br />
possibly only during container build-time<br />
<br />
- Extended attribute security.ima and bind mounting<br />
- It may be necessary that different namespaces be able to sign the same bind-mounted file with different keys<br />
(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<br />
able to access them.)<br />
- Extended attributes, such as seucrity.ima) may need to be virtualizeable (security.ima vs. security.ima@uid=1000 etc.)<br />
<br />
<br />
A concrete 'ab-use' case that we have to to avoid is the following:<br />
<br />
Root creates a container that shares the host's mount namespace but creates a new IMA namespace with an empty policy: it would be unexpected if there was an IMA policy active on the host that enforces file appraisal but in this case the IMA policy is not enforced since a (hypothetical) IMA namespace of the host was not joined because only the mount namespace of the host was joined and a new IMA namespace was created. Now we have two choices here: We tie the mount and IMA namespaces together via single clone flag (as proposed in RFC patches) and joining the mount namespace automatically joins the associated IMA namespace (single setns()). This eliminates being able to create independent IMA namespace. Or we make user space responsible for it and say if a mount namespace is joined, find the associated IMA namespace and join both of them (2 setns() calls). Well, I think the former would be preferred over the latter.<br />
<br />
So either we tie the IMA namespace to some other existing namespace, preferably mount namespace, or we have it be independently created (new clone flag or by writing into a sysfs/securityfs file).<br />
<br />
== MNT and IMA Namespaces tied together ==<br />
<br />
Let's assume we tie MNT and IMA namespaces together, then there are other scenarios with switching through the other namespaces (UTS, PID, IPC, NET, USER, CGROUP). I am not sure what is supposed to happen other than logging the activity active in the current IMA namespace:<br />
<br />
What should happen with IMA logging, appraisal, and auditing if we setns() through all available<br />
- PID namespaces and send signals: log, appraise, and audit file activity following IMA policy<br />
- IPC namespaces and send messages via IPC: same as for PID<br />
- UTS namespaces and setting hostname: same as for PID<br />
- NET namespaces and sending network traffic: same as for PID?<br />
- CGROUP namespaces and configuring cgroups: same as for PID?<br />
- USER: should now the keys of this USER namespace be active or the keys of the original user namespace used during the clone()? other than that, same as for PID?<br />
<br />
== Independent IMA Namespace ==<br />
<br />
If we create an IMA namespace independently from any other mount namespace, what are we to gain from this or loose? The above ab-use case shows some problem associated with it. Do we have a solution for the item "IMA-appraisal and namespacing" above? In the worst case, would it matter if root spawned a new IMA namespace, set a NULL policy, and only have its activities measured and audited but not appraised?</div>Stefanbhttp://kernsec.org/wiki/index.php?title=IMA_Namespacing_design_considerations&diff=3942IMA Namespacing design considerations2018-03-15T17:19:33Z<p>Stefanb: /* IMA Namespacing Considerations */</p>
<hr />
<div>== Namespacing IMA ==<br />
<br />
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.<br />
<br />
=== Background ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== IMA Namespacing Considerations ===<br />
<br />
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:<br />
<br />
<br />
Support for IMA in namespaces should enable the following:<br />
<br />
- IMA policy for container (similar to the host):<br />
- there should be an initial default policy for every IMA namespace that measures activities inside the container<br />
- the policy can be overwritten once with a user-defined policy that may activate appraisal<br />
- CAP_SYS_ADMIN is currently gating the setting of the IMA policy; <br />
- setting the policy should be possibly without the almighty CAP_SYS_ADMIN<br />
- 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<br />
<br />
- IMA policy extensions due to namespacing:<br />
- an IMA policy should allow rules that define whether activities in (all) child namespaces is to be measured (huge logs on the host)<br />
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<br />
host could possibly eat up a lot of memory<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
<br />
- IMA-measurement:<br />
- 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<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-audit:<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-appraisal and keys:<br />
- each IMA namespace should have its own keyring so that each container can have its files signed with different keys<br />
- the keys (certificates) for verifying signatures may be found inside containers<br />
- it should be possible to enforce that only certified keys are loaded onto a keyring, similar to .ima on the host<br />
- the CA public key used for verifying that public keys (certificates) used for verifying signatures may be found inside the container<br />
or could be known to the container management stack<br />
<br />
- IMA-appraisal and namespacing:<br />
- 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<br />
(nested) IMA namespace where an empty IMA policy has been set? We would measure and audit root's activities as described above.<br />
What about appraising? Would we traverse all the IMA namespaces back to the init_ima_ns and evaluate signatures against the appraisal policy<br />
set there and assume we would always find the keys in the init_user_ns?<br />
Maybe the following would be a solution for appraising file accesses by (host) root with the key used for signature verfication<br />
assumed in the current user_ns (we never pick any other user_ns than this one for trying to find a key):<br />
<br />
for imans from current-IMA-NS backwards up to and including init_ima_ns:<br />
if policy(imans) has appraisal rules for this file:<br />
if file appraisal fails<br />
fail access<br />
else<br />
allow access<br />
break<br />
<br />
- TPM and measurements:<br />
- 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,<br />
each IMA namespace would have to be associated with its own TPM instance (vTPM); measurement in the initial IMA namespace are extended into<br />
the hardware TPM as done already<br />
<br />
- Extended attribute security.ima:<br />
- A container should be able to set the security.ima extended attribute<br />
- this should be possibly without the almighty CAP_SYS_ADMIN;<br />
- we may want to gate this with a new capability CAP_SECURITY_XATTR_ADMIN that allows setting security extended attributes inside a container, <br />
possibly only during container build-time<br />
<br />
- Extended attribute security.ima and bind mounting<br />
- It may be necessary that different namespaces be able to sign the same bind-mounted file with different keys<br />
(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<br />
able to access them.)<br />
- Extended attributes, such as seucrity.ima) may need to be virtualizeable (security.ima vs. security.ima@uid=1000 etc.)<br />
<br />
<br />
A concrete 'ab-use' case that we have to to avoid is the following:<br />
<br />
Root creates a container that shares the host's mount namespace but creates a new IMA namespace with an empty policy: it would be unexpected if there was an IMA policy active on the host that enforces file appraisal but in this case the IMA policy is not enforced since a (hypothetical) IMA namespace of the host was not joined because only the mount namespace of the host was joined and a new IMA namespace was created. Now we have two choices here: We tie the mount and IMA namespaces together via single clone flag (as proposed in RFC patches) and joining the mount namespace automatically joins the associated IMA namespace (single setns()). This eliminates being able to create independent IMA namespace. Or we make user space responsible for it and say if a mount namespace is joined, find the associated IMA namespace and join both of them (2 setns() calls). Well, I think the former would be preferred over the latter.<br />
<br />
So either we tie the IMA namespace to some other existing namespace, preferably mount namespace, or we have it be independently created (new clone flag or by writing into a sysfs/securityfs file).<br />
<br />
== MNT and IMA Namespaces tied together ==<br />
<br />
Let's assume we tie MNT and IMA namespaces together, then there are other scenarios with switching through the other namespaces (UTS, PID, IPC, NET, USER, CGROUP). I am not sure what is supposed to happen other than logging the activity active in the current IMA namespace:<br />
<br />
What should happen with IMA logging, appraisal, and auditing if we setns() through all available<br />
- PID namespaces and send signals: log, appraise, and audit file activity following IMA policy<br />
- IPC namespaces and send messages via IPC: same as for PID<br />
- UTS namespaces and setting hostname: same as for PID<br />
- NET namespaces and sending network traffic: same as for PID?<br />
- CGROUP namespaces and configuring cgroups: same as for PID?<br />
- USER: should now the keys of this USER namespace be active or the keys of the original user namespace used during the clone()? other than that, same as for PID?<br />
<br />
== Independent IMA Namespace ==<br />
<br />
If we create an IMA namespace independently from any other mount namespace, what are we to gain from this or loose? The above ab-use case shows some problem associated with it. Do we have a solution for the item "IMA-appraisal and namespacing" above? In the worst case, would it matter if root spawned a new IMA namespace, set a NULL policy, and only have its activities measured and audited but not appraised?</div>Stefanbhttp://kernsec.org/wiki/index.php?title=IMA_Namespacing_design_considerations&diff=3941IMA Namespacing design considerations2018-03-15T17:14:01Z<p>Stefanb: /* IMA Namespacing Considerations */</p>
<hr />
<div>== Namespacing IMA ==<br />
<br />
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.<br />
<br />
=== Background ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== IMA Namespacing Considerations ===<br />
<br />
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:<br />
<br />
<br />
Support for IMA in namespaces should enable the following:<br />
<br />
- IMA policy for container (similar to the host):<br />
- there should be an initial default policy for every IMA namespace that measures activities inside the container<br />
- the policy can be overwritten once with a user-defined policy that may activate appraisal<br />
- CAP_SYS_ADMIN is currently gating the setting of the IMA policy; <br />
- setting the policy should be possibly without the almighty CAP_SYS_ADMIN<br />
- 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<br />
<br />
- IMA policy extensions due to namespacing:<br />
- an IMA policy should allow rules that define whether activities in (all) child namespaces is to be measured (huge logs on the host)<br />
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<br />
host could possibly eat up a lot of memory<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
<br />
- IMA-measurement:<br />
- 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<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-audit:<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-appraisal and keys:<br />
- each IMA namespace should have its own keyring so that each container can have its files signed with different keys<br />
- the keys (certificates) for verifying signatures may be found inside containers<br />
- it should be possible to enforce that only certified keys are loaded onto a keyring, similar to .ima on the host<br />
- the CA public key used for verifying that public keys (certificates) used for verifying signatures may be found inside the container<br />
or could be known to the container management stack<br />
<br />
- IMA-appraisal and namespacing:<br />
- 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<br />
(nested) IMA namespace where an empty IMA policy has been set? We would measure and audit root's activities as described above.<br />
What about appraising? Would we traverse all the IMA namespaces back to the init_ima_ns and evaluate signatures against the appraisal policy<br />
set there and assume we would always find the keys in the init_user_ns?<br />
Maybe the following would be a solution for appraising file accesses with keys assumed in the current user_ns:<br />
<br />
for imans from current-IMA-NS backwards up to and including init_ima_ns:<br />
if policy(imans) has appraisal rules for this file:<br />
if file appraisal fails<br />
fail access<br />
else<br />
allow access<br />
break<br />
<br />
- TPM and measurements:<br />
- 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,<br />
each IMA namespace would have to be associated with its own TPM instance (vTPM); measurement in the initial IMA namespace are extended into<br />
the hardware TPM as done already<br />
<br />
- Extended attribute security.ima:<br />
- A container should be able to set the security.ima extended attribute<br />
- this should be possibly without the almighty CAP_SYS_ADMIN;<br />
- we may want to gate this with a new capability CAP_SECURITY_XATTR_ADMIN that allows setting security extended attributes inside a container, <br />
possibly only during container build-time<br />
<br />
- Extended attribute security.ima and bind mounting<br />
- It may be necessary that different namespaces be able to sign the same bind-mounted file with different keys<br />
(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<br />
able to access them.)<br />
- Extended attributes, such as seucrity.ima) may need to be virtualizeable (security.ima vs. security.ima@uid=1000 etc.)<br />
<br />
<br />
A concrete 'ab-use' case that we have to to avoid is the following:<br />
<br />
Root creates a container that shares the host's mount namespace but creates a new IMA namespace with an empty policy: it would be unexpected if there was an IMA policy active on the host that enforces file appraisal but in this case the IMA policy is not enforced since a (hypothetical) IMA namespace of the host was not joined because only the mount namespace of the host was joined and a new IMA namespace was created. Now we have two choices here: We tie the mount and IMA namespaces together via single clone flag (as proposed in RFC patches) and joining the mount namespace automatically joins the associated IMA namespace (single setns()). This eliminates being able to create independent IMA namespace. Or we make user space responsible for it and say if a mount namespace is joined, find the associated IMA namespace and join both of them (2 setns() calls). Well, I think the former would be preferred over the latter.<br />
<br />
So either we tie the IMA namespace to some other existing namespace, preferably mount namespace, or we have it be independently created (new clone flag or by writing into a sysfs/securityfs file).<br />
<br />
== MNT and IMA Namespaces tied together ==<br />
<br />
Let's assume we tie MNT and IMA namespaces together, then there are other scenarios with switching through the other namespaces (UTS, PID, IPC, NET, USER, CGROUP). I am not sure what is supposed to happen other than logging the activity active in the current IMA namespace:<br />
<br />
What should happen with IMA logging, appraisal, and auditing if we setns() through all available<br />
- PID namespaces and send signals: log, appraise, and audit file activity following IMA policy<br />
- IPC namespaces and send messages via IPC: same as for PID<br />
- UTS namespaces and setting hostname: same as for PID<br />
- NET namespaces and sending network traffic: same as for PID?<br />
- CGROUP namespaces and configuring cgroups: same as for PID?<br />
- USER: should now the keys of this USER namespace be active or the keys of the original user namespace used during the clone()? other than that, same as for PID?<br />
<br />
== Independent IMA Namespace ==<br />
<br />
If we create an IMA namespace independently from any other mount namespace, what are we to gain from this or loose? The above ab-use case shows some problem associated with it. Do we have a solution for the item "IMA-appraisal and namespacing" above? In the worst case, would it matter if root spawned a new IMA namespace, set a NULL policy, and only have its activities measured and audited but not appraised?</div>Stefanbhttp://kernsec.org/wiki/index.php?title=IMA_Namespacing_design_considerations&diff=3940IMA Namespacing design considerations2018-03-15T17:13:37Z<p>Stefanb: /* IMA Namespacing Considerations */</p>
<hr />
<div>== Namespacing IMA ==<br />
<br />
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.<br />
<br />
=== Background ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== IMA Namespacing Considerations ===<br />
<br />
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:<br />
<br />
<br />
Support for IMA in namespaces should enable the following:<br />
<br />
- IMA policy for container (similar to the host):<br />
- there should be an initial default policy for every IMA namespace that measures activities inside the container<br />
- the policy can be overwritten once with a user-defined policy that may activate appraisal<br />
- CAP_SYS_ADMIN is currently gating the setting of the IMA policy; <br />
- setting the policy should be possibly without the almighty CAP_SYS_ADMIN<br />
- 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<br />
<br />
- IMA policy extensions due to namespacing:<br />
- an IMA policy should allow rules that define whether activities in (all) child namespaces is to be measured (huge logs on the host)<br />
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<br />
host could possibly eat up a lot of memory<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
<br />
- IMA-measurement:<br />
- 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<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-audit:<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-appraisal and keys:<br />
- each IMA namespace should have its own keyring so that each container can have its files signed with different keys<br />
- the keys (certificates) for verifying signatures may be found inside containers<br />
- it should be possible to enforce that only certified keys are loaded onto a keyring, similar to .ima on the host<br />
- the CA public key used for verifying that public keys (certificates) used for verifying signatures may be found inside the container<br />
or could be known to the container management stack<br />
<br />
- IMA-appraisal and namespacing:<br />
- 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<br />
(nested) IMA namespace where an empty IMA policy has been set? We would measure and audit root's activities as described above.<br />
What about appraising? Would we traverse all the IMA namespaces back to the init_ima_ns and evaluate signatures against the appraisal policy<br />
set there and assume we would always find the keys in the init_user_ns?<br />
Maybe the following would be a solution for appraising file accesses with keys assumed in the current user_ns:<br />
<br />
for imans from current-IMA-NS backwards up to and including init_ima_ns:<br />
if policy(imans) has appraisal rules for this file:<br />
if file appraisal fails<br />
fail access<br />
else<br />
allow access<br />
break<br />
<br />
- TPM and measurements:<br />
- 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,<br />
each IMA namespace would have to be associated with its own TPM instance (vTPM); measurement in the initial IMA namespace are extended into<br />
the hardware TPM as done already<br />
<br />
- Extended attribute security.ima:<br />
- A container should be able to set the security.ima extended attribute<br />
- this should be possibly without the almighty CAP_SYS_ADMIN;<br />
- we may want to gate this with a new capability CAP_SECURITY_XATTR_ADMIN that allows setting security extended attributes inside a container, <br />
possibly only during container build-time<br />
<br />
- Extended attribute security.ima and bind mounting<br />
- It may be necessary that different namespaces be able to sign the same bind-mounted file with different keys<br />
(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<br />
able to access them.)<br />
- Extended attributes, such as seucrity.ima) may need to be virtualizeable (security.ima vs. security.ima@uid=1000 etc.)<br />
<br />
<br />
A concrete 'ab-use' case that we have to to avoid is the following:<br />
<br />
Root creates a container that shares the host's mount namespace but creates a new IMA namespace with an empty policy: it would be unexpected if there was an IMA policy active on the host that enforces file appraisal but in this case the IMA policy is not enforced since a (hypothetical) IMA namespace of the host was not joined because only the mount namespace of the host was joined and a new IMA namespace was created. Now we have two choices here: We tie the mount and IMA namespaces together via single clone flag (as proposed in RFC patches) and joining the mount namespace automatically joins the associated IMA namespace (single setns()). This eliminates being able to create independent IMA namespace. Or we make user space responsible for it and say if a mount namespace is joined, find the associated IMA namespace and join both of them (2 setns() calls). Well, I think the former would be preferred over the latter.<br />
<br />
So either we tie the IMA namespace to some other existing namespace, preferably mount namespace, or we have it be independently created (new clone flag or by writing into a sysfs/securityfs file).<br />
<br />
== MNT and IMA Namespaces tied together ==<br />
<br />
Let's assume we tie MNT and IMA namespaces together, then there are other scenarios with switching through the other namespaces (UTS, PID, IPC, NET, USER, CGROUP). I am not sure what is supposed to happen other than logging the activity active in the current IMA namespace:<br />
<br />
What should happen with IMA logging, appraisal, and auditing if we setns() through all available<br />
- PID namespaces and send signals: log, appraise, and audit file activity following IMA policy<br />
- IPC namespaces and send messages via IPC: same as for PID<br />
- UTS namespaces and setting hostname: same as for PID<br />
- NET namespaces and sending network traffic: same as for PID?<br />
- CGROUP namespaces and configuring cgroups: same as for PID?<br />
- USER: should now the keys of this USER namespace be active or the keys of the original user namespace used during the clone()? other than that, same as for PID?<br />
<br />
== Independent IMA Namespace ==<br />
<br />
If we create an IMA namespace independently from any other mount namespace, what are we to gain from this or loose? The above ab-use case shows some problem associated with it. Do we have a solution for the item "IMA-appraisal and namespacing" above? In the worst case, would it matter if root spawned a new IMA namespace, set a NULL policy, and only have its activities measured and audited but not appraised?</div>Stefanbhttp://kernsec.org/wiki/index.php?title=IMA_Namespacing_design_considerations&diff=3939IMA Namespacing design considerations2018-03-15T15:04:29Z<p>Stefanb: /* IMA Namespacing Considerations */</p>
<hr />
<div>== Namespacing IMA ==<br />
<br />
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.<br />
<br />
=== Background ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== IMA Namespacing Considerations ===<br />
<br />
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:<br />
<br />
<br />
Support for IMA in namespaces should enable the following:<br />
<br />
- IMA policy for container (similar to the host):<br />
- there should be an initial default policy for every IMA namespace that measures activities inside the container<br />
- the policy can be overwritten once with a user-defined policy that may activate appraisal<br />
- CAP_SYS_ADMIN is currently gating the setting of the IMA policy; <br />
- setting the policy should be possibly without the almighty CAP_SYS_ADMIN<br />
- 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<br />
<br />
- IMA policy extensions due to namespacing:<br />
- an IMA policy should allow rules that define whether activities in (all) child namespaces is to be measured (huge logs on the host)<br />
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<br />
host could possibly eat up a lot of memory<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
<br />
- IMA-measurement:<br />
- 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<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-audit:<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-appraisal and keys:<br />
- each IMA namespace should have its own keyring so that each container can have its files signed with different keys<br />
- the keys (certificates) for verifying signatures may be found inside containers<br />
- it should be possible to enforce that only certified keys are loaded onto a keyring, similar to .ima on the host<br />
- the CA public key used for verifying that public keys (certificates) used for verifying signatures may be found inside the container<br />
or could be known to the container management stack<br />
<br />
- IMA-appraisal and namespacing:<br />
- 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<br />
(nested) IMA namespace where an empty IMA policy has been set? We would measure and audit root's activities as described above.<br />
What about appraising? Would we traverse all the IMA namespaces back to the init_ima_ns and evaluate signatures against the appraisal policy<br />
set there and assume we would always find the keys in the init_user_ns?<br />
<br />
- TPM and measurements:<br />
- 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,<br />
each IMA namespace would have to be associated with its own TPM instance (vTPM); measurement in the initial IMA namespace are extended into<br />
the hardware TPM as done already<br />
<br />
- Extended attribute security.ima:<br />
- A container should be able to set the security.ima extended attribute<br />
- this should be possibly without the almighty CAP_SYS_ADMIN;<br />
- we may want to gate this with a new capability CAP_SECURITY_XATTR_ADMIN that allows setting security extended attributes inside a container, <br />
possibly only during container build-time<br />
<br />
- Extended attribute security.ima and bind mounting<br />
- It may be necessary that different namespaces be able to sign the same bind-mounted file with different keys<br />
(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<br />
able to access them.)<br />
- Extended attributes, such as seucrity.ima) may need to be virtualizeable (security.ima vs. security.ima@uid=1000 etc.)<br />
<br />
<br />
A concrete 'ab-use' case that we have to to avoid is the following:<br />
<br />
Root creates a container that shares the host's mount namespace but creates a new IMA namespace with an empty policy: it would be unexpected if there was an IMA policy active on the host that enforces file appraisal but in this case the IMA policy is not enforced since a (hypothetical) IMA namespace of the host was not joined because only the mount namespace of the host was joined and a new IMA namespace was created. Now we have two choices here: We tie the mount and IMA namespaces together via single clone flag (as proposed in RFC patches) and joining the mount namespace automatically joins the associated IMA namespace (single setns()). This eliminates being able to create independent IMA namespace. Or we make user space responsible for it and say if a mount namespace is joined, find the associated IMA namespace and join both of them (2 setns() calls). Well, I think the former would be preferred over the latter.<br />
<br />
So either we tie the IMA namespace to some other existing namespace, preferably mount namespace, or we have it be independently created (new clone flag or by writing into a sysfs/securityfs file).<br />
<br />
== MNT and IMA Namespaces tied together ==<br />
<br />
Let's assume we tie MNT and IMA namespaces together, then there are other scenarios with switching through the other namespaces (UTS, PID, IPC, NET, USER, CGROUP). I am not sure what is supposed to happen other than logging the activity active in the current IMA namespace:<br />
<br />
What should happen with IMA logging, appraisal, and auditing if we setns() through all available<br />
- PID namespaces and send signals: log, appraise, and audit file activity following IMA policy<br />
- IPC namespaces and send messages via IPC: same as for PID<br />
- UTS namespaces and setting hostname: same as for PID<br />
- NET namespaces and sending network traffic: same as for PID?<br />
- CGROUP namespaces and configuring cgroups: same as for PID?<br />
- USER: should now the keys of this USER namespace be active or the keys of the original user namespace used during the clone()? other than that, same as for PID?<br />
<br />
== Independent IMA Namespace ==<br />
<br />
If we create an IMA namespace independently from any other mount namespace, what are we to gain from this or loose? The above ab-use case shows some problem associated with it. Do we have a solution for the item "IMA-appraisal and namespacing" above? In the worst case, would it matter if root spawned a new IMA namespace, set a NULL policy, and only have its activities measured and audited but not appraised?</div>Stefanbhttp://kernsec.org/wiki/index.php?title=IMA_Namespacing_design_considerations&diff=3938IMA Namespacing design considerations2018-03-15T14:45:49Z<p>Stefanb: /* IMA Namespacing Considerations */</p>
<hr />
<div>== Namespacing IMA ==<br />
<br />
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.<br />
<br />
=== Background ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== IMA Namespacing Considerations ===<br />
<br />
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:<br />
<br />
<br />
Support for IMA in namespaces should enable the following:<br />
<br />
- IMA policy for container (similar to the host):<br />
- there should be an initial default policy for every IMA namespace that measures activities inside the container<br />
- the policy can be overwritten once with a user-defined policy that may activate appraisal<br />
- CAP_SYS_ADMIN is currently gating the setting of the IMA policy; <br />
- setting the policy should be possibly without the almighty CAP_SYS_ADMIN<br />
- 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<br />
<br />
- IMA policy extensions due to namespacing:<br />
- an IMA policy should allow rules that define whether activities in (all) child namespaces is to be measured (huge logs on the host)<br />
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<br />
host could possibly eat up a lot of memory<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
<br />
- IMA-measurement:<br />
- 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<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-audit:<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-appraisal and keys:<br />
- each IMA namespace should have its own keyring so that each container can have its files signed with different keys<br />
- the keys (certificates) for verifying signatures may be found inside containers<br />
- it should be possible to enforce that only certified keys are loaded onto a keyring, similar to .ima on the host<br />
- the CA public key used for verifying that public keys (certificates) used for verifying signatures may be found inside the container<br />
or could be known to the container management stack<br />
<br />
- IMA-appraisal and namespacing:<br />
- 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<br />
(nested) IMA namespace where an empty IMA policy has been set? We would measure and audit root's activities as described above.<br />
What about appraising? Would we traverse all the IMA namespaces back to the init_ima_ns and evaluate signatures against the appraisal policy<br />
set there and assume we would always find the keys in the init_user_ns?<br />
<br />
- TPM and measurements:<br />
- 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,<br />
each IMA namespace would have to be associated with its own TPM instance (vTPM); measurement in the initial IMA namespace are extended into<br />
the hardware TPM as done already<br />
<br />
- Extended attribute security.ima:<br />
- A container should be able to set the security.ima extended attribute<br />
- this should be possibly without the almighty CAP_SYS_ADMIN;<br />
- we may want to gate this with a new capability CAP_SECURITY_XATTR_ADMIN that allows setting security extended attributes inside a container, <br />
possibly only during container build-time<br />
<br />
- Extended attribute security.ima and bind mounting<br />
- It may be necessary that different namespaces be able to sign the same bind-mounted file with different keys<br />
(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<br />
able to access them.)<br />
- Extended attributes, such as seucrity.ima) may need to be virtualizeable (security.ima vs. security.ima@uid=1000 etc.)<br />
<br />
<br />
A concrete 'ab-use' case that we have to to avoid is the following:<br />
<br />
Root creates a privileged container that shares the host's mount namespace but creates a new IMA namespace with an empty policy: it would be unexpected if there was an IMA policy active on the host that enforces file appraisal but in this case the IMA policy is not enforced since a (hypothetical) IMA namespace of the host was not joined because only the mount namespace of the host was joined. Now we have two choices here: We tie the mount and IMA namespaces together via single clone flag (as proposed in RFC patches) and joining the mount namespace automatically joins the associated IMA namespace (single setns()). Or we make user space responsible for it and say if a mount namespace is joined, find the associated IMA namespace and join both of them (2 setns() calls). Well, I think the former would be preferred over the latter.<br />
<br />
So either we tie the IMA namespace to some other existing namespace, preferably mount namespace, or we have it be independently created (new clone flag or by writing into a sysfs/securityfs file).<br />
<br />
== MNT and IMA Namespaces tied together ==<br />
<br />
Let's assume we tie MNT and IMA namespaces together, then there are other scenarios with switching through the other namespaces (UTS, PID, IPC, NET, USER, CGROUP). I am not sure what is supposed to happen other than logging the activity active in the current IMA namespace:<br />
<br />
What should happen with IMA logging, appraisal, and auditing if we setns() through all available<br />
- PID namespaces and send signals: log, appraise, and audit file activity following IMA policy<br />
- IPC namespaces and send messages via IPC: same as for PID<br />
- UTS namespaces and setting hostname: same as for PID<br />
- NET namespaces and sending network traffic: same as for PID?<br />
- CGROUP namespaces and configuring cgroups: same as for PID?<br />
- USER: should now the keys of this USER namespace be active or the keys of the original user namespace used during the clone()? other than that, same as for PID?<br />
<br />
== Independent IMA Namespace ==<br />
<br />
If we create an IMA namespace independently from any other mount namespace, what are we to gain from this or loose? The above ab-use case shows some problem associated with it. Do we have a solution for the item "IMA-appraisal and namespacing" above? In the worst case, would it matter if root spawned a new IMA namespace, set a NULL policy, and only have its activities measured and audited but not appraised?</div>Stefanbhttp://kernsec.org/wiki/index.php?title=IMA_Namespacing_design_considerations&diff=3937IMA Namespacing design considerations2018-03-15T14:34:31Z<p>Stefanb: /* Background */</p>
<hr />
<div>== Namespacing IMA ==<br />
<br />
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.<br />
<br />
=== Background ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== IMA Namespacing Considerations ===<br />
<br />
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:<br />
<br />
<br />
Support for IMA in namespaces should enable the following:<br />
<br />
- IMA policy for container (similar to the host):<br />
- there should be an initial default policy for every IMA namespace that measures activities inside the container<br />
- the policy can be overwritten once with a user-defined policy that may activate appraisal<br />
- CAP_SYS_ADMIN is currently gating the setting of the IMA policy; <br />
- setting the policy should be possibly without the almighty CAP_SYS_ADMIN<br />
- 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<br />
<br />
- IMA policy extensions due to namespacing:<br />
- an IMA policy should allow rules that define whether activities in (all) child namespaces is to be measured (huge logs on the host)<br />
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<br />
host could possibly eat up a lot of memory<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
<br />
- IMA-measurement:<br />
- 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<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-audit:<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-appraisal and keys:<br />
- each IMA namespace should have its own keyring so that each container can have its files signed with different keys<br />
- the keys (certificates) for verifying signatures may be found inside containers<br />
- it should be possible to enforce that only certified keys are loaded onto a keyring, similar to .ima on the host<br />
- the CA public key used for verifying that public keys (certificates) used for verifying signatures may be found inside the container<br />
or could be known to the container management stack<br />
<br />
- IMA-appraisal and namespacing:<br />
- 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<br />
(nested) IMA namespace where an empty IMA policy has been set? We would measure and audit root's activities as described above.<br />
What about appraising? Would we traverse all the IMA namespaces back to the init_ima_ns and evaluate signatures against the appraisal policy<br />
set there and assume we would always find the keys in the init_user_ns?<br />
<br />
- TPM and measurements:<br />
- 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,<br />
each IMA namespace would have to be associated with its own TPM instance (vTPM); measurement in the initial IMA namespace are extended into<br />
the hardware TPM as done already<br />
<br />
- Extended attribute security.ima:<br />
- A container should be able to set the security.ima extended attribute<br />
- this should be possibly without the almighty CAP_SYS_ADMIN;<br />
- we may want to gate this with a new capability CAP_SECURITY_XATTR_ADMIN that allows setting security extended attributes inside a container, <br />
possibly only during container build-time<br />
<br />
- Extended attribute security.ima and bind mounting<br />
- It may be necessary that different namespaces be able to sign the same bind-mounted file with different keys<br />
(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<br />
able to access them.)<br />
- Extended attributes, such as seucrity.ima) may need to be virtualizeable (security.ima vs. security.ima@uid=1000 etc.)<br />
<br />
<br />
A concrete 'ab-use' case that we have to to avoid is the following:<br />
<br />
A user creates a privileged container that shares the host's mount namespace: it would be unexpected if there was an IMA policy active on the host that enforces file appraisal but in this case the IMA policy is not enforced since a (hypothetical) IMA namespace of the host was not joined because only the mount namespace of the host was joined. Now we have two choices here: We tie the mount and IMA namespaces together via single clone flag (as proposed in RFC patches) and joining the mount namespace automatically joins the associated IMA namespace (single setns()). Or we make user space responsible for it and say if a mount namespace is joined, find the associated IMA namespace and join both of them (2 setns() calls). Well, I think the former would be preferred over the latter.<br />
<br />
So either we tie the IMA namespace to some other existing namespace, preferably mount namespace, or we have it be independently created (new clone flag or by writing into a sysfs/securityfs file).<br />
<br />
== MNT and IMA Namespaces tied together ==<br />
<br />
Let's assume we tie MNT and IMA namespaces together, then there are other scenarios with switching through the other namespaces (UTS, PID, IPC, NET, USER, CGROUP). I am not sure what is supposed to happen other than logging the activity active in the current IMA namespace:<br />
<br />
What should happen with IMA logging, appraisal, and auditing if we setns() through all available<br />
- PID namespaces and send signals: log, appraise, and audit file activity following IMA policy<br />
- IPC namespaces and send messages via IPC: same as for PID<br />
- UTS namespaces and setting hostname: same as for PID<br />
- NET namespaces and sending network traffic: same as for PID?<br />
- CGROUP namespaces and configuring cgroups: same as for PID?<br />
- USER: should now the keys of this USER namespace be active or the keys of the original user namespace used during the clone()? other than that, same as for PID?<br />
<br />
== Independent IMA Namespace ==<br />
<br />
If we create an IMA namespace independently from any other mount namespace, what are we to gain from this or loose? The above ab-use case shows some problem associated with it. Do we have a solution for the item "IMA-appraisal and namespacing" above? In the worst case, would it matter if root spawned a new IMA namespace, set a NULL policy, and only have its activities measured and audited but not appraised?</div>Stefanbhttp://kernsec.org/wiki/index.php?title=IMA_Namespacing_design_considerations&diff=3936IMA Namespacing design considerations2018-03-15T14:32:04Z<p>Stefanb: /* Independent IMA Namespace */</p>
<hr />
<div>== Namespacing IMA ==<br />
<br />
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.<br />
<br />
=== Background ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== IMA Namespacing Considerations ===<br />
<br />
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:<br />
<br />
<br />
Support for IMA in namespaces should enable the following:<br />
<br />
- IMA policy for container (similar to the host):<br />
- there should be an initial default policy for every IMA namespace that measures activities inside the container<br />
- the policy can be overwritten once with a user-defined policy that may activate appraisal<br />
- CAP_SYS_ADMIN is currently gating the setting of the IMA policy; <br />
- setting the policy should be possibly without the almighty CAP_SYS_ADMIN<br />
- 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<br />
<br />
- IMA policy extensions due to namespacing:<br />
- an IMA policy should allow rules that define whether activities in (all) child namespaces is to be measured (huge logs on the host)<br />
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<br />
host could possibly eat up a lot of memory<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
<br />
- IMA-measurement:<br />
- 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<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-audit:<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-appraisal and keys:<br />
- each IMA namespace should have its own keyring so that each container can have its files signed with different keys<br />
- the keys (certificates) for verifying signatures may be found inside containers<br />
- it should be possible to enforce that only certified keys are loaded onto a keyring, similar to .ima on the host<br />
- the CA public key used for verifying that public keys (certificates) used for verifying signatures may be found inside the container<br />
or could be known to the container management stack<br />
<br />
- IMA-appraisal and namespacing:<br />
- 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<br />
(nested) IMA namespace where an empty IMA policy has been set? We would measure and audit root's activities as described above.<br />
What about appraising? Would we traverse all the IMA namespaces back to the init_ima_ns and evaluate signatures against the appraisal policy<br />
set there and assume we would always find the keys in the init_user_ns?<br />
<br />
- TPM and measurements:<br />
- 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,<br />
each IMA namespace would have to be associated with its own TPM instance (vTPM); measurement in the initial IMA namespace are extended into<br />
the hardware TPM as done already<br />
<br />
- Extended attribute security.ima:<br />
- A container should be able to set the security.ima extended attribute<br />
- this should be possibly without the almighty CAP_SYS_ADMIN;<br />
- we may want to gate this with a new capability CAP_SECURITY_XATTR_ADMIN that allows setting security extended attributes inside a container, <br />
possibly only during container build-time<br />
<br />
- Extended attribute security.ima and bind mounting<br />
- It may be necessary that different namespaces be able to sign the same bind-mounted file with different keys<br />
(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<br />
able to access them.)<br />
- Extended attributes, such as seucrity.ima) may need to be virtualizeable (security.ima vs. security.ima@uid=1000 etc.)<br />
<br />
<br />
A concrete 'ab-use' case that we have to to avoid is the following:<br />
<br />
A user creates a privileged container that shares the host's mount namespace: it would be unexpected if there was an IMA policy active on the host that enforces file appraisal but in this case the IMA policy is not enforced since a (hypothetical) IMA namespace of the host was not joined because only the mount namespace of the host was joined. Now we have two choices here: We tie the mount and IMA namespaces together via single clone flag (as proposed in RFC patches) and joining the mount namespace automatically joins the associated IMA namespace (single setns()). Or we make user space responsible for it and say if a mount namespace is joined, find the associated IMA namespace and join both of them (2 setns() calls). Well, I think the former would be preferred over the latter.<br />
<br />
So either we tie the IMA namespace to some other existing namespace, preferably mount namespace, or we have it be independently created (new clone flag or by writing into a sysfs/securityfs file).<br />
<br />
== MNT and IMA Namespaces tied together ==<br />
<br />
Let's assume we tie MNT and IMA namespaces together, then there are other scenarios with switching through the other namespaces (UTS, PID, IPC, NET, USER, CGROUP). I am not sure what is supposed to happen other than logging the activity active in the current IMA namespace:<br />
<br />
What should happen with IMA logging, appraisal, and auditing if we setns() through all available<br />
- PID namespaces and send signals: log, appraise, and audit file activity following IMA policy<br />
- IPC namespaces and send messages via IPC: same as for PID<br />
- UTS namespaces and setting hostname: same as for PID<br />
- NET namespaces and sending network traffic: same as for PID?<br />
- CGROUP namespaces and configuring cgroups: same as for PID?<br />
- USER: should now the keys of this USER namespace be active or the keys of the original user namespace used during the clone()? other than that, same as for PID?<br />
<br />
== Independent IMA Namespace ==<br />
<br />
If we create an IMA namespace independently from any other mount namespace, what are we to gain from this or loose? The above ab-use case shows some problem associated with it. Do we have a solution for the item "IMA-appraisal and namespacing" above? In the worst case, would it matter if root spawned a new IMA namespace, set a NULL policy, and only have its activities measured and audited but not appraised?</div>Stefanbhttp://kernsec.org/wiki/index.php?title=IMA_Namespacing_design_considerations&diff=3935IMA Namespacing design considerations2018-03-15T14:31:21Z<p>Stefanb: /* IMA Namespacing Considerations */</p>
<hr />
<div>== Namespacing IMA ==<br />
<br />
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.<br />
<br />
=== Background ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== IMA Namespacing Considerations ===<br />
<br />
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:<br />
<br />
<br />
Support for IMA in namespaces should enable the following:<br />
<br />
- IMA policy for container (similar to the host):<br />
- there should be an initial default policy for every IMA namespace that measures activities inside the container<br />
- the policy can be overwritten once with a user-defined policy that may activate appraisal<br />
- CAP_SYS_ADMIN is currently gating the setting of the IMA policy; <br />
- setting the policy should be possibly without the almighty CAP_SYS_ADMIN<br />
- 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<br />
<br />
- IMA policy extensions due to namespacing:<br />
- an IMA policy should allow rules that define whether activities in (all) child namespaces is to be measured (huge logs on the host)<br />
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<br />
host could possibly eat up a lot of memory<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
<br />
- IMA-measurement:<br />
- 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<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-audit:<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-appraisal and keys:<br />
- each IMA namespace should have its own keyring so that each container can have its files signed with different keys<br />
- the keys (certificates) for verifying signatures may be found inside containers<br />
- it should be possible to enforce that only certified keys are loaded onto a keyring, similar to .ima on the host<br />
- the CA public key used for verifying that public keys (certificates) used for verifying signatures may be found inside the container<br />
or could be known to the container management stack<br />
<br />
- IMA-appraisal and namespacing:<br />
- 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<br />
(nested) IMA namespace where an empty IMA policy has been set? We would measure and audit root's activities as described above.<br />
What about appraising? Would we traverse all the IMA namespaces back to the init_ima_ns and evaluate signatures against the appraisal policy<br />
set there and assume we would always find the keys in the init_user_ns?<br />
<br />
- TPM and measurements:<br />
- 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,<br />
each IMA namespace would have to be associated with its own TPM instance (vTPM); measurement in the initial IMA namespace are extended into<br />
the hardware TPM as done already<br />
<br />
- Extended attribute security.ima:<br />
- A container should be able to set the security.ima extended attribute<br />
- this should be possibly without the almighty CAP_SYS_ADMIN;<br />
- we may want to gate this with a new capability CAP_SECURITY_XATTR_ADMIN that allows setting security extended attributes inside a container, <br />
possibly only during container build-time<br />
<br />
- Extended attribute security.ima and bind mounting<br />
- It may be necessary that different namespaces be able to sign the same bind-mounted file with different keys<br />
(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<br />
able to access them.)<br />
- Extended attributes, such as seucrity.ima) may need to be virtualizeable (security.ima vs. security.ima@uid=1000 etc.)<br />
<br />
<br />
A concrete 'ab-use' case that we have to to avoid is the following:<br />
<br />
A user creates a privileged container that shares the host's mount namespace: it would be unexpected if there was an IMA policy active on the host that enforces file appraisal but in this case the IMA policy is not enforced since a (hypothetical) IMA namespace of the host was not joined because only the mount namespace of the host was joined. Now we have two choices here: We tie the mount and IMA namespaces together via single clone flag (as proposed in RFC patches) and joining the mount namespace automatically joins the associated IMA namespace (single setns()). Or we make user space responsible for it and say if a mount namespace is joined, find the associated IMA namespace and join both of them (2 setns() calls). Well, I think the former would be preferred over the latter.<br />
<br />
So either we tie the IMA namespace to some other existing namespace, preferably mount namespace, or we have it be independently created (new clone flag or by writing into a sysfs/securityfs file).<br />
<br />
== MNT and IMA Namespaces tied together ==<br />
<br />
Let's assume we tie MNT and IMA namespaces together, then there are other scenarios with switching through the other namespaces (UTS, PID, IPC, NET, USER, CGROUP). I am not sure what is supposed to happen other than logging the activity active in the current IMA namespace:<br />
<br />
What should happen with IMA logging, appraisal, and auditing if we setns() through all available<br />
- PID namespaces and send signals: log, appraise, and audit file activity following IMA policy<br />
- IPC namespaces and send messages via IPC: same as for PID<br />
- UTS namespaces and setting hostname: same as for PID<br />
- NET namespaces and sending network traffic: same as for PID?<br />
- CGROUP namespaces and configuring cgroups: same as for PID?<br />
- USER: should now the keys of this USER namespace be active or the keys of the original user namespace used during the clone()? other than that, same as for PID?<br />
<br />
== Independent IMA Namespace ==<br />
<br />
If we create an IMA namespace independently from any other mount namespace, what are we to gain from this or loose? The above ab-use case shows some problem associated with it. Do we have a solution for the item "IMA-appraisal and namespacing" above? In the worst case, would it matter if root spawned a new IMA namespace, set a NULL policy and only have its activities measured and audited but not appraised?</div>Stefanbhttp://kernsec.org/wiki/index.php?title=IMA_Namespacing_design_considerations&diff=3934IMA Namespacing design considerations2018-03-15T14:30:36Z<p>Stefanb: </p>
<hr />
<div>== Namespacing IMA ==<br />
<br />
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.<br />
<br />
=== Background ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== IMA Namespacing Considerations ===<br />
<br />
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 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:<br />
<br />
<br />
Support for IMA in namespaces should enable the following:<br />
<br />
- IMA policy for container (similar to the host):<br />
- there should be an initial default policy for every IMA namespace that measures activities inside the container<br />
- the policy can be overwritten once with a user-defined policy that may activate appraisal<br />
- CAP_SYS_ADMIN is currently gating the setting of the IMA policy; <br />
- setting the policy should be possibly without the almighty CAP_SYS_ADMIN<br />
- 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<br />
<br />
- IMA policy extensions due to namespacing:<br />
- an IMA policy should allow rules that define whether activities in (all) child namespaces is to be measured (huge logs on the host)<br />
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<br />
host could possibly eat up a lot of memory<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
<br />
- IMA-measurement:<br />
- 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<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-audit:<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-appraisal and keys:<br />
- each IMA namespace should have its own keyring so that each container can have its files signed with different keys<br />
- the keys (certificates) for verifying signatures may be found inside containers<br />
- it should be possible to enforce that only certified keys are loaded onto a keyring, similar to .ima on the host<br />
- the CA public key used for verifying that public keys (certificates) used for verifying signatures may be found inside the container<br />
or could be known to the container management stack<br />
<br />
- IMA-appraisal and namespacing:<br />
- 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<br />
(nested) IMA namespace where an empty IMA policy has been set? We would measure and audit root's activities as described above.<br />
What about appraising? Would we traverse all the IMA namespaces back to the init_ima_ns and evaluate signatures against the appraisal policy<br />
set there and assume we would always find the keys in the init_user_ns?<br />
<br />
- TPM and measurements:<br />
- 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,<br />
each IMA namespace would have to be associated with its own TPM instance (vTPM); measurement in the initial IMA namespace are extended into<br />
the hardware TPM as done already<br />
<br />
- Extended attribute security.ima:<br />
- A container should be able to set the security.ima extended attribute<br />
- this should be possibly without the almighty CAP_SYS_ADMIN;<br />
- we may want to gate this with a new capability CAP_SECURITY_XATTR_ADMIN that allows setting security extended attributes inside a container, <br />
possibly only during container build-time<br />
<br />
- Extended attribute security.ima and bind mounting<br />
- It may be necessary that different namespaces be able to sign the same bind-mounted file with different keys<br />
(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<br />
able to access them.)<br />
- Extended attributes, such as seucrity.ima) may need to be virtualizeable (security.ima vs. security.ima@uid=1000 etc.)<br />
<br />
<br />
A concrete 'ab-use' case that we have to to avoid is the following:<br />
<br />
A user creates a privileged container that shares the host's mount namespace: it would be unexpected if there was an IMA policy active on the host that enforces file appraisal but in this case the IMA policy is not enforced since a (hypothetical) IMA namespace of the host was not joined because only the mount namespace of the host was joined. Now we have two choices here: We tie the mount and IMA namespaces together via single clone flag (as proposed in RFC patches) and joining the mount namespace automatically joins the associated IMA namespace (single setns()). Or we make user space responsible for it and say if a mount namespace is joined, find the associated IMA namespace and join both of them (2 setns() calls). Well, I think the former would be preferred over the latter.<br />
<br />
So either we tie the IMA namespace to some other existing namespace, preferably mount namespace, or we have it be independently created (new clone flag or by writing into a sysfs/securityfs file).<br />
<br />
== MNT and IMA Namespaces tied together ==<br />
<br />
Let's assume we tie MNT and IMA namespaces together, then there are other scenarios with switching through the other namespaces (UTS, PID, IPC, NET, USER, CGROUP). I am not sure what is supposed to happen other than logging the activity active in the current IMA namespace:<br />
<br />
What should happen with IMA logging, appraisal, and auditing if we setns() through all available<br />
- PID namespaces and send signals: log, appraise, and audit file activity following IMA policy<br />
- IPC namespaces and send messages via IPC: same as for PID<br />
- UTS namespaces and setting hostname: same as for PID<br />
- NET namespaces and sending network traffic: same as for PID?<br />
- CGROUP namespaces and configuring cgroups: same as for PID?<br />
- USER: should now the keys of this USER namespace be active or the keys of the original user namespace used during the clone()? other than that, same as for PID?<br />
<br />
== Independent IMA Namespace ==<br />
<br />
If we create an IMA namespace independently from any other mount namespace, what are we to gain from this or loose? The above ab-use case shows some problem associated with it. Do we have a solution for the item "IMA-appraisal and namespacing" above? In the worst case, would it matter if root spawned a new IMA namespace, set a NULL policy and only have its activities measured and audited but not appraised?</div>Stefanbhttp://kernsec.org/wiki/index.php?title=IMA_Namespacing_design_considerations&diff=3933IMA Namespacing design considerations2018-03-15T14:22:05Z<p>Stefanb: </p>
<hr />
<div>== Namespacing IMA ==<br />
<br />
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.<br />
<br />
=== Background ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
IMA-audit is about IMA related events, such as update of the IMA policy or files that were measured by IMA. Which file activity is audited can be configured using an IMA policy.<br />
<br />
=== IMA Namespacing Considerations ===<br />
<br />
When namespacing IMA we 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 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:<br />
<br />
<br />
Support for IMA in namespaces should enable the following:<br />
<br />
- IMA policy for container (similar to the host):<br />
- there should be an initial default policy for every IMA namespace that measures activities inside the container<br />
- the policy can be overwritten once with a user-defined policy that may activate appraisal<br />
- CAP_SYS_ADMIN is currently gating the setting of the IMA policy; <br />
- setting the policy should be possibly without the almighty CAP_SYS_ADMIN<br />
- 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<br />
<br />
- IMA policy extensions due to namespacing:<br />
- an IMA policy should allow rules that define whether activities in (all) child namespaces is to be measured (huge logs on the host)<br />
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<br />
host could possibly eat up a lot of memory<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
<br />
- IMA-measurement:<br />
- 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<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-audit:<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA-appraisal and keys:<br />
- each IMA namespace should have its own keyring so that each container can have its files signed with different keys<br />
- the keys (certificates) for verifying signatures may be found inside containers<br />
- it should be possible to enforce that only certified keys are loaded onto a keyring, similar to .ima on the host<br />
- the CA public key used for verifying that public keys (certificates) used for verifying signatures may be found inside the container<br />
or could be known to the container management stack<br />
<br />
- IMA-appraisal and namespacing:<br />
- 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<br />
(nested) IMA namespace where an empty IMA policy has been set? We would measure and audit root's activities as described above.<br />
What about appraising? Would we traverse all the IMA namespaces back to the init_ima_ns and evaluate signatures against the appraisal policy<br />
set there and assume we would always find the keys in the init_user_ns?<br />
<br />
- TPM and measurements:<br />
- 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,<br />
each IMA namespace would have to be associated with its own TPM instance (vTPM); measurement in the initial IMA namespace are extended into<br />
the hardware TPM as done already<br />
<br />
- Extended attribute security.ima:<br />
- A container should be able to set the security.ima extended attribute<br />
- this should be possibly without the almighty CAP_SYS_ADMIN;<br />
- we may want to gate this with a new capability CAP_SECURITY_XATTR_ADMIN that allows setting security extended attributes inside a container, <br />
possibly only during container build-time<br />
<br />
- Extended attribute security.ima and bind mounting<br />
- It may be necessary that different namespaces be able to sign the same bind-mounted file with different keys<br />
(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<br />
able to access them.)<br />
- Extended attributes, such as seucrity.ima) may need to be virtualizeable (security.ima vs. security.ima@uid=1000 etc.)<br />
<br />
<br />
A concrete 'ab-use' case that we have to to avoid is the following:<br />
<br />
A user creates a privileged container that shares the host's mount namespace: it would be unexpected if there was an IMA policy active on the host that enforces file appraisal but in this case the IMA policy is not enforced since a (hypothetical) IMA namespace of the host was not joined because only the mount namespace of the host was joined. Now we have two choices here: We tie the mount and IMA namespaces together via single clone flag (as proposed in RFC patches) and joining the mount namespace automatically joins the associated IMA namespace (single setns()). Or we make user space responsible for it and say if a mount namespace is joined, find the associated IMA namespace and join both of them (2 setns() calls). Well, I think the former would be preferred over the latter.<br />
<br />
So either we tie the IMA namespace to some other existing namespace, preferably mount namespace, or we have it be independently created (new clone flag or by writing into a sysfs/securityfs file).<br />
<br />
== MNT and IMA Namespaces tied together ==<br />
<br />
Let's assume we tie MNT and IMA namespaces together, then there are other scenarios with switching through the other namespaces (UTS, PID, IPC, NET, USER, CGROUP). I am not sure what is supposed to happen other than logging the activity active in the current IMA namespace:<br />
<br />
What should happen with IMA logging, appraisal, and auditing if we setns() through all available<br />
- PID namespaces and send signals: log, appraise, and audit file activity following IMA policy<br />
- IPC namespaces and send messages via IPC: same as for PID<br />
- UTS namespaces and setting hostname: same as for PID<br />
- NET namespaces and sending network traffic: same as for PID?<br />
- CGROUP namespaces and configuring cgroups: same as for PID?<br />
- USER: should now the keys of this USER namespace be active or the keys of the original user namespace used during the clone()? other than that, same as for PID?<br />
<br />
== Independent IMA Namespace ==<br />
<br />
If we create an IMA namespace independently from any other mount namespace, what are we to gain from this or loose? The above ab-use case shows some problem associated with it. Do we have a solution for the item "IMA-appraisal and namespacing" above? In the worst case, would it matter if root spawned a new IMA namespace, set a NULL policy and only have its activities measured and audited but not appraised?</div>Stefanbhttp://kernsec.org/wiki/index.php?title=User_talk:Stefanb&diff=3932User talk:Stefanb2018-03-15T14:16:19Z<p>Stefanb: Blanked the page</p>
<hr />
<div></div>Stefanbhttp://kernsec.org/wiki/index.php?title=Linux_Kernel_Integrity&diff=3931Linux Kernel Integrity2018-03-15T14:03:54Z<p>Stefanb: /* IMA */</p>
<hr />
<div>'''linux-integrity@vger.kernel.org''' is the mailing list for TPM and IMA targeted patches and discussion.<br />
<br />
* Subscription information is here: http://vger.kernel.org/vger-lists.html#linux-integrity<br />
<br />
For non-trivial patch sets, such as patch sets that touch multiple subsystems, it is recommended to CC the '''linux-security-module@vger.kernel.org''' mailing list for more broad screening.<br />
<br />
<br />
TPM and IMA have have their own maintainers and GIT trees:<br />
<br />
* '''IMA:''' Mimi Zohar, git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git<br />
* '''TPM:''' Jarkko Sakkinen, git://git.infradead.org/users/jjs/linux-tpmdd.git<br />
<br />
== TPM 2.0 ==<br />
The TPM 2.0 infrastructure in and around linux is currently moving fast.<br />
Here is a link list which tries to capture the current situation.<br />
<br />
<br />
=== Books & Links ===<br />
* A Practical Guide toTPM 2.0, free PDF, https://link.springer.com/book/10.1007/978-1-4302-6584-9<br />
* TPM2.0 in Context, http://www.springer.com/de/book/9783319087436<br />
* TCG Links https://trustedcomputinggroup.org/resources-using-trusted-platform-module-2-0-library-specification/<br />
* Matthew Garrett's blog https://mjg59.dreamwidth.org/ (not only about tpm)<br />
* James Bottomley's blog https://blog.hansenpartnership.com (not only about tpm)<br />
<br />
<br />
=== Intel TSS Stack ===<br />
The Intel TSS Stack, compliant with the TCG SAPI specifications consists of <br />
* The Stack: https://github.com/01org/tpm2-tss<br />
* The Tools: https://github.com/01org/tpm2-tools<br />
* The Broker: https://github.com/01org/tpm2-abrmd (Access Broker & Resource Management Daemon)<br />
<br />
Interesting Links can be found here:<br />
* https://lenovopress.com/lp0599-technical-introduction-tpm-20-with-linux<br />
* http://www.jwsecure.com/2017/02/07/implementing-platform-protection-for-linux/<br />
* https://github.com/01org/tpm2-tools/wiki/How-to-use-tpm2-tools (needs to be updated)<br />
* RSA signatures with TPM2.0 and OpenSSL https://dguerriblog.wordpress.com/<br />
* https://archive.fosdem.org/2017/schedule/event/tpm2/attachments/slides/1517/export/events/attachments/tpm2/slides/1517/FOSDEM___TPM2_0_practical_usage.pdf<br />
* https://elinux.org/images/6/6e/ELC2017_TPM2-and-TSS_Tricca.pdf<br />
<br />
==== Interesting Projects using Intel TSS Stack ====<br />
Automated Full Disk De/Encryption with Clevis/Tang+TPM+Luks<br />
* http://redhat.slides.com/npmccallum/sad<br />
* https://github.com/latchset/clevis/pull/17<br />
* https://github.com/martinezjavier/clevis/blob/tpm2-pin/doc/clevis-bind-luks-tpm2.md<br />
<br />
StrongSwan VPN Server + IMA + TPMSupport (Remote Attestation)<br />
* https://wiki.strongswan.org/projects/strongswan/wiki/TPMPlugin<br />
<br />
Others:<br />
* Remote Attestation https://01.org/opencit <br />
* https://github.com/irtimmer/tpm2-pk11<br />
* https://github.com/rqou/tpm2-luks<br />
* https://robertou.com/tpm2-sealed-luks-encryption-keys.html<br />
* https://github.com/WindRiver-OpenSourceLabs/cryptfs-tpm2<br />
<br />
<br />
=== IBM TSS Stack === <br />
The IBM Stack follows a more pragmatic approach - the code can be found at<br />
* https://sourceforge.net/projects/ibmtpm20tss/<br />
including tools and everything.<br />
<br />
James Bottomley has been actively developing against it<br />
* https://blog.hansenpartnership.com/using-your-tpm-as-a-secure-key-store/<br />
* https://blog.hansenpartnership.com/tpm-enabling-gnome-keyring/<br />
* https://blog.hansenpartnership.com/tpm2-and-linux/<br />
<br />
It comes with its own<br />
* TPM2.0 Simulator https://sourceforge.net/projects/ibmswtpm2/<br />
* Attestation client/server http://ibmswtpm.sourceforge.net/ibmacs.html <br />
<br />
<br />
== IMA ==<br />
See https://sourceforge.net/p/linux-ima/wiki/Home/ for details.<br />
<br />
IMA namespacing: [[IMA Namespacing design considerations]]</div>Stefanbhttp://kernsec.org/wiki/index.php?title=IMA_Namespacing_design_considerations&diff=3930IMA Namespacing design considerations2018-03-15T14:03:15Z<p>Stefanb: Created page with "== Namespacing IMA == Our goals are to enable IMA measurements, appraisal, and auditing inside a container using Linux namespaces. The intention is to introduce an IMA namesp..."</p>
<hr />
<div>== Namespacing IMA ==<br />
<br />
Our goals are to enable IMA measurements, appraisal, and auditing inside a container using Linux namespaces. The intention is to introduce an IMA namespace.<br />
<br />
=== Background ===<br />
<br />
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.<br />
<br />
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.iam extended attribute. The keys for verifying the signature are found in IMA specific keyrings .ima or _ima.<br />
<br />
IMA auditing is about reporting system events, such as update of the IMA policy or files that were measured. Which file activity is audited can be configured using an IMA policy.<br />
<br />
=== IMA Namespacing Considerations ===<br />
<br />
When namespacing IMA, we want to prevent the abuse of namespaces by users to do 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 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:<br />
<br />
<br />
Support for IMA in namespaces should enable the following:<br />
<br />
- IMA policy for container (similar to the host):<br />
- there should be an initial default policy for every IMA namespace that measures activities inside the container<br />
- the policy can be overwritten once with a user-defined policy that may activate appraisal<br />
- CAP_SYS_ADMIN is currently gating the setting of the IMA policy; <br />
- setting the policy should be possibly without the almighty CAP_SYS_ADMIN<br />
- 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<br />
<br />
- IMA policy extensions due to namespacing:<br />
- an IMA policy should allow rules that define whether activities in (all) child namespaces is to be measured (huge logs on the host)<br />
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<br />
host could possibly eat up a lot of memory<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
<br />
- IMA measurements:<br />
- 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<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA auditing:<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA appraisal and keys:<br />
- each IMA namespace should have its own keyring so that each container can have its files signed with different keys<br />
- the keys (certificates) for verifying signatures may be found inside containers<br />
- it should be possible to enforce that only certified keys are loaded onto a keyring, similar to .ima on the host<br />
- the CA public key used for verifying that public keys (certificates) used for verifying signatures may be found inside the container<br />
or could be known to the container management stack<br />
<br />
- IMA appraisal and namespacing:<br />
- 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<br />
(nested) IMA namespace where an empty IMA policy has been set? We would measure and audit root's activities as described above.<br />
What about appraising? Would we traverse all the IMA namespaces back to the init_ima_ns and evaluate signatures against the appraisal policy<br />
set there and assume we would always find the keys in the init_user_ns?<br />
<br />
- TPM and measurements:<br />
- 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,<br />
each IMA namespace would have to be associated with its own TPM instance (vTPM); measurement in the initial IMA namespace are extended into<br />
the hardware TPM as done already<br />
<br />
- Extended attribute security.ima:<br />
- A container should be able to set the security.ima extended attribute<br />
- this should be possibly without the almighty CAP_SYS_ADMIN;<br />
- we may want to gate this with a new capability CAP_SECURITY_XATTR_ADMIN that allows setting security extended attributes inside a container, <br />
possibly only during container build-time<br />
<br />
- Extended attribute security.ima and bind mounting<br />
- It may be necessary that different namespaces be able to sign the same bind-mounted file with different keys<br />
(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<br />
able to access them.)<br />
- Extended attributes, such as seucrity.ima) may need to be virtualizeable (security.ima vs. security.ima@uid=1000 etc.)<br />
<br />
<br />
A concrete 'ab-use' case that we have to to avoid is the following:<br />
<br />
A user creates a privileged container that shares the host's mount namespace: it would be unexpected if there was an IMA policy active on the host that enforces file appraisal but in this case the IMA policy is not enforced since a (hypothetical) IMA namespace of the host was not joined because only the mount namespace of the host was joined. Now we have two choices here: We tie the mount and IMA namespaces together via single clone flag (as proposed in RFC patches) and joining the mount namespace automatically joins the associated IMA namespace (single setns()). Or we make user space responsible for it and say if a mount namespace is joined, find the associated IMA namespace and join both of them (2 setns() calls). Well, I think the former would be preferred over the latter.<br />
<br />
So either we tie the IMA namespace to some other existing namespace, preferably mount namespace, or we have it be independently created (new clone flag or by writing into a sysfs/securityfs file).<br />
<br />
== MNT and IMA Namespaces tied together ==<br />
<br />
Let's assume we tie MNT and IMA namespaces together, then there are other scenarios with switching through the other namespaces (UTS, PID, IPC, NET, USER, CGROUP). I am not sure what is supposed to happen other than logging the activity active in the current IMA namespace:<br />
<br />
What should happen with IMA logging, appraisal, and auditing if we setns() through all available<br />
- PID namespaces and send signals: log, appraise, and audit file activity following IMA policy<br />
- IPC namespaces and send messages via IPC: same as for PID<br />
- UTS namespaces and setting hostname: same as for PID<br />
- NET namespaces and sending network traffic: same as for PID?<br />
- CGROUP namespaces and configuring cgroups: same as for PID?<br />
- USER: should now the keys of this USER namespace be active or the keys of the original user namespace used during the clone()? other than that, same as for PID?<br />
<br />
== Independent IMA Namespace ==<br />
<br />
If we create an IMA namespace independently from any other mount namespace, what are we to gain from this or loose? The above ab-use case shows some problem associated with it. Do we have a solution for the item "IMA appraisal and namespacing" above? In the worst case, would it matter if root spawned a new IMA namespace, set a NULL policy and only have its activities measured and audited but not appraised?</div>Stefanbhttp://kernsec.org/wiki/index.php?title=User_talk:Stefanb&diff=3929User talk:Stefanb2018-03-15T13:01:40Z<p>Stefanb: /* IMA Namespacing Considerations */</p>
<hr />
<div>== Namespacing IMA ==<br />
<br />
Our goals are to enable IMA measurements, appraisal, and auditing inside a container using Linux namespaces. The intention is to introduce an IMA namespace.<br />
<br />
=== Background ===<br />
<br />
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.<br />
<br />
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.iam extended attribute. The keys for verifying the signature are found in IMA specific keyrings .ima or _ima.<br />
<br />
IMA auditing is about reporting system events, such as update of the IMA policy or files that were measured. Which file activity is audited can be configured using an IMA policy.<br />
<br />
=== IMA Namespacing Considerations ===<br />
<br />
When namespacing IMA, we want to prevent the abuse of namespaces by users to do 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 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:<br />
<br />
<br />
Support for IMA in namespaces should enable the following:<br />
<br />
- IMA policy for container (similar to the host):<br />
- there should be an initial default policy for every IMA namespace that measures activities inside the container<br />
- the policy can be overwritten once with a user-defined policy that may activate appraisal<br />
- CAP_SYS_ADMIN is currently gating the setting of the IMA policy; <br />
- setting the policy should be possibly without the almighty CAP_SYS_ADMIN<br />
- 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<br />
<br />
- IMA policy extensions due to namespacing:<br />
- an IMA policy should allow rules that define whether activities in (all) child namespaces is to be measured (huge logs on the host)<br />
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<br />
host could possibly eat up a lot of memory<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
<br />
- IMA measurements:<br />
- 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<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA auditing:<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA appraisal and keys:<br />
- each IMA namespace should have its own keyring so that each container can have its files signed with different keys<br />
- the keys (certificates) for verifying signatures may be found inside containers<br />
- it should be possible to enforce that only certified keys are loaded onto a keyring, similar to .ima on the host<br />
- the CA public key used for verifying that public keys (certificates) used for verifying signatures may be found inside the container<br />
or could be known to the container management stack<br />
<br />
- IMA appraisal and namespacing:<br />
- 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<br />
(nested) IMA namespace where an empty IMA policy has been set? We would measure and audit root's activities as described above.<br />
What about appraising? Would we traverse all the IMA namespaces back to the init_ima_ns and evaluate signatures against the appraisal policy<br />
set there and assume we would always find the keys in the init_user_ns?<br />
<br />
- TPM and measurements:<br />
- 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,<br />
each IMA namespace would have to be associated with its own TPM instance (vTPM); measurement in the initial IMA namespace are extended into<br />
the hardware TPM as done already<br />
<br />
- Extended attribute security.ima:<br />
- A container should be able to set the security.ima extended attribute<br />
- this should be possibly without the almighty CAP_SYS_ADMIN;<br />
- we may want to gate this with a new capability CAP_SECURITY_XATTR_ADMIN that allows setting security extended attributes inside a container, <br />
possibly only during container build-time<br />
<br />
- Extended attribute security.ima and bind mounting<br />
- It may be necessary that different namespaces be able to sign the same bind-mounted file with different keys<br />
(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<br />
able to access them.)<br />
- Extended attributes, such as seucrity.ima) may need to be virtualizeable (security.ima vs. security.ima@uid=1000 etc.)<br />
<br />
<br />
A concrete 'ab-use' case that we have to to avoid is the following:<br />
<br />
A user creates a privileged container that shares the host's mount namespace: it would be unexpected if there was an IMA policy active on the host that enforces file appraisal but in this case the IMA policy is not enforced since a (hypothetical) IMA namespace of the host was not joined because only the mount namespace of the host was joined. Now we have two choices here: We tie the mount and IMA namespaces together via single clone flag (as proposed in RFC patches) and joining the mount namespace automatically joins the associated IMA namespace (single setns()). Or we make user space responsible for it and say if a mount namespace is joined, find the associated IMA namespace and join both of them (2 setns() calls). Well, I think the former would be preferred over the latter.<br />
<br />
So either we tie the IMA namespace to some other existing namespace, preferably mount namespace, or we have it be independently created (new clone flag or by writing into a sysfs/securityfs file).<br />
<br />
== MNT and IMA Namespaces tied together ==<br />
<br />
Let's assume we tie MNT and IMA namespaces together, then there are other scenarios with switching through the other namespaces (UTS, PID, IPC, NET, USER, CGROUP). I am not sure what is supposed to happen other than logging the activity active in the current IMA namespace:<br />
<br />
What should happen with IMA logging, appraisal, and auditing if we setns() through all available<br />
- PID namespaces and send signals: log, appraise, and audit file activity following IMA policy<br />
- IPC namespaces and send messages via IPC: same as for PID<br />
- UTS namespaces and setting hostname: same as for PID<br />
- NET namespaces and sending network traffic: same as for PID?<br />
- CGROUP namespaces and configuring cgroups: same as for PID?<br />
- USER: should now the keys of this USER namespace be active or the keys of the original user namespace used during the clone()? other than that, same as for PID?<br />
<br />
== Independent IMA Namespace ==<br />
<br />
If we create an IMA namespace independently from any other mount namespace, what are we to gain from this or loose? The above ab-use case shows some problem associated with it. Do we have a solution for the item "IMA appraisal and namespacing" above? In the worst case, would it matter if root spawned a new IMA namespace, set a NULL policy and only have its activities measured and audited but not appraised?</div>Stefanbhttp://kernsec.org/wiki/index.php?title=User_talk:Stefanb&diff=3928User talk:Stefanb2018-03-15T13:00:19Z<p>Stefanb: /* IMA Namespacing Considerations */</p>
<hr />
<div>== Namespacing IMA ==<br />
<br />
Our goals are to enable IMA measurements, appraisal, and auditing inside a container using Linux namespaces. The intention is to introduce an IMA namespace.<br />
<br />
=== Background ===<br />
<br />
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.<br />
<br />
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.iam extended attribute. The keys for verifying the signature are found in IMA specific keyrings .ima or _ima.<br />
<br />
IMA auditing is about reporting system events, such as update of the IMA policy or files that were measured. Which file activity is audited can be configured using an IMA policy.<br />
<br />
=== IMA Namespacing Considerations ===<br />
<br />
When namespacing IMA, we want to prevent the abuse of namespaces by users to do 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 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:<br />
<br />
<br />
Support for IMA in namespaces should enable the following:<br />
<br />
- IMA policy for container (similar to the host):<br />
- there should be an initial default policy for every IMA namespace that measures activities inside the container<br />
- the policy can be overwritten once with a user-defined policy that may activate appraisal<br />
- CAP_SYS_ADMIN is currently gating the setting of the IMA policy; <br />
- setting the policy should be possibly without the almighty CAP_SYS_ADMIN<br />
- 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<br />
<br />
- IMA policy extensions due to namespacing:<br />
- an IMA policy should allow rules that define whether activities in (all) child namespaces is to be measured (huge logs on the host)<br />
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<br />
host could possibly eat up a lot of memory<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
<br />
- IMA measurements:<br />
- 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<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA auditing:<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA appraisal and keys:<br />
- each IMA namespace should have its own keyring so that each container can have its files signed with different keys<br />
- the keys (certificates) for verifying signatures may be found inside containers<br />
- it should be possible to enforce that only certified keys are loaded onto a keyring, similar to .ima on the host<br />
- the CA public key used for verifying that public keys (certificates) used for verifying signatures may be found inside the container<br />
or could be known to the container management stack<br />
<br />
- IMA appraisal and namespacing:<br />
- 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<br />
(nested) IMA namespace where an empty IMA policy has been set? We would measure and audit root's activities as described above.<br />
What about appraising? Would we traverse all the IMA namespaces back to the init_ima_ns and evaluate signatures against the appraisal policy<br />
set there and assume we would always find the keys in the init_user_ns?<br />
<br />
- TPM and measurements:<br />
- 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,<br />
each IMA namespace would have to be associated with its own TPM instance (vTPM); measurement on the initial IMA namespace are extended into<br />
the hardware TPM as done already<br />
<br />
- Extended attribute security.ima:<br />
- A container should be able to set the security.ima extended attribute<br />
- this should be possibly without the almighty CAP_SYS_ADMIN;<br />
- we may want to gate this with a new capability CAP_SECURITY_XATTR_ADMIN that allows setting security extended attributes inside a container, <br />
possibly only during container build-time<br />
<br />
- Extended attribute security.ima and bind mounting<br />
- It may be necessary that different namespaces be able to sign the same bind-mounted file with different keys<br />
(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<br />
able to access them.)<br />
- Extended attributes, such as seucrity.ima) may need to be virtualizeable (security.ima vs. security.ima@uid=1000 etc.)<br />
<br />
<br />
A concrete 'ab-use' case that we have to to avoid is the following:<br />
<br />
A user creates a privileged container that shares the host's mount namespace: it would be unexpected if there was an IMA policy active on the host that enforces file appraisal but in this case the IMA policy is not enforced since a (hypothetical) IMA namespace of the host was not joined because only the mount namespace of the host was joined. Now we have two choices here: We tie the mount and IMA namespaces together via single clone flag (as proposed in RFC patches) and joining the mount namespace automatically joins the associated IMA namespace (single setns()). Or we make user space responsible for it and say if a mount namespace is joined, find the associated IMA namespace and join both of them (2 setns() calls). Well, I think the former would be preferred over the latter.<br />
<br />
So either we tie the IMA namespace to some other existing namespace, preferably mount namespace, or we have it be independently created (new clone flag or by writing into a sysfs/securityfs file).<br />
<br />
== MNT and IMA Namespaces tied together ==<br />
<br />
Let's assume we tie MNT and IMA namespaces together, then there are other scenarios with switching through the other namespaces (UTS, PID, IPC, NET, USER, CGROUP). I am not sure what is supposed to happen other than logging the activity active in the current IMA namespace:<br />
<br />
What should happen with IMA logging, appraisal, and auditing if we setns() through all available<br />
- PID namespaces and send signals: log, appraise, and audit file activity following IMA policy<br />
- IPC namespaces and send messages via IPC: same as for PID<br />
- UTS namespaces and setting hostname: same as for PID<br />
- NET namespaces and sending network traffic: same as for PID?<br />
- CGROUP namespaces and configuring cgroups: same as for PID?<br />
- USER: should now the keys of this USER namespace be active or the keys of the original user namespace used during the clone()? other than that, same as for PID?<br />
<br />
== Independent IMA Namespace ==<br />
<br />
If we create an IMA namespace independently from any other mount namespace, what are we to gain from this or loose? The above ab-use case shows some problem associated with it. Do we have a solution for the item "IMA appraisal and namespacing" above? In the worst case, would it matter if root spawned a new IMA namespace, set a NULL policy and only have its activities measured and audited but not appraised?</div>Stefanbhttp://kernsec.org/wiki/index.php?title=User_talk:Stefanb&diff=3927User talk:Stefanb2018-03-15T12:58:52Z<p>Stefanb: /* IMA Namespacing Considerations */</p>
<hr />
<div>== Namespacing IMA ==<br />
<br />
Our goals are to enable IMA measurements, appraisal, and auditing inside a container using Linux namespaces. The intention is to introduce an IMA namespace.<br />
<br />
=== Background ===<br />
<br />
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.<br />
<br />
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.iam extended attribute. The keys for verifying the signature are found in IMA specific keyrings .ima or _ima.<br />
<br />
IMA auditing is about reporting system events, such as update of the IMA policy or files that were measured. Which file activity is audited can be configured using an IMA policy.<br />
<br />
=== IMA Namespacing Considerations ===<br />
<br />
When namespacing IMA, we want to prevent the abuse of namespaces by users to do 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 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:<br />
<br />
<br />
Support for IMA in namespaces should enable the following:<br />
<br />
- IMA policy for container (similar to the host):<br />
- there should be an initial default policy for every IMA namespace that measures activities inside the container<br />
- the policy can be overwritten once with a user-defined policy that may activate appraisal<br />
- CAP_SYS_ADMIN is currently gating the setting of the IMA policy; <br />
- setting the policy should be possibly without the almighty CAP_SYS_ADMIN<br />
- 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<br />
<br />
- IMA policy extensions due to namespacing:<br />
- an IMA policy should allow rules that define whether activities in (all) child namespaces is to be measured (huge logs on the host)<br />
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<br />
host could possibly eat up a lot of memory<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
<br />
- IMA measurements:<br />
- 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<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA auditing:<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA appraisal and keys:<br />
- each IMA namespace should have its own keyring so that each container can have its files signed with different keys<br />
- the keys (certificates) for verifying signatures may be found inside containers<br />
- it should be possible to enforce that only certified keys are loaded onto a keyring, similar to .ima on the host<br />
- the CA public key used for verifying that public keys (certificates) used for verifying signatures may be found inside the container<br />
or could be known to the container management stack<br />
<br />
- IMA appraisal and namespacing:<br />
- 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<br />
(nested) IMA namespace where an empty IMA policy has been set? We would measure and audit root's activities as described above.<br />
What about appraising? Would we traverse all the IMA namespaces back to the init_ima_ns and evaluate signatures against the appraisal policy<br />
set there and assume we would always find the keys in the init_user_ns?<br />
<br />
- TPM and measurements:<br />
- 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,<br />
each IMA namespace would have to be associated with its own TPM instance (vTPM); measurement on the initial IMA namespace are extended into<br />
the hardware TPM as done already<br />
<br />
- Extended attribute security.ima:<br />
- A container should be able to set the security.ima extended attribute<br />
- this should be possibly without the almighty CAP_SYS_ADMIN;<br />
- we may want to gate this with a new capability CAP_SECURITY_XATTR_ADMIN that allows setting security extended attributes inside a container, <br />
possibly only during container build-time<br />
<br />
- Extended attribute security.ima and bind mounting<br />
- It may be necessary that different namespaces be able to sign the same bind-mounted file with different keys<br />
(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<br />
able to access them.)<br />
- Extended attributes, such as seucrity.ima) may need to be virtualizeable (security.ima vs. security.ima@uid=1000 etc.)<br />
<br />
<br />
A concrete 'ab-use' case that we have to to avoid is the following:<br />
<br />
A user creates a privileged container that shares the host's mount namespace: it would be unexpected if there was an IMA policy active on the host that enforces file appraisal but in this case the IMA policy is not enforced since a (hypothetical) IMA namespace of the host was not joined because only the mount namespace of the host was joined. Now we have two choices here: We tie the mount and IMA namespaces together via single clone flag (as proposed in RFC patches) and joining the mount namespace automatically joins the associated IMA namespace (single setns()). Or we make user space responsible for it and say if a mount namespace is joined, find the associated IMA namespace and join both of them (2 setns() calls). Well, I think the former would be preferred over the latter.<br />
<br />
So either we tie the IMA namespace to some other existing namespace, preferably mount namespace, or we have it be independently created (new clone flag or by writing into a sysfs/securityfs file).<br />
<br />
== MNT and IMA Namespaces tied together ==<br />
<br />
Let's assume we tie MNT and IMA namespaces together, then there are other scenarios with switching through the other namespaces (UTS, PID, IPC, NET, USER, CGROUP). I am not sure what is supposed to happen other than logging the activity active in the current IMA namespace:<br />
<br />
What should happen with IMA logging, appraisal, and auditing if we setns() through all available<br />
- PID namespaces and send signals: log, appraise, and audit file activity following IMA policy<br />
- IPC namespaces and send messages via IPC: same as for PID<br />
- UTS namespaces and setting hostname: same as for PID<br />
- NET namespaces and sending network traffic: same as for PID?<br />
- CGROUP namespaces and configuring cgroups: same as for PID?<br />
- USER: should now the keys of this USER namespace be active or the keys of the original user namespace used during the clone()? other than that, same as for PID?<br />
<br />
== Independent IMA Namespace ==<br />
<br />
If we create an IMA namespace independently from any other mount namespace, what are we to gain from this or loose? The above ab-use case shows some problem associated with it. Do we have a solution for the item "IMA appraisal and namespacing" above? In the worst case, would it matter if root spawned a new IMA namespace, set a NULL policy and only have its activities measured and audited but not appraised?</div>Stefanbhttp://kernsec.org/wiki/index.php?title=User_talk:Stefanb&diff=3926User talk:Stefanb2018-03-15T12:57:23Z<p>Stefanb: </p>
<hr />
<div>== Namespacing IMA ==<br />
<br />
Our goals are to enable IMA measurements, appraisal, and auditing inside a container using Linux namespaces. The intention is to introduce an IMA namespace.<br />
<br />
=== Background ===<br />
<br />
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.<br />
<br />
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.iam extended attribute. The keys for verifying the signature are found in IMA specific keyrings .ima or _ima.<br />
<br />
IMA auditing is about reporting system events, such as update of the IMA policy or files that were measured. Which file activity is audited can be configured using an IMA policy.<br />
<br />
=== IMA Namespacing Considerations ===<br />
<br />
When namespacing IMA, we want to prevent the abuse of namespaces by users to do 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 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:<br />
<br />
<br />
Support for IMA in namespaces should enable the following:<br />
<br />
- IMA policy for container (similar to the host):<br />
- there should be an initial default policy for every IMA namespace that measures activities inside the container<br />
- the policy can be overwritten once with a user-defined policy that may activate appraisal<br />
- CAP_SYS_ADMIN is currently gating the setting of the IMA policy; <br />
- setting the policy should be possibly without the almighty CAP_SYS_ADMIN<br />
- 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<br />
<br />
- IMA policy extensions due to namespacing:<br />
- an IMA policy should allow rules that define whether activities in (all) child namespaces is to be measured (huge logs on the host)<br />
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<br />
host could possibly eat up a lot of memory<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
<br />
- IMA measurements:<br />
- 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<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA auditing:<br />
- 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''<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace<br />
<br />
- IMA appraisal and keys:<br />
- each IMA namespace should have its own keyring so that each container can have its files signed with different keys<br />
- the keys (certificates) for verifying signatures may be found inside containers<br />
- it should be possible to enforce that only certified keys are loaded onto a keyring, similar to .ima on the host<br />
- the CA public key used for verifying that public keys (certificates) used for verifying signatures may be found inside the container<br />
or could be known to the container management stack<br />
<br />
- IMA appraisal and namespacing:<br />
- 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<br />
(nested) IMA namespace where an empty IMA policy has been set? We would measure and audit root's activities as described above.<br />
What about appraising? Would we traverse all the IMA namespaces back to the init_ima_ns and evaluate signatures against the appraisal policy<br />
set there and assume we would always find the keys in the init_user_ns?<br />
<br />
- TPM and measurements:<br />
- 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,<br />
each IMA namespace would have to be associated with its own TPM instance (vTPM); measurement on the initial IMA namespace are extended into<br />
the hardware TPM as done already<br />
<br />
- Extended attribute security.ima:<br />
- A container should be able to set the security.ima extended attribute<br />
- this should be possibly without the almighty CAP_SYS_ADMIN;<br />
- we may want to gate this with a new capability CAP_SECURITY_XATTR_ADMIN that allows setting security extended attributes inside a container, <br />
possibly only during container build-time<br />
<br />
- Extended attribute security.ima and bind mounting<br />
- It may be necessary that different namespaces be able to sign the same bind-mounted file with different keys<br />
(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<br />
able to access them.)<br />
- Extended attributes, such as seucrity.ima) may need to be virtualizeable (security.ima vs. security.ima@uid=1000 etc.)<br />
<br />
<br />
A concrete 'ab-use' case that we have to to avoid is the following:<br />
<br />
A user creates a privileged container that shares the host's mount namespace: it would be unexpected if there was an IMA policy active on the host that enforces file appraisal but in this case the IMA policy is not enforced since a (hypothetical) IMA namespace of the host was not joined because only the mount namespace of the host was joined. Now we have two choices here: We tie the mount and IMA namespaces together via single clone flag (as proposed in RFC patches) and joining the mount namespace automatically joins the associated IMA namespace (single setns()). Or we make user space responsible for it and say if a mount namespace is joined, find the associated IMA namespace and join both of them (2 setns() calls). Well, I think the former would be preferred over the latter.<br />
<br />
So either we tie the IMA namespace to some other existing namespace, preferably mount namespace, or we have it be independently created (new clone flag or by writing into a sysfs/securityfs file).<br />
<br />
== MNT and IMA Namespaces tied together ==<br />
<br />
Let's assume we tie MNT and IMA namespaces together, then there are other scenarios with switching through the other namespaces (UTS, PID, IPC, NET, USER, CGROUP). I am not sure what is supposed to happen other than logging the activity active in the current IMA namespace:<br />
<br />
What should happen with IMA logging, appraisal, and auditing if we setns() through all available<br />
- PID namespaces and send signals: log, appraise, and audit file activity following IMA policy<br />
- IPC namespaces and send messages via IPC: same as for PID<br />
- UTS namespaces and setting hostname: same as for PID<br />
- NET namespaces and sending network traffic: same as for PID?<br />
- CGROUP namespaces and configuring cgroups: same as for PID?<br />
- USER: should now the keys of this USER namespace be active or the keys of the original user namespace used during the clone()? other than that, same as for PID?<br />
<br />
== Independent IMA Namespace ==<br />
<br />
If we create an IMA namespace independently from any other mount namespace, what are we to gain from this or loose? The above ab-use case shows some problem associated with it. Do we have a solution for the item "IMA appraisal and namespacing" above? In the worst case, would it matter if root spawned a new IMA namespace, set a NULL policy and only have its activities measured and audited but not appraised?</div>Stefanbhttp://kernsec.org/wiki/index.php?title=User_talk:Stefanb&diff=3925User talk:Stefanb2018-03-14T21:52:10Z<p>Stefanb: Created page with "== Namespacing IMA == Our goals are to enable IMA measurements, appraisal, and auditing inside a container using Linux namespaces. The intention is to introduce an IMA namesp..."</p>
<hr />
<div>== Namespacing IMA ==<br />
<br />
Our goals are to enable IMA measurements, appraisal, and auditing inside a container using Linux namespaces. The intention is to introduce an IMA namespace.<br />
<br />
=== Background ===<br />
<br />
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 activties in the TCB, such as which programs were started by root. Which files are measured can be configured using an IMA policy.<br />
<br />
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.<br />
<br />
IMA auditing is about reporting system events, such as update of the policy or files that were measured. Which file activity is audited can be configured using an IMA policy.<br />
<br />
=== IMA Namespacing Considerations ===<br />
<br />
When namespacing IMA, we want to prevent the abuse of namespaces by users to do 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 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:<br />
<br />
<br />
Support for IMA in namespaces should enable the following:<br />
<br />
- IMA policy for container (similar to the host):<br />
- there should be an initial default policy for every IMA namespace that measures activities inside the container<br />
- the policy can be overwritten once with a user-defined policy that may activate appraisal<br />
- CAP_SYS_ADMIN is currently gating the setting of the IMA policy; <br />
- setting the policy should be possibly without the almighty CAP_SYS_ADMIN<br />
- 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<br />
<br />
- IMA policy extensions due to namespacing:<br />
- an IMA policy should allow rules that define whether activities in (all) child namespaces is to be measured (prevents huge logs on the host)<br />
and audited<br />
- to prevent root from spawning new IMA namespaces and doing things undetected in the TCB, all activities of root must be measured and audited<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
<br />
- IMA measurements:<br />
- to prevent root from spawning new IMA namespaces and doing things undetected in the TCB, all activities of root must be measured and audited<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
<br />
- IMA auditing:<br />
- to prevent root from spawning new IMA namespaces and doing things undetected in the TCB, all activities of root must be measured and audited<br />
in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces<br />
<br />
- IMA appraisal and keys:<br />
- each IMA namespace should have its own keyring so that each container can have its files signed with different keys<br />
- the keys (certificates) for verifying signatures may be found inside containers<br />
- it should be possible to enforce that only certified keys are loaded onto a keyring, similar to .ima on the host<br />
- the CA public key used for verifying that public keys (certificates) used for verifying signatures may be found inside the container<br />
or could be known to the container management stack<br />
<br />
- TPM and measurements:<br />
- 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,<br />
each IMA namespace would have to be associated with its own TPM instance (vTPM); measurement on the initial IMA namespace are extended into<br />
the hardware TPM as done already<br />
<br />
- Extended attribute security.ima:<br />
- A container should be able to set the security.ima extended attribute<br />
- this should be possibly without the almighty CAP_SYS_ADMIN;<br />
- we may want to gate this with a new capability CAP_SECURITY_XATTR_ADMIN that allows setting security extended attributes inside a container, <br />
possibly only during container build-time<br />
<br />
- Extended attribute security.ima and bind mounting<br />
- It may be necessary that different namespaces be able to sign the same bind-mounted file with different keys<br />
(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<br />
able to access them.)<br />
- Extended attributes, such as seucrity.ima) may need to be virtualizeable (security.ima vs. security.ima@uid=1000 etc.)<br />
<br />
<br />
A concrete 'ab-use' case that we have to to avoid is the following:<br />
<br />
A user creates a privileged container that shares the host's mount namespace: it would be unexpected if there was an IMA policy active on the host that enforces file appraisal but in this case the IMA policy is not enforced since a (hypothetical) IMA namespace of the host was not joined because only the mount namespace of the host was joined. Now we have two choices here: We tie the mount and IMA namespaces together via single clone flag (as proposed in RFC patches) and joining the mount namespace automatically joins the associated IMA namespace (single setns()). Or we make user space responsible for it and say if a mount namespace is joined, find the associated IMA namespace and join both of them (2 setns() calls). Well, I think the former would be preferred over the latter.<br />
<br />
Let's assume we tie MNT and IMA namespaces together, then there are other scenarios with switching through the other namespaces (UTS, PID, IPC, NET, USER, CGROUP). I am not sure what is supposed to happen other than logging the activity active in the current IMA namespace:<br />
<br />
What should happen with IMA logging, appraisal, and auditing if we setns() through all available<br />
- PID namespaces and send signals: log, appraise, and audit file activity following IMA policy<br />
- IPC namespaces and send messages via IPC: same as for PID<br />
- UTS namespaces and setting hostname: same as for PID<br />
- NET namespaces and sending network traffic: same as for PID?<br />
- CGROUP namespaces and configuring cgroups: same as for PID?<br />
- USER: should now the keys of this USER namespace be active or the keys of the original user namespace used during the clone()? other than that, same as for PID?</div>Stefanb