integrity: Always reference the blacklist keyring with appraisal

Commit 273df864cf746 ("ima: Check against blacklisted hashes for files with
modsig") introduced an appraise_flag option for referenci

integrity: Always reference the blacklist keyring with appraisal

Commit 273df864cf746 ("ima: Check against blacklisted hashes for files with
modsig") introduced an appraise_flag option for referencing the blacklist
keyring. Any matching binary found on this keyring fails signature
validation. This flag only works with module appended signatures.

An important part of a PKI infrastructure is to have the ability to do
revocation at a later time should a vulnerability be found. Expand the
revocation flag usage to all appraisal functions. The flag is now
enabled by default. Setting the flag with an IMA policy has been
deprecated. Without a revocation capability like this in place, only
authenticity can be maintained. With this change, integrity can now be
achieved with digital signature based IMA appraisal.

Signed-off-by: Eric Snowberg <[email protected]>
Reviewed-by: Nayna Jain <[email protected]>
Signed-off-by: Mimi Zohar <[email protected]>

show more ...

ima: Introduce MMAP_CHECK_REQPROT hook

Commit 98de59bfe4b2f ("take calculation of final prot in
security_mmap_file() into a helper") caused ima_file_mmap() to receive the
protections requested by th

ima: Introduce MMAP_CHECK_REQPROT hook

Commit 98de59bfe4b2f ("take calculation of final prot in
security_mmap_file() into a helper") caused ima_file_mmap() to receive the
protections requested by the application and not those applied by the
kernel.

After restoring the original MMAP_CHECK behavior, existing attestation
servers might be broken due to not being ready to handle new entries
(previously missing) in the IMA measurement list.

Restore the original correct MMAP_CHECK behavior, instead of keeping the
current buggy one and introducing a new hook with the correct behavior.
Otherwise, there would have been the risk of IMA users not noticing the
problem at all, as they would actively have to update the IMA policy, to
switch to the correct behavior.

Also, introduce the new MMAP_CHECK_REQPROT hook to keep the current
behavior, so that IMA users could easily fix a broken attestation server,
although this approach is discouraged due to potentially missing
measurements.

Signed-off-by: Roberto Sassu <[email protected]>
Signed-off-by: Mimi Zohar <[email protected]>

show more ...

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

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 <[email protected]>
Signed-off-by: Mimi Zohar <[email protected]>

show more ...

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

Permit fsverity's file digest (a hash of struct fsverity_descriptor) to
be included in the IMA measurement list, based on the new meas

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

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 <[email protected]>
Signed-off-by: Mimi Zohar <[email protected]>

show more ...

ima: add gid support

IMA currently supports the concept of rules based on uid where the rule
is based on the uid of the file owner or the uid of the user accessing
the file. Provide the ability to h

ima: add gid support

IMA currently supports the concept of rules based on uid where the rule
is based on the uid of the file owner or the uid of the user accessing
the file. Provide the ability to have similar rules based on gid.

Signed-off-by: Curtis Veit <[email protected]>
Co-developed-by: Alex Henrie <[email protected]>
Signed-off-by: Alex Henrie <[email protected]>
Reviewed-by: Petr Vorel <[email protected]>
Signed-off-by: Mimi Zohar <[email protected]>

show more ...

ABI: security: fix location for evm and ima_policy

The What: definitions there are wrong, pointing to different
locations than what's expected.

Reviewed-by: Mimi Zohar <[email protected]>
Signed-

ABI: security: fix location for evm and ima_policy

The What: definitions there are wrong, pointing to different
locations than what's expected.

Reviewed-by: Mimi Zohar <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Link: https://lore.kernel.org/r/b2563ac34c2e234cdd728f0c701b57ac9023c45a.1631782432.git.mchehab+huawei@kernel.org
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

IMA: introduce a new policy option func=SETXATTR_CHECK

While users can restrict the accepted hash algorithms for the
security.ima xattr file signature when appraising said file, users
cannot restric

IMA: introduce a new policy option func=SETXATTR_CHECK

While users can restrict the accepted hash algorithms for the
security.ima xattr file signature when appraising said file, users
cannot restrict the algorithms that can be set on that attribute:
any algorithm built in the kernel is accepted on a write.

Define a new value for the ima policy option 'func' that restricts
globally the hash algorithms accepted when writing the security.ima
xattr.

When a policy contains a rule of the form
appraise func=SETXATTR_CHECK appraise_algos=sha256,sha384,sha512
only values corresponding to one of these three digest algorithms
will be accepted for writing the security.ima xattr. Attempting to
write the attribute using another algorithm (or "free-form" data)
will be denied with an audit log message. In the absence of such a
policy rule, the default is still to only accept hash algorithms
built in the kernel (with all the limitations that entails).

Signed-off-by: THOBY Simon <[email protected]>
Reviewed-by: Lakshmi Ramasubramanian <[email protected]>
Signed-off-by: Mimi Zohar <[email protected]>

show more ...

IMA: add a policy option to restrict xattr hash algorithms on appraisal

The kernel has the ability to restrict the set of hash algorithms it
accepts for the security.ima xattr when it appraises file

IMA: add a policy option to restrict xattr hash algorithms on appraisal

The kernel has the ability to restrict the set of hash algorithms it
accepts for the security.ima xattr when it appraises files.

Define a new IMA policy rule option "appraise_algos=", using the
mentioned mechanism to expose a user-toggable policy knob to opt-in
to that restriction and select the desired set of algorithms that
must be accepted.

When a policy rule uses the 'appraise_algos' option, appraisal of a
file referenced by that rule will now fail if the digest algorithm
employed to hash the file was not one of those explicitly listed in
the option. In its absence, any hash algorithm compiled in the
kernel will be accepted.

For example, on a system where SELinux is properly deployed, the rule
appraise func=BPRM_CHECK obj_type=iptables_exec_t \
appraise_algos=sha256,sha384
will block the execution of iptables if the xattr security.ima of its
executables were not hashed with either sha256 or sha384.

Signed-off-by: THOBY Simon <[email protected]>
Reviewed-by: Lakshmi Ramasubramanian <[email protected]>
Signed-off-by: Mimi Zohar <[email protected]>

show more ...

docs: ABI: testing: ima_policy: Fixed missing bracket

This fixes a minor typo.

Fixes: 34433332841d ("docs: ABI: testing: make the files compatible with ReST output")
Signed-off-by: Michael Weiß <mi

docs: ABI: testing: ima_policy: Fixed missing bracket

This fixes a minor typo.

Fixes: 34433332841d ("docs: ABI: testing: make the files compatible with ReST output")
Signed-off-by: Michael Weiß <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jonathan Corbet <[email protected]>

show more ...

IMA: Measure kernel version in early boot

The integrity of a kernel can be verified by the boot loader on cold
boot, and during kexec, by the current running kernel, before it is
loaded. However, it

IMA: Measure kernel version in early boot

The integrity of a kernel can be verified by the boot loader on cold
boot, and during kexec, by the current running kernel, before it is
loaded. However, it is still possible that the new kernel being
loaded is older than the current kernel, and/or has known
vulnerabilities. Therefore, it is imperative that an attestation
service be able to verify the version of the kernel being loaded on
the client, from cold boot and subsequent kexec system calls,
ensuring that only kernels with versions known to be good are loaded.

Measure the kernel version using ima_measure_critical_data() early on
in the boot sequence, reducing the chances of known kernel
vulnerabilities being exploited. With IMA being part of the kernel,
this overall approach makes the measurement itself more trustworthy.

To enable measuring the kernel version "ima_policy=critical_data"
needs to be added to the kernel command line arguments.
For example,
BOOT_IMAGE=/boot/vmlinuz-5.11.0-rc3+ root=UUID=fd643309-a5d2-4ed3-b10d-3c579a5fab2f ro nomodeset ima_policy=critical_data

If runtime measurement of the kernel version is ever needed, the
following should be added to /etc/ima/ima-policy:

measure func=CRITICAL_DATA label=kernel_info

To extract the measured data after boot, the following command can be used:

grep -m 1 "kernel_version" \
/sys/kernel/security/integrity/ima/ascii_runtime_measurements

Sample output from the command above:

10 a8297d408e9d5155728b619761d0dd4cedf5ef5f ima-buf
sha256:5660e19945be0119bc19cbbf8d9c33a09935ab5d30dad48aa11f879c67d70988
kernel_version 352e31312e302d7263332d31363138372d676564623634666537383234342d6469727479

The above hex-ascii string corresponds to the kernel version
(e.g. xxd -r -p):

5.11.0-rc3-16187-gedb64fe78244-dirty

Signed-off-by: Raphael Gianotti <[email protected]>
Signed-off-by: Mimi Zohar <[email protected]>

show more ...

selinux: include a consumer of the new IMA critical data hook

SELinux stores the active policy in memory, so the changes to this data
at runtime would have an impact on the security guarantees provi

selinux: include a consumer of the new IMA critical data hook

SELinux stores the active policy in memory, so the changes to this data
at runtime would have an impact on the security guarantees provided
by SELinux. Measuring in-memory SELinux policy through IMA subsystem
provides a secure way for the attestation service to remotely validate
the policy contents at runtime.

Measure the hash of the loaded policy by calling the IMA hook
ima_measure_critical_data(). Since the size of the loaded policy
can be large (several MB), measure the hash of the policy instead of
the entire policy to avoid bloating the IMA log entry.

To enable SELinux data measurement, the following steps are required:

1, Add "ima_policy=critical_data" to the kernel command line arguments
to enable measuring SELinux data at boot time.
For example,
BOOT_IMAGE=/boot/vmlinuz-5.10.0-rc1+ root=UUID=fd643309-a5d2-4ed3-b10d-3c579a5fab2f ro nomodeset security=selinux ima_policy=critical_data

2, Add the following rule to /etc/ima/ima-policy
measure func=CRITICAL_DATA label=selinux

Sample measurement of the hash of SELinux policy:

To verify the measured data with the current SELinux policy run
the following commands and verify the output hash values match.

sha256sum /sys/fs/selinux/policy | cut -d' ' -f 1

grep "selinux-policy-hash" /sys/kernel/security/integrity/ima/ascii_runtime_measurements | tail -1 | cut -d' ' -f 6

Note that the actual verification of SELinux policy would require loading
the expected policy into an identical kernel on a pristine/known-safe
system and run the sha256sum /sys/kernel/selinux/policy there to get
the expected hash.

Signed-off-by: Lakshmi Ramasubramanian <[email protected]>
Suggested-by: Stephen Smalley <[email protected]>
Acked-by: Paul Moore <[email protected]>
Reviewed-by: Tyler Hicks <[email protected]>
Signed-off-by: Mimi Zohar <[email protected]>

show more ...

IMA: limit critical data measurement based on a label

Integrity critical data may belong to a single subsystem or it may
arise from cross subsystem interaction. Currently there is no mechanism
to g

IMA: limit critical data measurement based on a label

Integrity critical data may belong to a single subsystem or it may
arise from cross subsystem interaction. Currently there is no mechanism
to group or limit the data based on certain label. Limiting and
grouping critical data based on a label would make it flexible and
configurable to measure.

Define "label:=", a new IMA policy condition, for the IMA func
CRITICAL_DATA to allow grouping and limiting measurement of integrity
critical data.

Limit the measurement to the labels that are specified in the IMA
policy - CRITICAL_DATA+"label:=". If "label:=" is not provided with
the func CRITICAL_DATA, measure all the input integrity critical data.

Signed-off-by: Tushar Sugandhi <[email protected]>
Reviewed-by: Tyler Hicks <[email protected]>
Signed-off-by: Mimi Zohar <[email protected]>

show more ...

IMA: add policy rule to measure critical data

A new IMA policy rule is needed for the IMA hook
ima_measure_critical_data() and the corresponding func CRITICAL_DATA for
measuring the input buffer. T

IMA: add policy rule to measure critical data

A new IMA policy rule is needed for the IMA hook
ima_measure_critical_data() and the corresponding func CRITICAL_DATA for
measuring the input buffer. The policy rule should ensure the buffer
would get measured only when the policy rule allows the action. The
policy rule should also support the necessary constraints (flags etc.)
for integrity critical buffer data measurements.

Add policy rule support for measuring integrity critical data.

Signed-off-by: Tushar Sugandhi <[email protected]>
Reviewed-by: Tyler Hicks <[email protected]>
Signed-off-by: Mimi Zohar <[email protected]>

show more ...

docs: ABI: testing: make the files compatible with ReST output

Some files over there won't parse well by Sphinx.

Fix them.

Acked-by: Jonathan Cameron <[email protected]> # for IIO
Acked-

docs: ABI: testing: make the files compatible with ReST output

Some files over there won't parse well by Sphinx.

Fix them.

Acked-by: Jonathan Cameron <[email protected]> # for IIO
Acked-by: Fabrice Gasnier <[email protected]>
Acked-by: Jonathan Corbet <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Link: https://lore.kernel.org/r/58cf3c2d611e0197fb215652719ebd82ca2658db.1604042072.git.mchehab+huawei@kernel.org
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

IMA: Add support to limit measuring keys

Limit measuring keys to those keys being loaded onto a given set of
keyrings only and when the user id (uid) matches if uid is specified
in the policy.

This

IMA: Add support to limit measuring keys

Limit measuring keys to those keys being loaded onto a given set of
keyrings only and when the user id (uid) matches if uid is specified
in the policy.

This patch defines a new IMA policy option namely "keyrings=" that
can be used to specify a set of keyrings. If this option is specified
in the policy for "measure func=KEY_CHECK" then only the keys
loaded onto a keyring given in the "keyrings=" option are measured.

If uid is specified in the policy then the key is measured only if
the current user id matches the one specified in the policy.

Added a new parameter namely "keyring" (name of the keyring) to
process_buffer_measurement(). The keyring name is passed to
ima_get_action() to determine the required action.
ima_match_rules() is updated to check keyring in the policy, if
specified, for KEY_CHECK function.

Signed-off-by: Lakshmi Ramasubramanian <[email protected]>
Signed-off-by: Mimi Zohar <[email protected]>

show more ...

IMA: Add KEY_CHECK func to measure keys

Measure keys loaded onto any keyring.

This patch defines a new IMA policy func namely KEY_CHECK to
measure keys. Updated ima_match_rules() to check for KEY_C

IMA: Add KEY_CHECK func to measure keys

Measure keys loaded onto any keyring.

This patch defines a new IMA policy func namely KEY_CHECK to
measure keys. Updated ima_match_rules() to check for KEY_CHECK
and ima_parse_rule() to handle KEY_CHECK.

Signed-off-by: Lakshmi Ramasubramanian <[email protected]>
Signed-off-by: Mimi Zohar <[email protected]>

show more ...

ima: Check against blacklisted hashes for files with modsig

Asymmetric private keys are used to sign multiple files. The kernel
currently supports checking against blacklisted keys. However, if the

ima: Check against blacklisted hashes for files with modsig

Asymmetric private keys are used to sign multiple files. The kernel
currently supports checking against blacklisted keys. However, if the
public key is blacklisted, any file signed by the blacklisted key will
automatically fail signature verification. Blacklisting the public key
is not fine enough granularity, as we might want to only blacklist a
particular file.

This patch adds support for checking against the blacklisted hash of
the file, without the appended signature, based on the IMA policy. It
defines a new policy option "appraise_flag=check_blacklist".

In addition to the blacklisted binary hashes stored in the firmware
"dbx" variable, the Linux kernel may be configured to load blacklisted
binary hashes onto the .blacklist keyring as well. The following
example shows how to blacklist a specific kernel module hash.

$ sha256sum kernel/kheaders.ko
77fa889b35a05338ec52e51591c1b89d4c8d1c99a21251d7c22b1a8642a6bad3
kernel/kheaders.ko

$ grep BLACKLIST .config
CONFIG_SYSTEM_BLACKLIST_KEYRING=y
CONFIG_SYSTEM_BLACKLIST_HASH_LIST="blacklist-hash-list"

$ cat certs/blacklist-hash-list
"bin:77fa889b35a05338ec52e51591c1b89d4c8d1c99a21251d7c22b1a8642a6bad3"

Update the IMA custom measurement and appraisal policy
rules (/etc/ima-policy):

measure func=MODULE_CHECK template=ima-modsig
appraise func=MODULE_CHECK appraise_flag=check_blacklist
appraise_type=imasig|modsig

After building, installing, and rebooting the kernel:

545660333 ---lswrv 0 0 \_ blacklist:
bin:77fa889b35a05338ec52e51591c1b89d4c8d1c99a21251d7c22b1a8642a6bad3

measure func=MODULE_CHECK template=ima-modsig
appraise func=MODULE_CHECK appraise_flag=check_blacklist
appraise_type=imasig|modsig

modprobe: ERROR: could not insert 'kheaders': Permission denied

10 0c9834db5a0182c1fb0cdc5d3adcf11a11fd83dd ima-sig
sha256:3bc6ed4f0b4d6e31bc1dbc9ef844605abc7afdc6d81a57d77a1ec9407997c40
2 /usr/lib/modules/5.4.0-rc3+/kernel/kernel/kheaders.ko

10 82aad2bcc3fa8ed94762356b5c14838f3bcfa6a0 ima-modsig
sha256:3bc6ed4f0b4d6e31bc1dbc9ef844605abc7afdc6d81a57d77a1ec9407997c40
2 /usr/lib/modules/5.4.0rc3+/kernel/kernel/kheaders.ko sha256:77fa889b3
5a05338ec52e51591c1b89d4c8d1c99a21251d7c22b1a8642a6bad3
3082029a06092a864886f70d010702a082028b30820287020101310d300b0609608648
016503040201300b06092a864886f70d01070131820264....

10 25b72217cc1152b44b134ce2cd68f12dfb71acb3 ima-buf
sha256:8b58427fedcf8f4b20bc8dc007f2e232bf7285d7b93a66476321f9c2a3aa132
b blacklisted-hash
77fa889b35a05338ec52e51591c1b89d4c8d1c99a21251d7c22b1a8642a6bad3

Signed-off-by: Nayna Jain <[email protected]>
[[email protected]: updated patch description]
Signed-off-by: Mimi Zohar <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

ima: Add modsig appraise_type option for module-style appended signatures

Introduce the modsig keyword to the IMA policy syntax to specify that
a given hook should expect the file to have the IMA si

ima: Add modsig appraise_type option for module-style appended signatures

Introduce the modsig keyword to the IMA policy syntax to specify that
a given hook should expect the file to have the IMA signature appended
to it. Here is how it can be used in a rule:

appraise func=KEXEC_KERNEL_CHECK appraise_type=imasig|modsig

With this rule, IMA will accept either a signature stored in the extended
attribute or an appended signature.

For now, the rule above will behave exactly the same as if
appraise_type=imasig was specified. The actual modsig implementation
will be introduced separately.

Suggested-by: Mimi Zohar <[email protected]>
Signed-off-by: Thiago Jung Bauermann <[email protected]>
Signed-off-by: Mimi Zohar <[email protected]>

show more ...

IMA: Define a new hook to measure the kexec boot command line arguments

Currently during soft reboot(kexec_file_load) boot command line
arguments are not measured. Define hooks needed to measure kex

IMA: Define a new hook to measure the kexec boot command line arguments

Currently during soft reboot(kexec_file_load) boot command line
arguments are not measured. Define hooks needed to measure kexec
command line arguments during soft reboot(kexec_file_load).

- A new ima hook ima_kexec_cmdline is defined to be called by the
kexec code.
- A new function process_buffer_measurement is defined to measure
the buffer hash into the IMA measurement list.
- A new func policy KEXEC_CMDLINE is defined to control the
measurement.

Signed-off-by: Prakhar Srivastava <[email protected]>
Signed-off-by: Mimi Zohar <[email protected]>

show more ...

IMA: support for per policy rule template formats

Admins may wish to log different measurements using different IMA
templates. Add support for overriding the default template on a per-rule
basis.

I

IMA: support for per policy rule template formats

Admins may wish to log different measurements using different IMA
templates. Add support for overriding the default template on a per-rule
basis.

Inspired-by: Roberto Sassu <[email protected]>
Signed-off-by: Matthew Garrett <[email protected]>
Signed-off-by: Mimi Zohar <[email protected]>

show more ...

ima: define a new policy condition based on the filesystem name

If/when file data signatures are distributed with the file data, this
patch will not be needed. In the current environment where only

ima: define a new policy condition based on the filesystem name

If/when file data signatures are distributed with the file data, this
patch will not be needed. In the current environment where only some
files are signed, the ability to differentiate between file systems is
needed. Some file systems consider the file system magic number
internal to the file system.

This patch defines a new IMA policy condition named "fsname", based on
the superblock's file_system_type (sb->s_type) name. This allows policy
rules to be expressed in terms of the filesystem name.

The following sample rules require file signatures on rootfs files
executed or mmap'ed.

appraise func=BPRM_CHECK fsname=rootfs appraise_type=imasig
appraise func=FILE_MMAP fsname=rootfs appraise_type=imasig

Signed-off-by: Mimi Zohar <[email protected]>
Cc: Dave Chinner <[email protected]>
Cc: Theodore Ts'o <[email protected]>

show more ...

IMA: Support using new creds in appraisal policy

The existing BPRM_CHECK functionality in IMA validates against the
credentials of the existing process, not any new credentials that the
child proces

IMA: Support using new creds in appraisal policy

The existing BPRM_CHECK functionality in IMA validates against the
credentials of the existing process, not any new credentials that the
child process may transition to. Add an additional CREDS_CHECK target
and refactor IMA to pass the appropriate creds structure. In
ima_bprm_check(), check with both the existing process credentials and
the credentials that will be committed when the new process is started.
This will not change behaviour unless the system policy is extended to
include CREDS_CHECK targets - BPRM_CHECK will continue to check the same
credentials that it did previously.

After this patch, an IMA policy rule along the lines of:

measure func=CREDS_CHECK subj_type=unconfined_t

will trigger if a process is executed and runs as unconfined_t, ignoring
the context of the parent process. This is in contrast to:

measure func=BPRM_CHECK subj_type=unconfined_t

which will trigger if the process that calls exec() is already executing
in unconfined_t, ignoring the context that the child process executes
into.

Signed-off-by: Matthew Garrett <[email protected]>
Signed-off-by: Mimi Zohar <[email protected]>

Changelog:
- initialize ima_creds_status

show more ...

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 b

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 <[email protected]>
Signed-off-by: Stefan Berger <[email protected]>

show more ...

IMA: update IMA policy documentation to include pcr= option

Commit 0260643ce "ima: add policy support for extending different pcrs"
introduced a new IMA policy option "pcr=". Missing was the docume

IMA: update IMA policy documentation to include pcr= option

Commit 0260643ce "ima: add policy support for extending different pcrs"
introduced a new IMA policy option "pcr=". Missing was the documentation
for this option. This patch updates ima_policy to include this option,
as well as an example.

Signed-off-by: Eric Richter <[email protected]>
Signed-off-by: Mimi Zohar <[email protected]>

show more ...

ima: support for kexec image and initramfs

Add IMA policy support for measuring/appraising the kexec image and
initramfs. Two new IMA policy identifiers KEXEC_KERNEL_CHECK and
KEXEC_INITRAMFS_CHECK

ima: support for kexec image and initramfs

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=imasig

Moving 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_ID

enum ima_hooks {
...
KEXEC_KERNEL_CHECK
KEXEC_INITRAMFS_CHECK

Option 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 Young

Signed-off-by: Mimi Zohar <[email protected]>
Acked-by: Petko Manolov <[email protected]>
Acked-by: Dmitry Kasatkin <[email protected]>
Cc: Dave Young <[email protected]>

show more ...