| Message ID | 20210727102307.552052-2-simon.thoby@viveris.fr (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | IMA: restrict the accepted digest algorithms for the security.ima xattr | expand |
Hi Simon, On Tue, 2021-07-27 at 10:23 +0000, THOBY Simon wrote: > By default, any write to the extended attributes security.ima will be > accepted, even if the xattr value uses a hash algorithm not compiled in > the kernel (which doesn't make sense, because the kernel wouldn't be able > to appraise that file, as it lacks support for validating the hash). > > This patch prevents such writes: only writes using hash algorithms > available in the current kernel are now allowed. Any attempt to > perform these writes will be denied with an audit message. > Instead of "This patch", start with "Prevent". From Documentation/process/submitting-patches.rst: Describe your changes in imperative mood, e.g. "make xyzzy do frotz" instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy to do frotz", as if you are giving orders to the codebase to change its behaviour. > The idea behind this patch is that a user can disable weak hashes > when building the kernel, and thereby prevent their use in IMA > (these hash algorithms will not only be blocked for setxattr per > this patch, but they also won't be allowed for measurement/appraisal > either as the kernel isn't able to measure files hashed with them). The motivation for this patch set is described in the cover letter, which may be included as the merge message. The above paragraph isn't needed here in this particular patch description. > Note however that CONFIG_IMA depends on CONFIG_CRYPTO_MD5 and > CONFIG_CRYPTO_SHA1, which hampers the security benefits of this > measure. Unlike SHA1, which is still being used in the IMA measurement list, there is no reason to automatically select MD5 in the Kconfig. As a separate patch, probably the first in this series so that it could be backported, please remove the CRYPTO_MD5 select. > > Signed-off-by: Simon Thoby <simon.thoby@viveris.fr> > --- > security/integrity/ima/ima_appraise.c | 42 +++++++++++++++++++++++++++ > 1 file changed, 42 insertions(+) > > diff --git a/security/integrity/ima/ima_appraise.c b/security/integrity/ima/ima_appraise.c > index ef9dcfce45d4..b5b11f5ec90a 100644 > --- a/security/integrity/ima/ima_appraise.c > +++ b/security/integrity/ima/ima_appraise.c > @@ -575,6 +575,42 @@ static void ima_reset_appraise_flags(struct inode *inode, int digsig) > clear_bit(IMA_DIGSIG, &iint->atomic_flags); > } > > +/** > + * ima_setxattr_validate_hash_alg > + * "kernel-doc" has a specific format. Please refer to the section "Function documentation" in Documentation/doc-guide/kernel-doc.rst. > + * Called when the user tries to write the security.ima xattr. > + * The xattr value maps to the hash algorithm hash_alg, and this function > + * returns whether this setxattr should be allowed, emitting an audit > + * message if necessary. > + */ This is called by an LSM/IMA hook. On success return 0. On failure, return errno. > +int ima_setxattr_validate_hash_alg(struct dentry *dentry, > + const void *xattr_value, > + size_t xattr_value_len) > +{ > + int res = -EACCES; > + char *path = NULL, *pathbuf = NULL; > + enum hash_algo hash_alg = > + ima_get_hash_algo((struct evm_ima_xattr_data *)xattr_value, > + xattr_value_len); Programmatically it is the same to define a variable and assign it on the same line, but in this case, it might be cleaner to split it up. > + > + /* disallow xattr writes with algorithms not built in the kernel */ > + if (likely(hash_alg == ima_hash_algo > + || crypto_has_alg(hash_algo_name[hash_alg], 0, 0))) > + return 0; > + > + pathbuf = kmalloc(PATH_MAX, GFP_KERNEL); > + /* no memory available ? no file path for you */ > + if (pathbuf) > + path = dentry_path(dentry, pathbuf, PATH_MAX); > + > + integrity_audit_msg(AUDIT_INTEGRITY_DATA, d_inode(dentry), > + path, "collect_data", "unavailable-hash-algorithm", res, 0); > + The comment is applicable to integrity_audit_msg(). Why not move it prior to integrity_audit_msg(). > + kfree(pathbuf); > + > + return res; > +} > + > int ima_inode_setxattr(struct dentry *dentry, const char *xattr_name, > const void *xattr_value, size_t xattr_value_len) > { > @@ -592,6 +628,12 @@ int ima_inode_setxattr(struct dentry *dentry, const char *xattr_name, > digsig = (xvalue->type == EVM_XATTR_PORTABLE_DIGSIG); > } > if (result == 1 || evm_revalidate_status(xattr_name)) { > + /* the user-supplied xattr must use an allowed hash algo */ > + int rc = ima_setxattr_validate_hash_alg(dentry, xattr_value, > + xattr_value_len); Variables should be defined at the beginning of the function. > + if (rc != 0) > + return rc; > + "rc" should be 0 or < 1. thanks, Mimi > ima_reset_appraise_flags(d_backing_inode(dentry), digsig); > if (result == 1) > result = 0;
diff --git a/security/integrity/ima/ima_appraise.c b/security/integrity/ima/ima_appraise.c index ef9dcfce45d4..b5b11f5ec90a 100644 --- a/security/integrity/ima/ima_appraise.c +++ b/security/integrity/ima/ima_appraise.c @@ -575,6 +575,42 @@ static void ima_reset_appraise_flags(struct inode *inode, int digsig) clear_bit(IMA_DIGSIG, &iint->atomic_flags); } +/** + * ima_setxattr_validate_hash_alg + * + * Called when the user tries to write the security.ima xattr. + * The xattr value maps to the hash algorithm hash_alg, and this function + * returns whether this setxattr should be allowed, emitting an audit + * message if necessary. + */ +int ima_setxattr_validate_hash_alg(struct dentry *dentry, + const void *xattr_value, + size_t xattr_value_len) +{ + int res = -EACCES; + char *path = NULL, *pathbuf = NULL; + enum hash_algo hash_alg = + ima_get_hash_algo((struct evm_ima_xattr_data *)xattr_value, + xattr_value_len); + + /* disallow xattr writes with algorithms not built in the kernel */ + if (likely(hash_alg == ima_hash_algo + || crypto_has_alg(hash_algo_name[hash_alg], 0, 0))) + return 0; + + pathbuf = kmalloc(PATH_MAX, GFP_KERNEL); + /* no memory available ? no file path for you */ + if (pathbuf) + path = dentry_path(dentry, pathbuf, PATH_MAX); + + integrity_audit_msg(AUDIT_INTEGRITY_DATA, d_inode(dentry), + path, "collect_data", "unavailable-hash-algorithm", res, 0); + + kfree(pathbuf); + + return res; +} + int ima_inode_setxattr(struct dentry *dentry, const char *xattr_name, const void *xattr_value, size_t xattr_value_len) { @@ -592,6 +628,12 @@ int ima_inode_setxattr(struct dentry *dentry, const char *xattr_name, digsig = (xvalue->type == EVM_XATTR_PORTABLE_DIGSIG); } if (result == 1 || evm_revalidate_status(xattr_name)) { + /* the user-supplied xattr must use an allowed hash algo */ + int rc = ima_setxattr_validate_hash_alg(dentry, xattr_value, + xattr_value_len); + if (rc != 0) + return rc; + ima_reset_appraise_flags(d_backing_inode(dentry), digsig); if (result == 1) result = 0;
By default, any write to the extended attributes security.ima will be accepted, even if the xattr value uses a hash algorithm not compiled in the kernel (which doesn't make sense, because the kernel wouldn't be able to appraise that file, as it lacks support for validating the hash). This patch prevents such writes: only writes using hash algorithms available in the current kernel are now allowed. Any attempt to perform these writes will be denied with an audit message. The idea behind this patch is that a user can disable weak hashes when building the kernel, and thereby prevent their use in IMA (these hash algorithms will not only be blocked for setxattr per this patch, but they also won't be allowed for measurement/appraisal either as the kernel isn't able to measure files hashed with them). Note however that CONFIG_IMA depends on CONFIG_CRYPTO_MD5 and CONFIG_CRYPTO_SHA1, which hampers the security benefits of this measure. Signed-off-by: Simon Thoby <simon.thoby@viveris.fr> --- security/integrity/ima/ima_appraise.c | 42 +++++++++++++++++++++++++++ 1 file changed, 42 insertions(+)