2019-06-01 16:08:55 +08:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-only */
|
2011-03-10 03:13:22 +08:00
|
|
|
/*
|
|
|
|
* Copyright (C) 2009-2010 IBM Corporation
|
|
|
|
*
|
|
|
|
* Authors:
|
|
|
|
* Mimi Zohar <zohar@us.ibm.com>
|
|
|
|
*/
|
|
|
|
|
2020-02-19 08:06:11 +08:00
|
|
|
#ifdef pr_fmt
|
|
|
|
#undef pr_fmt
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
|
|
|
|
|
2011-03-10 03:13:22 +08:00
|
|
|
#include <linux/types.h>
|
|
|
|
#include <linux/integrity.h>
|
2020-11-13 13:20:21 +08:00
|
|
|
#include <crypto/sha1.h>
|
2022-01-25 03:26:23 +08:00
|
|
|
#include <crypto/hash.h>
|
2013-02-07 06:12:08 +08:00
|
|
|
#include <linux/key.h>
|
2018-06-05 04:54:54 +08:00
|
|
|
#include <linux/audit.h>
|
2011-03-10 03:13:22 +08:00
|
|
|
|
2012-09-13 01:51:32 +08:00
|
|
|
/* iint action cache flags */
|
2012-12-05 22:29:09 +08:00
|
|
|
#define IMA_MEASURE 0x00000001
|
|
|
|
#define IMA_MEASURED 0x00000002
|
|
|
|
#define IMA_APPRAISE 0x00000004
|
|
|
|
#define IMA_APPRAISED 0x00000008
|
|
|
|
/*#define IMA_COLLECT 0x00000010 do not use this flag */
|
|
|
|
#define IMA_COLLECTED 0x00000020
|
|
|
|
#define IMA_AUDIT 0x00000040
|
|
|
|
#define IMA_AUDITED 0x00000080
|
ima: support new "hash" and "dont_hash" policy actions
The builtin ima_appraise_tcb policy, which is specified on the boot
command line, can be replaced with a custom policy, normally early in
the boot process. Custom policies can be more restrictive in some ways,
like requiring file signatures, but can be less restrictive in other
ways, like not appraising mutable files. With a less restrictive policy
in place, files in the builtin policy might not be hashed and labeled
with a security.ima hash. On reboot, files which should be labeled in
the ima_appraise_tcb are not labeled, possibly preventing the system
from booting properly.
To resolve this problem, this patch extends the existing IMA policy
actions "measure", "dont_measure", "appraise", "dont_appraise", and
"audit" with "hash" and "dont_hash". The new "hash" action will write
the file hash as security.ima, but without requiring the file to be
appraised as well.
For example, the builtin ima_appraise_tcb policy includes the rule,
"appraise fowner=0". Adding the "hash fowner=0" rule to a custom
policy, will cause the needed file hashes to be calculated and written
as security.ima xattrs.
Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
2016-09-29 22:04:52 +08:00
|
|
|
#define IMA_HASH 0x00000100
|
|
|
|
#define IMA_HASHED 0x00000200
|
2012-09-13 01:51:32 +08:00
|
|
|
|
ima: rename IMA_ACTION_FLAGS to IMA_NONACTION_FLAGS
Simple policy rule options, such as fowner, uid, or euid, can be checked
immediately, while other policy rule options, such as requiring a file
signature, need to be deferred.
The 'flags' field in the integrity_iint_cache struct contains the policy
action', 'subaction', and non action/subaction.
action: measure/measured, appraise/appraised, (collect)/collected,
audit/audited
subaction: appraise status for each hook (e.g. file, mmap, bprm, read,
creds)
non action/subaction: deferred policy rule options and state
Rename the IMA_ACTION_FLAGS to IMA_NONACTION_FLAGS.
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2021-12-28 22:53:14 +08:00
|
|
|
/* iint policy rule cache flags */
|
|
|
|
#define IMA_NONACTION_FLAGS 0xff000000
|
ima: re-introduce own integrity cache lock
Before IMA appraisal was introduced, IMA was using own integrity cache
lock along with i_mutex. process_measurement and ima_file_free took
the iint->mutex first and then the i_mutex, while setxattr, chmod and
chown took the locks in reverse order. To resolve the potential deadlock,
i_mutex was moved to protect entire IMA functionality and the redundant
iint->mutex was eliminated.
Solution was based on the assumption that filesystem code does not take
i_mutex further. But when file is opened with O_DIRECT flag, direct-io
implementation takes i_mutex and produces deadlock. Furthermore, certain
other filesystem operations, such as llseek, also take i_mutex.
More recently some filesystems have replaced their filesystem specific
lock with the global i_rwsem to read a file. As a result, when IMA
attempts to calculate the file hash, reading the file attempts to take
the i_rwsem again.
To resolve O_DIRECT related deadlock problem, this patch re-introduces
iint->mutex. But to eliminate the original chmod() related deadlock
problem, this patch eliminates the requirement for chmod hooks to take
the iint->mutex by introducing additional atomic iint->attr_flags to
indicate calling of the hooks. The allowed locking order is to take
the iint->mutex first and then the i_rwsem.
Original flags were cleared in chmod(), setxattr() or removwxattr()
hooks and tested when file was closed or opened again. New atomic flags
are set or cleared in those hooks and tested to clear iint->flags on
close or on open.
Atomic flags are following:
* IMA_CHANGE_ATTR - indicates that chATTR() was called (chmod, chown,
chgrp) and file attributes have changed. On file open, it causes IMA
to clear iint->flags to re-evaluate policy and perform IMA functions
again.
* IMA_CHANGE_XATTR - indicates that setxattr or removexattr was called
and extended attributes have changed. On file open, it causes IMA to
clear iint->flags IMA_DONE_MASK to re-appraise.
* IMA_UPDATE_XATTR - indicates that security.ima needs to be updated.
It is cleared if file policy changes and no update is needed.
* IMA_DIGSIG - indicates that file security.ima has signature and file
security.ima must not update to file has on file close.
* IMA_MUST_MEASURE - indicates the file is in the measurement policy.
Fixes: Commit 6552321831dc ("xfs: remove i_iolock and use i_rwsem in
the VFS inode instead")
Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@huawei.com>
Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
2017-12-06 03:06:34 +08:00
|
|
|
#define IMA_DIGSIG_REQUIRED 0x01000000
|
|
|
|
#define IMA_PERMIT_DIRECTIO 0x02000000
|
|
|
|
#define IMA_NEW_FILE 0x04000000
|
|
|
|
#define EVM_IMMUTABLE_DIGSIG 0x08000000
|
2018-02-22 00:36:32 +08:00
|
|
|
#define IMA_FAIL_UNVERIFIABLE_SIGS 0x10000000
|
2019-06-28 10:19:28 +08:00
|
|
|
#define IMA_MODSIG_ALLOWED 0x20000000
|
2019-10-31 11:31:32 +08:00
|
|
|
#define IMA_CHECK_BLACKLIST 0x40000000
|
2021-12-24 01:29:56 +08:00
|
|
|
#define IMA_VERITY_REQUIRED 0x80000000
|
2012-09-13 01:51:32 +08:00
|
|
|
|
2012-12-04 06:08:11 +08:00
|
|
|
#define IMA_DO_MASK (IMA_MEASURE | IMA_APPRAISE | IMA_AUDIT | \
|
ima: support new "hash" and "dont_hash" policy actions
The builtin ima_appraise_tcb policy, which is specified on the boot
command line, can be replaced with a custom policy, normally early in
the boot process. Custom policies can be more restrictive in some ways,
like requiring file signatures, but can be less restrictive in other
ways, like not appraising mutable files. With a less restrictive policy
in place, files in the builtin policy might not be hashed and labeled
with a security.ima hash. On reboot, files which should be labeled in
the ima_appraise_tcb are not labeled, possibly preventing the system
from booting properly.
To resolve this problem, this patch extends the existing IMA policy
actions "measure", "dont_measure", "appraise", "dont_appraise", and
"audit" with "hash" and "dont_hash". The new "hash" action will write
the file hash as security.ima, but without requiring the file to be
appraised as well.
For example, the builtin ima_appraise_tcb policy includes the rule,
"appraise fowner=0". Adding the "hash fowner=0" rule to a custom
policy, will cause the needed file hashes to be calculated and written
as security.ima xattrs.
Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
2016-09-29 22:04:52 +08:00
|
|
|
IMA_HASH | IMA_APPRAISE_SUBMASK)
|
2012-12-04 06:08:11 +08:00
|
|
|
#define IMA_DONE_MASK (IMA_MEASURED | IMA_APPRAISED | IMA_AUDITED | \
|
ima: support new "hash" and "dont_hash" policy actions
The builtin ima_appraise_tcb policy, which is specified on the boot
command line, can be replaced with a custom policy, normally early in
the boot process. Custom policies can be more restrictive in some ways,
like requiring file signatures, but can be less restrictive in other
ways, like not appraising mutable files. With a less restrictive policy
in place, files in the builtin policy might not be hashed and labeled
with a security.ima hash. On reboot, files which should be labeled in
the ima_appraise_tcb are not labeled, possibly preventing the system
from booting properly.
To resolve this problem, this patch extends the existing IMA policy
actions "measure", "dont_measure", "appraise", "dont_appraise", and
"audit" with "hash" and "dont_hash". The new "hash" action will write
the file hash as security.ima, but without requiring the file to be
appraised as well.
For example, the builtin ima_appraise_tcb policy includes the rule,
"appraise fowner=0". Adding the "hash fowner=0" rule to a custom
policy, will cause the needed file hashes to be calculated and written
as security.ima xattrs.
Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
2016-09-29 22:04:52 +08:00
|
|
|
IMA_HASHED | IMA_COLLECTED | \
|
|
|
|
IMA_APPRAISED_SUBMASK)
|
2012-12-04 06:08:11 +08:00
|
|
|
|
|
|
|
/* iint subaction appraise cache flags */
|
ima: support new "hash" and "dont_hash" policy actions
The builtin ima_appraise_tcb policy, which is specified on the boot
command line, can be replaced with a custom policy, normally early in
the boot process. Custom policies can be more restrictive in some ways,
like requiring file signatures, but can be less restrictive in other
ways, like not appraising mutable files. With a less restrictive policy
in place, files in the builtin policy might not be hashed and labeled
with a security.ima hash. On reboot, files which should be labeled in
the ima_appraise_tcb are not labeled, possibly preventing the system
from booting properly.
To resolve this problem, this patch extends the existing IMA policy
actions "measure", "dont_measure", "appraise", "dont_appraise", and
"audit" with "hash" and "dont_hash". The new "hash" action will write
the file hash as security.ima, but without requiring the file to be
appraised as well.
For example, the builtin ima_appraise_tcb policy includes the rule,
"appraise fowner=0". Adding the "hash fowner=0" rule to a custom
policy, will cause the needed file hashes to be calculated and written
as security.ima xattrs.
Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
2016-09-29 22:04:52 +08:00
|
|
|
#define IMA_FILE_APPRAISE 0x00001000
|
|
|
|
#define IMA_FILE_APPRAISED 0x00002000
|
|
|
|
#define IMA_MMAP_APPRAISE 0x00004000
|
|
|
|
#define IMA_MMAP_APPRAISED 0x00008000
|
|
|
|
#define IMA_BPRM_APPRAISE 0x00010000
|
|
|
|
#define IMA_BPRM_APPRAISED 0x00020000
|
|
|
|
#define IMA_READ_APPRAISE 0x00040000
|
|
|
|
#define IMA_READ_APPRAISED 0x00080000
|
2018-01-09 05:36:20 +08:00
|
|
|
#define IMA_CREDS_APPRAISE 0x00100000
|
|
|
|
#define IMA_CREDS_APPRAISED 0x00200000
|
2012-12-04 06:08:11 +08:00
|
|
|
#define IMA_APPRAISE_SUBMASK (IMA_FILE_APPRAISE | IMA_MMAP_APPRAISE | \
|
2018-01-09 05:36:20 +08:00
|
|
|
IMA_BPRM_APPRAISE | IMA_READ_APPRAISE | \
|
|
|
|
IMA_CREDS_APPRAISE)
|
2012-12-04 06:08:11 +08:00
|
|
|
#define IMA_APPRAISED_SUBMASK (IMA_FILE_APPRAISED | IMA_MMAP_APPRAISED | \
|
2018-01-09 05:36:20 +08:00
|
|
|
IMA_BPRM_APPRAISED | IMA_READ_APPRAISED | \
|
|
|
|
IMA_CREDS_APPRAISED)
|
2011-03-10 03:13:22 +08:00
|
|
|
|
ima: re-introduce own integrity cache lock
Before IMA appraisal was introduced, IMA was using own integrity cache
lock along with i_mutex. process_measurement and ima_file_free took
the iint->mutex first and then the i_mutex, while setxattr, chmod and
chown took the locks in reverse order. To resolve the potential deadlock,
i_mutex was moved to protect entire IMA functionality and the redundant
iint->mutex was eliminated.
Solution was based on the assumption that filesystem code does not take
i_mutex further. But when file is opened with O_DIRECT flag, direct-io
implementation takes i_mutex and produces deadlock. Furthermore, certain
other filesystem operations, such as llseek, also take i_mutex.
More recently some filesystems have replaced their filesystem specific
lock with the global i_rwsem to read a file. As a result, when IMA
attempts to calculate the file hash, reading the file attempts to take
the i_rwsem again.
To resolve O_DIRECT related deadlock problem, this patch re-introduces
iint->mutex. But to eliminate the original chmod() related deadlock
problem, this patch eliminates the requirement for chmod hooks to take
the iint->mutex by introducing additional atomic iint->attr_flags to
indicate calling of the hooks. The allowed locking order is to take
the iint->mutex first and then the i_rwsem.
Original flags were cleared in chmod(), setxattr() or removwxattr()
hooks and tested when file was closed or opened again. New atomic flags
are set or cleared in those hooks and tested to clear iint->flags on
close or on open.
Atomic flags are following:
* IMA_CHANGE_ATTR - indicates that chATTR() was called (chmod, chown,
chgrp) and file attributes have changed. On file open, it causes IMA
to clear iint->flags to re-evaluate policy and perform IMA functions
again.
* IMA_CHANGE_XATTR - indicates that setxattr or removexattr was called
and extended attributes have changed. On file open, it causes IMA to
clear iint->flags IMA_DONE_MASK to re-appraise.
* IMA_UPDATE_XATTR - indicates that security.ima needs to be updated.
It is cleared if file policy changes and no update is needed.
* IMA_DIGSIG - indicates that file security.ima has signature and file
security.ima must not update to file has on file close.
* IMA_MUST_MEASURE - indicates the file is in the measurement policy.
Fixes: Commit 6552321831dc ("xfs: remove i_iolock and use i_rwsem in
the VFS inode instead")
Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@huawei.com>
Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
2017-12-06 03:06:34 +08:00
|
|
|
/* iint cache atomic_flags */
|
|
|
|
#define IMA_CHANGE_XATTR 0
|
|
|
|
#define IMA_UPDATE_XATTR 1
|
|
|
|
#define IMA_CHANGE_ATTR 2
|
|
|
|
#define IMA_DIGSIG 3
|
|
|
|
#define IMA_MUST_MEASURE 4
|
|
|
|
|
2011-03-10 03:28:20 +08:00
|
|
|
enum evm_ima_xattr_type {
|
|
|
|
IMA_XATTR_DIGEST = 0x01,
|
|
|
|
EVM_XATTR_HMAC,
|
|
|
|
EVM_IMA_XATTR_DIGSIG,
|
2013-08-12 16:22:51 +08:00
|
|
|
IMA_XATTR_DIGEST_NG,
|
2017-11-07 23:17:42 +08:00
|
|
|
EVM_XATTR_PORTABLE_DIGSIG,
|
ima: support fs-verity file digest based version 3 signatures
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 <stefanb@linux.ibm.com>
Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2021-11-24 23:56:33 +08:00
|
|
|
IMA_VERITY_DIGSIG,
|
2014-10-28 19:31:22 +08:00
|
|
|
IMA_XATTR_LAST
|
2011-03-10 03:28:20 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
struct evm_ima_xattr_data {
|
|
|
|
u8 type;
|
2019-06-11 14:28:08 +08:00
|
|
|
u8 data[];
|
|
|
|
} __packed;
|
|
|
|
|
|
|
|
/* Only used in the EVM HMAC code. */
|
|
|
|
struct evm_xattr {
|
|
|
|
struct evm_ima_xattr_data data;
|
2011-03-10 03:28:20 +08:00
|
|
|
u8 digest[SHA1_DIGEST_SIZE];
|
2013-04-25 15:43:56 +08:00
|
|
|
} __packed;
|
|
|
|
|
ima: support fs-verity file digest based version 3 signatures
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 <stefanb@linux.ibm.com>
Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2021-11-24 23:56:33 +08:00
|
|
|
#define IMA_MAX_DIGEST_SIZE HASH_MAX_DIGESTSIZE
|
2013-04-25 15:43:56 +08:00
|
|
|
|
|
|
|
struct ima_digest_data {
|
|
|
|
u8 algo;
|
|
|
|
u8 length;
|
2013-08-12 16:22:51 +08:00
|
|
|
union {
|
|
|
|
struct {
|
|
|
|
u8 unused;
|
|
|
|
u8 type;
|
|
|
|
} sha1;
|
|
|
|
struct {
|
|
|
|
u8 type;
|
|
|
|
u8 algo;
|
|
|
|
} ng;
|
|
|
|
u8 data[2];
|
|
|
|
} xattr;
|
2020-05-28 22:35:11 +08:00
|
|
|
u8 digest[];
|
2013-04-25 15:43:56 +08:00
|
|
|
} __packed;
|
2011-03-10 03:28:20 +08:00
|
|
|
|
2022-01-25 03:26:23 +08:00
|
|
|
/*
|
|
|
|
* Instead of wrapping the ima_digest_data struct inside a local structure
|
|
|
|
* with the maximum hash size, define ima_max_digest_data struct.
|
|
|
|
*/
|
|
|
|
struct ima_max_digest_data {
|
|
|
|
struct ima_digest_data hdr;
|
|
|
|
u8 digest[HASH_MAX_DIGESTSIZE];
|
|
|
|
} __packed;
|
|
|
|
|
2013-04-25 15:44:04 +08:00
|
|
|
/*
|
ima: support fs-verity file digest based version 3 signatures
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 <stefanb@linux.ibm.com>
Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2021-11-24 23:56:33 +08:00
|
|
|
* signature header format v2 - for using with asymmetric keys
|
|
|
|
*
|
|
|
|
* The signature_v2_hdr struct includes a signature format version
|
|
|
|
* to simplify defining new signature formats.
|
|
|
|
*
|
|
|
|
* signature format:
|
|
|
|
* version 2: regular file data hash based signature
|
|
|
|
* version 3: struct ima_file_id data based signature
|
2013-04-25 15:44:04 +08:00
|
|
|
*/
|
|
|
|
struct signature_v2_hdr {
|
2013-10-10 15:12:03 +08:00
|
|
|
uint8_t type; /* xattr type */
|
2013-04-25 15:44:04 +08:00
|
|
|
uint8_t version; /* signature format version */
|
2016-03-04 05:49:27 +08:00
|
|
|
uint8_t hash_algo; /* Digest algorithm [enum hash_algo] */
|
2017-06-08 09:49:10 +08:00
|
|
|
__be32 keyid; /* IMA key identifier - not X509/PGP specific */
|
|
|
|
__be16 sig_size; /* signature size */
|
2020-05-28 22:35:11 +08:00
|
|
|
uint8_t sig[]; /* signature payload */
|
2013-04-25 15:44:04 +08:00
|
|
|
} __packed;
|
|
|
|
|
ima: support fs-verity file digest based version 3 signatures
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 <stefanb@linux.ibm.com>
Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2021-11-24 23:56:33 +08:00
|
|
|
/*
|
|
|
|
* IMA signature version 3 disambiguates the data that is signed, by
|
|
|
|
* indirectly signing the hash of the ima_file_id structure data,
|
|
|
|
* containing either the fsverity_descriptor struct digest or, in the
|
|
|
|
* future, the regular IMA file hash.
|
|
|
|
*
|
|
|
|
* (The hash of the ima_file_id structure is only of the portion used.)
|
|
|
|
*/
|
|
|
|
struct ima_file_id {
|
|
|
|
__u8 hash_type; /* xattr type [enum evm_ima_xattr_type] */
|
|
|
|
__u8 hash_algorithm; /* Digest algorithm [enum hash_algo] */
|
|
|
|
__u8 hash[HASH_MAX_DIGESTSIZE];
|
|
|
|
} __packed;
|
|
|
|
|
2011-03-10 03:13:22 +08:00
|
|
|
/* integrity data associated with an inode */
|
|
|
|
struct integrity_iint_cache {
|
2013-04-25 15:43:56 +08:00
|
|
|
struct rb_node rb_node; /* rooted in integrity_iint_tree */
|
ima: re-introduce own integrity cache lock
Before IMA appraisal was introduced, IMA was using own integrity cache
lock along with i_mutex. process_measurement and ima_file_free took
the iint->mutex first and then the i_mutex, while setxattr, chmod and
chown took the locks in reverse order. To resolve the potential deadlock,
i_mutex was moved to protect entire IMA functionality and the redundant
iint->mutex was eliminated.
Solution was based on the assumption that filesystem code does not take
i_mutex further. But when file is opened with O_DIRECT flag, direct-io
implementation takes i_mutex and produces deadlock. Furthermore, certain
other filesystem operations, such as llseek, also take i_mutex.
More recently some filesystems have replaced their filesystem specific
lock with the global i_rwsem to read a file. As a result, when IMA
attempts to calculate the file hash, reading the file attempts to take
the i_rwsem again.
To resolve O_DIRECT related deadlock problem, this patch re-introduces
iint->mutex. But to eliminate the original chmod() related deadlock
problem, this patch eliminates the requirement for chmod hooks to take
the iint->mutex by introducing additional atomic iint->attr_flags to
indicate calling of the hooks. The allowed locking order is to take
the iint->mutex first and then the i_rwsem.
Original flags were cleared in chmod(), setxattr() or removwxattr()
hooks and tested when file was closed or opened again. New atomic flags
are set or cleared in those hooks and tested to clear iint->flags on
close or on open.
Atomic flags are following:
* IMA_CHANGE_ATTR - indicates that chATTR() was called (chmod, chown,
chgrp) and file attributes have changed. On file open, it causes IMA
to clear iint->flags to re-evaluate policy and perform IMA functions
again.
* IMA_CHANGE_XATTR - indicates that setxattr or removexattr was called
and extended attributes have changed. On file open, it causes IMA to
clear iint->flags IMA_DONE_MASK to re-appraise.
* IMA_UPDATE_XATTR - indicates that security.ima needs to be updated.
It is cleared if file policy changes and no update is needed.
* IMA_DIGSIG - indicates that file security.ima has signature and file
security.ima must not update to file has on file close.
* IMA_MUST_MEASURE - indicates the file is in the measurement policy.
Fixes: Commit 6552321831dc ("xfs: remove i_iolock and use i_rwsem in
the VFS inode instead")
Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@huawei.com>
Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
2017-12-06 03:06:34 +08:00
|
|
|
struct mutex mutex; /* protects: version, flags, digest */
|
2011-03-10 03:13:22 +08:00
|
|
|
struct inode *inode; /* back pointer to inode in question */
|
|
|
|
u64 version; /* track inode changes */
|
2012-12-05 22:29:09 +08:00
|
|
|
unsigned long flags;
|
2016-06-02 02:14:00 +08:00
|
|
|
unsigned long measured_pcrs;
|
ima: re-introduce own integrity cache lock
Before IMA appraisal was introduced, IMA was using own integrity cache
lock along with i_mutex. process_measurement and ima_file_free took
the iint->mutex first and then the i_mutex, while setxattr, chmod and
chown took the locks in reverse order. To resolve the potential deadlock,
i_mutex was moved to protect entire IMA functionality and the redundant
iint->mutex was eliminated.
Solution was based on the assumption that filesystem code does not take
i_mutex further. But when file is opened with O_DIRECT flag, direct-io
implementation takes i_mutex and produces deadlock. Furthermore, certain
other filesystem operations, such as llseek, also take i_mutex.
More recently some filesystems have replaced their filesystem specific
lock with the global i_rwsem to read a file. As a result, when IMA
attempts to calculate the file hash, reading the file attempts to take
the i_rwsem again.
To resolve O_DIRECT related deadlock problem, this patch re-introduces
iint->mutex. But to eliminate the original chmod() related deadlock
problem, this patch eliminates the requirement for chmod hooks to take
the iint->mutex by introducing additional atomic iint->attr_flags to
indicate calling of the hooks. The allowed locking order is to take
the iint->mutex first and then the i_rwsem.
Original flags were cleared in chmod(), setxattr() or removwxattr()
hooks and tested when file was closed or opened again. New atomic flags
are set or cleared in those hooks and tested to clear iint->flags on
close or on open.
Atomic flags are following:
* IMA_CHANGE_ATTR - indicates that chATTR() was called (chmod, chown,
chgrp) and file attributes have changed. On file open, it causes IMA
to clear iint->flags to re-evaluate policy and perform IMA functions
again.
* IMA_CHANGE_XATTR - indicates that setxattr or removexattr was called
and extended attributes have changed. On file open, it causes IMA to
clear iint->flags IMA_DONE_MASK to re-appraise.
* IMA_UPDATE_XATTR - indicates that security.ima needs to be updated.
It is cleared if file policy changes and no update is needed.
* IMA_DIGSIG - indicates that file security.ima has signature and file
security.ima must not update to file has on file close.
* IMA_MUST_MEASURE - indicates the file is in the measurement policy.
Fixes: Commit 6552321831dc ("xfs: remove i_iolock and use i_rwsem in
the VFS inode instead")
Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@huawei.com>
Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
2017-12-06 03:06:34 +08:00
|
|
|
unsigned long atomic_flags;
|
2023-10-19 02:47:02 +08:00
|
|
|
unsigned long real_ino;
|
|
|
|
dev_t real_dev;
|
2012-12-04 06:08:11 +08:00
|
|
|
enum integrity_status ima_file_status:4;
|
|
|
|
enum integrity_status ima_mmap_status:4;
|
|
|
|
enum integrity_status ima_bprm_status:4;
|
2016-01-15 06:57:47 +08:00
|
|
|
enum integrity_status ima_read_status:4;
|
2018-01-09 05:36:20 +08:00
|
|
|
enum integrity_status ima_creds_status:4;
|
2012-09-21 22:00:43 +08:00
|
|
|
enum integrity_status evm_status:4;
|
2013-04-25 15:44:04 +08:00
|
|
|
struct ima_digest_data *ima_hash;
|
2011-03-10 03:13:22 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
/* rbtree tree calls to lookup, insert, delete
|
|
|
|
* integrity data associated with an inode.
|
|
|
|
*/
|
|
|
|
struct integrity_iint_cache *integrity_iint_find(struct inode *inode);
|
2011-08-17 08:34:33 +08:00
|
|
|
|
2014-11-05 23:01:12 +08:00
|
|
|
int integrity_kernel_read(struct file *file, loff_t offset,
|
2017-06-08 09:49:10 +08:00
|
|
|
void *addr, unsigned long count);
|
|
|
|
|
2011-10-05 16:54:46 +08:00
|
|
|
#define INTEGRITY_KEYRING_EVM 0
|
2015-10-23 02:26:10 +08:00
|
|
|
#define INTEGRITY_KEYRING_IMA 1
|
2018-12-13 09:39:09 +08:00
|
|
|
#define INTEGRITY_KEYRING_PLATFORM 2
|
2022-01-26 10:58:28 +08:00
|
|
|
#define INTEGRITY_KEYRING_MACHINE 3
|
|
|
|
#define INTEGRITY_KEYRING_MAX 4
|
2011-10-05 16:54:46 +08:00
|
|
|
|
2018-05-12 07:12:34 +08:00
|
|
|
extern struct dentry *integrity_dir;
|
|
|
|
|
2019-06-28 10:19:30 +08:00
|
|
|
struct modsig;
|
|
|
|
|
2012-01-17 23:12:07 +08:00
|
|
|
#ifdef CONFIG_INTEGRITY_SIGNATURE
|
2011-10-05 16:54:46 +08:00
|
|
|
|
|
|
|
int integrity_digsig_verify(const unsigned int id, const char *sig, int siglen,
|
2013-10-10 14:56:13 +08:00
|
|
|
const char *digest, int digestlen);
|
2019-06-28 10:19:30 +08:00
|
|
|
int integrity_modsig_verify(unsigned int id, const struct modsig *modsig);
|
2011-10-05 16:54:46 +08:00
|
|
|
|
2014-10-02 02:43:07 +08:00
|
|
|
int __init integrity_init_keyring(const unsigned int id);
|
2014-11-26 22:55:00 +08:00
|
|
|
int __init integrity_load_x509(const unsigned int id, const char *path);
|
2018-12-09 04:27:00 +08:00
|
|
|
int __init integrity_load_cert(const unsigned int id, const char *source,
|
2019-07-11 09:43:43 +08:00
|
|
|
const void *data, size_t len, key_perm_t perm);
|
2011-10-05 16:54:46 +08:00
|
|
|
#else
|
|
|
|
|
|
|
|
static inline int integrity_digsig_verify(const unsigned int id,
|
|
|
|
const char *sig, int siglen,
|
|
|
|
const char *digest, int digestlen)
|
|
|
|
{
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
}
|
|
|
|
|
2019-06-28 10:19:30 +08:00
|
|
|
static inline int integrity_modsig_verify(unsigned int id,
|
|
|
|
const struct modsig *modsig)
|
|
|
|
{
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
}
|
|
|
|
|
2013-08-13 20:47:43 +08:00
|
|
|
static inline int integrity_init_keyring(const unsigned int id)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
2018-12-09 04:27:00 +08:00
|
|
|
|
|
|
|
static inline int __init integrity_load_cert(const unsigned int id,
|
|
|
|
const char *source,
|
|
|
|
const void *data, size_t len,
|
2019-07-11 09:43:43 +08:00
|
|
|
key_perm_t perm)
|
2018-12-09 04:27:00 +08:00
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
2012-01-17 23:12:07 +08:00
|
|
|
#endif /* CONFIG_INTEGRITY_SIGNATURE */
|
2011-10-05 16:54:46 +08:00
|
|
|
|
2013-02-07 06:12:08 +08:00
|
|
|
#ifdef CONFIG_INTEGRITY_ASYMMETRIC_KEYS
|
|
|
|
int asymmetric_verify(struct key *keyring, const char *sig,
|
|
|
|
int siglen, const char *data, int datalen);
|
|
|
|
#else
|
|
|
|
static inline int asymmetric_verify(struct key *keyring, const char *sig,
|
|
|
|
int siglen, const char *data, int datalen)
|
|
|
|
{
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2019-06-28 10:19:30 +08:00
|
|
|
#ifdef CONFIG_IMA_APPRAISE_MODSIG
|
|
|
|
int ima_modsig_verify(struct key *keyring, const struct modsig *modsig);
|
|
|
|
#else
|
|
|
|
static inline int ima_modsig_verify(struct key *keyring,
|
|
|
|
const struct modsig *modsig)
|
|
|
|
{
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2014-11-05 23:01:14 +08:00
|
|
|
#ifdef CONFIG_IMA_LOAD_X509
|
|
|
|
void __init ima_load_x509(void);
|
|
|
|
#else
|
|
|
|
static inline void ima_load_x509(void)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2015-10-23 02:26:21 +08:00
|
|
|
#ifdef CONFIG_EVM_LOAD_X509
|
|
|
|
void __init evm_load_x509(void);
|
|
|
|
#else
|
|
|
|
static inline void evm_load_x509(void)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2013-03-19 02:48:02 +08:00
|
|
|
#ifdef CONFIG_INTEGRITY_AUDIT
|
|
|
|
/* declarations */
|
|
|
|
void integrity_audit_msg(int audit_msgno, struct inode *inode,
|
|
|
|
const unsigned char *fname, const char *op,
|
|
|
|
const char *cause, int result, int info);
|
2018-06-05 04:54:54 +08:00
|
|
|
|
2020-06-19 05:10:11 +08:00
|
|
|
void integrity_audit_message(int audit_msgno, struct inode *inode,
|
|
|
|
const unsigned char *fname, const char *op,
|
|
|
|
const char *cause, int result, int info,
|
|
|
|
int errno);
|
|
|
|
|
2018-06-05 04:54:54 +08:00
|
|
|
static inline struct audit_buffer *
|
|
|
|
integrity_audit_log_start(struct audit_context *ctx, gfp_t gfp_mask, int type)
|
|
|
|
{
|
|
|
|
return audit_log_start(ctx, gfp_mask, type);
|
|
|
|
}
|
|
|
|
|
2013-03-19 02:48:02 +08:00
|
|
|
#else
|
|
|
|
static inline void integrity_audit_msg(int audit_msgno, struct inode *inode,
|
|
|
|
const unsigned char *fname,
|
|
|
|
const char *op, const char *cause,
|
|
|
|
int result, int info)
|
|
|
|
{
|
|
|
|
}
|
2018-06-05 04:54:54 +08:00
|
|
|
|
2020-06-19 05:10:11 +08:00
|
|
|
static inline void integrity_audit_message(int audit_msgno,
|
|
|
|
struct inode *inode,
|
|
|
|
const unsigned char *fname,
|
|
|
|
const char *op, const char *cause,
|
|
|
|
int result, int info, int errno)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2018-06-05 04:54:54 +08:00
|
|
|
static inline struct audit_buffer *
|
|
|
|
integrity_audit_log_start(struct audit_context *ctx, gfp_t gfp_mask, int type)
|
|
|
|
{
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2013-03-19 02:48:02 +08:00
|
|
|
#endif
|
2018-12-09 04:27:00 +08:00
|
|
|
|
|
|
|
#ifdef CONFIG_INTEGRITY_PLATFORM_KEYRING
|
|
|
|
void __init add_to_platform_keyring(const char *source, const void *data,
|
|
|
|
size_t len);
|
|
|
|
#else
|
|
|
|
static inline void __init add_to_platform_keyring(const char *source,
|
|
|
|
const void *data, size_t len)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
#endif
|
2022-01-26 10:58:28 +08:00
|
|
|
|
|
|
|
#ifdef CONFIG_INTEGRITY_MACHINE_KEYRING
|
|
|
|
void __init add_to_machine_keyring(const char *source, const void *data, size_t len);
|
2023-08-15 19:27:20 +08:00
|
|
|
bool __init imputed_trust_enabled(void);
|
2022-01-26 10:58:28 +08:00
|
|
|
#else
|
|
|
|
static inline void __init add_to_machine_keyring(const char *source,
|
|
|
|
const void *data, size_t len)
|
|
|
|
{
|
|
|
|
}
|
2023-08-15 19:27:20 +08:00
|
|
|
|
|
|
|
static inline bool __init imputed_trust_enabled(void)
|
2022-01-26 10:58:34 +08:00
|
|
|
{
|
|
|
|
return false;
|
|
|
|
}
|
2022-01-26 10:58:28 +08:00
|
|
|
#endif
|