| Message ID | 20210727163330.790010-3-simon.thoby@viveris.fr (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | IMA: restrict the accepted digest algorithms for | expand |
[Cc'ing Paul Moore] Hi Simon, On Tue, 2021-07-27 at 16:33 +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). > > Prevent 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. > > Note however that CONFIG_IMA depends on CONFIG_CRYPTO_SHA1, which > somewhat hampers the security benefits of this measure (but MD4 and > MD5 can be disabled, which is already a significant improvement). > > Signed-off-by: Simon Thoby <simon.thoby@viveris.fr> > --- > security/integrity/ima/ima_appraise.c | 51 ++++++++++++++++++++++++++- > 1 file changed, 50 insertions(+), 1 deletion(-) > > diff --git a/security/integrity/ima/ima_appraise.c b/security/integrity/ima/ima_appraise.c > index ef9dcfce45d4..989da2fbf496 100644 > --- a/security/integrity/ima/ima_appraise.c > +++ b/security/integrity/ima/ima_appraise.c > @@ -575,12 +575,55 @@ static void ima_reset_appraise_flags(struct inode *inode, int digsig) > clear_bit(IMA_DIGSIG, &iint->atomic_flags); > } > > +/** > + * ima_setxattr_validate_hash_alg() - Block setxattr with invalid digests > + * @dentry: file being altered There isn't a one to one mapping betwen dentry and "file". Perhaps something like used in __vfs_setxattr_locked: * @dentry: object to perform setxattr on > + * @xattr_value: value supplied by userland for the xattr > + * @xattr_value_len: length of xattr_value > + * > + * Context: called when the user tries to write the security.ima xattr. > + * The xattr value is mapped to some hash algorithm, and this algorithm > + * must be built in the kernel for the setxattr to be allowed. > + * > + * Emit an audit message when the algorithm is invalid. > + * > + * Return: 0 on success, else an error. > + */ > +int ima_setxattr_validate_hash_alg(struct dentry *dentry, > + const void *xattr_value, > + size_t xattr_value_len) Should this be static? If it is a local function, then it doesn't really need to be prefixed with "ima_". It could even be trimmed to validate_hash_algo(). > +{ > + int res = -EACCES; I know there isn't any variable naming consistency. The original code used rc. Subsequently it was replaced with result or ret. Let's not introduce yet another variable name here. > + char *path = NULL, *pathbuf = NULL; > + enum hash_algo dentry_hash; > + > + dentry_hash = ima_get_hash_algo((struct evm_ima_xattr_data *)xattr_value, > + xattr_value_len); The hash algorithm is extracted from the xattr_value. Perhaps rename the variable to xattr_hash, xattr_hash_algo, or simply hash_algo? > + > + if (likely(dentry_hash == ima_hash_algo > + || crypto_has_alg(hash_algo_name[dentry_hash], 0, 0))) > + return 0; > + > + pathbuf = kmalloc(PATH_MAX, GFP_KERNEL); > + /* no memory available ? no file path for you */ The comment here is unnecessary. Avoid or limit comments inside a function. Refer to the section "8) Commenting" in Documentation/process/coding-style.rst > + if (pathbuf) > + path = dentry_path(dentry, pathbuf, PATH_MAX); > + > + /* disallow xattr writes with algorithms not built in the kernel */ > + integrity_audit_msg(AUDIT_INTEGRITY_DATA, d_inode(dentry), > + path, "collect_data", "unavailable-hash-algorithm", res, 0); This will emit an audit message without the filename when !path. Is this what you intended? Now that this patch set is getting closer, examples of each new type of audit message needs to be provided to the audit mailing list. Paul, any suggestions as to how/when to provide them? > + > + kfree(pathbuf); > + > + return res; > +} > + > int ima_inode_setxattr(struct dentry *dentry, const char *xattr_name, > const void *xattr_value, size_t xattr_value_len) > { > const struct evm_ima_xattr_data *xvalue = xattr_value; > int digsig = 0; > - int result; > + int result, rc; > > result = ima_protect_xattr(dentry, xattr_name, xattr_value, > xattr_value_len); > @@ -592,6 +635,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 */ With a function name containing "validate_hash_alg", this comment is unnecessary. thanks, Mimi > + rc = ima_setxattr_validate_hash_alg(dentry, xattr_value, > + xattr_value_len); > + if (!rc) > + return rc; > + > ima_reset_appraise_flags(d_backing_inode(dentry), digsig); > if (result == 1) > result = 0;
Hi Mimi, On 7/27/21 10:32 PM, Mimi Zohar wrote: > [Cc'ing Paul Moore] > > Hi Simon, > [snip] > >> + >> + if (likely(dentry_hash == ima_hash_algo >> + || crypto_has_alg(hash_algo_name[dentry_hash], 0, 0))) >> + return 0; >> + >> + pathbuf = kmalloc(PATH_MAX, GFP_KERNEL); >> + /* no memory available ? no file path for you */ > > The comment here is unnecessary. Avoid or limit comments inside a > function. Refer to the section "8) Commenting" in > Documentation/process/coding-style.rst > >> + if (pathbuf) >> + path = dentry_path(dentry, pathbuf, PATH_MAX); >> + >> + /* disallow xattr writes with algorithms not built in the kernel */ >> + integrity_audit_msg(AUDIT_INTEGRITY_DATA, d_inode(dentry), >> + path, "collect_data", "unavailable-hash-algorithm", res, 0); > > This will emit an audit message without the filename when !path. Is > this what you intended? > This is what I was clumsily trying to explain in the previous comment: if we cannot allocate memory for a file path, I thought it best to log the audit message without the path than fail with a -ENOMEM (auditing will also try to allocate a memory buffer too, but a bit smaller, and memory could have been reclaimed between the two calls, so the auditing operation may succeed). Of course I could also return -ENOMEM, and it would happily propagate back to the user. What do you think ? Thanks, Simon
Hi Simon, On Wed, 2021-07-28 at 07:00 +0000, THOBY Simon wrote: > >> + > >> + if (likely(dentry_hash == ima_hash_algo > >> + || crypto_has_alg(hash_algo_name[dentry_hash], 0, 0))) > >> + return 0; > >> + > >> + pathbuf = kmalloc(PATH_MAX, GFP_KERNEL); > >> + /* no memory available ? no file path for you */ > > > > The comment here is unnecessary. Avoid or limit comments inside a > > function. Refer to the section "8) Commenting" in > > Documentation/process/coding-style.rst > > > >> + if (pathbuf) > >> + path = dentry_path(dentry, pathbuf, PATH_MAX); > >> + > >> + /* disallow xattr writes with algorithms not built in the kernel */ > >> + integrity_audit_msg(AUDIT_INTEGRITY_DATA, d_inode(dentry), > >> + path, "collect_data", "unavailable-hash-algorithm", res, 0); > > > > This will emit an audit message without the filename when !path. Is > > this what you intended? > > > > This is what I was clumsily trying to explain in the previous comment: if we cannot > allocate memory for a file path, I thought it best to log the audit message without > the path than fail with a -ENOMEM (auditing will also try to allocate a memory buffer > too, but a bit smaller, and memory could have been reclaimed between the two calls, > so the auditing operation may succeed). > > Of course I could also return -ENOMEM, and it would happily propagate back to the user. > > What do you think ? Memory pressure isn't the reason for preventing the xattr write. It's the reason for not being able to audit the setxattr failure. thanks, Mimi
Hi Mimi, On 7/28/21 2:43 PM, Mimi Zohar wrote: > Hi Simon, > > On Wed, 2021-07-28 at 07:00 +0000, THOBY Simon wrote: >>>> + >>>> + if (likely(dentry_hash == ima_hash_algo >>>> + || crypto_has_alg(hash_algo_name[dentry_hash], 0, 0))) >>>> + return 0; >>>> + >>>> + pathbuf = kmalloc(PATH_MAX, GFP_KERNEL); >>>> + /* no memory available ? no file path for you */ >>> >>> The comment here is unnecessary. Avoid or limit comments inside a >>> function. Refer to the section "8) Commenting" in >>> Documentation/process/coding-style.rst >>> >>>> + if (pathbuf) >>>> + path = dentry_path(dentry, pathbuf, PATH_MAX); >>>> + >>>> + /* disallow xattr writes with algorithms not built in the kernel */ >>>> + integrity_audit_msg(AUDIT_INTEGRITY_DATA, d_inode(dentry), >>>> + path, "collect_data", "unavailable-hash-algorithm", res, 0); >>> >>> This will emit an audit message without the filename when !path. Is >>> this what you intended? >>> >> >> This is what I was clumsily trying to explain in the previous comment: if we cannot >> allocate memory for a file path, I thought it best to log the audit message without >> the path than fail with a -ENOMEM (auditing will also try to allocate a memory buffer >> too, but a bit smaller, and memory could have been reclaimed between the two calls, >> so the auditing operation may succeed). >> >> Of course I could also return -ENOMEM, and it would happily propagate back to the user. >> >> What do you think ? > > Memory pressure isn't the reason for preventing the xattr write. It's > the reason for not being able to audit the setxattr failure. > I completely agree with you, but I'm not quite sure I get the action you want to take from there. Does this mean you prefer the mechanism already implemented in this patch (not printing the file path and trying to audit the setxattr failure anyway)? > thanks, > > Mimi >
On Wed, 2021-07-28 at 12:53 +0000, THOBY Simon wrote: > Hi Mimi, > > On 7/28/21 2:43 PM, Mimi Zohar wrote: > > Hi Simon, > > > > On Wed, 2021-07-28 at 07:00 +0000, THOBY Simon wrote: > >>>> + > >>>> + if (likely(dentry_hash == ima_hash_algo > >>>> + || crypto_has_alg(hash_algo_name[dentry_hash], 0, 0))) > >>>> + return 0; > >>>> + > >>>> + pathbuf = kmalloc(PATH_MAX, GFP_KERNEL); > >>>> + /* no memory available ? no file path for you */ > >>> > >>> The comment here is unnecessary. Avoid or limit comments inside a > >>> function. Refer to the section "8) Commenting" in > >>> Documentation/process/coding-style.rst > >>> > >>>> + if (pathbuf) > >>>> + path = dentry_path(dentry, pathbuf, PATH_MAX); > >>>> + > >>>> + /* disallow xattr writes with algorithms not built in the kernel */ > >>>> + integrity_audit_msg(AUDIT_INTEGRITY_DATA, d_inode(dentry), > >>>> + path, "collect_data", "unavailable-hash-algorithm", res, 0); > >>> > >>> This will emit an audit message without the filename when !path. Is > >>> this what you intended? > >>> > >> > >> This is what I was clumsily trying to explain in the previous comment: if we cannot > >> allocate memory for a file path, I thought it best to log the audit message without > >> the path than fail with a -ENOMEM (auditing will also try to allocate a memory buffer > >> too, but a bit smaller, and memory could have been reclaimed between the two calls, > >> so the auditing operation may succeed). > >> > >> Of course I could also return -ENOMEM, and it would happily propagate back to the user. > >> > >> What do you think ? > > > > Memory pressure isn't the reason for preventing the xattr write. It's > > the reason for not being able to audit the setxattr failure. Return the existing errno, not -ENOMEM. > > I completely agree with you, but I'm not quite sure I get the action you want to take > from there. > Does this mean you prefer the mechanism already implemented in this patch (not printing > the file path and trying to audit the setxattr failure anyway)? Under memory pressure, I don't think partially auditing the setxattr, without the pathname, makes sense. Not being able to audit the setxattr failure shouldn't affect the returned result. It would be the same in either case. if (pathbuf) { < audit message > < free pathbuf > } return <failure> thanks, Mimi
diff --git a/security/integrity/ima/ima_appraise.c b/security/integrity/ima/ima_appraise.c index ef9dcfce45d4..989da2fbf496 100644 --- a/security/integrity/ima/ima_appraise.c +++ b/security/integrity/ima/ima_appraise.c @@ -575,12 +575,55 @@ static void ima_reset_appraise_flags(struct inode *inode, int digsig) clear_bit(IMA_DIGSIG, &iint->atomic_flags); } +/** + * ima_setxattr_validate_hash_alg() - Block setxattr with invalid digests + * @dentry: file being altered + * @xattr_value: value supplied by userland for the xattr + * @xattr_value_len: length of xattr_value + * + * Context: called when the user tries to write the security.ima xattr. + * The xattr value is mapped to some hash algorithm, and this algorithm + * must be built in the kernel for the setxattr to be allowed. + * + * Emit an audit message when the algorithm is invalid. + * + * Return: 0 on success, else an error. + */ +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 dentry_hash; + + dentry_hash = ima_get_hash_algo((struct evm_ima_xattr_data *)xattr_value, + xattr_value_len); + + if (likely(dentry_hash == ima_hash_algo + || crypto_has_alg(hash_algo_name[dentry_hash], 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); + + /* disallow xattr writes with algorithms not built in the kernel */ + 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) { const struct evm_ima_xattr_data *xvalue = xattr_value; int digsig = 0; - int result; + int result, rc; result = ima_protect_xattr(dentry, xattr_name, xattr_value, xattr_value_len); @@ -592,6 +635,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 */ + rc = ima_setxattr_validate_hash_alg(dentry, xattr_value, + xattr_value_len); + if (!rc) + 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). Prevent 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. Note however that CONFIG_IMA depends on CONFIG_CRYPTO_SHA1, which somewhat hampers the security benefits of this measure (but MD4 and MD5 can be disabled, which is already a significant improvement). Signed-off-by: Simon Thoby <simon.thoby@viveris.fr> --- security/integrity/ima/ima_appraise.c | 51 ++++++++++++++++++++++++++- 1 file changed, 50 insertions(+), 1 deletion(-)