12 Jan, 2017
1 commit
-
commit 9a11a18902bc3b904353063763d06480620245a6 upstream.
When the "policy" securityfs file is opened for read, it is opened as a
sequential file. However, when it is eventually released, there is no
cleanup for the sequential file, therefore some memory is leaked.This patch adds a call to seq_release() in ima_release_policy() to clean up
the memory when the file is opened for read.Fixes: 80eae209d63a IMA: allow reading back the current policy
Reported-by: Colin Ian King
Signed-off-by: Eric Richter
Tested-by: Colin Ian King
Signed-off-by: Mimi Zohar
Signed-off-by: Greg Kroah-Hartman
11 Oct, 2016
1 commit
-
Pull vfs xattr updates from Al Viro:
"xattr stuff from AndreasThis completes the switch to xattr_handler ->get()/->set() from
->getxattr/->setxattr/->removexattr"* 'work.xattr' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
vfs: Remove {get,set,remove}xattr inode operations
xattr: Stop calling {get,set,remove}xattr inode operations
vfs: Check for the IOP_XATTR flag in listxattr
xattr: Add __vfs_{get,set,remove}xattr helpers
libfs: Use IOP_XATTR flag for empty directory handling
vfs: Use IOP_XATTR flag for bad-inode handling
vfs: Add IOP_XATTR inode operations flag
vfs: Move xattr_resolve_name to the front of fs/xattr.c
ecryptfs: Switch to generic xattr handlers
sockfs: Get rid of getxattr iop
sockfs: getxattr: Fail with -EOPNOTSUPP for invalid attribute names
kernfs: Switch to generic xattr handlers
hfs: Switch to generic xattr handlers
jffs2: Remove jffs2_{get,set,remove}xattr macros
xattr: Remove unnecessary NULL attribute name check
08 Oct, 2016
1 commit
-
Right now, various places in the kernel check for the existence of
getxattr, setxattr, and removexattr inode operations and directly call
those operations. Switch to helper functions and test for the IOP_XATTR
flag instead.Signed-off-by: Andreas Gruenbacher
Acked-by: James Morris
Signed-off-by: Al Viro
16 Sep, 2016
1 commit
-
Ima tries to call ->setxattr() on overlayfs dentry after having locked
underlying inode, which results in a deadlock.Reported-by: Krisztian Litkey
Fixes: 4bacc9c9234c ("overlayfs: Make f_path always point to the overlay and f_inode to the underlay")
Signed-off-by: Miklos Szeredi
Cc: # v4.2
Cc: Mimi Zohar
30 Jul, 2016
1 commit
-
Pull security subsystem updates from James Morris:
"Highlights:- TPM core and driver updates/fixes
- IPv6 security labeling (CALIPSO)
- Lots of Apparmor fixes
- Seccomp: remove 2-phase API, close hole where ptrace can change
syscall #"* 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: (156 commits)
apparmor: fix SECURITY_APPARMOR_HASH_DEFAULT parameter handling
tpm: Add TPM 2.0 support to the Nuvoton i2c driver (NPCT6xx family)
tpm: Factor out common startup code
tpm: use devm_add_action_or_reset
tpm2_i2c_nuvoton: add irq validity check
tpm: read burstcount from TPM_STS in one 32-bit transaction
tpm: fix byte-order for the value read by tpm2_get_tpm_pt
tpm_tis_core: convert max timeouts from msec to jiffies
apparmor: fix arg_size computation for when setprocattr is null terminated
apparmor: fix oops, validate buffer size in apparmor_setprocattr()
apparmor: do not expose kernel stack
apparmor: fix module parameters can be changed after policy is locked
apparmor: fix oops in profile_unpack() when policy_db is not present
apparmor: don't check for vmalloc_addr if kvzalloc() failed
apparmor: add missing id bounds check on dfa verification
apparmor: allow SYS_CAP_RESOURCE to be sufficient to prlimit another task
apparmor: use list_next_entry instead of list_entry_next
apparmor: fix refcount race when finding a child profile
apparmor: fix ref count leak when profile sha1 hash is read
apparmor: check that xindex is in trans_table bounds
...
06 Jul, 2016
1 commit
-
The EVM HMAC should be calculated using the on disk user and
group ids, so the k[ug]ids in the inode must be translated
relative to the s_user_ns of the inode's super block.Signed-off-by: Seth Forshee
Signed-off-by: Eric W. Biederman
30 Jun, 2016
8 commits
-
Extend the PCR supplied as a parameter, instead of assuming that the
measurement entry uses the default configured PCR.Signed-off-by: Eric Richter
Signed-off-by: Mimi Zohar -
IMA avoids re-measuring files by storing the current state as a flag in
the integrity cache. It will then skip adding a new measurement log entry
if the cache reports the file as already measured.If a policy measures an already measured file to a new PCR, the measurement
will not be added to the list. This patch implements a new bitfield for
specifying which PCR the file was measured into, rather than if it was
measured.Signed-off-by: Eric Richter
Signed-off-by: Mimi Zohar -
Template entry duplicates are prevented from being added to the
measurement list by checking a hash table that contains the template
entry digests. However, the PCR value is not included in this comparison,
so duplicate template entry digests with differing PCRs may be dropped.This patch redefines duplicate template entries as template entries with
the same digest and same PCR values.Reported-by: Mimi Zohar
Signed-off-by: Eric Richter
Signed-off-by: Mimi Zohar -
IMA assumes that the same default Kconfig PCR is extended for each
entry. This patch replaces the default configured PCR with the policy
defined PCR.Signed-off-by: Eric Richter
Signed-off-by: Mimi Zohar -
The IMA measurement list entries include the Kconfig defined PCR value.
This patch defines a new ima_template_entry field for including the PCR
as specified in the policy rule.Signed-off-by: Eric Richter
Signed-off-by: Mimi Zohar -
Different policy rules may extend different PCRs. This patch retrieves
the specific PCR for the matched rule. Subsequent patches will include
the rule specific PCR in the measurement list and extend the appropriate
PCR.Signed-off-by: Eric Richter
Signed-off-by: Mimi Zohar -
This patch defines a new IMA measurement policy rule option "pcr=",
which allows extending different PCRs on a per rule basis. For example,
the system independent files could extend the default IMA Kconfig
specified PCR, while the system dependent files could extend a different
PCR.The following is an example of this usage with an SELinux policy; the
rule would extend PCR 11 with system configuration files:measure func=FILE_CHECK mask=MAY_READ obj_type=system_conf_t pcr=11
Changelog v3:
- FIELD_SIZEOF returns bytes, not bits. Fixed INVALID_PCRSigned-off-by: Eric Richter
Signed-off-by: Mimi Zohar -
To keep track of which measurements have been extended to which PCRs, this
patch defines a new integrity_iint_cache field named measured_pcrs. This
field is a bitmask of the PCRs measured. Each bit corresponds to a PCR
index. For example, bit 10 corresponds to PCR 10.Signed-off-by: Eric Richter
Signed-off-by: Mimi Zohar
21 May, 2016
1 commit
-
Instead of open coded variant re-use extension that vsprintf.c provides
us for ages.Signed-off-by: Andy Shevchenko
Reviewed-by: Matt Fleming
Cc: Dmitry Kasatkin
Cc: Mimi Zohar
Cc: Rasmus Villemoes
Cc: Arnd Bergmann
Cc: "Theodore Ts'o"
Cc: Al Viro
Cc: Jens Axboe
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
20 May, 2016
1 commit
-
Pull security subsystem updates from James Morris:
"Highlights:- A new LSM, "LoadPin", from Kees Cook is added, which allows forcing
of modules and firmware to be loaded from a specific device (this
is from ChromeOS, where the device as a whole is verified
cryptographically via dm-verity).This is disabled by default but can be configured to be enabled by
default (don't do this if you don't know what you're doing).- Keys: allow authentication data to be stored in an asymmetric key.
Lots of general fixes and updates.- SELinux: add restrictions for loading of kernel modules via
finit_module(). Distinguish non-init user namespace capability
checks. Apply execstack check on thread stacks"* 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: (48 commits)
LSM: LoadPin: provide enablement CONFIG
Yama: use atomic allocations when reporting
seccomp: Fix comment typo
ima: add support for creating files using the mknodat syscall
ima: fix ima_inode_post_setattr
vfs: forbid write access when reading a file into memory
fs: fix over-zealous use of "const"
selinux: apply execstack check on thread stacks
selinux: distinguish non-init user namespace capability checks
LSM: LoadPin for kernel file loading restrictions
fs: define a string representation of the kernel_read_file_id enumeration
Yama: consolidate error reporting
string_helpers: add kstrdup_quotable_file
string_helpers: add kstrdup_quotable_cmdline
string_helpers: add kstrdup_quotable
selinux: check ss_initialized before revalidating an inode label
selinux: delay inode label lookup as long as possible
selinux: don't revalidate an inode's label when explicitly setting it
selinux: Change bool variable name to index.
KEYS: Add KEYCTL_DH_COMPUTE command
...
18 May, 2016
1 commit
-
Pull 'struct path' constification update from Al Viro:
"'struct path' is passed by reference to a bunch of Linux security
methods; in theory, there's nothing to stop them from modifying the
damn thing and LSM community being what it is, sooner or later some
enterprising soul is going to decide that it's a good idea.Let's remove the temptation and constify all of those..."
* 'work.const-path' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
constify ima_d_path()
constify security_sb_pivotroot()
constify security_path_chroot()
constify security_path_{link,rename}
apparmor: remove useless checks for NULL ->mnt
constify security_path_{mkdir,mknod,symlink}
constify security_path_{unlink,rmdir}
apparmor: constify common_perm_...()
apparmor: constify aa_path_link()
apparmor: new helper - common_path_perm()
constify chmod_common/security_path_chmod
constify security_sb_mount()
constify chown_common/security_path_chown
tomoyo: constify assorted struct path *
apparmor_path_truncate(): path->mnt is never NULL
constify vfs_truncate()
constify security_path_truncate()
[apparmor] constify struct path * in a bunch of helpers
17 May, 2016
1 commit
-
Backmerge to resolve a conflict in ovl_lookup_real();
"ovl_lookup_real(): use lookup_one_len_unlocked()" instead,
but it was too late in the cycle to rebase.
06 May, 2016
1 commit
-
…dhowells/linux-fs into next
05 May, 2016
1 commit
-
Here's a set of patches that changes how certificates/keys are determined
to be trusted. That's currently a two-step process:(1) Up until recently, when an X.509 certificate was parsed - no matter
the source - it was judged against the keys in .system_keyring,
assuming those keys to be trusted if they have KEY_FLAG_TRUSTED set
upon them.This has just been changed such that any key in the .ima_mok keyring,
if configured, may also be used to judge the trustworthiness of a new
certificate, whether or not the .ima_mok keyring is meant to be
consulted for whatever process is being undertaken.If a certificate is determined to be trustworthy, KEY_FLAG_TRUSTED
will be set upon a key it is loaded into (if it is loaded into one),
no matter what the key is going to be loaded for.(2) If an X.509 certificate is loaded into a key, then that key - if
KEY_FLAG_TRUSTED gets set upon it - can be linked into any keyring
with KEY_FLAG_TRUSTED_ONLY set upon it. This was meant to be the
system keyring only, but has been extended to various IMA keyrings.
A user can at will link any key marked KEY_FLAG_TRUSTED into any
keyring marked KEY_FLAG_TRUSTED_ONLY if the relevant permissions masks
permit it.These patches change that:
(1) Trust becomes a matter of consulting the ring of trusted keys supplied
when the trust is evaluated only.(2) Every keyring can be supplied with its own manager function to
restrict what may be added to that keyring. This is called whenever a
key is to be linked into the keyring to guard against a key being
created in one keyring and then linked across.This function is supplied with the keyring and the key type and
payload[*] of the key being linked in for use in its evaluation. It
is permitted to use other data also, such as the contents of other
keyrings such as the system keyrings.[*] The type and payload are supplied instead of a key because as an
optimisation this function may be called whilst creating a key and
so may reject the proposed key between preparse and allocation.(3) A default manager function is provided that permits keys to be
restricted to only asymmetric keys that are vouched for by the
contents of the system keyring.A second manager function is provided that just rejects with EPERM.
(4) A key allocation flag, KEY_ALLOC_BYPASS_RESTRICTION, is made available
so that the kernel can initialise keyrings with keys that form the
root of the trust relationship.(5) KEY_FLAG_TRUSTED and KEY_FLAG_TRUSTED_ONLY are removed, along with
key_preparsed_payload::trusted.This change also makes it possible in future for userspace to create a private
set of trusted keys and then to have it sealed by setting a manager function
where the private set is wholly independent of the kernel's trust
relationships.Further changes in the set involve extracting certain IMA special keyrings
and making them generally global:(*) .system_keyring is renamed to .builtin_trusted_keys and remains read
only. It carries only keys built in to the kernel. It may be where
UEFI keys should be loaded - though that could better be the new
secondary keyring (see below) or a separate UEFI keyring.(*) An optional secondary system keyring (called .secondary_trusted_keys)
is added to replace the IMA MOK keyring.(*) Keys can be added to the secondary keyring by root if the keys can
be vouched for by either ring of system keys.(*) Module signing and kexec only use .builtin_trusted_keys and do not use
the new secondary keyring.(*) Config option SYSTEM_TRUSTED_KEYS now depends on ASYMMETRIC_KEY_TYPE as
that's the only type currently permitted on the system keyrings.(*) A new config option, IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY,
is provided to allow keys to be added to IMA keyrings, subject to the
restriction that such keys are validly signed by a key already in the
system keyrings.If this option is enabled, but secondary keyrings aren't, additions to
the IMA keyrings will be restricted to signatures verifiable by keys in
the builtin system keyring only.Signed-off-by: David Howells
04 May, 2016
1 commit
-
This patch fixes the string representation of the LSM/IMA hook enumeration
ordering used for displaying the IMA policy.Fixes: d9ddf077bb85 ("ima: support for kexec image and initramfs")
Signed-off-by: Mimi Zohar
Tested-by: Eric Richter
Signed-off-by: James Morris
01 May, 2016
2 commits
-
Commit 3034a14 "ima: pass 'opened' flag to identify newly created files"
stopped identifying empty files as new files. However new empty files
can be created using the mknodat syscall. On systems with IMA-appraisal
enabled, these empty files are not labeled with security.ima extended
attributes properly, preventing them from subsequently being opened in
order to write the file data contents. This patch defines a new hook
named ima_post_path_mknod() to mark these empty files, created using
mknodat, as new in order to allow the file data contents to be written.In addition, files with security.ima xattrs containing a file signature
are considered "immutable" and can not be modified. The file contents
need to be written, before signing the file. This patch relaxes this
requirement for new files, allowing the file signature to be written
before the file contents.Changelog:
- defer identifying files with signatures stored as security.ima
(based on Dmitry Rozhkov's comments)
- removing tests (eg. dentry, dentry->d_inode, inode->i_size == 0)
(based on Al's review)Signed-off-by: Mimi Zohar
Cc: Al Viro <
Tested-by: Dmitry Rozhkov -
Changing file metadata (eg. uid, guid) could result in having to
re-appraise a file's integrity, but does not change the "new file"
status nor the security.ima xattr. The IMA_PERMIT_DIRECTIO and
IMA_DIGSIG_REQUIRED flags are policy rule specific. This patch
only resets these flags, not the IMA_NEW_FILE or IMA_DIGSIG flags.With this patch, changing the file timestamp will not remove the
file signature on new files.Reported-by: Dmitry Rozhkov
Signed-off-by: Mimi Zohar
Tested-by: Dmitry Rozhkov
13 Apr, 2016
1 commit
-
Commit d43de6c780a8 ("akcipher: Move the RSA DER encoding check to
the crypto layer") removed the Kconfig option PUBLIC_KEY_ALGO_RSA,
but forgot to remove a 'select' to this option in the definition of
INTEGRITY_ASYMMETRIC_KEYS.Let's remove the select, as it's ineffective now.
Signed-off-by: Andreas Ziegler
Signed-off-by: David Howells
12 Apr, 2016
4 commits
-
Add a config option (IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY)
that, when enabled, allows keys to be added to the IMA keyrings by
userspace - with the restriction that each must be signed by a key in the
system trusted keyrings.EPERM will be returned if this option is disabled, ENOKEY will be returned if
no authoritative key can be found and EKEYREJECTED will be returned if the
signature doesn't match. Other errors such as ENOPKG may also be returned.If this new option is enabled, the builtin system keyring is searched, as is
the secondary system keyring if that is also enabled. Intermediate keys
between the builtin system keyring and the key being added can be added to
the secondary keyring (which replaces .ima_mok) to form a trust chain -
provided they are also validly signed by a key in one of the trusted keyrings.The .ima_mok keyring is then removed and the IMA blacklist keyring gets its
own config option (IMA_BLACKLIST_KEYRING).Signed-off-by: David Howells
Signed-off-by: Mimi Zohar -
Remove KEY_FLAG_TRUSTED and KEY_ALLOC_TRUSTED as they're no longer
meaningful. Also we can drop the trusted flag from the preparse structure.Given this, we no longer need to pass the key flags through to
restrict_link().Further, we can now get rid of keyring_restrict_trusted_only() also.
Signed-off-by: David Howells
-
Move the point at which a key is determined to be trustworthy to
__key_link() so that we use the contents of the keyring being linked in to
to determine whether the key being linked in is trusted or not.What is 'trusted' then becomes a matter of what's in the keyring.
Currently, the test is done when the key is parsed, but given that at that
point we can only sensibly refer to the contents of the system trusted
keyring, we can only use that as the basis for working out the
trustworthiness of a new key.With this change, a trusted keyring is a set of keys that once the
trusted-only flag is set cannot be added to except by verification through
one of the contained keys.Further, adding a key into a trusted keyring, whilst it might grant
trustworthiness in the context of that keyring, does not automatically
grant trustworthiness in the context of a second keyring to which it could
be secondarily linked.To accomplish this, the authentication data associated with the key source
must now be retained. For an X.509 cert, this means the contents of the
AuthorityKeyIdentifier and the signature data.If system keyrings are disabled then restrict_link_by_builtin_trusted()
resolves to restrict_link_reject(). The integrity digital signature code
still works correctly with this as it was previously using
KEY_FLAG_TRUSTED_ONLY, which doesn't permit anything to be added if there
is no system keyring against which trust can be determined.Signed-off-by: David Howells
-
Add a facility whereby proposed new links to be added to a keyring can be
vetted, permitting them to be rejected if necessary. This can be used to
block public keys from which the signature cannot be verified or for which
the signature verification fails. It could also be used to provide
blacklisting.This affects operations like add_key(), KEYCTL_LINK and KEYCTL_INSTANTIATE.
To this end:
(1) A function pointer is added to the key struct that, if set, points to
the vetting function. This is called as:int (*restrict_link)(struct key *keyring,
const struct key_type *key_type,
unsigned long key_flags,
const union key_payload *key_payload),where 'keyring' will be the keyring being added to, key_type and
key_payload will describe the key being added and key_flags[*] can be
AND'ed with KEY_FLAG_TRUSTED.[*] This parameter will be removed in a later patch when
KEY_FLAG_TRUSTED is removed.The function should return 0 to allow the link to take place or an
error (typically -ENOKEY, -ENOPKG or -EKEYREJECTED) to reject the
link.The pointer should not be set directly, but rather should be set
through keyring_alloc().Note that if called during add_key(), preparse is called before this
method, but a key isn't actually allocated until after this function
is called.(2) KEY_ALLOC_BYPASS_RESTRICTION is added. This can be passed to
key_create_or_update() or key_instantiate_and_link() to bypass the
restriction check.(3) KEY_FLAG_TRUSTED_ONLY is removed. The entire contents of a keyring
with this restriction emplaced can be considered 'trustworthy' by
virtue of being in the keyring when that keyring is consulted.(4) key_alloc() and keyring_alloc() take an extra argument that will be
used to set restrict_link in the new key. This ensures that the
pointer is set before the key is published, thus preventing a window
of unrestrictedness. Normally this argument will be NULL.(5) As a temporary affair, keyring_restrict_trusted_only() is added. It
should be passed to keyring_alloc() as the extra argument instead of
setting KEY_FLAG_TRUSTED_ONLY on a keyring. This will be replaced in
a later patch with functions that look in the appropriate places for
authoritative keys.Signed-off-by: David Howells
Reviewed-by: Mimi Zohar
11 Apr, 2016
2 commits
-
Signed-off-by: Al Viro
-
... and neither can ever be NULL
Signed-off-by: Al Viro
28 Mar, 2016
1 commit
-
Signed-off-by: Al Viro
18 Mar, 2016
1 commit
-
Pull security layer updates from James Morris:
"There are a bunch of fixes to the TPM, IMA, and Keys code, with minor
fixes scattered across the subsystem.IMA now requires signed policy, and that policy is also now measured
and appraised"* 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: (67 commits)
X.509: Make algo identifiers text instead of enum
akcipher: Move the RSA DER encoding check to the crypto layer
crypto: Add hash param to pkcs1pad
sign-file: fix build with CMS support disabled
MAINTAINERS: update tpmdd urls
MODSIGN: linux/string.h should be #included to get memcpy()
certs: Fix misaligned data in extra certificate list
X.509: Handle midnight alternative notation in GeneralizedTime
X.509: Support leap seconds
Handle ISO 8601 leap seconds and encodings of midnight in mktime64()
X.509: Fix leap year handling again
PKCS#7: fix unitialized boolean 'want'
firmware: change kernel read fail to dev_dbg()
KEYS: Use the symbol value for list size, updated by scripts/insert-sys-cert
KEYS: Reserve an extra certificate symbol for inserting without recompiling
modsign: hide openssl output in silent builds
tpm_tis: fix build warning with tpm_tis_resume
ima: require signed IMA policy
ima: measure and appraise the IMA policy itself
ima: load policy using path
...
04 Mar, 2016
3 commits
-
…dhowells/linux-fs into next
-
Make the identifier public key and digest algorithm fields text instead of
enum.Signed-off-by: David Howells
Acked-by: Herbert Xu -
Move the RSA EMSA-PKCS1-v1_5 encoding from the asymmetric-key public_key
subtype to the rsa crypto module's pkcs1pad template. This means that the
public_key subtype no longer has any dependencies on public key type.To make this work, the following changes have been made:
(1) The rsa pkcs1pad template is now used for RSA keys. This strips off the
padding and returns just the message hash.(2) In a previous patch, the pkcs1pad template gained an optional second
parameter that, if given, specifies the hash used. We now give this,
and pkcs1pad checks the encoded message E(M) for the EMSA-PKCS1-v1_5
encoding and verifies that the correct digest OID is present.(3) The crypto driver in crypto/asymmetric_keys/rsa.c is now reduced to
something that doesn't care about what the encryption actually does
and and has been merged into public_key.c.(4) CONFIG_PUBLIC_KEY_ALGO_RSA is gone. Module signing must set
CONFIG_CRYPTO_RSA=y instead.Thoughts:
(*) Should the encoding style (eg. raw, EMSA-PKCS1-v1_5) also be passed to
the padding template? Should there be multiple padding templates
registered that share most of the code?Signed-off-by: David Howells
Signed-off-by: Tadeusz Struk
Acked-by: Herbert Xu
21 Feb, 2016
5 commits
-
Require the IMA policy to be signed when additional rules can be added.
v1:
- initialize the policy flag
- include IMA_APPRAISE_POLICY in the policy flagSigned-off-by: Mimi Zohar
Acked-by: Petko Manolov
Acked-by: Dmitry Kasatkin -
Add support for measuring and appraising the IMA policy itself.
Changelog v4:
- use braces on both if/else branches, even if single line on one of the
branches - Dmitry
- Use the id mapping - DmitrySigned-off-by: Mimi Zohar
Acked-by: Petko Manolov
Acked-by: Dmitry Kasatkin -
We currently cannot do appraisal or signature vetting of IMA policies
since we currently can only load IMA policies by writing the contents
of the policy directly in, as follows:cat policy-file > /ima/policy
If we provide the kernel the path to the IMA policy so it can load
the policy itself it'd be able to later appraise or vet the file
signature if it has one. This patch adds support to load the IMA
policy with a given path as follows:echo /etc/ima/ima_policy > /sys/kernel/security/ima/policy
Changelog v4+:
- moved kernel_read_file_from_path() error messages to callers
v3:
- moved kernel_read_file_from_path() to a separate patch
v2:
- after re-ordering the patches, replace calling integrity_kernel_read()
to read the file with kernel_read_file_from_path() (Mimi)
- Patch description re-written by Luis R. RodriguezSigned-off-by: Dmitry Kasatkin
Signed-off-by: Mimi Zohar -
Add IMA policy support for measuring/appraising the kexec image and
initramfs. Two new IMA policy identifiers KEXEC_KERNEL_CHECK and
KEXEC_INITRAMFS_CHECK are defined.Example policy rules:
measure func=KEXEC_KERNEL_CHECK
appraise func=KEXEC_KERNEL_CHECK appraise_type=imasig
measure func=KEXEC_INITRAMFS_CHECK
appraise func=KEXEC_INITRAMFS_CHECK appraise_type=imasigMoving the enumeration to the vfs layer simplified the patches, allowing
the IMA changes, for the most part, to be separated from the other
changes. Unfortunately, passing either a kernel_read_file_id or a
ima_hooks enumeration within IMA is messy.Option 1: duplicate kernel_read_file enumeration in ima_hooks
enum kernel_read_file_id {
...
READING_KEXEC_IMAGE,
READING_KEXEC_INITRAMFS,
READING_MAX_IDenum ima_hooks {
...
KEXEC_KERNEL_CHECK
KEXEC_INITRAMFS_CHECKOption 2: define ima_hooks as extension of kernel_read_file
eg: enum ima_hooks {
FILE_CHECK = READING_MAX_ID,
MMAP_CHECK,In order to pass both kernel_read_file_id and ima_hooks values, we
would need to specify a struct containing a union.struct caller_id {
union {
enum ima_hooks func_id;
enum kernel_read_file_id read_id;
};
};Option 3: incorportate the ima_hooks enumeration into kernel_read_file_id,
perhaps changing the enumeration name.For now, duplicate the new READING_KEXEC_IMAGE/INITRAMFS in the ima_hooks.
Changelog v4:
- replaced switch statement with a kernel_read_file_id to an ima_hooks
id mapping array - Dmitry
- renamed ima_hook tokens KEXEC_CHECK and INITRAMFS_CHECK to
KEXEC_KERNEL_CHECK and KEXEC_INITRAMFS_CHECK respectively - Dave YoungSigned-off-by: Mimi Zohar
Acked-by: Petko Manolov
Acked-by: Dmitry Kasatkin
Cc: Dave Young -
Each time a file is read by the kernel, the file should be re-measured and
the file signature re-appraised, based on policy. As there is no need to
preserve the status information, this patch replaces the firmware and
module specific cache status with a generic one named read_file.This change simplifies adding support for other files read by the kernel.
Signed-off-by: Mimi Zohar
Acked-by: Petko Manolov
Acked-by: Dmitry Kasatkin
