* Re: [RFC PATCH 1/2] ima: Implement support for uncompressed module appended signatures
From: Lakshmi Ramasubramanian @ 2020-02-06 17:07 UTC (permalink / raw)
To: Eric Snowberg, zohar, dmitry.kasatkin, jmorris, serge
Cc: dhowells, geert, gregkh, nayna, tglx, bauerman, mpe,
linux-integrity, linux-security-module, linux-kernel
In-Reply-To: <20200206164226.24875-2-eric.snowberg@oracle.com>
On 2/6/2020 8:42 AM, Eric Snowberg wrote:
>
> @@ -31,6 +32,7 @@ static const char * const keyring_name[INTEGRITY_KEYRING_MAX] = {
> ".ima",
> #endif
> ".platform",
> + ".builtin_trusted_keys",
> };
>
> #ifdef CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY
> @@ -45,8 +47,11 @@ static struct key *integrity_keyring_from_id(const unsigned int id)
> return ERR_PTR(-EINVAL);
>
> if (!keyring[id]) {
> - keyring[id] =
> - request_key(&key_type_keyring, keyring_name[id], NULL);
> + if (id == INTEGRITY_KEYRING_KERNEL)
> + keyring[id] = VERIFY_USE_SECONDARY_KEYRING;
Since "Built-In Trusted Keyring" or "Secondary Trusted Keyring" is used,
would it be more appropriate to name this identifier
INTEGRITY_KEYRING_BUILTIN_OR_SECONDARY?
> diff --git a/security/integrity/integrity.h b/security/integrity/integrity.h
> index 73fc286834d7..63f0e6bff0e0 100644
> --- a/security/integrity/integrity.h
> +++ b/security/integrity/integrity.h
> @@ -145,7 +145,8 @@ int integrity_kernel_read(struct file *file, loff_t offset,
> #define INTEGRITY_KEYRING_EVM 0
> #define INTEGRITY_KEYRING_IMA 1
> #define INTEGRITY_KEYRING_PLATFORM 2
> -#define INTEGRITY_KEYRING_MAX 3
> +#define INTEGRITY_KEYRING_KERNEL 3
> +#define INTEGRITY_KEYRING_MAX 4
-lakshmi
^ permalink raw reply
* Re: [RFC PATCH 1/2] ima: Implement support for uncompressed module appended signatures
From: Eric Snowberg @ 2020-02-06 17:30 UTC (permalink / raw)
To: Lakshmi Ramasubramanian
Cc: zohar, dmitry.kasatkin, jmorris, serge, dhowells, geert, gregkh,
nayna, tglx, bauerman, mpe, linux-integrity,
linux-security-module, linux-kernel
In-Reply-To: <fda8b3e4-e3aa-a83a-0ddc-8ec096e67316@linux.microsoft.com>
> On Feb 6, 2020, at 10:07 AM, Lakshmi Ramasubramanian <nramas@linux.microsoft.com> wrote:
>
> On 2/6/2020 8:42 AM, Eric Snowberg wrote:
>
>> @@ -31,6 +32,7 @@ static const char * const keyring_name[INTEGRITY_KEYRING_MAX] = {
>> ".ima",
>> #endif
>> ".platform",
>> + ".builtin_trusted_keys",
>> };
>> #ifdef CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY
>> @@ -45,8 +47,11 @@ static struct key *integrity_keyring_from_id(const unsigned int id)
>> return ERR_PTR(-EINVAL);
>> if (!keyring[id]) {
>> - keyring[id] =
>> - request_key(&key_type_keyring, keyring_name[id], NULL);
>> + if (id == INTEGRITY_KEYRING_KERNEL)
>> + keyring[id] = VERIFY_USE_SECONDARY_KEYRING;
>
> Since "Built-In Trusted Keyring" or "Secondary Trusted Keyring" is used, would it be more appropriate to name this identifier INTEGRITY_KEYRING_BUILTIN_OR_SECONDARY?
I’m open to changing INTEGRITY_KEYRING_KERNEL to INTEGRITY_KEYRING_BUILTIN_OR_SECONDARY if that seems more appropriate.
^ permalink raw reply
* Re: [PATCH v5 01/10] capabilities: introduce CAP_PERFMON to kernel and user space
From: Alexey Budankov @ 2020-02-06 18:03 UTC (permalink / raw)
To: Stephen Smalley, Serge Hallyn, James Morris
Cc: Alexei Starovoitov, Peter Zijlstra, Arnaldo Carvalho de Melo,
Ingo Molnar, jani.nikula@linux.intel.com,
joonas.lahtinen@linux.intel.com, rodrigo.vivi@intel.com,
benh@kernel.crashing.org, Paul Mackerras, Michael Ellerman,
Will Deacon, Mark Rutland, Robert Richter, Alexei Starovoitov,
Jiri Olsa, Andi Kleen, Stephane Eranian, Igor Lubashev,
Alexander Shishkin, Namhyung Kim, Song Liu, Lionel Landwerlin,
Thomas Gleixner, linux-kernel,
linux-security-module@vger.kernel.org, selinux@vger.kernel.org,
intel-gfx@lists.freedesktop.org, linux-parisc@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-arm-kernel,
linux-perf-users@vger.kernel.org, oprofile-list, Andy Lutomirski
In-Reply-To: <ac0dbab7-de47-ee34-bb88-4c43d3538b7d@linux.intel.com>
On 22.01.2020 17:25, Alexey Budankov wrote:
>
> On 22.01.2020 17:07, Stephen Smalley wrote:
>> On 1/22/20 5:45 AM, Alexey Budankov wrote:
>>>
>>> On 21.01.2020 21:27, Alexey Budankov wrote:
>>>>
>>>> On 21.01.2020 20:55, Alexei Starovoitov wrote:
>>>>> On Tue, Jan 21, 2020 at 9:31 AM Alexey Budankov
>>>>> <alexey.budankov@linux.intel.com> wrote:
>>>>>>
>>>>>>
>>>>>> On 21.01.2020 17:43, Stephen Smalley wrote:
>>>>>>> On 1/20/20 6:23 AM, Alexey Budankov wrote:
>>>>>>>>
>>>>>>>> Introduce CAP_PERFMON capability designed to secure system performance
>>>>>>>> monitoring and observability operations so that CAP_PERFMON would assist
>>>>>>>> CAP_SYS_ADMIN capability in its governing role for perf_events, i915_perf
>>>>>>>> and other performance monitoring and observability subsystems.
>>>>>>>>
>>>>>>>> CAP_PERFMON intends to harden system security and integrity during system
>>>>>>>> performance monitoring and observability operations by decreasing attack
>>>>>>>> surface that is available to a CAP_SYS_ADMIN privileged process [1].
>>>>>>>> Providing access to system performance monitoring and observability
>>>>>>>> operations under CAP_PERFMON capability singly, without the rest of
>>>>>>>> CAP_SYS_ADMIN credentials, excludes chances to misuse the credentials and
>>>>>>>> makes operation more secure.
>>>>>>>>
>>>>>>>> CAP_PERFMON intends to take over CAP_SYS_ADMIN credentials related to
>>>>>>>> system performance monitoring and observability operations and balance
>>>>>>>> amount of CAP_SYS_ADMIN credentials following the recommendations in the
>>>>>>>> capabilities man page [1] for CAP_SYS_ADMIN: "Note: this capability is
>>>>>>>> overloaded; see Notes to kernel developers, below."
>>>>>>>>
>>>>>>>> Although the software running under CAP_PERFMON can not ensure avoidance
>>>>>>>> of related hardware issues, the software can still mitigate these issues
>>>>>>>> following the official embargoed hardware issues mitigation procedure [2].
>>>>>>>> The bugs in the software itself could be fixed following the standard
>>>>>>>> kernel development process [3] to maintain and harden security of system
>>>>>>>> performance monitoring and observability operations.
>>>>>>>>
>>>>>>>> [1] http://man7.org/linux/man-pages/man7/capabilities.7.html
>>>>>>>> [2] https://www.kernel.org/doc/html/latest/process/embargoed-hardware-issues.html
>>>>>>>> [3] https://www.kernel.org/doc/html/latest/admin-guide/security-bugs.html
<SNIP>
>>>>>>>>
>>>>>>>> Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com>
>>>>>>>
>>>>>>> Why _noaudit()? Normally only used when a permission failure is non-fatal to the operation. Otherwise, we want the audit message.
>>>
>>> So far so good, I suggest using the simplest version for v6:
>>>
>>> static inline bool perfmon_capable(void)
>>> {
>>> return capable(CAP_PERFMON) || capable(CAP_SYS_ADMIN);
>>> }
>>>
>>> It keeps the implementation simple and readable. The implementation is more
>>> performant in the sense of calling the API - one capable() call for CAP_PERFMON
>>> privileged process.
>>>
>>> Yes, it bloats audit log for CAP_SYS_ADMIN privileged and unprivileged processes,
>>> but this bloating also advertises and leverages using more secure CAP_PERFMON
>>> based approach to use perf_event_open system call.
>>
>> I can live with that. We just need to document that when you see both a CAP_PERFMON and a CAP_SYS_ADMIN audit message for a process, try only allowing CAP_PERFMON first and see if that resolves the issue. We have a similar issue with CAP_DAC_READ_SEARCH versus CAP_DAC_OVERRIDE.
>
> perf security [1] document can be updated, at least, to align and document
> this audit logging specifics.
And I plan to update the document right after this patch set is accepted.
Feel free to let me know of the places in the kernel docs that also
require update w.r.t CAP_PERFMON extension.
~Alexey
>
> ~Alexey
>
> [1] https://www.kernel.org/doc/html/latest/admin-guide/perf-security.html
>
^ permalink raw reply
* Re: [RFC PATCH 1/2] ima: Implement support for uncompressed module appended signatures
From: Mimi Zohar @ 2020-02-06 18:05 UTC (permalink / raw)
To: Eric Snowberg, dmitry.kasatkin, jmorris, serge
Cc: dhowells, geert, gregkh, nayna, tglx, bauerman, mpe,
linux-integrity, linux-security-module, linux-kernel
In-Reply-To: <20200206164226.24875-2-eric.snowberg@oracle.com>
Hi Eric,
On Thu, 2020-02-06 at 11:42 -0500, Eric Snowberg wrote:
> Currently IMA can validate compressed modules containing appended
> signatures. This adds the ability to also validate uncompressed
> modules when appraise_type=imasig|modsig.
>
> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
Your patch description in no way matches the code.
Mimi
> ---
> security/integrity/digsig.c | 9 +++++++--
> security/integrity/ima/ima_appraise.c | 3 +++
> security/integrity/integrity.h | 3 ++-
> 3 files changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/security/integrity/digsig.c b/security/integrity/digsig.c
> index ea1aae3d07b3..5e0c4d04ab9d 100644
> --- a/security/integrity/digsig.c
> +++ b/security/integrity/digsig.c
> @@ -15,6 +15,7 @@
> #include <linux/key-type.h>
> #include <linux/digsig.h>
> #include <linux/vmalloc.h>
> +#include <linux/verification.h>
> #include <crypto/public_key.h>
> #include <keys/system_keyring.h>
>
> @@ -31,6 +32,7 @@ static const char * const keyring_name[INTEGRITY_KEYRING_MAX] = {
> ".ima",
> #endif
> ".platform",
> + ".builtin_trusted_keys",
> };
>
> #ifdef CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY
> @@ -45,8 +47,11 @@ static struct key *integrity_keyring_from_id(const unsigned int id)
> return ERR_PTR(-EINVAL);
>
> if (!keyring[id]) {
> - keyring[id] =
> - request_key(&key_type_keyring, keyring_name[id], NULL);
> + if (id == INTEGRITY_KEYRING_KERNEL)
> + keyring[id] = VERIFY_USE_SECONDARY_KEYRING;
> + else
> + keyring[id] = request_key(&key_type_keyring,
> + keyring_name[id], NULL);
> if (IS_ERR(keyring[id])) {
> int err = PTR_ERR(keyring[id]);
> pr_err("no %s keyring: %d\n", keyring_name[id], err);
> diff --git a/security/integrity/ima/ima_appraise.c b/security/integrity/ima/ima_appraise.c
> index 300c8d2943c5..4c009c55d620 100644
> --- a/security/integrity/ima/ima_appraise.c
> +++ b/security/integrity/ima/ima_appraise.c
> @@ -294,6 +294,9 @@ static int modsig_verify(enum ima_hooks func, const struct modsig *modsig,
> func == KEXEC_KERNEL_CHECK)
> rc = integrity_modsig_verify(INTEGRITY_KEYRING_PLATFORM,
> modsig);
> + if (rc && func == MODULE_CHECK)
> + rc = integrity_modsig_verify(INTEGRITY_KEYRING_KERNEL, modsig);
> +
> if (rc) {
> *cause = "invalid-signature";
> *status = INTEGRITY_FAIL;
> diff --git a/security/integrity/integrity.h b/security/integrity/integrity.h
> index 73fc286834d7..63f0e6bff0e0 100644
> --- a/security/integrity/integrity.h
> +++ b/security/integrity/integrity.h
> @@ -145,7 +145,8 @@ int integrity_kernel_read(struct file *file, loff_t offset,
> #define INTEGRITY_KEYRING_EVM 0
> #define INTEGRITY_KEYRING_IMA 1
> #define INTEGRITY_KEYRING_PLATFORM 2
> -#define INTEGRITY_KEYRING_MAX 3
> +#define INTEGRITY_KEYRING_KERNEL 3
> +#define INTEGRITY_KEYRING_MAX 4
>
> extern struct dentry *integrity_dir;
>
^ permalink raw reply
* Re: [PATCH v6 01/10] capabilities: introduce CAP_PERFMON to kernel and user space
From: Stephen Smalley @ 2020-02-06 18:23 UTC (permalink / raw)
To: Alexey Budankov, James Morris, Serge Hallyn, Peter Zijlstra,
Arnaldo Carvalho de Melo, Ingo Molnar,
joonas.lahtinen@linux.intel.com, Alexei Starovoitov, Will Deacon,
Paul Mackerras, Michael Ellerman
Cc: Andi Kleen, Thomas Gleixner, Stephane Eranian, Igor Lubashev,
Jiri Olsa, linux-kernel, intel-gfx@lists.freedesktop.org,
linux-security-module@vger.kernel.org, selinux@vger.kernel.org,
linux-arm-kernel, linuxppc-dev@lists.ozlabs.org,
linux-parisc@vger.kernel.org, oprofile-list
In-Reply-To: <a4c5da70-b6d1-b133-9b64-34e164834b03@linux.intel.com>
On 2/5/20 12:30 PM, Alexey Budankov wrote:
>
> Introduce CAP_PERFMON capability designed to secure system performance
> monitoring and observability operations so that CAP_PERFMON would assist
> CAP_SYS_ADMIN capability in its governing role for performance monitoring
> and observability subsystems.
>
> CAP_PERFMON hardens system security and integrity during performance
> monitoring and observability operations by decreasing attack surface that
> is available to a CAP_SYS_ADMIN privileged process [2]. Providing the access
> to system performance monitoring and observability operations under CAP_PERFMON
> capability singly, without the rest of CAP_SYS_ADMIN credentials, excludes
> chances to misuse the credentials and makes the operation more secure.
> Thus, CAP_PERFMON implements the principal of least privilege for performance
> monitoring and observability operations (POSIX IEEE 1003.1e: 2.2.2.39 principle
> of least privilege: A security design principle that states that a process
> or program be granted only those privileges (e.g., capabilities) necessary
> to accomplish its legitimate function, and only for the time that such
> privileges are actually required)
>
> CAP_PERFMON meets the demand to secure system performance monitoring and
> observability operations for adoption in security sensitive, restricted,
> multiuser production environments (e.g. HPC clusters, cloud and virtual compute
> environments), where root or CAP_SYS_ADMIN credentials are not available to
> mass users of a system, and securely unblocks accessibility of system performance monitoring and observability operations beyond root and CAP_SYS_ADMIN use cases.
>
> CAP_PERFMON takes over CAP_SYS_ADMIN credentials related to system performance
> monitoring and observability operations and balances amount of CAP_SYS_ADMIN
> credentials following the recommendations in the capabilities man page [1]
> for CAP_SYS_ADMIN: "Note: this capability is overloaded; see Notes to kernel
> developers, below." For backward compatibility reasons access to system
> performance monitoring and observability subsystems of the kernel remains
> open for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN capability
> usage for secure system performance monitoring and observability operations
> is discouraged with respect to the designed CAP_PERFMON capability.
>
> Although the software running under CAP_PERFMON can not ensure avoidance
> of related hardware issues, the software can still mitigate these issues
> following the official hardware issues mitigation procedure [2]. The bugs
> in the software itself can be fixed following the standard kernel development
> process [3] to maintain and harden security of system performance monitoring
> and observability operations.
>
> [1] http://man7.org/linux/man-pages/man7/capabilities.7.html
> [2] https://www.kernel.org/doc/html/latest/process/embargoed-hardware-issues.html
> [3] https://www.kernel.org/doc/html/latest/admin-guide/security-bugs.html
>
> Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com>
This will require a small update to the selinux-testsuite to correctly
reflect the new capability requirements, but that's easy enough.
Acked-by: Stephen Smalley <sds@tycho.nsa.gov>
> ---
> include/linux/capability.h | 4 ++++
> include/uapi/linux/capability.h | 8 +++++++-
> security/selinux/include/classmap.h | 4 ++--
> 3 files changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/capability.h b/include/linux/capability.h
> index ecce0f43c73a..027d7e4a853b 100644
> --- a/include/linux/capability.h
> +++ b/include/linux/capability.h
> @@ -251,6 +251,10 @@ extern bool privileged_wrt_inode_uidgid(struct user_namespace *ns, const struct
> extern bool capable_wrt_inode_uidgid(const struct inode *inode, int cap);
> extern bool file_ns_capable(const struct file *file, struct user_namespace *ns, int cap);
> extern bool ptracer_capable(struct task_struct *tsk, struct user_namespace *ns);
> +static inline bool perfmon_capable(void)
> +{
> + return capable(CAP_PERFMON) || capable(CAP_SYS_ADMIN);
> +}
>
> /* audit system wants to get cap info from files as well */
> extern int get_vfs_caps_from_disk(const struct dentry *dentry, struct cpu_vfs_cap_data *cpu_caps);
> diff --git a/include/uapi/linux/capability.h b/include/uapi/linux/capability.h
> index 240fdb9a60f6..8b416e5f3afa 100644
> --- a/include/uapi/linux/capability.h
> +++ b/include/uapi/linux/capability.h
> @@ -366,8 +366,14 @@ struct vfs_ns_cap_data {
>
> #define CAP_AUDIT_READ 37
>
> +/*
> + * Allow system performance and observability privileged operations
> + * using perf_events, i915_perf and other kernel subsystems
> + */
> +
> +#define CAP_PERFMON 38
>
> -#define CAP_LAST_CAP CAP_AUDIT_READ
> +#define CAP_LAST_CAP CAP_PERFMON
>
> #define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)
>
> diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h
> index 7db24855e12d..c599b0c2b0e7 100644
> --- a/security/selinux/include/classmap.h
> +++ b/security/selinux/include/classmap.h
> @@ -27,9 +27,9 @@
> "audit_control", "setfcap"
>
> #define COMMON_CAP2_PERMS "mac_override", "mac_admin", "syslog", \
> - "wake_alarm", "block_suspend", "audit_read"
> + "wake_alarm", "block_suspend", "audit_read", "perfmon"
>
> -#if CAP_LAST_CAP > CAP_AUDIT_READ
> +#if CAP_LAST_CAP > CAP_PERFMON
> #error New capability defined, please update COMMON_CAP2_PERMS.
> #endif
>
>
^ permalink raw reply
* Re: [PATCH v6 01/10] capabilities: introduce CAP_PERFMON to kernel and user space
From: Alexey Budankov @ 2020-02-06 18:26 UTC (permalink / raw)
To: Stephen Smalley, James Morris, Serge Hallyn, Peter Zijlstra,
Arnaldo Carvalho de Melo, Ingo Molnar,
joonas.lahtinen@linux.intel.com, Alexei Starovoitov, Will Deacon,
Paul Mackerras, Michael Ellerman
Cc: Andi Kleen, Thomas Gleixner, Stephane Eranian, Igor Lubashev,
Jiri Olsa, linux-kernel, intel-gfx@lists.freedesktop.org,
linux-security-module@vger.kernel.org, selinux@vger.kernel.org,
linux-arm-kernel, linuxppc-dev@lists.ozlabs.org,
linux-parisc@vger.kernel.org, oprofile-list
In-Reply-To: <5be0f67c-17e2-7861-37f3-a0f8a82be8f0@tycho.nsa.gov>
On 06.02.2020 21:23, Stephen Smalley wrote:
> On 2/5/20 12:30 PM, Alexey Budankov wrote:
>>
>> Introduce CAP_PERFMON capability designed to secure system performance
>> monitoring and observability operations so that CAP_PERFMON would assist
>> CAP_SYS_ADMIN capability in its governing role for performance monitoring
>> and observability subsystems.
>>
>> CAP_PERFMON hardens system security and integrity during performance
>> monitoring and observability operations by decreasing attack surface that
>> is available to a CAP_SYS_ADMIN privileged process [2]. Providing the access
>> to system performance monitoring and observability operations under CAP_PERFMON
>> capability singly, without the rest of CAP_SYS_ADMIN credentials, excludes
>> chances to misuse the credentials and makes the operation more secure.
>> Thus, CAP_PERFMON implements the principal of least privilege for performance
>> monitoring and observability operations (POSIX IEEE 1003.1e: 2.2.2.39 principle
>> of least privilege: A security design principle that states that a process
>> or program be granted only those privileges (e.g., capabilities) necessary
>> to accomplish its legitimate function, and only for the time that such
>> privileges are actually required)
>>
>> CAP_PERFMON meets the demand to secure system performance monitoring and
>> observability operations for adoption in security sensitive, restricted,
>> multiuser production environments (e.g. HPC clusters, cloud and virtual compute
>> environments), where root or CAP_SYS_ADMIN credentials are not available to
>> mass users of a system, and securely unblocks accessibility of system performance monitoring and observability operations beyond root and CAP_SYS_ADMIN use cases.
>>
>> CAP_PERFMON takes over CAP_SYS_ADMIN credentials related to system performance
>> monitoring and observability operations and balances amount of CAP_SYS_ADMIN
>> credentials following the recommendations in the capabilities man page [1]
>> for CAP_SYS_ADMIN: "Note: this capability is overloaded; see Notes to kernel
>> developers, below." For backward compatibility reasons access to system
>> performance monitoring and observability subsystems of the kernel remains
>> open for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN capability
>> usage for secure system performance monitoring and observability operations
>> is discouraged with respect to the designed CAP_PERFMON capability.
>>
>> Although the software running under CAP_PERFMON can not ensure avoidance
>> of related hardware issues, the software can still mitigate these issues
>> following the official hardware issues mitigation procedure [2]. The bugs
>> in the software itself can be fixed following the standard kernel development
>> process [3] to maintain and harden security of system performance monitoring
>> and observability operations.
>>
>> [1] http://man7.org/linux/man-pages/man7/capabilities.7.html
>> [2] https://www.kernel.org/doc/html/latest/process/embargoed-hardware-issues.html
>> [3] https://www.kernel.org/doc/html/latest/admin-guide/security-bugs.html
>>
>> Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com>
>
> This will require a small update to the selinux-testsuite to correctly reflect the new capability requirements, but that's easy enough.
Is the suite a part of the kernel sources or something else?
~Alexey
>
> Acked-by: Stephen Smalley <sds@tycho.nsa.gov>
>
>> ---
>> include/linux/capability.h | 4 ++++
>> include/uapi/linux/capability.h | 8 +++++++-
>> security/selinux/include/classmap.h | 4 ++--
>> 3 files changed, 13 insertions(+), 3 deletions(-)
>>
>> diff --git a/include/linux/capability.h b/include/linux/capability.h
>> index ecce0f43c73a..027d7e4a853b 100644
>> --- a/include/linux/capability.h
>> +++ b/include/linux/capability.h
>> @@ -251,6 +251,10 @@ extern bool privileged_wrt_inode_uidgid(struct user_namespace *ns, const struct
>> extern bool capable_wrt_inode_uidgid(const struct inode *inode, int cap);
>> extern bool file_ns_capable(const struct file *file, struct user_namespace *ns, int cap);
>> extern bool ptracer_capable(struct task_struct *tsk, struct user_namespace *ns);
>> +static inline bool perfmon_capable(void)
>> +{
>> + return capable(CAP_PERFMON) || capable(CAP_SYS_ADMIN);
>> +}
>> /* audit system wants to get cap info from files as well */
>> extern int get_vfs_caps_from_disk(const struct dentry *dentry, struct cpu_vfs_cap_data *cpu_caps);
>> diff --git a/include/uapi/linux/capability.h b/include/uapi/linux/capability.h
>> index 240fdb9a60f6..8b416e5f3afa 100644
>> --- a/include/uapi/linux/capability.h
>> +++ b/include/uapi/linux/capability.h
>> @@ -366,8 +366,14 @@ struct vfs_ns_cap_data {
>> #define CAP_AUDIT_READ 37
>> +/*
>> + * Allow system performance and observability privileged operations
>> + * using perf_events, i915_perf and other kernel subsystems
>> + */
>> +
>> +#define CAP_PERFMON 38
>> -#define CAP_LAST_CAP CAP_AUDIT_READ
>> +#define CAP_LAST_CAP CAP_PERFMON
>> #define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)
>> diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h
>> index 7db24855e12d..c599b0c2b0e7 100644
>> --- a/security/selinux/include/classmap.h
>> +++ b/security/selinux/include/classmap.h
>> @@ -27,9 +27,9 @@
>> "audit_control", "setfcap"
>> #define COMMON_CAP2_PERMS "mac_override", "mac_admin", "syslog", \
>> - "wake_alarm", "block_suspend", "audit_read"
>> + "wake_alarm", "block_suspend", "audit_read", "perfmon"
>> -#if CAP_LAST_CAP > CAP_AUDIT_READ
>> +#if CAP_LAST_CAP > CAP_PERFMON
>> #error New capability defined, please update COMMON_CAP2_PERMS.
>> #endif
>>
>
^ permalink raw reply
* Re: [PATCH v6 01/10] capabilities: introduce CAP_PERFMON to kernel and user space
From: Stephen Smalley @ 2020-02-06 18:30 UTC (permalink / raw)
To: Alexey Budankov, James Morris, Serge Hallyn, Peter Zijlstra,
Arnaldo Carvalho de Melo, Ingo Molnar,
joonas.lahtinen@linux.intel.com, Alexei Starovoitov, Will Deacon,
Paul Mackerras, Michael Ellerman
Cc: Andi Kleen, Thomas Gleixner, Stephane Eranian, Igor Lubashev,
Jiri Olsa, linux-kernel, intel-gfx@lists.freedesktop.org,
linux-security-module@vger.kernel.org, selinux@vger.kernel.org,
linux-arm-kernel, linuxppc-dev@lists.ozlabs.org,
linux-parisc@vger.kernel.org, oprofile-list
In-Reply-To: <1bcb4cb1-98c4-cc1a-b8e3-fd8a0e1e606f@linux.intel.com>
On 2/6/20 1:26 PM, Alexey Budankov wrote:
>
> On 06.02.2020 21:23, Stephen Smalley wrote:
>> On 2/5/20 12:30 PM, Alexey Budankov wrote:
>>>
>>> Introduce CAP_PERFMON capability designed to secure system performance
>>> monitoring and observability operations so that CAP_PERFMON would assist
>>> CAP_SYS_ADMIN capability in its governing role for performance monitoring
>>> and observability subsystems.
>>>
>>> CAP_PERFMON hardens system security and integrity during performance
>>> monitoring and observability operations by decreasing attack surface that
>>> is available to a CAP_SYS_ADMIN privileged process [2]. Providing the access
>>> to system performance monitoring and observability operations under CAP_PERFMON
>>> capability singly, without the rest of CAP_SYS_ADMIN credentials, excludes
>>> chances to misuse the credentials and makes the operation more secure.
>>> Thus, CAP_PERFMON implements the principal of least privilege for performance
>>> monitoring and observability operations (POSIX IEEE 1003.1e: 2.2.2.39 principle
>>> of least privilege: A security design principle that states that a process
>>> or program be granted only those privileges (e.g., capabilities) necessary
>>> to accomplish its legitimate function, and only for the time that such
>>> privileges are actually required)
>>>
>>> CAP_PERFMON meets the demand to secure system performance monitoring and
>>> observability operations for adoption in security sensitive, restricted,
>>> multiuser production environments (e.g. HPC clusters, cloud and virtual compute
>>> environments), where root or CAP_SYS_ADMIN credentials are not available to
>>> mass users of a system, and securely unblocks accessibility of system performance monitoring and observability operations beyond root and CAP_SYS_ADMIN use cases.
>>>
>>> CAP_PERFMON takes over CAP_SYS_ADMIN credentials related to system performance
>>> monitoring and observability operations and balances amount of CAP_SYS_ADMIN
>>> credentials following the recommendations in the capabilities man page [1]
>>> for CAP_SYS_ADMIN: "Note: this capability is overloaded; see Notes to kernel
>>> developers, below." For backward compatibility reasons access to system
>>> performance monitoring and observability subsystems of the kernel remains
>>> open for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN capability
>>> usage for secure system performance monitoring and observability operations
>>> is discouraged with respect to the designed CAP_PERFMON capability.
>>>
>>> Although the software running under CAP_PERFMON can not ensure avoidance
>>> of related hardware issues, the software can still mitigate these issues
>>> following the official hardware issues mitigation procedure [2]. The bugs
>>> in the software itself can be fixed following the standard kernel development
>>> process [3] to maintain and harden security of system performance monitoring
>>> and observability operations.
>>>
>>> [1] http://man7.org/linux/man-pages/man7/capabilities.7.html
>>> [2] https://www.kernel.org/doc/html/latest/process/embargoed-hardware-issues.html
>>> [3] https://www.kernel.org/doc/html/latest/admin-guide/security-bugs.html
>>>
>>> Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com>
>>
>> This will require a small update to the selinux-testsuite to correctly reflect the new capability requirements, but that's easy enough.
>
> Is the suite a part of the kernel sources or something else?
It is external,
https://github.com/SELinuxProject/selinux-testsuite
I wasn't suggesting that your patch be blocked on updating the
testsuite, just noting that it will need to be done.
^ permalink raw reply
* Re: [PATCH v6 01/10] capabilities: introduce CAP_PERFMON to kernel and user space
From: Alexey Budankov @ 2020-02-06 18:38 UTC (permalink / raw)
To: Stephen Smalley, James Morris, Serge Hallyn, Peter Zijlstra,
Arnaldo Carvalho de Melo, Ingo Molnar,
joonas.lahtinen@linux.intel.com, Alexei Starovoitov, Will Deacon,
Paul Mackerras, Michael Ellerman
Cc: Andi Kleen, Thomas Gleixner, Stephane Eranian, Igor Lubashev,
Jiri Olsa, linux-kernel, intel-gfx@lists.freedesktop.org,
linux-security-module@vger.kernel.org, selinux@vger.kernel.org,
linux-arm-kernel, linuxppc-dev@lists.ozlabs.org,
linux-parisc@vger.kernel.org, oprofile-list
In-Reply-To: <06cdca0e-65f2-b58d-a84e-5a1907aa9eb5@tycho.nsa.gov>
On 06.02.2020 21:30, Stephen Smalley wrote:
> On 2/6/20 1:26 PM, Alexey Budankov wrote:
>>
>> On 06.02.2020 21:23, Stephen Smalley wrote:
>>> On 2/5/20 12:30 PM, Alexey Budankov wrote:
>>>>
>>>> Introduce CAP_PERFMON capability designed to secure system performance
>>>> monitoring and observability operations so that CAP_PERFMON would assist
>>>> CAP_SYS_ADMIN capability in its governing role for performance monitoring
>>>> and observability subsystems.
>>>>
>>>> CAP_PERFMON hardens system security and integrity during performance
>>>> monitoring and observability operations by decreasing attack surface that
>>>> is available to a CAP_SYS_ADMIN privileged process [2]. Providing the access
>>>> to system performance monitoring and observability operations under CAP_PERFMON
>>>> capability singly, without the rest of CAP_SYS_ADMIN credentials, excludes
>>>> chances to misuse the credentials and makes the operation more secure.
>>>> Thus, CAP_PERFMON implements the principal of least privilege for performance
>>>> monitoring and observability operations (POSIX IEEE 1003.1e: 2.2.2.39 principle
>>>> of least privilege: A security design principle that states that a process
>>>> or program be granted only those privileges (e.g., capabilities) necessary
>>>> to accomplish its legitimate function, and only for the time that such
>>>> privileges are actually required)
>>>>
>>>> CAP_PERFMON meets the demand to secure system performance monitoring and
>>>> observability operations for adoption in security sensitive, restricted,
>>>> multiuser production environments (e.g. HPC clusters, cloud and virtual compute
>>>> environments), where root or CAP_SYS_ADMIN credentials are not available to
>>>> mass users of a system, and securely unblocks accessibility of system performance monitoring and observability operations beyond root and CAP_SYS_ADMIN use cases.
>>>>
>>>> CAP_PERFMON takes over CAP_SYS_ADMIN credentials related to system performance
>>>> monitoring and observability operations and balances amount of CAP_SYS_ADMIN
>>>> credentials following the recommendations in the capabilities man page [1]
>>>> for CAP_SYS_ADMIN: "Note: this capability is overloaded; see Notes to kernel
>>>> developers, below." For backward compatibility reasons access to system
>>>> performance monitoring and observability subsystems of the kernel remains
>>>> open for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN capability
>>>> usage for secure system performance monitoring and observability operations
>>>> is discouraged with respect to the designed CAP_PERFMON capability.
>>>>
>>>> Although the software running under CAP_PERFMON can not ensure avoidance
>>>> of related hardware issues, the software can still mitigate these issues
>>>> following the official hardware issues mitigation procedure [2]. The bugs
>>>> in the software itself can be fixed following the standard kernel development
>>>> process [3] to maintain and harden security of system performance monitoring
>>>> and observability operations.
>>>>
>>>> [1] http://man7.org/linux/man-pages/man7/capabilities.7.html
>>>> [2] https://www.kernel.org/doc/html/latest/process/embargoed-hardware-issues.html
>>>> [3] https://www.kernel.org/doc/html/latest/admin-guide/security-bugs.html
>>>>
>>>> Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com>
>>>
>>> This will require a small update to the selinux-testsuite to correctly reflect the new capability requirements, but that's easy enough.
>>
>> Is the suite a part of the kernel sources or something else?
>
> It is external,
> https://github.com/SELinuxProject/selinux-testsuite
>
> I wasn't suggesting that your patch be blocked on updating the testsuite, just noting that it will need to be done.
Ok. Thanks!
~Alexey
^ permalink raw reply
* Re: [RFC PATCH 1/2] ima: Implement support for uncompressed module appended signatures
From: Eric Snowberg @ 2020-02-06 19:01 UTC (permalink / raw)
To: Mimi Zohar
Cc: dmitry.kasatkin, jmorris, serge, dhowells, geert, gregkh, nayna,
tglx, bauerman, mpe, linux-integrity, linux-security-module,
linux-kernel
In-Reply-To: <1581012329.5585.439.camel@linux.ibm.com>
> On Feb 6, 2020, at 11:05 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
>
> On Thu, 2020-02-06 at 11:42 -0500, Eric Snowberg wrote:
>> Currently IMA can validate compressed modules containing appended
>> signatures. This adds the ability to also validate uncompressed
>> modules when appraise_type=imasig|modsig.
>>
>> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
>
> Your patch description in no way matches the code.
>
How about if I changed the description to the following:
Currently IMA can only validate compressed modules containing appended
signatures when appraise_type=imasig|modsig. An uncompressed module that
is internally signed must still be ima signed.
Add the ability to validate the uncompress module by validating it against
keys contained within the .builtin_trusted_keys keyring. Now when using a
policy such as:
appraise func=MODULE_CHECK appraise_type=imasig|modsig
It will load modules containing an appended signature when either compressed
or uncompressed.
>> ---
>> security/integrity/digsig.c | 9 +++++++--
>> security/integrity/ima/ima_appraise.c | 3 +++
>> security/integrity/integrity.h | 3 ++-
>> 3 files changed, 12 insertions(+), 3 deletions(-)
>>
>> diff --git a/security/integrity/digsig.c b/security/integrity/digsig.c
>> index ea1aae3d07b3..5e0c4d04ab9d 100644
>> --- a/security/integrity/digsig.c
>> +++ b/security/integrity/digsig.c
>> @@ -15,6 +15,7 @@
>> #include <linux/key-type.h>
>> #include <linux/digsig.h>
>> #include <linux/vmalloc.h>
>> +#include <linux/verification.h>
>> #include <crypto/public_key.h>
>> #include <keys/system_keyring.h>
>>
>> @@ -31,6 +32,7 @@ static const char * const keyring_name[INTEGRITY_KEYRING_MAX] = {
>> ".ima",
>> #endif
>> ".platform",
>> + ".builtin_trusted_keys",
>> };
>>
>> #ifdef CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY
>> @@ -45,8 +47,11 @@ static struct key *integrity_keyring_from_id(const unsigned int id)
>> return ERR_PTR(-EINVAL);
>>
>> if (!keyring[id]) {
>> - keyring[id] =
>> - request_key(&key_type_keyring, keyring_name[id], NULL);
>> + if (id == INTEGRITY_KEYRING_KERNEL)
>> + keyring[id] = VERIFY_USE_SECONDARY_KEYRING;
>> + else
>> + keyring[id] = request_key(&key_type_keyring,
>> + keyring_name[id], NULL);
>> if (IS_ERR(keyring[id])) {
>> int err = PTR_ERR(keyring[id]);
>> pr_err("no %s keyring: %d\n", keyring_name[id], err);
>> diff --git a/security/integrity/ima/ima_appraise.c b/security/integrity/ima/ima_appraise.c
>> index 300c8d2943c5..4c009c55d620 100644
>> --- a/security/integrity/ima/ima_appraise.c
>> +++ b/security/integrity/ima/ima_appraise.c
>> @@ -294,6 +294,9 @@ static int modsig_verify(enum ima_hooks func, const struct modsig *modsig,
>> func == KEXEC_KERNEL_CHECK)
>> rc = integrity_modsig_verify(INTEGRITY_KEYRING_PLATFORM,
>> modsig);
>> + if (rc && func == MODULE_CHECK)
>> + rc = integrity_modsig_verify(INTEGRITY_KEYRING_KERNEL, modsig);
>> +
>> if (rc) {
>> *cause = "invalid-signature";
>> *status = INTEGRITY_FAIL;
>> diff --git a/security/integrity/integrity.h b/security/integrity/integrity.h
>> index 73fc286834d7..63f0e6bff0e0 100644
>> --- a/security/integrity/integrity.h
>> +++ b/security/integrity/integrity.h
>> @@ -145,7 +145,8 @@ int integrity_kernel_read(struct file *file, loff_t offset,
>> #define INTEGRITY_KEYRING_EVM 0
>> #define INTEGRITY_KEYRING_IMA 1
>> #define INTEGRITY_KEYRING_PLATFORM 2
>> -#define INTEGRITY_KEYRING_MAX 3
>> +#define INTEGRITY_KEYRING_KERNEL 3
>> +#define INTEGRITY_KEYRING_MAX 4
>>
>> extern struct dentry *integrity_dir;
>>
>
^ permalink raw reply
* Re: [RFC PATCH 1/2] ima: Implement support for uncompressed module appended signatures
From: Mimi Zohar @ 2020-02-06 19:10 UTC (permalink / raw)
To: Eric Snowberg
Cc: dmitry.kasatkin, jmorris, serge, dhowells, geert, gregkh, nayna,
tglx, bauerman, mpe, linux-integrity, linux-security-module,
linux-kernel
In-Reply-To: <73919AC1-E13A-4B35-B811-B0FFBC7E8644@oracle.com>
On Thu, 2020-02-06 at 12:01 -0700, Eric Snowberg wrote:
> > On Feb 6, 2020, at 11:05 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> >
> > On Thu, 2020-02-06 at 11:42 -0500, Eric Snowberg wrote:
> >> Currently IMA can validate compressed modules containing appended
> >> signatures. This adds the ability to also validate uncompressed
> >> modules when appraise_type=imasig|modsig.
> >>
> >> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
> >
> > Your patch description in no way matches the code.
> >
>
> How about if I changed the description to the following:
>
> Currently IMA can only validate compressed modules containing appended
> signatures when appraise_type=imasig|modsig. An uncompressed module that
> is internally signed must still be ima signed.
>
> Add the ability to validate the uncompress module by validating it against
> keys contained within the .builtin_trusted_keys keyring. Now when using a
> policy such as:
>
> appraise func=MODULE_CHECK appraise_type=imasig|modsig
>
> It will load modules containing an appended signature when either compressed
> or uncompressed.
We - Nayna and I - will be commenting on the cover letter shortly. I
think that will help clarify the problem(s).
Mimi
^ permalink raw reply
* Re: [RFC PATCH 0/2] ima: uncompressed module appraisal support
From: Nayna @ 2020-02-06 20:22 UTC (permalink / raw)
To: Eric Snowberg, dmitry.kasatkin, jmorris, serge
Cc: zohar, dhowells, geert, gregkh, nayna, tglx, bauerman, mpe,
linux-integrity, linux-security-module, linux-kernel
In-Reply-To: <20200206164226.24875-1-eric.snowberg@oracle.com>
On 2/6/20 11:42 AM, Eric Snowberg wrote:
> When booting with either "ima_policy=secure_boot module.sig_enforce=1"
> or building a kernel with CONFIG_IMA_ARCH_POLICY and booting with
> "ima_policy=secure_boot", module loading behaves differently based on if
> the module is compressed or not. Originally when appraising a module
> with ima it had to be uncompressed and ima signed. Recent changes in 5.4
> have allowed internally signed modules to load [1]. But this only works
> if the internally signed module is compressed. The uncompressed module
> that is internally signed must still be ima signed. This patch series
> tries to bring the two in line.
We (Mimi and I) have been trying to understand the cover letter. It
seems "by internally signed" you are referring to modules signed with
build time generated keys.
Our interpretation of the cover letter is that IMA originally did not
support appended signatures and now does. Since the modules are signed
with build time generated keys, the signature verification still fails,
as the keys are only available on the .builtin keyring and not the .ima
keyring.
Lastly, there is nothing in these patches that indicate that the kernel
modules being compressed/uncompressed is related to the signature
verification.
Thanks & Regards,
- Nayna
^ permalink raw reply
* Re: [RFC PATCH 0/2] ima: uncompressed module appraisal support
From: Eric Snowberg @ 2020-02-06 21:40 UTC (permalink / raw)
To: Nayna
Cc: dmitry.kasatkin, jmorris, serge, Mimi Zohar, dhowells, geert,
gregkh, nayna, tglx, bauerman, mpe, linux-integrity,
Eric Snowberg, linux-security-module, linux-kernel
In-Reply-To: <5c246616-9a3a-3ed2-c1f9-f634cef511c9@linux.vnet.ibm.com>
> On Feb 6, 2020, at 1:22 PM, Nayna <nayna@linux.vnet.ibm.com> wrote:
>
>
> On 2/6/20 11:42 AM, Eric Snowberg wrote:
>> When booting with either "ima_policy=secure_boot module.sig_enforce=1"
>> or building a kernel with CONFIG_IMA_ARCH_POLICY and booting with
>> "ima_policy=secure_boot", module loading behaves differently based on if
>> the module is compressed or not. Originally when appraising a module
>> with ima it had to be uncompressed and ima signed. Recent changes in 5.4
>> have allowed internally signed modules to load [1]. But this only works
>> if the internally signed module is compressed. The uncompressed module
>> that is internally signed must still be ima signed. This patch series
>> tries to bring the two in line.
>
> We (Mimi and I) have been trying to understand the cover letter. It seems "by internally signed" you are referring to modules signed with build time generated keys.
I am referring to any module that includes an appended signature. They could be signed at build time or anytime afterwards using /usr/src/kernels/$(uname -r)/scripts/sign-file. As long as the public key is contained in the builtin kernel trusted keyring.
> Our interpretation of the cover letter is that IMA originally did not support appended signatures and now does.
Correct, before the changes added to 5.4 [1], it was not possible to have a digital signature based appraisal policy that worked with a compressed module. This is because you can’t ima sign a compressed module, since the signature would be lost by the time it gets to the init_module syscall. With the changes in [1] you can, if you include “modsig” to your policy, which allows the appended module to be checked instead.
> Since the modules are signed with build time generated keys, the signature verification still fails, as the keys are only available on the .builtin keyring and not the .ima keyring.
Currently the upstream code will fail if the module is uncompressed. If you compress the same module it will load with the current upstream code.
> Lastly, there is nothing in these patches that indicate that the kernel modules being compressed/uncompressed is related to the signature verification.
>
Basically if you have the following setup:
Kernel built with CONFIG_IMA_ARCH_POLICY or kernel booted with module.sig_enforce=1 along with the following ima policy:
appraise func=MODULE_CHECK appraise_type=imasig|modsig
If you have a module foo.ko that contains a valid appended signature but is not ima signed, it will fail to load. Now if the enduser simply compresses the same foo.ko, making it foo.ko.xz. The module will load.
Modules can be loaded thru two different syscalls, finit_module and init_module. The changes added in [1] work if you use the init_module syscall. My change adds support when the finit_module syscall gets used instead.
[1] https://patchwork.kernel.org/cover/10986023
^ permalink raw reply
* [PATCH 1/2] crypto: sm3 - add a new alias name sm3-256
From: Tianjia Zhang @ 2020-02-07 9:22 UTC (permalink / raw)
To: herbert, davem, zohar, dmitry.kasatkin, jmorris, serge
Cc: linux-crypto, linux-integrity, linux-security-module,
linux-kernel
In-Reply-To: <20200207092219.115056-1-tianjia.zhang@linux.alibaba.com>
The name sm3-256 is defined in hash_algo_name in hash_info, but the
algorithm name implemented in sm3_generic.c is sm3, which will cause
the sm3-256 algorithm to be not found in some application scenarios of
the hash algorithm, and an ENOENT error will occur. For example,
IMA, keys, and other subsystems that reference hash_algo_name cannot use
the hash algorithm of sm3. This patch adds an alias name sm3-256 to sm3,
which can better solve the above problems.
Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
---
crypto/sm3_generic.c | 21 +++++++++++++++++----
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/crypto/sm3_generic.c b/crypto/sm3_generic.c
index 3468975215ca..ded41031bd5f 100644
--- a/crypto/sm3_generic.c
+++ b/crypto/sm3_generic.c
@@ -163,7 +163,7 @@ int crypto_sm3_finup(struct shash_desc *desc, const u8 *data,
}
EXPORT_SYMBOL(crypto_sm3_finup);
-static struct shash_alg sm3_alg = {
+static struct shash_alg sm3_algs[2] = { {
.digestsize = SM3_DIGEST_SIZE,
.init = sm3_base_init,
.update = crypto_sm3_update,
@@ -176,16 +176,28 @@ static struct shash_alg sm3_alg = {
.cra_blocksize = SM3_BLOCK_SIZE,
.cra_module = THIS_MODULE,
}
-};
+}, {
+ .digestsize = SM3_DIGEST_SIZE,
+ .init = sm3_base_init,
+ .update = crypto_sm3_update,
+ .final = sm3_final,
+ .finup = crypto_sm3_finup,
+ .descsize = sizeof(struct sm3_state),
+ .base = {
+ .cra_name = "sm3-256",
+ .cra_blocksize = SM3_BLOCK_SIZE,
+ .cra_module = THIS_MODULE,
+ }
+} };
static int __init sm3_generic_mod_init(void)
{
- return crypto_register_shash(&sm3_alg);
+ return crypto_register_shashes(sm3_algs, ARRAY_SIZE(sm3_algs));
}
static void __exit sm3_generic_mod_fini(void)
{
- crypto_unregister_shash(&sm3_alg);
+ crypto_unregister_shashes(sm3_algs, ARRAY_SIZE(sm3_algs));
}
subsys_initcall(sm3_generic_mod_init);
@@ -196,3 +208,4 @@ MODULE_DESCRIPTION("SM3 Secure Hash Algorithm");
MODULE_ALIAS_CRYPTO("sm3");
MODULE_ALIAS_CRYPTO("sm3-generic");
+MODULE_ALIAS_CRYPTO("sm3-256");
--
2.17.1
^ permalink raw reply related
* [PATCH] IMA hash algorithm supports sm3-256
From: Tianjia Zhang @ 2020-02-07 9:22 UTC (permalink / raw)
To: herbert, davem, zohar, dmitry.kasatkin, jmorris, serge
Cc: linux-crypto, linux-integrity, linux-security-module,
linux-kernel
The algorithm name sm3-256 referenced by IMA is implemented in crypto as sm3,
which causes IMA to not use sm3-256 algorithm. This patch solves this problem
by adding an alias name sm3-256 to sm3 algorithm, and let IMA hash algorithm
configuration list supports sm3.
^ permalink raw reply
* [PATCH 2/2] ima: add sm3-256 algorithm to hash algorithm configuration list
From: Tianjia Zhang @ 2020-02-07 9:22 UTC (permalink / raw)
To: herbert, davem, zohar, dmitry.kasatkin, jmorris, serge
Cc: linux-crypto, linux-integrity, linux-security-module,
linux-kernel
In-Reply-To: <20200207092219.115056-1-tianjia.zhang@linux.alibaba.com>
sm3-256 has been supported by the ima hash algorithm, but it is not
yet in the Kconfig configuration list. After adding, both ima and tpm2
can support sm3-256 well.
Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
---
security/integrity/ima/Kconfig | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/security/integrity/ima/Kconfig b/security/integrity/ima/Kconfig
index 838476d780e5..27b5df895808 100644
--- a/security/integrity/ima/Kconfig
+++ b/security/integrity/ima/Kconfig
@@ -112,6 +112,10 @@ choice
config IMA_DEFAULT_HASH_WP512
bool "WP512"
depends on CRYPTO_WP512=y && !IMA_TEMPLATE
+
+ config IMA_DEFAULT_HASH_SM3_256
+ bool "SM3_256"
+ depends on CRYPTO_SM3=y && !IMA_TEMPLATE
endchoice
config IMA_DEFAULT_HASH
@@ -121,6 +125,7 @@ config IMA_DEFAULT_HASH
default "sha256" if IMA_DEFAULT_HASH_SHA256
default "sha512" if IMA_DEFAULT_HASH_SHA512
default "wp512" if IMA_DEFAULT_HASH_WP512
+ default "sm3-256" if IMA_DEFAULT_HASH_SM3_256
config IMA_WRITE_POLICY
bool "Enable multiple writes to the IMA policy"
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v5 01/10] capabilities: introduce CAP_PERFMON to kernel and user space
From: Thomas Gleixner @ 2020-02-07 11:38 UTC (permalink / raw)
To: Alexey Budankov, Stephen Smalley, Serge Hallyn, James Morris
Cc: Alexei Starovoitov, Peter Zijlstra, Arnaldo Carvalho de Melo,
Ingo Molnar, jani.nikula@linux.intel.com,
joonas.lahtinen@linux.intel.com, rodrigo.vivi@intel.com,
benh@kernel.crashing.org, Paul Mackerras, Michael Ellerman,
Will Deacon, Mark Rutland, Robert Richter, Alexei Starovoitov,
Jiri Olsa, Andi Kleen, Stephane Eranian, Igor Lubashev,
Alexander Shishkin, Namhyung Kim, Song Liu, Lionel Landwerlin,
linux-kernel, linux-security-module@vger.kernel.org,
selinux@vger.kernel.org, intel-gfx@lists.freedesktop.org,
linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel, linux-perf-users@vger.kernel.org, oprofile-list,
Andy Lutomirski
In-Reply-To: <2b608e26-354b-3df9-aea9-58e56dc0c5e5@linux.intel.com>
Alexey Budankov <alexey.budankov@linux.intel.com> writes:
> On 22.01.2020 17:25, Alexey Budankov wrote:
>> On 22.01.2020 17:07, Stephen Smalley wrote:
>>>> It keeps the implementation simple and readable. The implementation is more
>>>> performant in the sense of calling the API - one capable() call for CAP_PERFMON
>>>> privileged process.
>>>>
>>>> Yes, it bloats audit log for CAP_SYS_ADMIN privileged and unprivileged processes,
>>>> but this bloating also advertises and leverages using more secure CAP_PERFMON
>>>> based approach to use perf_event_open system call.
>>>
>>> I can live with that. We just need to document that when you see
>>> both a CAP_PERFMON and a CAP_SYS_ADMIN audit message for a process,
>>> try only allowing CAP_PERFMON first and see if that resolves the
>>> issue. We have a similar issue with CAP_DAC_READ_SEARCH versus
>>> CAP_DAC_OVERRIDE.
>>
>> perf security [1] document can be updated, at least, to align and document
>> this audit logging specifics.
>
> And I plan to update the document right after this patch set is accepted.
> Feel free to let me know of the places in the kernel docs that also
> require update w.r.t CAP_PERFMON extension.
The documentation update wants be part of the patch set and not planned
to be done _after_ the patch set is merged.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH v5 01/10] capabilities: introduce CAP_PERFMON to kernel and user space
From: Alexey Budankov @ 2020-02-07 13:39 UTC (permalink / raw)
To: Thomas Gleixner, Stephen Smalley, Serge Hallyn, James Morris
Cc: Alexei Starovoitov, Peter Zijlstra, Arnaldo Carvalho de Melo,
Ingo Molnar, jani.nikula@linux.intel.com,
joonas.lahtinen@linux.intel.com, rodrigo.vivi@intel.com,
benh@kernel.crashing.org, Paul Mackerras, Michael Ellerman,
Will Deacon, Mark Rutland, Robert Richter, Alexei Starovoitov,
Jiri Olsa, Andi Kleen, Stephane Eranian, Igor Lubashev,
Alexander Shishkin, Namhyung Kim, Song Liu, Lionel Landwerlin,
linux-kernel, linux-security-module@vger.kernel.org,
selinux@vger.kernel.org, intel-gfx@lists.freedesktop.org,
linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel, linux-perf-users@vger.kernel.org, oprofile-list,
Andy Lutomirski
In-Reply-To: <875zgizkyk.fsf@nanos.tec.linutronix.de>
On 07.02.2020 14:38, Thomas Gleixner wrote:
> Alexey Budankov <alexey.budankov@linux.intel.com> writes:
>> On 22.01.2020 17:25, Alexey Budankov wrote:
>>> On 22.01.2020 17:07, Stephen Smalley wrote:
>>>>> It keeps the implementation simple and readable. The implementation is more
>>>>> performant in the sense of calling the API - one capable() call for CAP_PERFMON
>>>>> privileged process.
>>>>>
>>>>> Yes, it bloats audit log for CAP_SYS_ADMIN privileged and unprivileged processes,
>>>>> but this bloating also advertises and leverages using more secure CAP_PERFMON
>>>>> based approach to use perf_event_open system call.
>>>>
>>>> I can live with that. We just need to document that when you see
>>>> both a CAP_PERFMON and a CAP_SYS_ADMIN audit message for a process,
>>>> try only allowing CAP_PERFMON first and see if that resolves the
>>>> issue. We have a similar issue with CAP_DAC_READ_SEARCH versus
>>>> CAP_DAC_OVERRIDE.
>>>
>>> perf security [1] document can be updated, at least, to align and document
>>> this audit logging specifics.
>>
>> And I plan to update the document right after this patch set is accepted.
>> Feel free to let me know of the places in the kernel docs that also
>> require update w.r.t CAP_PERFMON extension.
>
> The documentation update wants be part of the patch set and not planned
> to be done _after_ the patch set is merged.
Well, accepted. It is going to make patches #11 and beyond.
Thanks,
Alexey
>
> Thanks,
>
> tglx
>
^ permalink raw reply
* Re: [RFC PATCH 0/2] ima: uncompressed module appraisal support
From: Mimi Zohar @ 2020-02-07 14:51 UTC (permalink / raw)
To: Eric Snowberg, Nayna
Cc: dmitry.kasatkin, jmorris, serge, dhowells, geert, gregkh, nayna,
tglx, bauerman, mpe, linux-integrity, linux-security-module,
linux-kernel
In-Reply-To: <09D68C13-75E2-4BD6-B4E6-F765B175C7FD@oracle.com>
On Thu, 2020-02-06 at 14:40 -0700, Eric Snowberg wrote:
<snip>
> Currently the upstream code will fail if the module is uncompressed.
> If you compress the same module it will load with the current
> upstream code.
>
> > Lastly, there is nothing in these patches that indicate that the
> kernel modules being compressed/uncompressed is related to the
> signature verification.
> >
>
> Basically if you have the following setup:
>
> Kernel built with CONFIG_IMA_ARCH_POLICY or kernel booted with
> module.sig_enforce=1 along with the following ima policy:
>
> appraise func=MODULE_CHECK appraise_type=imasig|modsig
Enabling CONFIG_IMA_ARCH_POLICY or module.sig_enforce=1 behave totally
differently. CONFIG_IMA_ARCH_POLICY coordinates between the IMA
signature verification and the original module_sig_check()
verification. Either one signature verification method is enabled or
the other, but not both.
The existing IMA x86 arch policy has not been updated to support
appended signatures.
To understand what is happening, we need to analyze each scenario
separately.
- If CONFIG_MODULE_SIG is configured or enabled on the boot command
line ("module.sig_enforce = 1"), then the IMA arch x86 policy WILL NOT
require an IMA signature.
- If CONFIG_MODULE_SIG is NOT configured or enabled on the boot
command line, then the IMA arch x86 policy WILL require an IMA
signature.
- If CONFIG_MODULE_SIG is configured or enabled on the boot command
line, the IMA arch x86 policy is not configured, and the above policy
rule is defined, an appended signature will be verified by both IMA
and module_sig_check().
>
> If you have a module foo.ko that contains a valid appended signature
> but is not ima signed, it will fail to load.
That would only happen in the second scenario or in the last scenario
if the key is not found.
> Now if the end user simply compresses the same foo.ko, making it
> foo.ko.xz. The module will load.
This implies that CONFIG_MODULE_SIG is configured or enabled on the
boot command line, like the first scenario described above, or in the
last scenario and the key is found.
>
> Modules can be loaded thru two different syscalls, finit_module and
> init_module. The changes added in [1] work if you use the
> init_module syscall. My change adds support when the finit_module
> syscall gets used instead.
With the IMA arch x86 policy, without CONFIG_MODULE_SIG configured or
enabled on the boot command line, IMA will prevent the init_module()
syscall. This is intentional.
Your second patch (2/2) changes the arch x86 policy rule to allow
appended signatures. The reason for any other changes needs to be
clearer. I suggest you look at the audit log and kernel messages, as
well as the kexec selftests, to better understand what is happening.
Mimi
^ permalink raw reply
* Re: [RFC PATCH 0/2] ima: uncompressed module appraisal support
From: Eric Snowberg @ 2020-02-07 16:57 UTC (permalink / raw)
To: Mimi Zohar
Cc: Nayna, dmitry.kasatkin, jmorris, serge, dhowells, geert, gregkh,
nayna, tglx, bauerman, mpe, linux-integrity,
linux-security-module, linux-kernel
In-Reply-To: <1581087096.5585.597.camel@linux.ibm.com>
> On Feb 7, 2020, at 7:51 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
>
> On Thu, 2020-02-06 at 14:40 -0700, Eric Snowberg wrote:
>
> <snip>
>
>> Currently the upstream code will fail if the module is uncompressed.
>> If you compress the same module it will load with the current
>> upstream code.
>>
>>> Lastly, there is nothing in these patches that indicate that the
>> kernel modules being compressed/uncompressed is related to the
>> signature verification.
>>>
>>
>> Basically if you have the following setup:
>>
>> Kernel built with CONFIG_IMA_ARCH_POLICY or kernel booted with
>> module.sig_enforce=1 along with the following ima policy:
>>
>> appraise func=MODULE_CHECK appraise_type=imasig|modsig
>
> Enabling CONFIG_IMA_ARCH_POLICY or module.sig_enforce=1 behave totally
> differently. CONFIG_IMA_ARCH_POLICY coordinates between the IMA
> signature verification and the original module_sig_check()
> verification. Either one signature verification method is enabled or
> the other, but not both.
>
> The existing IMA x86 arch policy has not been updated to support
> appended signatures.
That is not what I’m seeing. Appended signatures mostly work. They just
don’t work thru the finit_module system call.
> To understand what is happening, we need to analyze each scenario
> separately.
>
> - If CONFIG_MODULE_SIG is configured or enabled on the boot command
> line ("module.sig_enforce = 1"), then the IMA arch x86 policy WILL NOT
> require an IMA signature.
All tests below are without my change
x86 booted with module.sig_enforce=1
empty ima policy
$ cat /sys/kernel/security/ima/policy
$ insmod ./foo.ko.xz <— loads ok
$ rmmod foo
$ unxz ./foo.ko.xz
$ insmod ./foo.ko <— loads ok
$ rmmod foo
add in module appraisal
$ echo "appraise func=MODULE_CHECK appraise_type=imasig|modsig" > /sys/kernel/security/ima/policy
$ insmod ./foo.ko.xz <— loads ok
$ rmmod foo
$ insmod ./foo.ko
insmod: ERROR: could not insert module ./foo.ko: Permission denied
last entry from audit log:
type=INTEGRITY_DATA msg=audit(1581089373.076:83): pid=2874 uid=0 auid=0 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 op=appraise_data cause=invalid-signature comm="insmod" name="/root/keys/modules/foo.ko" dev="dm-0" ino=10918365 res=0^]UID="root" AUID=“root"
This is because modsig_verify() will be called from within ima_appraise_measurement(),
since try_modsig is true. Then modsig_verify() will return INTEGRITY_FAIL.
If I build with CONFIG_IMA_ARCH_POLICY & CONFIG_MODULE_SIG all tests work the same above,
I just don’t have to add module.sig_enforce=1 when I boot.
Adding my change will allow foo.ko to load above when “|modsig” is added, since it will now evaluate
the module. Without my change the “imsig|modsig” is true for compressed, but the policy is really
“imasig&modsig” for uncompressed.
> - If CONFIG_MODULE_SIG is NOT configured or enabled on the boot
> command line, then the IMA arch x86 policy WILL require an IMA
> signature.
Agreed
> - If CONFIG_MODULE_SIG is configured or enabled on the boot command
> line, the IMA arch x86 policy is not configured, and the above policy
> rule is defined, an appended signature will be verified by both IMA
> and module_sig_check().
I think this is the same as what I have done above?
>> If you have a module foo.ko that contains a valid appended signature
>> but is not ima signed, it will fail to load.
>
> That would only happen in the second scenario or in the last scenario
> if the key is not found.
>
>> Now if the end user simply compresses the same foo.ko, making it
>> foo.ko.xz. The module will load.
>
> This implies that CONFIG_MODULE_SIG is configured or enabled on the
> boot command line, like the first scenario described above, or in the
> last scenario and the key is found.
>> Modules can be loaded thru two different syscalls, finit_module and
>> init_module. The changes added in [1] work if you use the
>> init_module syscall. My change adds support when the finit_module
>> syscall gets used instead.
>
> With the IMA arch x86 policy, without CONFIG_MODULE_SIG configured or
> enabled on the boot command line, IMA will prevent the init_module()
> syscall. This is intentional.
Agreed
> Your second patch (2/2) changes the arch x86 policy rule to allow
> appended signatures. The reason for any other changes needs to be
> clearer. I suggest you look at the audit log and kernel messages, as
> well as the kexec selftests, to better understand what is happening.
>
I can add more details. I’m just trying to make it so the end user has the same
experience when using the default secure_boot ima policy. I don’t see a point in
forcing someone to compress a module to get around security, especially when they
have a policy that contains “|modsig”.
Let me know how you would like me to move forward. Are you ok with the actual code in
my patches, assuming I add a lot more details? Or do you want more analysis here first?
^ permalink raw reply
* Re: [PATCH v25 10/21] x86/sgx: Linux Enclave Driver
From: Haitao Huang @ 2020-02-07 17:03 UTC (permalink / raw)
To: linux-kernel, x86, linux-sgx, Jarkko Sakkinen
Cc: akpm, dave.hansen, sean.j.christopherson, nhorman, npmccallum,
andriy.shevchenko, tglx, kai.svahn, bp, josh, luto, kai.huang,
rientjes, cedric.xing, puiterwijk, Jarkko Sakkinen,
linux-security-module, haitao.huang
In-Reply-To: <20200204060545.31729-11-jarkko.sakkinen@linux.intel.com>
Tested-by: Haitao Huang<haitao.huang@linux.intel.com>
^ permalink raw reply
* Re: [RFC PATCH 0/2] ima: uncompressed module appraisal support
From: Mimi Zohar @ 2020-02-07 17:40 UTC (permalink / raw)
To: Eric Snowberg
Cc: Nayna, dmitry.kasatkin, jmorris, serge, dhowells, geert, gregkh,
nayna, tglx, bauerman, mpe, linux-integrity,
linux-security-module, linux-kernel
In-Reply-To: <330BDFAC-E778-4E9D-A2D2-DD81B745F6AB@oracle.com>
On Fri, 2020-02-07 at 09:57 -0700, Eric Snowberg wrote:
> > On Feb 7, 2020, at 7:51 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> >
> > On Thu, 2020-02-06 at 14:40 -0700, Eric Snowberg wrote:
> >
> > <snip>
> >
> >> Currently the upstream code will fail if the module is uncompressed.
> >> If you compress the same module it will load with the current
> >> upstream code.
> >>
> >>> Lastly, there is nothing in these patches that indicate that the
> >> kernel modules being compressed/uncompressed is related to the
> >> signature verification.
> >>>
> >>
> >> Basically if you have the following setup:
> >>
> >> Kernel built with CONFIG_IMA_ARCH_POLICY or kernel booted with
> >> module.sig_enforce=1 along with the following ima policy:
> >>
> >> appraise func=MODULE_CHECK appraise_type=imasig|modsig
> >
> > Enabling CONFIG_IMA_ARCH_POLICY or module.sig_enforce=1 behave totally
> > differently. CONFIG_IMA_ARCH_POLICY coordinates between the IMA
> > signature verification and the original module_sig_check()
> > verification. Either one signature verification method is enabled or
> > the other, but not both.
> >
> > The existing IMA x86 arch policy has not been updated to support
> > appended signatures.
>
> That is not what I’m seeing. Appended signatures mostly work. They just
> don’t work thru the finit_module system call.
>
> > To understand what is happening, we need to analyze each scenario
> > separately.
> >
> > - If CONFIG_MODULE_SIG is configured or enabled on the boot command
> > line ("module.sig_enforce = 1"), then the IMA arch x86 policy WILL NOT
> > require an IMA signature.
>
> All tests below are without my change
> x86 booted with module.sig_enforce=1
>
> empty ima policy
Sure, in this example the IMA arch x86 policy is not configured and
there is no custom IMA policy - no IMA.
> $ cat /sys/kernel/security/ima/policy
On a real system, you would want to require a signed IMA policy.
> $ insmod ./foo.ko.xz <— loads ok
> $ rmmod foo
> $ unxz ./foo.ko.xz
> $ insmod ./foo.ko <— loads ok
> $ rmmod foo
>
> add in module appraisal
Sure, the current system
> $ echo "appraise func=MODULE_CHECK appraise_type=imasig|modsig" >
> /sys/kernel/security/ima/policy
>
> $ insmod ./foo.ko.xz <— loads ok
> $ rmmod foo
Sure, CONFIG_MODULE_SIG is configured or enabled on the boot command
line ("module.sig_enforce = 1"). IMA won't prevent the init_module()
syscall.
>
> $ insmod ./foo.ko
> insmod: ERROR: could not insert module ./foo.ko: Permission denied
>
> last entry from audit log:
> type=INTEGRITY_DATA msg=audit(1581089373.076:83): pid=2874 uid=0
> auid=0 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-
> s0:c0.c1023 op=appraise_data cause=invalid-signature comm="insmod"
> name="/root/keys/modules/foo.ko" dev="dm-0" ino=10918365
> res=0^]UID="root" AUID=“root"
>
> This is because modsig_verify() will be called from within
> ima_appraise_measurement(),
> since try_modsig is true. Then modsig_verify() will return
> INTEGRITY_FAIL.
Why is it an "invalid signature"? For that you need to look at the
kernel messages. Most likely it can't find the public key on the .ima
keyring to verify the signature.
Mimi
^ permalink raw reply
* Re: [RFC PATCH 0/2] ima: uncompressed module appraisal support
From: Eric Snowberg @ 2020-02-07 17:49 UTC (permalink / raw)
To: Mimi Zohar
Cc: Nayna, dmitry.kasatkin, jmorris, serge, dhowells, geert, gregkh,
nayna, tglx, bauerman, mpe, linux-integrity,
linux-security-module, linux-kernel
In-Reply-To: <1581097201.5585.613.camel@linux.ibm.com>
> On Feb 7, 2020, at 10:40 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
>
> On Fri, 2020-02-07 at 09:57 -0700, Eric Snowberg wrote:
>>> On Feb 7, 2020, at 7:51 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
>>>
>>> On Thu, 2020-02-06 at 14:40 -0700, Eric Snowberg wrote:
>>>
>>> <snip>
>>>
>>>> Currently the upstream code will fail if the module is uncompressed.
>>>> If you compress the same module it will load with the current
>>>> upstream code.
>>>>
>>>>> Lastly, there is nothing in these patches that indicate that the
>>>> kernel modules being compressed/uncompressed is related to the
>>>> signature verification.
>>>>>
>>>>
>>>> Basically if you have the following setup:
>>>>
>>>> Kernel built with CONFIG_IMA_ARCH_POLICY or kernel booted with
>>>> module.sig_enforce=1 along with the following ima policy:
>>>>
>>>> appraise func=MODULE_CHECK appraise_type=imasig|modsig
>>>
>>> Enabling CONFIG_IMA_ARCH_POLICY or module.sig_enforce=1 behave totally
>>> differently. CONFIG_IMA_ARCH_POLICY coordinates between the IMA
>>> signature verification and the original module_sig_check()
>>> verification. Either one signature verification method is enabled or
>>> the other, but not both.
>>>
>>> The existing IMA x86 arch policy has not been updated to support
>>> appended signatures.
>>
>> That is not what I’m seeing. Appended signatures mostly work. They just
>> don’t work thru the finit_module system call.
>>
>>> To understand what is happening, we need to analyze each scenario
>>> separately.
>>>
>>> - If CONFIG_MODULE_SIG is configured or enabled on the boot command
>>> line ("module.sig_enforce = 1"), then the IMA arch x86 policy WILL NOT
>>> require an IMA signature.
>>
>> All tests below are without my change
>> x86 booted with module.sig_enforce=1
>>
>> empty ima policy
>
> Sure, in this example the IMA arch x86 policy is not configured and
> there is no custom IMA policy - no IMA.
>
>> $ cat /sys/kernel/security/ima/policy
>
> On a real system, you would want to require a signed IMA policy.
>
>> $ insmod ./foo.ko.xz <— loads ok
>> $ rmmod foo
>> $ unxz ./foo.ko.xz
>> $ insmod ./foo.ko <— loads ok
>> $ rmmod foo
>>
>> add in module appraisal
>
> Sure, the current system
>
>> $ echo "appraise func=MODULE_CHECK appraise_type=imasig|modsig" >
>> /sys/kernel/security/ima/policy
>>
>> $ insmod ./foo.ko.xz <— loads ok
>> $ rmmod foo
>
> Sure, CONFIG_MODULE_SIG is configured or enabled on the boot command
> line ("module.sig_enforce = 1"). IMA won't prevent the init_module()
> syscall.
>
>>
>> $ insmod ./foo.ko
>> insmod: ERROR: could not insert module ./foo.ko: Permission denied
>>
>> last entry from audit log:
>> type=INTEGRITY_DATA msg=audit(1581089373.076:83): pid=2874 uid=0
>> auid=0 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-
>> s0:c0.c1023 op=appraise_data cause=invalid-signature comm="insmod"
>> name="/root/keys/modules/foo.ko" dev="dm-0" ino=10918365
>> res=0^]UID="root" AUID=“root"
>>
>> This is because modsig_verify() will be called from within
>> ima_appraise_measurement(),
>> since try_modsig is true. Then modsig_verify() will return
>> INTEGRITY_FAIL.
>
> Why is it an "invalid signature"? For that you need to look at the
> kernel messages. Most likely it can't find the public key on the .ima
> keyring to verify the signature.
It is invalid because the module has not been ima signed.
^ permalink raw reply
* Re: [RFC PATCH 0/2] ima: uncompressed module appraisal support
From: Mimi Zohar @ 2020-02-07 18:28 UTC (permalink / raw)
To: Eric Snowberg
Cc: Nayna, dmitry.kasatkin, jmorris, serge, dhowells, geert, gregkh,
nayna, tglx, bauerman, mpe, linux-integrity,
linux-security-module, linux-kernel
In-Reply-To: <764C5FC8-DF0C-4B7A-8B5B-FD8B83F31568@oracle.com>
On Fri, 2020-02-07 at 10:49 -0700, Eric Snowberg wrote:
>
> > On Feb 7, 2020, at 10:40 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> >
> >> $ insmod ./foo.ko
> >> insmod: ERROR: could not insert module ./foo.ko: Permission denied
> >>
> >> last entry from audit log:
> >> type=INTEGRITY_DATA msg=audit(1581089373.076:83): pid=2874 uid=0
> >> auid=0 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-
> >> s0:c0.c1023 op=appraise_data cause=invalid-signature comm="insmod"
> >> name="/root/keys/modules/foo.ko" dev="dm-0" ino=10918365
> >> res=0^]UID="root" AUID=“root"
> >>
> >> This is because modsig_verify() will be called from within
> >> ima_appraise_measurement(),
> >> since try_modsig is true. Then modsig_verify() will return
> >> INTEGRITY_FAIL.
> >
> > Why is it an "invalid signature"? For that you need to look at the
> > kernel messages. Most likely it can't find the public key on the .ima
> > keyring to verify the signature.
>
> It is invalid because the module has not been ima signed.
With the IMA policy rule "appraise func=MODULE_CHECK
appraise_type=imasig|modsig", IMA first tries to verify the IMA
signature stored as an xattr and on failure then attempts to verify
the appended signatures.
The audit message above indicates that there was a signature, but the
signature validation failed.
Mimi
^ permalink raw reply
* Re: [RFC PATCH 0/2] ima: uncompressed module appraisal support
From: Eric Snowberg @ 2020-02-07 18:45 UTC (permalink / raw)
To: Mimi Zohar
Cc: Nayna, dmitry.kasatkin, jmorris, serge, dhowells, geert, gregkh,
nayna, tglx, bauerman, mpe, linux-integrity,
linux-security-module, linux-kernel
In-Reply-To: <1581100125.5585.623.camel@linux.ibm.com>
> On Feb 7, 2020, at 11:28 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
>
> On Fri, 2020-02-07 at 10:49 -0700, Eric Snowberg wrote:
>>
>>> On Feb 7, 2020, at 10:40 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
>>>
>>>> $ insmod ./foo.ko
>>>> insmod: ERROR: could not insert module ./foo.ko: Permission denied
>>>>
>>>> last entry from audit log:
>>>> type=INTEGRITY_DATA msg=audit(1581089373.076:83): pid=2874 uid=0
>>>> auid=0 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-
>>>> s0:c0.c1023 op=appraise_data cause=invalid-signature comm="insmod"
>>>> name="/root/keys/modules/foo.ko" dev="dm-0" ino=10918365
>>>> res=0^]UID="root" AUID=“root"
>>>>
>>>> This is because modsig_verify() will be called from within
>>>> ima_appraise_measurement(),
>>>> since try_modsig is true. Then modsig_verify() will return
>>>> INTEGRITY_FAIL.
>>>
>>> Why is it an "invalid signature"? For that you need to look at the
>>> kernel messages. Most likely it can't find the public key on the .ima
>>> keyring to verify the signature.
>>
>> It is invalid because the module has not been ima signed.
>
> With the IMA policy rule "appraise func=MODULE_CHECK
> appraise_type=imasig|modsig", IMA first tries to verify the IMA
> signature stored as an xattr and on failure then attempts to verify
> the appended signatures.
>
> The audit message above indicates that there was a signature, but the
> signature validation failed.
>
I do have CONFIG_IMA_APPRAISE_MODSIG enabled. I believe the audit message above
is coming from modsig_verify in security/integrity/ima/ima_appraise.c.
^ permalink raw reply
* Re: [RFC PATCH 0/2] ima: uncompressed module appraisal support
From: Mimi Zohar @ 2020-02-07 18:54 UTC (permalink / raw)
To: Eric Snowberg
Cc: Nayna, dmitry.kasatkin, jmorris, serge, dhowells, geert, gregkh,
nayna, tglx, bauerman, mpe, linux-integrity,
linux-security-module, linux-kernel
In-Reply-To: <992E95D5-D4B9-4913-A36F-BB47631DFE0A@oracle.com>
On Fri, 2020-02-07 at 11:45 -0700, Eric Snowberg wrote:
>
> > On Feb 7, 2020, at 11:28 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> >
> > On Fri, 2020-02-07 at 10:49 -0700, Eric Snowberg wrote:
> >>
> >>> On Feb 7, 2020, at 10:40 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> >>>
> >>>> $ insmod ./foo.ko
> >>>> insmod: ERROR: could not insert module ./foo.ko: Permission denied
> >>>>
> >>>> last entry from audit log:
> >>>> type=INTEGRITY_DATA msg=audit(1581089373.076:83): pid=2874 uid=0
> >>>> auid=0 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-
> >>>> s0:c0.c1023 op=appraise_data cause=invalid-signature comm="insmod"
> >>>> name="/root/keys/modules/foo.ko" dev="dm-0" ino=10918365
> >>>> res=0^]UID="root" AUID=“root"
> >>>>
> >>>> This is because modsig_verify() will be called from within
> >>>> ima_appraise_measurement(),
> >>>> since try_modsig is true. Then modsig_verify() will return
> >>>> INTEGRITY_FAIL.
> >>>
> >>> Why is it an "invalid signature"? For that you need to look at the
> >>> kernel messages. Most likely it can't find the public key on the .ima
> >>> keyring to verify the signature.
> >>
> >> It is invalid because the module has not been ima signed.
> >
> > With the IMA policy rule "appraise func=MODULE_CHECK
> > appraise_type=imasig|modsig", IMA first tries to verify the IMA
> > signature stored as an xattr and on failure then attempts to verify
> > the appended signatures.
> >
> > The audit message above indicates that there was a signature, but the
> > signature validation failed.
> >
>
> I do have CONFIG_IMA_APPRAISE_MODSIG enabled. I believe the audit message above
> is coming from modsig_verify in security/integrity/ima/ima_appraise.c.
Right, and it's calling:
rc = integrity_modsig_verify(INTEGRITY_KEYRING_IMA, modsig);
It's failing because it is trying to find the public key on the .ima
keyring. Make sure that the public needed to validate the kernel
module is on the IMA keyring (eg. keyctl show %keyring:.ima).
Mimi
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox