Hi Simon, On Tue, 2021-07-27 at 16:33 +0000, THOBY Simon wrote: > While users can restrict the accepted hash algorithms for the > security.ima xattr file signature when appraising said file, users > cannot restrict the algorithms that can be set on that attribute: > any algorithm built in the kernel is accepted on a write. > > Define a new value for the ima policy option 'func' that restricts > globally the hash algorithms accepted when writing the security.ima > xattr. > > When a policy contains a rule of the form > appraise func=SETXATTR_CHECK appraise_hash=sha256,sha384,sha512 > only values corresponding to one of these three digest algorithms > will be accepted for writing the security.ima xattr. > Attempting to write the attribute using another algorithm (or "free-form" > data) will be denied with an audit log message. > In the absence of such a policy rule, the default is still to only > accept hash algorithms built in the kernel (with all the limitations > that entails). > > On policy update, the latest SETXATTR_CHECK rule is the only one > that apply, and other SETXATTR_CHECK rules are deleted. > > Signed-off-by: Simon Thoby <simon.thoby@xxxxxxxxxx> Sorry, I was just getting to this patch, when you re-posted the patch set. In the future, I'll make sure the responses are sent in quick succession. There are a number of assumptions related to the IMA policy: - A builtin policy may be replaced by a custom policy. - Depending on the Kconfig, the policy rules may not change be updated. - Subsequent to replacing the builtin policy with a custom policy, rules may only be appended, based on the Kconfig. The locking around the policy rules is dependent on these assumptions. Removing policy rules is a major change that needs to be considered carefully. Why should "func=SETXATTR_CHECK" be treated any differently than any other policy rule? How would an attestation server know which setxattr rule was enabled at the time the file was appraised? thanks, Mimi
