linux-toradex.git/security/integrity/ima/ima_template_lib.c, branch v6.4

fs: port ->permission() to pass mnt_idmap

2023-01-19T08:24:28+00:00

Convert to struct mnt_idmap.

Last cycle we merged the necessary infrastructure in
256c8aed2b42 ("fs: introduce dedicated idmap type for mounts").
This is just the conversion to struct mnt_idmap.

Currently we still pass around the plain namespace that was attached to a
mount. This is in general pretty convenient but it makes it easy to
conflate namespaces that are relevant on the filesystem with namespaces
that are relevent on the mount level. Especially for non-vfs developers
without detailed knowledge in this area this can be a potential source for
bugs.

Once the conversion to struct mnt_idmap is done all helpers down to the
really low-level helpers will take a struct mnt_idmap argument instead of
two namespace arguments. This way it becomes impossible to conflate the two
eliminating the possibility of any bugs. All of the vfs and all filesystems
only operate on struct mnt_idmap.

Acked-by: Dave Chinner 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Christian Brauner (Microsoft)

lsm,fs: fix vfs_getxattr_alloc() return type and caller error paths

2022-11-18T22:07:03+00:00

The vfs_getxattr_alloc() function currently returns a ssize_t value
despite the fact that it only uses int values internally for return
values.  Fix this by converting vfs_getxattr_alloc() to return an
int type and adjust the callers as necessary.  As part of these
caller modifications, some of the callers are fixed to properly free
the xattr value buffer on both success and failure to ensure that
memory is not leaked in the failure case.

Reviewed-by: Serge Hallyn 
Reviewed-by: Mimi Zohar 
Signed-off-by: Paul Moore

ima: fix violation measurement list record

2022-07-07T02:31:52+00:00

Although the violation digest in the IMA measurement list is always
zeroes, the size of the digest should be based on the hash algorithm.
Until recently the hash algorithm was hard coded to sha1.  Fix the
violation digest size included in the IMA measurement list.

This is just a cosmetic change which should not affect attestation.

Reported-by: Stefan Berger 
Fixes: 09091c44cb73 ("ima: use IMA default hash algorithm for integrity violations")
Tested-by: Stefan Berger 
Signed-off-by: Mimi Zohar

ima: support fs-verity file digest based version 3 signatures

2022-05-05T21:41:51+00:00

IMA may verify a file's integrity against a "good" value stored in the
'security.ima' xattr or as an appended signature, based on policy.  When
the "good value" is stored in the xattr, the xattr may contain a file
hash or signature.  In either case, the "good" value is preceded by a
header.  The first byte of the xattr header indicates the type of data
- hash, signature - stored in the xattr.  To support storing fs-verity
signatures in the 'security.ima' xattr requires further differentiating
the fs-verity signature from the existing IMA signature.

In addition the signatures stored in 'security.ima' xattr, need to be
disambiguated.  Instead of directly signing the fs-verity digest, a new
signature format version 3 is defined as the hash of the ima_file_id
structure, which identifies the type of signature and the digest.

The IMA policy defines "which" files are to be measured, verified, and/or
audited.  For those files being verified, the policy rules indicate "how"
the file should be verified.  For example to require a file be signed,
the appraise policy rule must include the 'appraise_type' option.

	appraise_type:= [imasig] | [imasig|modsig] | [sigv3]
           where 'imasig' is the original or signature format v2 (default),
           where 'modsig' is an appended signature,
           where 'sigv3' is the signature format v3.

The policy rule must also indicate the type of digest, if not the IMA
default, by first specifying the digest type:

	digest_type:= [verity]

The following policy rule requires fsverity signatures.  The rule may be
constrained, for example based on a fsuuid or LSM label.

      appraise func=BPRM_CHECK digest_type=verity appraise_type=sigv3

Acked-by: Stefan Berger 
Signed-off-by: Mimi Zohar

ima: permit fsverity's file digests in the IMA measurement list

2022-05-05T15:49:13+00:00

Permit fsverity's file digest (a hash of struct fsverity_descriptor) to
be included in the IMA measurement list, based on the new measurement
policy rule 'digest_type=verity' option.

To differentiate between a regular IMA file hash from an fsverity's
file digest, use the new d-ngv2 format field included in the ima-ngv2
template.

The following policy rule requires fsverity file digests and specifies
the new 'ima-ngv2' template, which contains the new 'd-ngv2' field.  The
policy rule may be constrained, for example based on a fsuuid or LSM
label.

measure func=FILE_CHECK digest_type=verity template=ima-ngv2

Acked-by: Stefan Berger 
Signed-off-by: Mimi Zohar

ima: define a new template field named 'd-ngv2' and templates

2022-05-05T15:49:13+00:00

In preparation to differentiate between unsigned regular IMA file
hashes and fs-verity's file digests in the IMA measurement list,
define a new template field named 'd-ngv2'.

Also define two new templates named 'ima-ngv2' and 'ima-sigv2', which
include the new 'd-ngv2' field.

Signed-off-by: Mimi Zohar

ima: use IMA default hash algorithm for integrity violations

2022-05-01T20:39:10+00:00

Integrity file violations - ToM/ToU, open writers - are recorded in the IMA
measurement list, containing 0x00's in both the template data and file data
hash fields, but 0xFF's are actually extended into TPM PCRs.  Although the
original 'ima' template data field ('d') is limited to 20 bytes, the 'd-ng'
template digest field is not.

The violation file data hash template field ('d-ng') is unnecessarily hard
coded to SHA1.  Instead of simply replacing the hard coded SHA1 hash
algorithm with a larger hash algorithm, use the hash algorithm as defined
in "ima_hash_algo".  ima_hash_algo is set to either the Kconfig IMA default
hash algorithm or as defined on the boot command line (ima_hash=).

Including a non-SHA1 file data hash algorithm in the 'd-ng' field of
violations is a cosmetic change.  The template data hash field, which is
extended into the TPM PCRs, is not affected by this change and should not
affect attestation of the IMA measurement list.

Tested-by: Stefan Berger 
Signed-off-by: Mimi Zohar

ima: fix 'd-ng' comments and documentation

2022-05-01T20:38:10+00:00

Initially the 'd-ng' template field did not prefix the digest with either
"md5" or "sha1" hash algorithms.  Prior to being upstreamed this changed,
but the comments and documentation were not updated.  Fix the comments
and documentation.

Fixes: 4d7aeee73f53 ("ima: define new template ima-ng and template fields d-ng and n-ng")
Reported-by: Eric Biggers 
Reviewed-by: Stefan Berger 
Signed-off-by: Mimi Zohar

ima: define ima_max_digest_data struct without a flexible array variable

2022-02-15T16:52:06+00:00

To support larger hash digests in the 'iint' cache, instead of defining
the 'digest' field as the maximum digest size, the 'digest' field was
defined as a flexible array variable.  The "ima_digest_data" struct was
wrapped inside a local structure with the maximum digest size.  But
before adding the record to the iint cache, memory for the exact digest
size was dynamically allocated.

The original reason for defining the 'digest' field as a flexible array
variable is still valid for the 'iint' cache use case.  Instead of
wrapping the 'ima_digest_data' struct in a local structure define
'ima_max_digest_data' struct.

Reviewed-by: Stefan Berger 
Signed-off-by: Mimi Zohar

ima: Fix trivial typos in the comments

2022-02-15T16:10:03+00:00

There are a few minor typos in the comments. Fix these.

Signed-off-by: Austin Kim 
Signed-off-by: Mimi Zohar