2024-08-02 23:08:16 -07:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
|
|
|
/*
|
|
|
|
* Copyright (C) 2020-2024 Microsoft Corporation. All rights reserved.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/errno.h>
|
|
|
|
#include <linux/verification.h>
|
|
|
|
|
|
|
|
#include "ipe.h"
|
2024-08-02 23:08:22 -07:00
|
|
|
#include "eval.h"
|
|
|
|
#include "fs.h"
|
2024-08-02 23:08:16 -07:00
|
|
|
#include "policy.h"
|
|
|
|
#include "policy_parser.h"
|
audit,ipe: add IPE auditing support
Users of IPE require a way to identify when and why an operation fails,
allowing them to both respond to violations of policy and be notified
of potentially malicious actions on their systems with respect to IPE
itself.
This patch introduces 3 new audit events.
AUDIT_IPE_ACCESS(1420) indicates the result of an IPE policy evaluation
of a resource.
AUDIT_IPE_CONFIG_CHANGE(1421) indicates the current active IPE policy
has been changed to another loaded policy.
AUDIT_IPE_POLICY_LOAD(1422) indicates a new IPE policy has been loaded
into the kernel.
This patch also adds support for success auditing, allowing users to
identify why an allow decision was made for a resource. However, it is
recommended to use this option with caution, as it is quite noisy.
Here are some examples of the new audit record types:
AUDIT_IPE_ACCESS(1420):
audit: AUDIT1420 ipe_op=EXECUTE ipe_hook=BPRM_CHECK enforcing=1
pid=297 comm="sh" path="/root/vol/bin/hello" dev="tmpfs"
ino=3897 rule="op=EXECUTE boot_verified=TRUE action=ALLOW"
audit: AUDIT1420 ipe_op=EXECUTE ipe_hook=BPRM_CHECK enforcing=1
pid=299 comm="sh" path="/mnt/ipe/bin/hello" dev="dm-0"
ino=2 rule="DEFAULT action=DENY"
audit: AUDIT1420 ipe_op=EXECUTE ipe_hook=BPRM_CHECK enforcing=1
pid=300 path="/tmp/tmpdp2h1lub/deny/bin/hello" dev="tmpfs"
ino=131 rule="DEFAULT action=DENY"
The above three records were generated when the active IPE policy only
allows binaries from the initramfs to run. The three identical `hello`
binary were placed at different locations, only the first hello from
the rootfs(initramfs) was allowed.
Field ipe_op followed by the IPE operation name associated with the log.
Field ipe_hook followed by the name of the LSM hook that triggered the IPE
event.
Field enforcing followed by the enforcement state of IPE. (it will be
introduced in the next commit)
Field pid followed by the pid of the process that triggered the IPE
event.
Field comm followed by the command line program name of the process that
triggered the IPE event.
Field path followed by the file's path name.
Field dev followed by the device name as found in /dev where the file is
from.
Note that for device mappers it will use the name `dm-X` instead of
the name in /dev/mapper.
For a file in a temp file system, which is not from a device, it will use
`tmpfs` for the field.
The implementation of this part is following another existing use case
LSM_AUDIT_DATA_INODE in security/lsm_audit.c
Field ino followed by the file's inode number.
Field rule followed by the IPE rule made the access decision. The whole
rule must be audited because the decision is based on the combination of
all property conditions in the rule.
Along with the syscall audit event, user can know why a blocked
happened. For example:
audit: AUDIT1420 ipe_op=EXECUTE ipe_hook=BPRM_CHECK enforcing=1
pid=2138 comm="bash" path="/mnt/ipe/bin/hello" dev="dm-0"
ino=2 rule="DEFAULT action=DENY"
audit[1956]: SYSCALL arch=c000003e syscall=59
success=no exit=-13 a0=556790138df0 a1=556790135390 a2=5567901338b0
a3=ab2a41a67f4f1f4e items=1 ppid=147 pid=1956 auid=4294967295 uid=0
gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0
ses=4294967295 comm="bash" exe="/usr/bin/bash" key=(null)
The above two records showed bash used execve to run "hello" and got
blocked by IPE. Note that the IPE records are always prior to a SYSCALL
record.
AUDIT_IPE_CONFIG_CHANGE(1421):
audit: AUDIT1421
old_active_pol_name="Allow_All" old_active_pol_version=0.0.0
old_policy_digest=sha256:E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649
new_active_pol_name="boot_verified" new_active_pol_version=0.0.0
new_policy_digest=sha256:820EEA5B40CA42B51F68962354BA083122A20BB846F
auid=4294967295 ses=4294967295 lsm=ipe res=1
The above record showed the current IPE active policy switch from
`Allow_All` to `boot_verified` along with the version and the hash
digest of the two policies. Note IPE can only have one policy active
at a time, all access decision evaluation is based on the current active
policy.
The normal procedure to deploy a policy is loading the policy to deploy
into the kernel first, then switch the active policy to it.
AUDIT_IPE_POLICY_LOAD(1422):
audit: AUDIT1422 policy_name="boot_verified" policy_version=0.0.0
policy_digest=sha256:820EEA5B40CA42B51F68962354BA083122A20BB846F2676
auid=4294967295 ses=4294967295 lsm=ipe res=1
The above record showed a new policy has been loaded into the kernel
with the policy name, policy version and policy hash.
Signed-off-by: Deven Bowers <deven.desai@linux.microsoft.com>
Signed-off-by: Fan Wu <wufan@linux.microsoft.com>
[PM: subject line tweak]
Signed-off-by: Paul Moore <paul@paul-moore.com>
2024-08-02 23:08:23 -07:00
|
|
|
#include "audit.h"
|
2024-08-02 23:08:16 -07:00
|
|
|
|
2024-08-02 23:08:22 -07:00
|
|
|
/* lock for synchronizing writers across ipe policy */
|
|
|
|
DEFINE_MUTEX(ipe_policy_lock);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ver_to_u64() - Convert an internal ipe_policy_version to a u64.
|
|
|
|
* @p: Policy to extract the version from.
|
|
|
|
*
|
|
|
|
* Bits (LSB is index 0):
|
|
|
|
* [48,32] -> Major
|
|
|
|
* [32,16] -> Minor
|
|
|
|
* [16, 0] -> Revision
|
|
|
|
*
|
|
|
|
* Return: u64 version of the embedded version structure.
|
|
|
|
*/
|
|
|
|
static inline u64 ver_to_u64(const struct ipe_policy *const p)
|
|
|
|
{
|
|
|
|
u64 r;
|
|
|
|
|
|
|
|
r = (((u64)p->parsed->version.major) << 32)
|
|
|
|
| (((u64)p->parsed->version.minor) << 16)
|
|
|
|
| ((u64)(p->parsed->version.rev));
|
|
|
|
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
2024-08-02 23:08:16 -07:00
|
|
|
/**
|
|
|
|
* ipe_free_policy() - Deallocate a given IPE policy.
|
|
|
|
* @p: Supplies the policy to free.
|
|
|
|
*
|
|
|
|
* Safe to call on IS_ERR/NULL.
|
|
|
|
*/
|
|
|
|
void ipe_free_policy(struct ipe_policy *p)
|
|
|
|
{
|
|
|
|
if (IS_ERR_OR_NULL(p))
|
|
|
|
return;
|
|
|
|
|
2024-08-02 23:08:22 -07:00
|
|
|
ipe_del_policyfs_node(p);
|
2024-08-02 23:08:16 -07:00
|
|
|
ipe_free_parsed_policy(p->parsed);
|
|
|
|
/*
|
|
|
|
* p->text is allocated only when p->pkcs7 is not NULL
|
|
|
|
* otherwise it points to the plaintext data inside the pkcs7
|
|
|
|
*/
|
|
|
|
if (!p->pkcs7)
|
|
|
|
kfree(p->text);
|
|
|
|
kfree(p->pkcs7);
|
|
|
|
kfree(p);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int set_pkcs7_data(void *ctx, const void *data, size_t len,
|
|
|
|
size_t asn1hdrlen __always_unused)
|
|
|
|
{
|
|
|
|
struct ipe_policy *p = ctx;
|
|
|
|
|
|
|
|
p->text = (const char *)data;
|
|
|
|
p->textlen = len;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2024-08-02 23:08:22 -07:00
|
|
|
/**
|
|
|
|
* ipe_update_policy() - parse a new policy and replace old with it.
|
|
|
|
* @root: Supplies a pointer to the securityfs inode saved the policy.
|
|
|
|
* @text: Supplies a pointer to the plain text policy.
|
|
|
|
* @textlen: Supplies the length of @text.
|
|
|
|
* @pkcs7: Supplies a pointer to a buffer containing a pkcs7 message.
|
|
|
|
* @pkcs7len: Supplies the length of @pkcs7len.
|
|
|
|
*
|
|
|
|
* @text/@textlen is mutually exclusive with @pkcs7/@pkcs7len - see
|
|
|
|
* ipe_new_policy.
|
|
|
|
*
|
|
|
|
* Context: Requires root->i_rwsem to be held.
|
|
|
|
* Return: %0 on success. If an error occurs, the function will return
|
|
|
|
* the -errno.
|
|
|
|
*/
|
|
|
|
int ipe_update_policy(struct inode *root, const char *text, size_t textlen,
|
|
|
|
const char *pkcs7, size_t pkcs7len)
|
|
|
|
{
|
|
|
|
struct ipe_policy *old, *ap, *new = NULL;
|
|
|
|
int rc = 0;
|
|
|
|
|
|
|
|
old = (struct ipe_policy *)root->i_private;
|
|
|
|
if (!old)
|
|
|
|
return -ENOENT;
|
|
|
|
|
|
|
|
new = ipe_new_policy(text, textlen, pkcs7, pkcs7len);
|
|
|
|
if (IS_ERR(new))
|
|
|
|
return PTR_ERR(new);
|
|
|
|
|
|
|
|
if (strcmp(new->parsed->name, old->parsed->name)) {
|
|
|
|
rc = -EINVAL;
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
|
2024-09-25 14:01:34 -07:00
|
|
|
if (ver_to_u64(old) >= ver_to_u64(new)) {
|
2024-09-25 14:01:33 -07:00
|
|
|
rc = -ESTALE;
|
2024-08-02 23:08:22 -07:00
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
|
|
|
|
root->i_private = new;
|
|
|
|
swap(new->policyfs, old->policyfs);
|
audit,ipe: add IPE auditing support
Users of IPE require a way to identify when and why an operation fails,
allowing them to both respond to violations of policy and be notified
of potentially malicious actions on their systems with respect to IPE
itself.
This patch introduces 3 new audit events.
AUDIT_IPE_ACCESS(1420) indicates the result of an IPE policy evaluation
of a resource.
AUDIT_IPE_CONFIG_CHANGE(1421) indicates the current active IPE policy
has been changed to another loaded policy.
AUDIT_IPE_POLICY_LOAD(1422) indicates a new IPE policy has been loaded
into the kernel.
This patch also adds support for success auditing, allowing users to
identify why an allow decision was made for a resource. However, it is
recommended to use this option with caution, as it is quite noisy.
Here are some examples of the new audit record types:
AUDIT_IPE_ACCESS(1420):
audit: AUDIT1420 ipe_op=EXECUTE ipe_hook=BPRM_CHECK enforcing=1
pid=297 comm="sh" path="/root/vol/bin/hello" dev="tmpfs"
ino=3897 rule="op=EXECUTE boot_verified=TRUE action=ALLOW"
audit: AUDIT1420 ipe_op=EXECUTE ipe_hook=BPRM_CHECK enforcing=1
pid=299 comm="sh" path="/mnt/ipe/bin/hello" dev="dm-0"
ino=2 rule="DEFAULT action=DENY"
audit: AUDIT1420 ipe_op=EXECUTE ipe_hook=BPRM_CHECK enforcing=1
pid=300 path="/tmp/tmpdp2h1lub/deny/bin/hello" dev="tmpfs"
ino=131 rule="DEFAULT action=DENY"
The above three records were generated when the active IPE policy only
allows binaries from the initramfs to run. The three identical `hello`
binary were placed at different locations, only the first hello from
the rootfs(initramfs) was allowed.
Field ipe_op followed by the IPE operation name associated with the log.
Field ipe_hook followed by the name of the LSM hook that triggered the IPE
event.
Field enforcing followed by the enforcement state of IPE. (it will be
introduced in the next commit)
Field pid followed by the pid of the process that triggered the IPE
event.
Field comm followed by the command line program name of the process that
triggered the IPE event.
Field path followed by the file's path name.
Field dev followed by the device name as found in /dev where the file is
from.
Note that for device mappers it will use the name `dm-X` instead of
the name in /dev/mapper.
For a file in a temp file system, which is not from a device, it will use
`tmpfs` for the field.
The implementation of this part is following another existing use case
LSM_AUDIT_DATA_INODE in security/lsm_audit.c
Field ino followed by the file's inode number.
Field rule followed by the IPE rule made the access decision. The whole
rule must be audited because the decision is based on the combination of
all property conditions in the rule.
Along with the syscall audit event, user can know why a blocked
happened. For example:
audit: AUDIT1420 ipe_op=EXECUTE ipe_hook=BPRM_CHECK enforcing=1
pid=2138 comm="bash" path="/mnt/ipe/bin/hello" dev="dm-0"
ino=2 rule="DEFAULT action=DENY"
audit[1956]: SYSCALL arch=c000003e syscall=59
success=no exit=-13 a0=556790138df0 a1=556790135390 a2=5567901338b0
a3=ab2a41a67f4f1f4e items=1 ppid=147 pid=1956 auid=4294967295 uid=0
gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0
ses=4294967295 comm="bash" exe="/usr/bin/bash" key=(null)
The above two records showed bash used execve to run "hello" and got
blocked by IPE. Note that the IPE records are always prior to a SYSCALL
record.
AUDIT_IPE_CONFIG_CHANGE(1421):
audit: AUDIT1421
old_active_pol_name="Allow_All" old_active_pol_version=0.0.0
old_policy_digest=sha256:E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649
new_active_pol_name="boot_verified" new_active_pol_version=0.0.0
new_policy_digest=sha256:820EEA5B40CA42B51F68962354BA083122A20BB846F
auid=4294967295 ses=4294967295 lsm=ipe res=1
The above record showed the current IPE active policy switch from
`Allow_All` to `boot_verified` along with the version and the hash
digest of the two policies. Note IPE can only have one policy active
at a time, all access decision evaluation is based on the current active
policy.
The normal procedure to deploy a policy is loading the policy to deploy
into the kernel first, then switch the active policy to it.
AUDIT_IPE_POLICY_LOAD(1422):
audit: AUDIT1422 policy_name="boot_verified" policy_version=0.0.0
policy_digest=sha256:820EEA5B40CA42B51F68962354BA083122A20BB846F2676
auid=4294967295 ses=4294967295 lsm=ipe res=1
The above record showed a new policy has been loaded into the kernel
with the policy name, policy version and policy hash.
Signed-off-by: Deven Bowers <deven.desai@linux.microsoft.com>
Signed-off-by: Fan Wu <wufan@linux.microsoft.com>
[PM: subject line tweak]
Signed-off-by: Paul Moore <paul@paul-moore.com>
2024-08-02 23:08:23 -07:00
|
|
|
ipe_audit_policy_load(new);
|
2024-08-02 23:08:22 -07:00
|
|
|
|
|
|
|
mutex_lock(&ipe_policy_lock);
|
|
|
|
ap = rcu_dereference_protected(ipe_active_policy,
|
|
|
|
lockdep_is_held(&ipe_policy_lock));
|
|
|
|
if (old == ap) {
|
|
|
|
rcu_assign_pointer(ipe_active_policy, new);
|
|
|
|
mutex_unlock(&ipe_policy_lock);
|
audit,ipe: add IPE auditing support
Users of IPE require a way to identify when and why an operation fails,
allowing them to both respond to violations of policy and be notified
of potentially malicious actions on their systems with respect to IPE
itself.
This patch introduces 3 new audit events.
AUDIT_IPE_ACCESS(1420) indicates the result of an IPE policy evaluation
of a resource.
AUDIT_IPE_CONFIG_CHANGE(1421) indicates the current active IPE policy
has been changed to another loaded policy.
AUDIT_IPE_POLICY_LOAD(1422) indicates a new IPE policy has been loaded
into the kernel.
This patch also adds support for success auditing, allowing users to
identify why an allow decision was made for a resource. However, it is
recommended to use this option with caution, as it is quite noisy.
Here are some examples of the new audit record types:
AUDIT_IPE_ACCESS(1420):
audit: AUDIT1420 ipe_op=EXECUTE ipe_hook=BPRM_CHECK enforcing=1
pid=297 comm="sh" path="/root/vol/bin/hello" dev="tmpfs"
ino=3897 rule="op=EXECUTE boot_verified=TRUE action=ALLOW"
audit: AUDIT1420 ipe_op=EXECUTE ipe_hook=BPRM_CHECK enforcing=1
pid=299 comm="sh" path="/mnt/ipe/bin/hello" dev="dm-0"
ino=2 rule="DEFAULT action=DENY"
audit: AUDIT1420 ipe_op=EXECUTE ipe_hook=BPRM_CHECK enforcing=1
pid=300 path="/tmp/tmpdp2h1lub/deny/bin/hello" dev="tmpfs"
ino=131 rule="DEFAULT action=DENY"
The above three records were generated when the active IPE policy only
allows binaries from the initramfs to run. The three identical `hello`
binary were placed at different locations, only the first hello from
the rootfs(initramfs) was allowed.
Field ipe_op followed by the IPE operation name associated with the log.
Field ipe_hook followed by the name of the LSM hook that triggered the IPE
event.
Field enforcing followed by the enforcement state of IPE. (it will be
introduced in the next commit)
Field pid followed by the pid of the process that triggered the IPE
event.
Field comm followed by the command line program name of the process that
triggered the IPE event.
Field path followed by the file's path name.
Field dev followed by the device name as found in /dev where the file is
from.
Note that for device mappers it will use the name `dm-X` instead of
the name in /dev/mapper.
For a file in a temp file system, which is not from a device, it will use
`tmpfs` for the field.
The implementation of this part is following another existing use case
LSM_AUDIT_DATA_INODE in security/lsm_audit.c
Field ino followed by the file's inode number.
Field rule followed by the IPE rule made the access decision. The whole
rule must be audited because the decision is based on the combination of
all property conditions in the rule.
Along with the syscall audit event, user can know why a blocked
happened. For example:
audit: AUDIT1420 ipe_op=EXECUTE ipe_hook=BPRM_CHECK enforcing=1
pid=2138 comm="bash" path="/mnt/ipe/bin/hello" dev="dm-0"
ino=2 rule="DEFAULT action=DENY"
audit[1956]: SYSCALL arch=c000003e syscall=59
success=no exit=-13 a0=556790138df0 a1=556790135390 a2=5567901338b0
a3=ab2a41a67f4f1f4e items=1 ppid=147 pid=1956 auid=4294967295 uid=0
gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0
ses=4294967295 comm="bash" exe="/usr/bin/bash" key=(null)
The above two records showed bash used execve to run "hello" and got
blocked by IPE. Note that the IPE records are always prior to a SYSCALL
record.
AUDIT_IPE_CONFIG_CHANGE(1421):
audit: AUDIT1421
old_active_pol_name="Allow_All" old_active_pol_version=0.0.0
old_policy_digest=sha256:E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649
new_active_pol_name="boot_verified" new_active_pol_version=0.0.0
new_policy_digest=sha256:820EEA5B40CA42B51F68962354BA083122A20BB846F
auid=4294967295 ses=4294967295 lsm=ipe res=1
The above record showed the current IPE active policy switch from
`Allow_All` to `boot_verified` along with the version and the hash
digest of the two policies. Note IPE can only have one policy active
at a time, all access decision evaluation is based on the current active
policy.
The normal procedure to deploy a policy is loading the policy to deploy
into the kernel first, then switch the active policy to it.
AUDIT_IPE_POLICY_LOAD(1422):
audit: AUDIT1422 policy_name="boot_verified" policy_version=0.0.0
policy_digest=sha256:820EEA5B40CA42B51F68962354BA083122A20BB846F2676
auid=4294967295 ses=4294967295 lsm=ipe res=1
The above record showed a new policy has been loaded into the kernel
with the policy name, policy version and policy hash.
Signed-off-by: Deven Bowers <deven.desai@linux.microsoft.com>
Signed-off-by: Fan Wu <wufan@linux.microsoft.com>
[PM: subject line tweak]
Signed-off-by: Paul Moore <paul@paul-moore.com>
2024-08-02 23:08:23 -07:00
|
|
|
ipe_audit_policy_activation(old, new);
|
2024-08-02 23:08:22 -07:00
|
|
|
} else {
|
|
|
|
mutex_unlock(&ipe_policy_lock);
|
|
|
|
}
|
|
|
|
synchronize_rcu();
|
|
|
|
ipe_free_policy(old);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
err:
|
|
|
|
ipe_free_policy(new);
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
2024-08-02 23:08:16 -07:00
|
|
|
/**
|
|
|
|
* ipe_new_policy() - Allocate and parse an ipe_policy structure.
|
|
|
|
*
|
|
|
|
* @text: Supplies a pointer to the plain-text policy to parse.
|
|
|
|
* @textlen: Supplies the length of @text.
|
|
|
|
* @pkcs7: Supplies a pointer to a pkcs7-signed IPE policy.
|
|
|
|
* @pkcs7len: Supplies the length of @pkcs7.
|
|
|
|
*
|
|
|
|
* @text/@textlen Should be NULL/0 if @pkcs7/@pkcs7len is set.
|
|
|
|
*
|
|
|
|
* Return:
|
|
|
|
* * a pointer to the ipe_policy structure - Success
|
|
|
|
* * %-EBADMSG - Policy is invalid
|
|
|
|
* * %-ENOMEM - Out of memory (OOM)
|
|
|
|
* * %-ERANGE - Policy version number overflow
|
|
|
|
* * %-EINVAL - Policy version parsing error
|
|
|
|
*/
|
|
|
|
struct ipe_policy *ipe_new_policy(const char *text, size_t textlen,
|
|
|
|
const char *pkcs7, size_t pkcs7len)
|
|
|
|
{
|
|
|
|
struct ipe_policy *new = NULL;
|
|
|
|
int rc = 0;
|
|
|
|
|
|
|
|
new = kzalloc(sizeof(*new), GFP_KERNEL);
|
|
|
|
if (!new)
|
|
|
|
return ERR_PTR(-ENOMEM);
|
|
|
|
|
|
|
|
if (!text) {
|
|
|
|
new->pkcs7len = pkcs7len;
|
|
|
|
new->pkcs7 = kmemdup(pkcs7, pkcs7len, GFP_KERNEL);
|
|
|
|
if (!new->pkcs7) {
|
|
|
|
rc = -ENOMEM;
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
|
ipe: allow secondary and platform keyrings to install/update policies
The current policy management makes it impossible to use IPE
in a general purpose distribution. In such cases the users are not
building the kernel, the distribution is, and access to the private
key included in the trusted keyring is, for obvious reason, not
available.
This means that users have no way to enable IPE, since there will
be no built-in generic policy, and no access to the key to sign
updates validated by the trusted keyring.
Just as we do for dm-verity, kernel modules and more, allow the
secondary and platform keyrings to also validate policies. This
allows users enrolling their own keys in UEFI db or MOK to also
sign policies, and enroll them. This makes it sensible to enable
IPE in general purpose distributions, as it becomes usable by
any user wishing to do so. Keys in these keyrings can already
load kernels and kernel modules, so there is no security
downgrade.
Add a kconfig each, like dm-verity does, but default to enabled if
the dependencies are available.
Signed-off-by: Luca Boccassi <bluca@debian.org>
Reviewed-by: Serge Hallyn <serge@hallyn.com>
[FW: fixed some style issues]
Signed-off-by: Fan Wu <wufan@kernel.org>
2024-09-15 02:11:19 -07:00
|
|
|
rc = verify_pkcs7_signature(NULL, 0, new->pkcs7, pkcs7len,
|
|
|
|
#ifdef CONFIG_IPE_POLICY_SIG_SECONDARY_KEYRING
|
|
|
|
VERIFY_USE_SECONDARY_KEYRING,
|
|
|
|
#else
|
|
|
|
NULL,
|
|
|
|
#endif
|
2024-08-02 23:08:16 -07:00
|
|
|
VERIFYING_UNSPECIFIED_SIGNATURE,
|
|
|
|
set_pkcs7_data, new);
|
ipe: allow secondary and platform keyrings to install/update policies
The current policy management makes it impossible to use IPE
in a general purpose distribution. In such cases the users are not
building the kernel, the distribution is, and access to the private
key included in the trusted keyring is, for obvious reason, not
available.
This means that users have no way to enable IPE, since there will
be no built-in generic policy, and no access to the key to sign
updates validated by the trusted keyring.
Just as we do for dm-verity, kernel modules and more, allow the
secondary and platform keyrings to also validate policies. This
allows users enrolling their own keys in UEFI db or MOK to also
sign policies, and enroll them. This makes it sensible to enable
IPE in general purpose distributions, as it becomes usable by
any user wishing to do so. Keys in these keyrings can already
load kernels and kernel modules, so there is no security
downgrade.
Add a kconfig each, like dm-verity does, but default to enabled if
the dependencies are available.
Signed-off-by: Luca Boccassi <bluca@debian.org>
Reviewed-by: Serge Hallyn <serge@hallyn.com>
[FW: fixed some style issues]
Signed-off-by: Fan Wu <wufan@kernel.org>
2024-09-15 02:11:19 -07:00
|
|
|
#ifdef CONFIG_IPE_POLICY_SIG_PLATFORM_KEYRING
|
2024-09-27 01:23:44 -07:00
|
|
|
if (rc == -ENOKEY || rc == -EKEYREJECTED)
|
ipe: allow secondary and platform keyrings to install/update policies
The current policy management makes it impossible to use IPE
in a general purpose distribution. In such cases the users are not
building the kernel, the distribution is, and access to the private
key included in the trusted keyring is, for obvious reason, not
available.
This means that users have no way to enable IPE, since there will
be no built-in generic policy, and no access to the key to sign
updates validated by the trusted keyring.
Just as we do for dm-verity, kernel modules and more, allow the
secondary and platform keyrings to also validate policies. This
allows users enrolling their own keys in UEFI db or MOK to also
sign policies, and enroll them. This makes it sensible to enable
IPE in general purpose distributions, as it becomes usable by
any user wishing to do so. Keys in these keyrings can already
load kernels and kernel modules, so there is no security
downgrade.
Add a kconfig each, like dm-verity does, but default to enabled if
the dependencies are available.
Signed-off-by: Luca Boccassi <bluca@debian.org>
Reviewed-by: Serge Hallyn <serge@hallyn.com>
[FW: fixed some style issues]
Signed-off-by: Fan Wu <wufan@kernel.org>
2024-09-15 02:11:19 -07:00
|
|
|
rc = verify_pkcs7_signature(NULL, 0, new->pkcs7, pkcs7len,
|
|
|
|
VERIFY_USE_PLATFORM_KEYRING,
|
|
|
|
VERIFYING_UNSPECIFIED_SIGNATURE,
|
|
|
|
set_pkcs7_data, new);
|
|
|
|
#endif
|
2024-08-02 23:08:16 -07:00
|
|
|
if (rc)
|
|
|
|
goto err;
|
|
|
|
} else {
|
|
|
|
new->textlen = textlen;
|
|
|
|
new->text = kstrdup(text, GFP_KERNEL);
|
|
|
|
if (!new->text) {
|
|
|
|
rc = -ENOMEM;
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
rc = ipe_parse_policy(new);
|
|
|
|
if (rc)
|
|
|
|
goto err;
|
|
|
|
|
|
|
|
return new;
|
|
|
|
err:
|
|
|
|
ipe_free_policy(new);
|
|
|
|
return ERR_PTR(rc);
|
|
|
|
}
|
2024-08-02 23:08:22 -07:00
|
|
|
|
|
|
|
/**
|
|
|
|
* ipe_set_active_pol() - Make @p the active policy.
|
|
|
|
* @p: Supplies a pointer to the policy to make active.
|
|
|
|
*
|
|
|
|
* Context: Requires root->i_rwsem, which i_private has the policy, to be held.
|
|
|
|
* Return:
|
|
|
|
* * %0 - Success
|
|
|
|
* * %-EINVAL - New active policy version is invalid
|
|
|
|
*/
|
|
|
|
int ipe_set_active_pol(const struct ipe_policy *p)
|
|
|
|
{
|
|
|
|
struct ipe_policy *ap = NULL;
|
|
|
|
|
|
|
|
mutex_lock(&ipe_policy_lock);
|
|
|
|
|
|
|
|
ap = rcu_dereference_protected(ipe_active_policy,
|
|
|
|
lockdep_is_held(&ipe_policy_lock));
|
|
|
|
if (ap == p) {
|
|
|
|
mutex_unlock(&ipe_policy_lock);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
if (ap && ver_to_u64(ap) > ver_to_u64(p)) {
|
|
|
|
mutex_unlock(&ipe_policy_lock);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
rcu_assign_pointer(ipe_active_policy, p);
|
audit,ipe: add IPE auditing support
Users of IPE require a way to identify when and why an operation fails,
allowing them to both respond to violations of policy and be notified
of potentially malicious actions on their systems with respect to IPE
itself.
This patch introduces 3 new audit events.
AUDIT_IPE_ACCESS(1420) indicates the result of an IPE policy evaluation
of a resource.
AUDIT_IPE_CONFIG_CHANGE(1421) indicates the current active IPE policy
has been changed to another loaded policy.
AUDIT_IPE_POLICY_LOAD(1422) indicates a new IPE policy has been loaded
into the kernel.
This patch also adds support for success auditing, allowing users to
identify why an allow decision was made for a resource. However, it is
recommended to use this option with caution, as it is quite noisy.
Here are some examples of the new audit record types:
AUDIT_IPE_ACCESS(1420):
audit: AUDIT1420 ipe_op=EXECUTE ipe_hook=BPRM_CHECK enforcing=1
pid=297 comm="sh" path="/root/vol/bin/hello" dev="tmpfs"
ino=3897 rule="op=EXECUTE boot_verified=TRUE action=ALLOW"
audit: AUDIT1420 ipe_op=EXECUTE ipe_hook=BPRM_CHECK enforcing=1
pid=299 comm="sh" path="/mnt/ipe/bin/hello" dev="dm-0"
ino=2 rule="DEFAULT action=DENY"
audit: AUDIT1420 ipe_op=EXECUTE ipe_hook=BPRM_CHECK enforcing=1
pid=300 path="/tmp/tmpdp2h1lub/deny/bin/hello" dev="tmpfs"
ino=131 rule="DEFAULT action=DENY"
The above three records were generated when the active IPE policy only
allows binaries from the initramfs to run. The three identical `hello`
binary were placed at different locations, only the first hello from
the rootfs(initramfs) was allowed.
Field ipe_op followed by the IPE operation name associated with the log.
Field ipe_hook followed by the name of the LSM hook that triggered the IPE
event.
Field enforcing followed by the enforcement state of IPE. (it will be
introduced in the next commit)
Field pid followed by the pid of the process that triggered the IPE
event.
Field comm followed by the command line program name of the process that
triggered the IPE event.
Field path followed by the file's path name.
Field dev followed by the device name as found in /dev where the file is
from.
Note that for device mappers it will use the name `dm-X` instead of
the name in /dev/mapper.
For a file in a temp file system, which is not from a device, it will use
`tmpfs` for the field.
The implementation of this part is following another existing use case
LSM_AUDIT_DATA_INODE in security/lsm_audit.c
Field ino followed by the file's inode number.
Field rule followed by the IPE rule made the access decision. The whole
rule must be audited because the decision is based on the combination of
all property conditions in the rule.
Along with the syscall audit event, user can know why a blocked
happened. For example:
audit: AUDIT1420 ipe_op=EXECUTE ipe_hook=BPRM_CHECK enforcing=1
pid=2138 comm="bash" path="/mnt/ipe/bin/hello" dev="dm-0"
ino=2 rule="DEFAULT action=DENY"
audit[1956]: SYSCALL arch=c000003e syscall=59
success=no exit=-13 a0=556790138df0 a1=556790135390 a2=5567901338b0
a3=ab2a41a67f4f1f4e items=1 ppid=147 pid=1956 auid=4294967295 uid=0
gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0
ses=4294967295 comm="bash" exe="/usr/bin/bash" key=(null)
The above two records showed bash used execve to run "hello" and got
blocked by IPE. Note that the IPE records are always prior to a SYSCALL
record.
AUDIT_IPE_CONFIG_CHANGE(1421):
audit: AUDIT1421
old_active_pol_name="Allow_All" old_active_pol_version=0.0.0
old_policy_digest=sha256:E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649
new_active_pol_name="boot_verified" new_active_pol_version=0.0.0
new_policy_digest=sha256:820EEA5B40CA42B51F68962354BA083122A20BB846F
auid=4294967295 ses=4294967295 lsm=ipe res=1
The above record showed the current IPE active policy switch from
`Allow_All` to `boot_verified` along with the version and the hash
digest of the two policies. Note IPE can only have one policy active
at a time, all access decision evaluation is based on the current active
policy.
The normal procedure to deploy a policy is loading the policy to deploy
into the kernel first, then switch the active policy to it.
AUDIT_IPE_POLICY_LOAD(1422):
audit: AUDIT1422 policy_name="boot_verified" policy_version=0.0.0
policy_digest=sha256:820EEA5B40CA42B51F68962354BA083122A20BB846F2676
auid=4294967295 ses=4294967295 lsm=ipe res=1
The above record showed a new policy has been loaded into the kernel
with the policy name, policy version and policy hash.
Signed-off-by: Deven Bowers <deven.desai@linux.microsoft.com>
Signed-off-by: Fan Wu <wufan@linux.microsoft.com>
[PM: subject line tweak]
Signed-off-by: Paul Moore <paul@paul-moore.com>
2024-08-02 23:08:23 -07:00
|
|
|
ipe_audit_policy_activation(ap, p);
|
2024-08-02 23:08:22 -07:00
|
|
|
mutex_unlock(&ipe_policy_lock);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|