IMA Namespacing design considerations - Revision history

Stefanb: /* Standalone IMA namespace versus IMA namespace attached to MOUNT namespace or USER namespace */

2019-03-01T16:52:56Z

Standalone IMA namespace versus IMA namespace attached to MOUNT namespace or USER namespace

← Older revision		Revision as of 16:52, 1 March 2019
Line 143:		Line 143:
	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.		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.

	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.		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.

	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.		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.

Stefanb: /* IMA Namespacing Considerations */

2018-04-30T19:14:43Z

IMA Namespacing Considerations

← Older revision		Revision as of 19:14, 30 April 2018
Line 34:		Line 34:
	host could possibly eat up a lot of memory		host could possibly eat up a lot of memory
	- to prevent (host) root from spawning new IMA namespaces and doing things undetected in the TCB, all activities of root must be		- to prevent (host) root from spawning new IMA namespaces and doing things undetected in the TCB, all activities of root must be
	''measured and audited'' in all IMA namespaces independent of whether the policy enables logging or auditing in child ~~namespacee~~		''measured and audited'' in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces
	- The existing builtin policies assume policy rules are based on the global “uid” or “fowner”, not based on the namespaced “uid” or “fowner”.		- The existing builtin policies assume policy rules are based on the global “uid” or “fowner”, not based on the namespaced “uid” or “fowner”.
	Instead of explicitly including specific “uid” or “fowner” rules for each container, allow rules to be specified in terms of the namespaced		Instead of explicitly including specific “uid” or “fowner” rules for each container, allow rules to be specified in terms of the namespaced

Stefanb: /* IMA Namespacing Considerations */

2018-04-30T19:12:44Z

IMA Namespacing Considerations

← Older revision		Revision as of 19:12, 30 April 2018
Line 41:		Line 41:
	- The measurement list size is currently unbounded. Additional rules, which measure files opened by root in the namespace or appraise files		- The measurement list size is currently unbounded. Additional rules, which measure files opened by root in the namespace or appraise files
	owned by root in the namespace, will add additional system memory pressures.		owned by root in the namespace, will add additional system memory pressures.

	- IMA-measurement:		- IMA-measurement:
	- to prevent (host) root from spawning new IMA namespaces and doing things undetected in the TCB, all activities of root must be		- to prevent (host) root from spawning new IMA namespaces and doing things undetected in the TCB, all activities of root must be

Stefanb: /* IMA Namespacing Considerations */

2018-04-30T19:12:21Z

IMA Namespacing Considerations

← Older revision		Revision as of 19:12, 30 April 2018
Line 22:		Line 22:
	- IMA policy for container (similar to the host):		- IMA policy for container (similar to the host):
	- there should be an initial default policy for every IMA namespace that measures activities inside the container		- there should be an initial default policy for every IMA namespace that measures activities inside the container
	- the policy can be ~~overwritten once~~ with a user-defined policy ~~that may activate appraisal; this policy~~ would be independent of that of		- the 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
	the host		- like the existing builtin policies can be replaced with a custom policy once, the namespace policy can be replaced with a user-defined
			custom policy once. Both the initial and custom namespace IMA policies would be independent of that of the host policy.
	- CAP_SYS_ADMIN is currently gating the setting of the IMA policy;		- CAP_SYS_ADMIN is currently gating the setting of the IMA policy;
	- setting the policy should be possibly without the almighty CAP_SYS_ADMIN		- setting the policy should be possibly without the almighty CAP_SYS_ADMIN
Line 33:		Line 34:
	host could possibly eat up a lot of memory		host could possibly eat up a lot of memory
	- to prevent (host) root from spawning new IMA namespaces and doing things undetected in the TCB, all activities of root must be		- to prevent (host) root from spawning new IMA namespaces and doing things undetected in the TCB, all activities of root must be
	''measured and audited'' in all IMA namespaces independent of whether the policy enables logging or auditing in child ~~namespaces~~		''measured and audited'' in all IMA namespaces independent of whether the policy enables logging or auditing in child namespacee
			- The existing builtin policies assume policy rules are based on the global “uid” or “fowner”, not based on the namespaced “uid” or “fowner”.
			Instead of explicitly including specific “uid” or “fowner” rules for each container, allow rules to be specified in terms of the namespaced
			“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
			namespace and “appraise fowner=0 ns” means appraise all files owned by root in the namespace.
			- The measurement list size is currently unbounded. Additional rules, which measure files opened by root in the namespace or appraise files
			owned by root in the namespace, will add additional system memory pressures.

	- IMA-measurement:		- IMA-measurement:
	- to prevent (host) root from spawning new IMA namespaces and doing things undetected in the TCB, all activities of root must be		- to prevent (host) root from spawning new IMA namespaces and doing things undetected in the TCB, all activities of root must be

Stefanb: /* Namespacing IMA */

2018-04-30T17:57:54Z

Namespacing IMA

← Older revision		Revision as of 17:57, 30 April 2018
Line 11:		Line 11:
	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.		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.

	Namespacing each of these features requires not only adding IMA namespacing support, but requires some additional kernel changes.		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.

	=== IMA Namespacing Considerations ===		=== IMA Namespacing Considerations ===

Stefanb: /* Background */

2018-04-30T17:54:55Z

Background

← Older revision		Revision as of 17:54, 30 April 2018
Line 5:		Line 5:
	=== Background ===		=== Background ===

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

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

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

			Namespacing each of these features requires not only adding IMA namespacing support, but requires some additional kernel changes.

	=== IMA Namespacing Considerations ===		=== IMA Namespacing Considerations ===

Stefanb: /* IMA namespaces and IMA policy semantics */

2018-04-20T13:22:16Z

IMA namespaces and IMA policy semantics

← Older revision		Revision as of 13:22, 20 April 2018
Line 122:		Line 122:
	The interpretation of these IMA policy rules is as follows:		The interpretation of these IMA policy rules is as follows:

	1) Files executed in the IMA namespace that has this policy rule and its child namespaces are audited once		1) Files executed in the IMA namespace that has this policy rule and its child namespaces are audited once
	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		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
	3) Files executed in the IMA namespace that has this policy rule and its child namespaces are measured once		3) Files executed in the IMA namespace that has this policy rule and its child namespaces are measured once

	Note: Initially, the init_ima_ns will be the only IMA namespace that will have a policy.		Note: Initially, the init_ima_ns will be the only IMA namespace that will have a policy.

Stefanb: /* IMA namespaces and IMA policy semantics */

2018-04-20T13:21:56Z

IMA namespaces and IMA policy semantics

← Older revision		Revision as of 13:21, 20 April 2018
Line 114:		Line 114:
	=== IMA namespaces and IMA policy semantics ===		=== IMA namespaces and IMA policy semantics ===

	The following shows a IMA policy rules and their semantics when applied to IMA namespaces:		The following shows IMA policy rules and their semantics when applied to IMA namespaces:

	1) audit FUNC=BPRM_CHECK		1) audit FUNC=BPRM_CHECK

Stefanb: /* Namespacing IMA */

2018-04-20T13:21:32Z

Namespacing IMA

← Older revision		Revision as of 13:21, 20 April 2018
Line 111:		Line 111:
	- MNT namespaces and access files or execute program: same as for PID; if active IMA namespace policy requires file appraisal, files would need		- MNT namespaces and access files or execute program: same as for PID; if active IMA namespace policy requires file appraisal, files would need
	to be signed with key from keyring in current USER namespace		to be signed with key from keyring in current USER namespace

			=== IMA namespaces and IMA policy semantics ===

			The following shows a IMA policy rules and their semantics when applied to IMA namespaces:

			1) audit FUNC=BPRM_CHECK
			2) audit FUNC=BPRM_CHECK ns
			3) measure func=BPRM_CHECK

			The interpretation of these IMA policy rules is as follows:

			1) Files executed in the IMA namespace that has this policy rule and its child namespaces are audited once
			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
			3) Files executed in the IMA namespace that has this policy rule and its child namespaces are measured once

			Note: Initially, the init_ima_ns will be the only IMA namespace that will have a policy.

	== Standalone IMA namespace versus IMA namespace attached to MOUNT namespace or USER namespace ==		== Standalone IMA namespace versus IMA namespace attached to MOUNT namespace or USER namespace ==

Stefanb: Reformatting of text in boxes to fit on printed landscape page

2018-04-12T13:34:51Z

Reformatting of text in boxes to fit on printed landscape page

← Older revision		Revision as of 13:34, 12 April 2018
Line 20:		Line 20:
	- IMA policy for container (similar to the host):		- IMA policy for container (similar to the host):
	- there should be an initial default policy for every IMA namespace that measures activities inside the container		- there should be an initial default policy for every IMA namespace that measures activities inside the container
	- the policy can be overwritten once with a user-defined policy that may activate appraisal; this policy would be independent of that of the host		- the policy can be overwritten once with a user-defined policy that may activate appraisal; this policy would be independent of that of
			the host
	- CAP_SYS_ADMIN is currently gating the setting of the IMA policy;		- CAP_SYS_ADMIN is currently gating the setting of the IMA policy;
	- setting the policy should be possibly without the almighty CAP_SYS_ADMIN		- setting the policy should be possibly without the almighty CAP_SYS_ADMIN
Line 29:		Line 30:
	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		and audited or 'not'; a use case for not measuring may be found in cloud environments where containers come and go and the log on the
	host could possibly eat up a lot of memory		host could possibly eat up a lot of memory
	- to prevent (host) root from spawning new IMA namespaces and doing things undetected in the TCB, all activities of root must be ''measured and audited''		- to prevent (host) root from spawning new IMA namespaces and doing things undetected in the TCB, all activities of root must be
	in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces		''measured and audited'' in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces

	- IMA-measurement:		- IMA-measurement:
	- to prevent (host) root from spawning new IMA namespaces and doing things undetected in the TCB, all activities of root must be ''measured'' and audited		- to prevent (host) root from spawning new IMA namespaces and doing things undetected in the TCB, all activities of root must be
	in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces		''measured'' and audited in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces
	- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace		- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace

	- IMA-audit:		- IMA-audit:
	- to prevent (host) root from spawning new IMA namespaces and doing things undetected in the TCB, all activities of root must be measured and ''audited''		- to prevent (host) root from spawning new IMA namespaces and doing things undetected in the TCB, all activities of root must be
	in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces		measured and ''audited'' in all IMA namespaces independent of whether the policy enables logging or auditing in child namespaces
	- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace		- activities of all other users, including container-root user, would only be subject to the policy set in the IMA namespace

Line 52:		Line 53:
	- 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		- If IMA-appraisal is active on the host (per policy rules on the host), what is supposed to happen when (host) root executes files in a
	(nested) IMA namespace where an empty IMA policy has been set? We would measure and audit root's activities as described above.		(nested) IMA namespace where an empty IMA policy has been set? We would measure and audit root's activities as described above.
	What about appraising? Would we traverse all the IMA namespaces back to the init_ima_ns and evaluate signatures against the appraisal ~~policy~~		What about appraising? Would we traverse all the IMA namespaces back to the init_ima_ns and evaluate signatures against the appraisal
	set there and assume we would always find the keys in the init_user_ns?		policy set there and assume we would always find the keys in the init_user_ns?

	Maybe the following would be a solution for appraising file accesses by (host) root with the key used for signature verification		Maybe the following would be a solution for appraising file accesses by (host) root with the key used for signature verification
Line 73:		Line 74:

	- TPM and measurements:		- TPM and measurements:
	- The IMA namespace that holds the logs should be configurable to extend PCRs; since the single TPM of the host cannot be shared by containers,		- The IMA namespace that holds the logs should be configurable to extend PCRs; since the single TPM of the host cannot be shared by
	each IMA namespace would have to be associated with its own TPM instance (vTPM); measurement in the initial IMA namespace are extended into		containers, each IMA namespace would have to be associated with its own TPM instance (vTPM); measurement in the initial IMA namespace
	the hardware TPM as done already		are extended into the hardware TPM as done already
	- Each IMA namespace should only have access to the sysfs entries of its own TPM instance; ideally, sysfs would only show a single TPM ~~device~~		- Each IMA namespace should only have access to the sysfs entries of its own TPM instance; ideally, sysfs would only show a single TPM
	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		device entry when viewed from an IMA namespace; an alternative may be that all devices are shown but refuse read/write access to their
	is initiated from the 'wrong' IMA namespace		files if it is initiated from the 'wrong' IMA namespace

	- Extended attribute security.ima:		- Extended attribute security.ima:
	- A container should be able to set the security.ima extended attribute		- A container should be able to set the security.ima extended attribute
	- this should be possibly without the almighty CAP_SYS_ADMIN;		- this should be possibly without the almighty CAP_SYS_ADMIN;
	- we may want to gate this with a new capability CAP_SECURITY_XATTR_ADMIN that allows setting security extended attributes inside a container,		- we may want to gate this with a new capability CAP_SECURITY_XATTR_ADMIN that allows setting security extended attributes inside a
	possibly only during container build-time		container, possibly only during container build-time

	- Extended attribute security.ima and bind mounting		- Extended attribute security.ima and bind mounting
	- It may be necessary that different namespaces be able to sign the same bind-mounted file with different keys		- It may be necessary that different namespaces be able to sign the same bind-mounted file with different keys
	(I am thinking of bind-mounted files that the container management stack modifies and that may need to be signed for the container to be		(I am thinking of bind-mounted files that the container management stack modifies and that may need to be signed for the container to
	able to access them.)		be able to access them.)
	- Extended attributes, such as security.ima) may need to be virtualizeable (security.ima vs. security.ima@uid=1000 etc.)		- Extended attributes, such as security.ima) may need to be virtualizeable (security.ima vs. security.ima@uid=1000 etc.)

Line 117:		Line 118:
	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.		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.

	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.		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.

	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.		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.