2020-12-14 06:03:08

by Tushar Sugandhi

[permalink] [raw]
Subject: [PATCH v9 0/8] IMA: support for measuring kernel integrity critical data

IMA measures files and buffer data such as keys, command-line arguments
passed to the kernel on kexec system call, etc. While these measurements
are necessary for monitoring and validating the integrity of the system,
they are not sufficient. Various data structures, policies, and states
stored in kernel memory also impact the integrity of the system.
Several kernel subsystems contain such integrity critical data -
e.g. LSMs like SELinux, AppArmor etc. or device-mapper targets like
dm-crypt, dm-verity, dm-integrity etc. These kernel subsystems help
protect the integrity of a device. Their integrity critical data is not
expected to change frequently during run-time. Some of these structures
cannot be defined as __ro_after_init, because they are initialized later.

For a given device, various external services/infrastructure tools
(including the attestation service) interact with it - both during the
setup and during rest of the device run-time. They share sensitive data
and/or execute critical workload on that device. The external services
may want to verify the current run-time state of the relevant kernel
subsystems before fully trusting the device with business critical
data/workload. For instance, verifying that SELinux is in "enforce" mode
along with the expected policy, disks are encrypted with a certain
configuration, secure boot is enabled etc.

This series provides the necessary IMA functionality for kernel
subsystems to ensure their configuration can be measured:
- by kernel subsystems themselves,
- in a tamper resistant way,
- and re-measured - triggered on state/configuration change.

This patch set:
- defines a new IMA hook ima_measure_critical_data() to measure
integrity critical data,
- limits the critical data being measured based on a label,
- defines a builtin critical data measurement policy,
- and includes an SELinux consumer of the new IMA critical data hook.

This series is based on the following repo/branch:

repo: https://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git
branch: next-integrity
commit 207cdd565dfc ("ima: Don't modify file descriptor mode on the fly")

Change Log v9:
Incorporated feedback from Tyler on v8 of this series.
- Moved rule->data_source logic from Patch #4 to Patch #5.
- Removed unnecessary variable event_name from selinux_event_name()
in Patch #8.


Change Log v8:
Incorporated feedback from Tyler on v7 of this series.
- Removed unnecessary 'else' clauses in ima_match_rule_data().
- Fixed ima_store_template() to pass the buffer hash in case the
buffer is large.
- fixed function description for ima_measure_critical_data().
- Moved some usage of CRITICAL_DATA from Patch #3 to Patch #4.
- Moved IMA_DATA_SOURCE from Patch #4 to Patch #5.
- Removed unnecessary pr_err() from ima_measure_critical_data()
and selinux_event_name().
- Fixed log formatting in selinux_measure_state() to be consistent
with other messages in that file.

Change Log v7:
Incorporated feedback from Mimi on v6 of this series.
- Updated cover letter and patch descriptions as per Mimi's feedback.
- Changed references to variable names and policy documentation from
plural "data_sources" to singular "data_source".
- Updated SELinux patch to measure only policy, instead of policy and
state. The state measurement will be upstreamed through a separate
patch.
- Updated admin-guide/kernel-parameters.txt to document support for
critical_data in builtin policy.

Change Log v6:
Incorporated feedback from Mimi on v5 of this series.
- Got rid of patch 5 from the v5 of the series.(the allow list for data
sources)
- Updated function descriptions, changed variable names etc.
- Moved the input param event_data_source in ima_measure_critical_data()
to a new patch. (patch 6/8 of this series)
- Split patch 4 from v5 of the series into two patches (patch 4/8 and
patch 5/8)
- Updated cover letter and patch descriptions as per feedback.

Change Log v5:
(1) Incorporated feedback from Stephen on the last SeLinux patch.
SeLinux Patch: https://patchwork.kernel.org/patch/11801585/
- Freed memory in the reverse order of allocation in
selinux_measure_state().
- Used scnprintf() instead of snprintf() to create the string for
selinux state.
- Allocated event name passed to ima_measure_critical_data() before
gathering selinux state and policy information for measuring.

(2) Incorporated feedback from Mimi on v4 of this series.
V4 of this Series: https://patchwork.kernel.org/project/linux-integrity/list/?series=354437

- Removed patch "[v4,2/6] IMA: conditionally allow empty rule data"
- Reversed the order of following patches.
[v4,4/6] IMA: add policy to measure critical data from kernel components
[v4,5/6] IMA: add hook to measure critical data from kernel components
and renamed them to remove "from kernel components"
- Added a new patch to this series -
IMA: add critical_data to built-in policy rules

- Added the next version of SeLinux patch (mentioned above) to this
series
selinux: measure state and hash of the policy using IMA

- Updated cover-letter description to give broader perspective of the
feature, rearranging paragraphs, removing unnecessary info, clarifying
terms etc.
- Got rid of opt_list param from ima_match_rule_data().
- Updated the documentation to remove sources that don't yet exist.
- detailed IMA hook description added to ima_measure_critical_data(),
as well as elaborating terms event_name, event_data_source.
- "data_sources:=" is not a mandatory policy option for
func=CRITICAL_DATA anymore. If not present, all the data sources
specified in __ima_supported_kernel_data_sources will be measured.


Lakshmi Ramasubramanian (2):
IMA: define a builtin critical data measurement policy
selinux: include a consumer of the new IMA critical data hook

Tushar Sugandhi (6):
IMA: generalize keyring specific measurement constructs
IMA: add support to measure buffer data hash
IMA: define a hook to measure kernel integrity critical data
IMA: add policy rule to measure critical data
IMA: limit critical data measurement based on a label
IMA: extend critical data hook to limit the measurement based on a
label

Documentation/ABI/testing/ima_policy | 5 +-
.../admin-guide/kernel-parameters.txt | 5 +-
include/linux/ima.h | 8 ++
security/integrity/ima/ima.h | 8 +-
security/integrity/ima/ima_api.c | 8 +-
security/integrity/ima/ima_appraise.c | 2 +-
security/integrity/ima/ima_asymmetric_keys.c | 2 +-
security/integrity/ima/ima_main.c | 81 ++++++++++--
security/integrity/ima/ima_policy.c | 118 ++++++++++++++----
security/integrity/ima/ima_queue_keys.c | 3 +-
security/selinux/Makefile | 2 +
security/selinux/include/security.h | 11 +-
security/selinux/measure.c | 79 ++++++++++++
security/selinux/ss/services.c | 71 +++++++++--
14 files changed, 352 insertions(+), 51 deletions(-)
create mode 100644 security/selinux/measure.c

--
2.17.1


2020-12-14 06:03:09

by Tushar Sugandhi

[permalink] [raw]
Subject: [PATCH v9 8/8] selinux: include a consumer of the new IMA critical data hook

From: Lakshmi Ramasubramanian <[email protected]>

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

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

Add "selinux" to the list of supported data sources maintained by IMA
to enable measuring SELinux data.

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

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

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

Sample measurement of the hash of SELinux policy:

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

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

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

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

Signed-off-by: Lakshmi Ramasubramanian <[email protected]>
Suggested-by: Stephen Smalley <[email protected]>
Reviewed-by: Tyler Hicks <[email protected]>
---
Documentation/ABI/testing/ima_policy | 3 +-
security/selinux/Makefile | 2 +
security/selinux/include/security.h | 11 +++-
security/selinux/measure.c | 79 ++++++++++++++++++++++++++++
security/selinux/ss/services.c | 71 +++++++++++++++++++++----
5 files changed, 155 insertions(+), 11 deletions(-)
create mode 100644 security/selinux/measure.c

diff --git a/Documentation/ABI/testing/ima_policy b/Documentation/ABI/testing/ima_policy
index 0f4ee9e0a455..7c7023f7986b 100644
--- a/Documentation/ABI/testing/ima_policy
+++ b/Documentation/ABI/testing/ima_policy
@@ -52,8 +52,9 @@ Description:
template:= name of a defined IMA template type
(eg, ima-ng). Only valid when action is "measure".
pcr:= decimal value
- data_source:= [label]
+ data_source:= [selinux]|[label]
label:= a unique string used for grouping and limiting critical data.
+ For example, "selinux" to measure critical data for SELinux.

default policy:
# PROC_SUPER_MAGIC
diff --git a/security/selinux/Makefile b/security/selinux/Makefile
index 4d8e0e8adf0b..83d512116341 100644
--- a/security/selinux/Makefile
+++ b/security/selinux/Makefile
@@ -16,6 +16,8 @@ selinux-$(CONFIG_NETLABEL) += netlabel.o

selinux-$(CONFIG_SECURITY_INFINIBAND) += ibpkey.o

+selinux-$(CONFIG_IMA) += measure.o
+
ccflags-y := -I$(srctree)/security/selinux -I$(srctree)/security/selinux/include

$(addprefix $(obj)/,$(selinux-y)): $(obj)/flask.h
diff --git a/security/selinux/include/security.h b/security/selinux/include/security.h
index 3cc8bab31ea8..18ee65c98446 100644
--- a/security/selinux/include/security.h
+++ b/security/selinux/include/security.h
@@ -229,7 +229,8 @@ void selinux_policy_cancel(struct selinux_state *state,
struct selinux_policy *policy);
int security_read_policy(struct selinux_state *state,
void **data, size_t *len);
-
+int security_read_policy_kernel(struct selinux_state *state,
+ void **data, size_t *len);
int security_policycap_supported(struct selinux_state *state,
unsigned int req_cap);

@@ -446,4 +447,12 @@ extern void ebitmap_cache_init(void);
extern void hashtab_cache_init(void);
extern int security_sidtab_hash_stats(struct selinux_state *state, char *page);

+#ifdef CONFIG_IMA
+extern void selinux_measure_state(struct selinux_state *selinux_state);
+#else
+static inline void selinux_measure_state(struct selinux_state *selinux_state)
+{
+}
+#endif
+
#endif /* _SELINUX_SECURITY_H_ */
diff --git a/security/selinux/measure.c b/security/selinux/measure.c
new file mode 100644
index 000000000000..b7e24358e11d
--- /dev/null
+++ b/security/selinux/measure.c
@@ -0,0 +1,79 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Measure SELinux state using IMA subsystem.
+ */
+#include <linux/vmalloc.h>
+#include <linux/ktime.h>
+#include <linux/ima.h>
+#include "security.h"
+
+/*
+ * This function creates a unique name by appending the timestamp to
+ * the given string. This string is passed as "event_name" to the IMA
+ * hook to measure the given SELinux data.
+ *
+ * The data provided by SELinux to the IMA subsystem for measuring may have
+ * already been measured (for instance the same state existed earlier).
+ * But for SELinux the current data represents a state change and hence
+ * needs to be measured again. To enable this, pass a unique "event_name"
+ * to the IMA hook so that IMA subsystem will always measure the given data.
+ *
+ * For example,
+ * At time T0 SELinux data to be measured is "foo". IMA measures it.
+ * At time T1 the data is changed to "bar". IMA measures it.
+ * At time T2 the data is changed to "foo" again. IMA will not measure it
+ * (since it was already measured) unless the event_name, for instance,
+ * is different in this call.
+ */
+static char *selinux_event_name(const char *name_prefix)
+{
+ struct timespec64 cur_time;
+
+ ktime_get_real_ts64(&cur_time);
+ return kasprintf(GFP_KERNEL, "%s-%lld:%09ld", name_prefix,
+ cur_time.tv_sec, cur_time.tv_nsec);
+}
+
+/*
+ * selinux_measure_state - Measure hash of the SELinux policy
+ *
+ * @state: selinux state struct
+ *
+ * NOTE: This function must be called with policy_mutex held.
+ */
+void selinux_measure_state(struct selinux_state *state)
+{
+ void *policy = NULL;
+ char *policy_event_name = NULL;
+ size_t policy_len;
+ int rc = 0;
+ bool initialized = selinux_initialized(state);
+
+ /*
+ * Measure SELinux policy only after initialization is completed.
+ */
+ if (!initialized)
+ goto out;
+
+ policy_event_name = selinux_event_name("selinux-policy-hash");
+ if (!policy_event_name) {
+ pr_err("SELinux: %s: event name for policy not allocated.\n",
+ __func__);
+ rc = -ENOMEM;
+ goto out;
+ }
+
+ rc = security_read_policy_kernel(state, &policy, &policy_len);
+ if (rc) {
+ pr_err("SELinux: %s: failed to read policy %d.\n", __func__, rc);
+ goto out;
+ }
+
+ ima_measure_critical_data("selinux", policy_event_name,
+ policy, policy_len, true);
+
+ vfree(policy);
+
+out:
+ kfree(policy_event_name);
+}
diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
index 9704c8a32303..dfa2e00894ae 100644
--- a/security/selinux/ss/services.c
+++ b/security/selinux/ss/services.c
@@ -2180,6 +2180,7 @@ static void selinux_notify_policy_change(struct selinux_state *state,
selinux_status_update_policyload(state, seqno);
selinux_netlbl_cache_invalidate();
selinux_xfrm_notify_policyload();
+ selinux_measure_state(state);
}

void selinux_policy_commit(struct selinux_state *state,
@@ -3875,8 +3876,33 @@ int security_netlbl_sid_to_secattr(struct selinux_state *state,
}
#endif /* CONFIG_NETLABEL */

+/**
+ * security_read_selinux_policy - read the policy.
+ * @policy: SELinux policy
+ * @data: binary policy data
+ * @len: length of data in bytes
+ *
+ */
+static int security_read_selinux_policy(struct selinux_policy *policy,
+ void *data, size_t *len)
+{
+ int rc;
+ struct policy_file fp;
+
+ fp.data = data;
+ fp.len = *len;
+
+ rc = policydb_write(&policy->policydb, &fp);
+ if (rc)
+ return rc;
+
+ *len = (unsigned long)fp.data - (unsigned long)data;
+ return 0;
+}
+
/**
* security_read_policy - read the policy.
+ * @state: selinux_state
* @data: binary policy data
* @len: length of data in bytes
*
@@ -3885,8 +3911,6 @@ int security_read_policy(struct selinux_state *state,
void **data, size_t *len)
{
struct selinux_policy *policy;
- int rc;
- struct policy_file fp;

policy = rcu_dereference_protected(
state->policy, lockdep_is_held(&state->policy_mutex));
@@ -3898,14 +3922,43 @@ int security_read_policy(struct selinux_state *state,
if (!*data)
return -ENOMEM;

- fp.data = *data;
- fp.len = *len;
+ return security_read_selinux_policy(policy, *data, len);
+}

- rc = policydb_write(&policy->policydb, &fp);
- if (rc)
- return rc;
+/**
+ * security_read_policy_kernel - read the policy.
+ * @state: selinux_state
+ * @data: binary policy data
+ * @len: length of data in bytes
+ *
+ * Allocates kernel memory for reading SELinux policy.
+ * This function is for internal use only and should not
+ * be used for returning data to user space.
+ *
+ * This function must be called with policy_mutex held.
+ */
+int security_read_policy_kernel(struct selinux_state *state,
+ void **data, size_t *len)
+{
+ struct selinux_policy *policy;
+ int rc = 0;

- *len = (unsigned long)fp.data - (unsigned long)*data;
- return 0;
+ policy = rcu_dereference_protected(
+ state->policy, lockdep_is_held(&state->policy_mutex));
+ if (!policy) {
+ rc = -EINVAL;
+ goto out;
+ }
+
+ *len = policy->policydb.len;
+ *data = vmalloc(*len);
+ if (!*data) {
+ rc = -ENOMEM;
+ goto out;
+ }

+ rc = security_read_selinux_policy(policy, *data, len);
+
+out:
+ return rc;
}
--
2.17.1

2020-12-14 08:15:08

by Tushar Sugandhi

[permalink] [raw]
Subject: [PATCH v9 7/8] IMA: define a builtin critical data measurement policy

From: Lakshmi Ramasubramanian <[email protected]>

Define a new critical data builtin policy to allow measuring
early kernel integrity critical data before a custom IMA policy
is loaded.

Add critical data to built-in IMA rules if the kernel command line
contains "ima_policy=critical_data".

Update the documentation on kernel parameters to document
the new critical data builtin policy.

Signed-off-by: Lakshmi Ramasubramanian <[email protected]>
Reviewed-by: Tyler Hicks <[email protected]>
---
Documentation/admin-guide/kernel-parameters.txt | 5 ++++-
security/integrity/ima/ima_policy.c | 12 ++++++++++++
2 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 526d65d8573a..6034d75c3ca0 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1746,7 +1746,7 @@
ima_policy= [IMA]
The builtin policies to load during IMA setup.
Format: "tcb | appraise_tcb | secure_boot |
- fail_securely"
+ fail_securely | critical_data"

The "tcb" policy measures all programs exec'd, files
mmap'd for exec, and all files opened with the read
@@ -1765,6 +1765,9 @@
filesystems with the SB_I_UNVERIFIABLE_SIGNATURE
flag.

+ The "critical_data" policy measures kernel integrity
+ critical data.
+
ima_tcb [IMA] Deprecated. Use ima_policy= instead.
Load a policy which meets the needs of the Trusted
Computing Base. This means IMA will measure all
diff --git a/security/integrity/ima/ima_policy.c b/security/integrity/ima/ima_policy.c
index fea996a9e26c..376b625acc72 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -206,6 +206,10 @@ static struct ima_rule_entry secure_boot_rules[] __ro_after_init = {
.flags = IMA_FUNC | IMA_DIGSIG_REQUIRED},
};

+static struct ima_rule_entry critical_data_rules[] __ro_after_init = {
+ {.action = MEASURE, .func = CRITICAL_DATA, .flags = IMA_FUNC},
+};
+
/* An array of architecture specific rules */
static struct ima_rule_entry *arch_policy_entry __ro_after_init;

@@ -228,6 +232,7 @@ __setup("ima_tcb", default_measure_policy_setup);

static bool ima_use_appraise_tcb __initdata;
static bool ima_use_secure_boot __initdata;
+static bool ima_use_critical_data __initdata;
static bool ima_fail_unverifiable_sigs __ro_after_init;
static int __init policy_setup(char *str)
{
@@ -242,6 +247,8 @@ static int __init policy_setup(char *str)
ima_use_appraise_tcb = true;
else if (strcmp(p, "secure_boot") == 0)
ima_use_secure_boot = true;
+ else if (strcmp(p, "critical_data") == 0)
+ ima_use_critical_data = true;
else if (strcmp(p, "fail_securely") == 0)
ima_fail_unverifiable_sigs = true;
else
@@ -872,6 +879,11 @@ void __init ima_init_policy(void)
ARRAY_SIZE(default_appraise_rules),
IMA_DEFAULT_POLICY);

+ if (ima_use_critical_data)
+ add_rules(critical_data_rules,
+ ARRAY_SIZE(critical_data_rules),
+ IMA_DEFAULT_POLICY);
+
ima_update_policy_flag();
}

--
2.17.1

2020-12-23 21:15:28

by Paul Moore

[permalink] [raw]
Subject: Re: [PATCH v9 8/8] selinux: include a consumer of the new IMA critical data hook

On Sat, Dec 12, 2020 at 1:03 PM Tushar Sugandhi
<[email protected]> wrote:
> From: Lakshmi Ramasubramanian <[email protected]>
>
> SELinux stores the active policy in memory, so the changes to this data
> at runtime would have an impact on the security guarantees provided
> by SELinux. Measuring in-memory SELinux policy through IMA subsystem
> provides a secure way for the attestation service to remotely validate
> the policy contents at runtime.
>
> Measure the hash of the loaded policy by calling the IMA hook
> ima_measure_critical_data(). Since the size of the loaded policy can
> be large (several MB), measure the hash of the policy instead of
> the entire policy to avoid bloating the IMA log entry.
>
> Add "selinux" to the list of supported data sources maintained by IMA
> to enable measuring SELinux data.
>
> To enable SELinux data measurement, the following steps are required:
>
> 1, Add "ima_policy=critical_data" to the kernel command line arguments
> to enable measuring SELinux data at boot time.
> For example,
> BOOT_IMAGE=/boot/vmlinuz-5.10.0-rc1+ root=UUID=fd643309-a5d2-4ed3-b10d-3c579a5fab2f ro nomodeset security=selinux ima_policy=critical_data
>
> 2, Add the following rule to /etc/ima/ima-policy
> measure func=CRITICAL_DATA data_source=selinux
>
> Sample measurement of the hash of SELinux policy:
>
> To verify the measured data with the current SELinux policy run
> the following commands and verify the output hash values match.
>
> sha256sum /sys/fs/selinux/policy | cut -d' ' -f 1
>
> grep "selinux-policy-hash" /sys/kernel/security/integrity/ima/ascii_runtime_measurements | tail -1 | cut -d' ' -f 6
>
> Note that the actual verification of SELinux policy would require loading
> the expected policy into an identical kernel on a pristine/known-safe
> system and run the sha256sum /sys/kernel/selinux/policy there to get
> the expected hash.
>
> Signed-off-by: Lakshmi Ramasubramanian <[email protected]>
> Suggested-by: Stephen Smalley <[email protected]>
> Reviewed-by: Tyler Hicks <[email protected]>
> ---
> Documentation/ABI/testing/ima_policy | 3 +-
> security/selinux/Makefile | 2 +
> security/selinux/include/security.h | 11 +++-
> security/selinux/measure.c | 79 ++++++++++++++++++++++++++++
> security/selinux/ss/services.c | 71 +++++++++++++++++++++----
> 5 files changed, 155 insertions(+), 11 deletions(-)
> create mode 100644 security/selinux/measure.c

...

> diff --git a/security/selinux/Makefile b/security/selinux/Makefile
> index 4d8e0e8adf0b..83d512116341 100644
> --- a/security/selinux/Makefile
> +++ b/security/selinux/Makefile
> @@ -16,6 +16,8 @@ selinux-$(CONFIG_NETLABEL) += netlabel.o
>
> selinux-$(CONFIG_SECURITY_INFINIBAND) += ibpkey.o
>
> +selinux-$(CONFIG_IMA) += measure.o

Naming things is hard, I get that, but I would prefer if we just
called this file "ima.c" or something similar. The name "measure.c"
implies a level of abstraction or general use which simply doesn't
exist here. Let's help make it a bit more obvious what should belong
in this file.

> diff --git a/security/selinux/include/security.h b/security/selinux/include/security.h
> index 3cc8bab31ea8..18ee65c98446 100644
> --- a/security/selinux/include/security.h
> +++ b/security/selinux/include/security.h
> @@ -229,7 +229,8 @@ void selinux_policy_cancel(struct selinux_state *state,
> struct selinux_policy *policy);
> int security_read_policy(struct selinux_state *state,
> void **data, size_t *len);
> -
> +int security_read_policy_kernel(struct selinux_state *state,
> + void **data, size_t *len);
> int security_policycap_supported(struct selinux_state *state,
> unsigned int req_cap);
>
> @@ -446,4 +447,12 @@ extern void ebitmap_cache_init(void);
> extern void hashtab_cache_init(void);
> extern int security_sidtab_hash_stats(struct selinux_state *state, char *page);
>
> +#ifdef CONFIG_IMA
> +extern void selinux_measure_state(struct selinux_state *selinux_state);
> +#else
> +static inline void selinux_measure_state(struct selinux_state *selinux_state)
> +{
> +}
> +#endif

If you are going to put the SELinux/IMA function(s) into a separate
source file, please put the function declarations into a separate
header file too. For example, look at
security/selinux/include/{netif,netnode,netport,etc.}.h.

> diff --git a/security/selinux/measure.c b/security/selinux/measure.c
> new file mode 100644
> index 000000000000..b7e24358e11d
> --- /dev/null
> +++ b/security/selinux/measure.c
> @@ -0,0 +1,79 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Measure SELinux state using IMA subsystem.
> + */
> +#include <linux/vmalloc.h>
> +#include <linux/ktime.h>
> +#include <linux/ima.h>
> +#include "security.h"
> +
> +/*
> + * This function creates a unique name by appending the timestamp to
> + * the given string. This string is passed as "event_name" to the IMA
> + * hook to measure the given SELinux data.
> + *
> + * The data provided by SELinux to the IMA subsystem for measuring may have
> + * already been measured (for instance the same state existed earlier).
> + * But for SELinux the current data represents a state change and hence
> + * needs to be measured again. To enable this, pass a unique "event_name"
> + * to the IMA hook so that IMA subsystem will always measure the given data.
> + *
> + * For example,
> + * At time T0 SELinux data to be measured is "foo". IMA measures it.
> + * At time T1 the data is changed to "bar". IMA measures it.
> + * At time T2 the data is changed to "foo" again. IMA will not measure it
> + * (since it was already measured) unless the event_name, for instance,
> + * is different in this call.
> + */
> +static char *selinux_event_name(const char *name_prefix)
> +{
> + struct timespec64 cur_time;
> +
> + ktime_get_real_ts64(&cur_time);
> + return kasprintf(GFP_KERNEL, "%s-%lld:%09ld", name_prefix,
> + cur_time.tv_sec, cur_time.tv_nsec);
> +}

Why is this a separate function? It's three lines long and only
called from selinux_measure_state(). Do you ever see the SELinux/IMA
code in this file expanding to the point where this function is nice
from a reuse standpoint?

Also, I assume you are not concerned about someone circumventing the
IMA measurements by manipulating the time? In most systems I would
expect the time to be a protected entity, but with many systems
getting their time from remote systems I thought it was worth
mentioning.

> +/*
> + * selinux_measure_state - Measure hash of the SELinux policy
> + *
> + * @state: selinux state struct
> + *
> + * NOTE: This function must be called with policy_mutex held.
> + */
> +void selinux_measure_state(struct selinux_state *state)

Similar to the name of this source file, let's make it clear this is
for IMA. How about calling this selinux_ima_measure_state() or
similar?

> +{
> + void *policy = NULL;
> + char *policy_event_name = NULL;
> + size_t policy_len;
> + int rc = 0;
> + bool initialized = selinux_initialized(state);

Why bother with the initialized variable? Unless I'm missing
something it is only used once in the code below.

> + /*
> + * Measure SELinux policy only after initialization is completed.
> + */
> + if (!initialized)
> + goto out;
> +
> + policy_event_name = selinux_event_name("selinux-policy-hash");
> + if (!policy_event_name) {
> + pr_err("SELinux: %s: event name for policy not allocated.\n",
> + __func__);
> + rc = -ENOMEM;

This function doesn't return an error code, why bother with setting
the rc variable here?

> + goto out;
> + }
> +
> + rc = security_read_policy_kernel(state, &policy, &policy_len);
> + if (rc) {
> + pr_err("SELinux: %s: failed to read policy %d.\n", __func__, rc);
> + goto out;
> + }
> +
> + ima_measure_critical_data("selinux", policy_event_name,
> + policy, policy_len, true);
> +
> + vfree(policy);
> +
> +out:
> + kfree(policy_event_name);
> +}
> diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
> index 9704c8a32303..dfa2e00894ae 100644
> --- a/security/selinux/ss/services.c
> +++ b/security/selinux/ss/services.c
> @@ -2180,6 +2180,7 @@ static void selinux_notify_policy_change(struct selinux_state *state,
> selinux_status_update_policyload(state, seqno);
> selinux_netlbl_cache_invalidate();
> selinux_xfrm_notify_policyload();
> + selinux_measure_state(state);
> }
>
> void selinux_policy_commit(struct selinux_state *state,
> @@ -3875,8 +3876,33 @@ int security_netlbl_sid_to_secattr(struct selinux_state *state,
> }
> #endif /* CONFIG_NETLABEL */
>
> +/**
> + * security_read_selinux_policy - read the policy.
> + * @policy: SELinux policy
> + * @data: binary policy data
> + * @len: length of data in bytes
> + *
> + */
> +static int security_read_selinux_policy(struct selinux_policy *policy,
> + void *data, size_t *len)

Let's just call this "security_read_policy()".

> +{
> + int rc;
> + struct policy_file fp;
> +
> + fp.data = data;
> + fp.len = *len;
> +
> + rc = policydb_write(&policy->policydb, &fp);
> + if (rc)
> + return rc;
> +
> + *len = (unsigned long)fp.data - (unsigned long)data;
> + return 0;
> +}
> +
> /**
> * security_read_policy - read the policy.
> + * @state: selinux_state
> * @data: binary policy data
> * @len: length of data in bytes
> *
> @@ -3885,8 +3911,6 @@ int security_read_policy(struct selinux_state *state,
> void **data, size_t *len)
> {
> struct selinux_policy *policy;
> - int rc;
> - struct policy_file fp;
>
> policy = rcu_dereference_protected(
> state->policy, lockdep_is_held(&state->policy_mutex));
> @@ -3898,14 +3922,43 @@ int security_read_policy(struct selinux_state *state,
> if (!*data)> --
> 2.17.1
>

> return -ENOMEM;
>
> - fp.data = *data;
> - fp.len = *len;
> + return security_read_selinux_policy(policy, *data, len);
> +}
>
> - rc = policydb_write(&policy->policydb, &fp);
> - if (rc)
> - return rc;
> +/**
> + * security_read_policy_kernel - read the policy.
> + * @state: selinux_state
> + * @data: binary policy data
> + * @len: length of data in bytes
> + *
> + * Allocates kernel memory for reading SELinux policy.
> + * This function is for internal use only and should not
> + * be used for returning data to user space.
> + *
> + * This function must be called with policy_mutex held.
> + */
> +int security_read_policy_kernel(struct selinux_state *state,
> + void **data, size_t *len)

Let's call this "security_read_state_kernel()".

> +{
> + struct selinux_policy *policy;
> + int rc = 0;

See below, the rc variable is not needed.

> - *len = (unsigned long)fp.data - (unsigned long)*data;
> - return 0;
> + policy = rcu_dereference_protected(
> + state->policy, lockdep_is_held(&state->policy_mutex));
> + if (!policy) {
> + rc = -EINVAL;
> + goto out;

Jumping to the out label is a little silly since it is just a return;
do a "return -EINVAL;" here instead.

> + }
> +
> + *len = policy->policydb.len;
> + *data = vmalloc(*len);
> + if (!*data) {
> + rc = -ENOMEM;
> + goto out;

Same as above, "return -ENOMEM;" please.

> + }
>
> + rc = security_read_selinux_policy(policy, *data, len);

You should be able to do "return security_read_selinux_policy(...);" here.

> +
> +out:
> + return rc;
> }

--
paul moore
http://www.paul-moore.com

2020-12-24 14:44:32

by Mimi Zohar

[permalink] [raw]
Subject: Re: [PATCH v9 7/8] IMA: define a builtin critical data measurement policy

On Sat, 2020-12-12 at 10:02 -0800, Tushar Sugandhi wrote:
> From: Lakshmi Ramasubramanian <[email protected]>
>
> Define a new critical data builtin policy to allow measuring
> early kernel integrity critical data before a custom IMA policy
> is loaded.
>
> Add critical data to built-in IMA rules if the kernel command line
> contains "ima_policy=critical_data".

This sentence isn't really necessary.

>
> Update the documentation on kernel parameters to document
> the new critical data builtin policy.
>
> Signed-off-by: Lakshmi Ramasubramanian <[email protected]>
> Reviewed-by: Tyler Hicks <[email protected]>

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

thanks,

Mimi

2021-01-04 23:33:12

by Lakshmi Ramasubramanian

[permalink] [raw]
Subject: Re: [PATCH v9 8/8] selinux: include a consumer of the new IMA critical data hook

On 12/23/20 1:10 PM, Paul Moore wrote:

Hi Paul,

> ...
>
>> diff --git a/security/selinux/Makefile b/security/selinux/Makefile
>> index 4d8e0e8adf0b..83d512116341 100644
>> --- a/security/selinux/Makefile
>> +++ b/security/selinux/Makefile
>> @@ -16,6 +16,8 @@ selinux-$(CONFIG_NETLABEL) += netlabel.o
>>
>> selinux-$(CONFIG_SECURITY_INFINIBAND) += ibpkey.o
>>
>> +selinux-$(CONFIG_IMA) += measure.o
>
> Naming things is hard, I get that, but I would prefer if we just
> called this file "ima.c" or something similar. The name "measure.c"
> implies a level of abstraction or general use which simply doesn't
> exist here. Let's help make it a bit more obvious what should belong
> in this file.
Agreed - I will rename the file to ima.c

>
>> diff --git a/security/selinux/include/security.h b/security/selinux/include/security.h
>> index 3cc8bab31ea8..18ee65c98446 100644
>> --- a/security/selinux/include/security.h
>> +++ b/security/selinux/include/security.h
>> @@ -229,7 +229,8 @@ void selinux_policy_cancel(struct selinux_state *state,
>> struct selinux_policy *policy);
>> int security_read_policy(struct selinux_state *state,
>> void **data, size_t *len);
>> -
>> +int security_read_policy_kernel(struct selinux_state *state,
>> + void **data, size_t *len);
>> int security_policycap_supported(struct selinux_state *state,
>> unsigned int req_cap);
>>
>> @@ -446,4 +447,12 @@ extern void ebitmap_cache_init(void);
>> extern void hashtab_cache_init(void);
>> extern int security_sidtab_hash_stats(struct selinux_state *state, char *page);
>>
>> +#ifdef CONFIG_IMA
>> +extern void selinux_measure_state(struct selinux_state *selinux_state);
>> +#else
>> +static inline void selinux_measure_state(struct selinux_state *selinux_state)
>> +{
>> +}
>> +#endif
>
> If you are going to put the SELinux/IMA function(s) into a separate
> source file, please put the function declarations into a separate
> header file too. For example, look at
> security/selinux/include/{netif,netnode,netport,etc.}.h.

I will create a new header file "security/selinux/include/ima.h" and
move the function declarations for IMA functions to that header.

>
>> diff --git a/security/selinux/measure.c b/security/selinux/measure.c
>> new file mode 100644
>> index 000000000000..b7e24358e11d
>> --- /dev/null
>> +++ b/security/selinux/measure.c
>> @@ -0,0 +1,79 @@
>> +// SPDX-License-Identifier: GPL-2.0-or-later
>> +/*
>> + * Measure SELinux state using IMA subsystem.
>> + */
>> +#include <linux/vmalloc.h>
>> +#include <linux/ktime.h>
>> +#include <linux/ima.h>
>> +#include "security.h"
>> +
>> +/*
>> + * This function creates a unique name by appending the timestamp to
>> + * the given string. This string is passed as "event_name" to the IMA
>> + * hook to measure the given SELinux data.
>> + *
>> + * The data provided by SELinux to the IMA subsystem for measuring may have
>> + * already been measured (for instance the same state existed earlier).
>> + * But for SELinux the current data represents a state change and hence
>> + * needs to be measured again. To enable this, pass a unique "event_name"
>> + * to the IMA hook so that IMA subsystem will always measure the given data.
>> + *
>> + * For example,
>> + * At time T0 SELinux data to be measured is "foo". IMA measures it.
>> + * At time T1 the data is changed to "bar". IMA measures it.
>> + * At time T2 the data is changed to "foo" again. IMA will not measure it
>> + * (since it was already measured) unless the event_name, for instance,
>> + * is different in this call.
>> + */
>> +static char *selinux_event_name(const char *name_prefix)
>> +{
>> + struct timespec64 cur_time;
>> +
>> + ktime_get_real_ts64(&cur_time);
>> + return kasprintf(GFP_KERNEL, "%s-%lld:%09ld", name_prefix,
>> + cur_time.tv_sec, cur_time.tv_nsec);
>> +}
>
> Why is this a separate function? It's three lines long and only
> called from selinux_measure_state(). Do you ever see the SELinux/IMA
> code in this file expanding to the point where this function is nice
> from a reuse standpoint?

Earlier I had two measurements - one for SELinux configuration/state and
another for SELinux policy. selinux_event_name() was used to generate
event name for each of them.

In this patch set I have included only one measurement - for SELinux
policy. I plan to add "SELinux configuration/state" measurement in a
separate patch - I can reuse selinux_event_name() in that patch.

Also, I think the comment in the function header for
selinux_event_name() is useful.

I prefer to have a separate function, if that's fine by you.

>
> Also, I assume you are not concerned about someone circumventing the
> IMA measurements by manipulating the time? In most systems I would
> expect the time to be a protected entity, but with many systems
> getting their time from remote systems I thought it was worth
> mentioning.
I am using time function to generate a unique name for the IMA
measurement event, such as, "selinux-policy-hash-1609790281:860232824".
This is to ensure that state changes in SELinux data are always measured.

If you think time manipulation can be an issue, please let me know a
better way to generate unique event names.

>
>> +/*
>> + * selinux_measure_state - Measure hash of the SELinux policy
>> + *
>> + * @state: selinux state struct
>> + *
>> + * NOTE: This function must be called with policy_mutex held.
>> + */
>> +void selinux_measure_state(struct selinux_state *state)
>
> Similar to the name of this source file, let's make it clear this is
> for IMA. How about calling this selinux_ima_measure_state() or
> similar?
Sure - I will change the function name to selinux_ima_measure_state().

>
>> +{
>> + void *policy = NULL;
>> + char *policy_event_name = NULL;
>> + size_t policy_len;
>> + int rc = 0;
>> + bool initialized = selinux_initialized(state);
>
> Why bother with the initialized variable? Unless I'm missing
> something it is only used once in the code below.
You are right - I will remove "initialized" variable and directly get
the state using selinux_initialized().

>
>> + /*
>> + * Measure SELinux policy only after initialization is completed.
>> + */
>> + if (!initialized)
>> + goto out;
>> +
>> + policy_event_name = selinux_event_name("selinux-policy-hash");
>> + if (!policy_event_name) {
>> + pr_err("SELinux: %s: event name for policy not allocated.\n",
>> + __func__);
>> + rc = -ENOMEM;
>
> This function doesn't return an error code, why bother with setting
> the rc variable here?
Yes - it is not necessary. I will remove the line.

>
>> + goto out;
>> + }
>> +
>> + rc = security_read_policy_kernel(state, &policy, &policy_len);
>> + if (rc) {
>> + pr_err("SELinux: %s: failed to read policy %d.\n", __func__, rc);
>> + goto out;
>> + }
>> +
>> + ima_measure_critical_data("selinux", policy_event_name,
>> + policy, policy_len, true);
>> +
>> + vfree(policy);
>> +
>> +out:
>> + kfree(policy_event_name);
>> +}
>> diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
>> index 9704c8a32303..dfa2e00894ae 100644
>> --- a/security/selinux/ss/services.c
>> +++ b/security/selinux/ss/services.c
>> @@ -2180,6 +2180,7 @@ static void selinux_notify_policy_change(struct selinux_state *state,
>> selinux_status_update_policyload(state, seqno);
>> selinux_netlbl_cache_invalidate();
>> selinux_xfrm_notify_policyload();
>> + selinux_measure_state(state);
>> }
>>
>> void selinux_policy_commit(struct selinux_state *state,
>> @@ -3875,8 +3876,33 @@ int security_netlbl_sid_to_secattr(struct selinux_state *state,
>> }
>> #endif /* CONFIG_NETLABEL */
>>
>> +/**
>> + * security_read_selinux_policy - read the policy.
>> + * @policy: SELinux policy
>> + * @data: binary policy data
>> + * @len: length of data in bytes
>> + *
>> + */
>> +static int security_read_selinux_policy(struct selinux_policy *policy,
>> + void *data, size_t *len)
>
> Let's just call this "security_read_policy()".
There is another function in this file with the name security_read_policy().

How about changing the above function name to "read_selinux_policy()"
since this is a local/static function.

>
>> +{
>> + int rc;
>> + struct policy_file fp;
>> +
>> + fp.data = data;
>> + fp.len = *len;
>> +
>> + rc = policydb_write(&policy->policydb, &fp);
>> + if (rc)
>> + return rc;
>> +
>> + *len = (unsigned long)fp.data - (unsigned long)data;
>> + return 0;
>> +}
>> +
>> /**
>> * security_read_policy - read the policy.
>> + * @state: selinux_state
>> * @data: binary policy data
>> * @len: length of data in bytes
>> *
>> @@ -3885,8 +3911,6 @@ int security_read_policy(struct selinux_state *state,
>> void **data, size_t *len)
>> {
>> struct selinux_policy *policy;
>> - int rc;
>> - struct policy_file fp;
>>
>> policy = rcu_dereference_protected(
>> state->policy, lockdep_is_held(&state->policy_mutex));
>> @@ -3898,14 +3922,43 @@ int security_read_policy(struct selinux_state *state,
>> if (!*data)> --
>> 2.17.1
>>
>
>> return -ENOMEM;
>>
>> - fp.data = *data;
>> - fp.len = *len;
>> + return security_read_selinux_policy(policy, *data, len);
>> +}
>>
>> - rc = policydb_write(&policy->policydb, &fp);
>> - if (rc)
>> - return rc;
>> +/**
>> + * security_read_policy_kernel - read the policy.
>> + * @state: selinux_state
>> + * @data: binary policy data
>> + * @len: length of data in bytes
>> + *
>> + * Allocates kernel memory for reading SELinux policy.
>> + * This function is for internal use only and should not
>> + * be used for returning data to user space.
>> + *
>> + * This function must be called with policy_mutex held.
>> + */
>> +int security_read_policy_kernel(struct selinux_state *state,
>> + void **data, size_t *len)
>
> Let's call this "security_read_state_kernel()".
Sure - I will rename the function.

>
>> +{
>> + struct selinux_policy *policy;
>> + int rc = 0;
>
> See below, the rc variable is not needed.
>
>> - *len = (unsigned long)fp.data - (unsigned long)*data;
>> - return 0;
>> + policy = rcu_dereference_protected(
>> + state->policy, lockdep_is_held(&state->policy_mutex));
>> + if (!policy) {
>> + rc = -EINVAL;
>> + goto out;
>
> Jumping to the out label is a little silly since it is just a return;
> do a "return -EINVAL;" here instead.
>
>> + }
>> +
>> + *len = policy->policydb.len;
>> + *data = vmalloc(*len);
>> + if (!*data) {
>> + rc = -ENOMEM;
>> + goto out;
>
> Same as above, "return -ENOMEM;" please.
>
>> + }
>>
>> + rc = security_read_selinux_policy(policy, *data, len);
>
> You should be able to do "return security_read_selinux_policy(...);" here.

I will remove the local variable "rc" and make the three changes you've
stated above.

Thanks for reviewing the changes.

-lakshmi

>
>> +
>> +out:
>> + return rc;
>> }
>

2021-01-05 02:15:54

by Paul Moore

[permalink] [raw]
Subject: Re: [PATCH v9 8/8] selinux: include a consumer of the new IMA critical data hook

On Mon, Jan 4, 2021 at 6:30 PM Lakshmi Ramasubramanian
<[email protected]> wrote:
> On 12/23/20 1:10 PM, Paul Moore wrote:
> Hi Paul,

Hello.

> >> diff --git a/security/selinux/measure.c b/security/selinux/measure.c
> >> new file mode 100644
> >> index 000000000000..b7e24358e11d
> >> --- /dev/null
> >> +++ b/security/selinux/measure.c
> >> @@ -0,0 +1,79 @@
> >> +// SPDX-License-Identifier: GPL-2.0-or-later
> >> +/*
> >> + * Measure SELinux state using IMA subsystem.
> >> + */
> >> +#include <linux/vmalloc.h>
> >> +#include <linux/ktime.h>
> >> +#include <linux/ima.h>
> >> +#include "security.h"
> >> +
> >> +/*
> >> + * This function creates a unique name by appending the timestamp to
> >> + * the given string. This string is passed as "event_name" to the IMA
> >> + * hook to measure the given SELinux data.
> >> + *
> >> + * The data provided by SELinux to the IMA subsystem for measuring may have
> >> + * already been measured (for instance the same state existed earlier).
> >> + * But for SELinux the current data represents a state change and hence
> >> + * needs to be measured again. To enable this, pass a unique "event_name"
> >> + * to the IMA hook so that IMA subsystem will always measure the given data.
> >> + *
> >> + * For example,
> >> + * At time T0 SELinux data to be measured is "foo". IMA measures it.
> >> + * At time T1 the data is changed to "bar". IMA measures it.
> >> + * At time T2 the data is changed to "foo" again. IMA will not measure it
> >> + * (since it was already measured) unless the event_name, for instance,
> >> + * is different in this call.
> >> + */
> >> +static char *selinux_event_name(const char *name_prefix)
> >> +{
> >> + struct timespec64 cur_time;
> >> +
> >> + ktime_get_real_ts64(&cur_time);
> >> + return kasprintf(GFP_KERNEL, "%s-%lld:%09ld", name_prefix,
> >> + cur_time.tv_sec, cur_time.tv_nsec);
> >> +}
> >
> > Why is this a separate function? It's three lines long and only
> > called from selinux_measure_state(). Do you ever see the SELinux/IMA
> > code in this file expanding to the point where this function is nice
> > from a reuse standpoint?
>
> Earlier I had two measurements - one for SELinux configuration/state and
> another for SELinux policy. selinux_event_name() was used to generate
> event name for each of them.
>
> In this patch set I have included only one measurement - for SELinux
> policy. I plan to add "SELinux configuration/state" measurement in a
> separate patch - I can reuse selinux_event_name() in that patch.

I'm curious about this second measurement. My apologies if you posted
it previously, this patchset has gone through several iterations and
simply can't recall all the different versions without digging through
the list archives.

Is there a reason why the second measurement isn't included in this
patch? Or this patchset if it is too big to be a single patch?

> Also, I think the comment in the function header for
> selinux_event_name() is useful.
>
> I prefer to have a separate function, if that's fine by you.

Given just this patch I would prefer if you folded
selinux_event_name() into selinux_measure_state(). However, I agree
with you that the comments in the selinux_event_name() header block is
useful, I would suggest moving those into the body of
selinux_measure_state() directly above the calls to
ktime_get_real_ts64() and kasprintf().

> > Also, I assume you are not concerned about someone circumventing the
> > IMA measurements by manipulating the time? In most systems I would
> > expect the time to be a protected entity, but with many systems
> > getting their time from remote systems I thought it was worth
> > mentioning.
>
> I am using time function to generate a unique name for the IMA
> measurement event, such as, "selinux-policy-hash-1609790281:860232824".
> This is to ensure that state changes in SELinux data are always measured.
>
> If you think time manipulation can be an issue, please let me know a
> better way to generate unique event names.

Yes, I understand that you are using the time value as a way of
ensuring you always have a different event name and hence a new
measurement. However, I was wondering if you would be okay if the
time was adjusted such that an event name was duplicated and a
measurement missed? Is that a problem for you? It seems like it
might be an issue, but you and Mimi know IMA better than I do.

> >> diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
> >> index 9704c8a32303..dfa2e00894ae 100644
> >> --- a/security/selinux/ss/services.c
> >> +++ b/security/selinux/ss/services.c
> >> @@ -3875,8 +3876,33 @@ int security_netlbl_sid_to_secattr(struct selinux_state *state,
> >> }
> >> #endif /* CONFIG_NETLABEL */
> >>
> >> +/**
> >> + * security_read_selinux_policy - read the policy.
> >> + * @policy: SELinux policy
> >> + * @data: binary policy data
> >> + * @len: length of data in bytes
> >> + *
> >> + */
> >> +static int security_read_selinux_policy(struct selinux_policy *policy,
> >> + void *data, size_t *len)
> >
> > Let's just call this "security_read_policy()".
> There is another function in this file with the name security_read_policy().
>
> How about changing the above function name to "read_selinux_policy()"
> since this is a local/static function.

Ooops, sorry about that! I'm not sure what I was thinking there :)

How about "__security_read_policy()"?

--
paul moore
http://www.paul-moore.com

2021-01-05 05:29:00

by Lakshmi Ramasubramanian

[permalink] [raw]
Subject: Re: [PATCH v9 8/8] selinux: include a consumer of the new IMA critical data hook

On 1/4/21 6:13 PM, Paul Moore wrote:
> On Mon, Jan 4, 2021 at 6:30 PM Lakshmi Ramasubramanian
> <[email protected]> wrote:
>> On 12/23/20 1:10 PM, Paul Moore wrote:
>> Hi Paul,
>
> Hello.
>
>>>> diff --git a/security/selinux/measure.c b/security/selinux/measure.c
>>>> new file mode 100644
>>>> index 000000000000..b7e24358e11d
>>>> --- /dev/null
>>>> +++ b/security/selinux/measure.c
>>>> @@ -0,0 +1,79 @@
>>>> +// SPDX-License-Identifier: GPL-2.0-or-later
>>>> +/*
>>>> + * Measure SELinux state using IMA subsystem.
>>>> + */
>>>> +#include <linux/vmalloc.h>
>>>> +#include <linux/ktime.h>
>>>> +#include <linux/ima.h>
>>>> +#include "security.h"
>>>> +
>>>> +/*
>>>> + * This function creates a unique name by appending the timestamp to
>>>> + * the given string. This string is passed as "event_name" to the IMA
>>>> + * hook to measure the given SELinux data.
>>>> + *
>>>> + * The data provided by SELinux to the IMA subsystem for measuring may have
>>>> + * already been measured (for instance the same state existed earlier).
>>>> + * But for SELinux the current data represents a state change and hence
>>>> + * needs to be measured again. To enable this, pass a unique "event_name"
>>>> + * to the IMA hook so that IMA subsystem will always measure the given data.
>>>> + *
>>>> + * For example,
>>>> + * At time T0 SELinux data to be measured is "foo". IMA measures it.
>>>> + * At time T1 the data is changed to "bar". IMA measures it.
>>>> + * At time T2 the data is changed to "foo" again. IMA will not measure it
>>>> + * (since it was already measured) unless the event_name, for instance,
>>>> + * is different in this call.
>>>> + */
>>>> +static char *selinux_event_name(const char *name_prefix)
>>>> +{
>>>> + struct timespec64 cur_time;
>>>> +
>>>> + ktime_get_real_ts64(&cur_time);
>>>> + return kasprintf(GFP_KERNEL, "%s-%lld:%09ld", name_prefix,
>>>> + cur_time.tv_sec, cur_time.tv_nsec);
>>>> +}
>>>
>>> Why is this a separate function? It's three lines long and only
>>> called from selinux_measure_state(). Do you ever see the SELinux/IMA
>>> code in this file expanding to the point where this function is nice
>>> from a reuse standpoint?
>>
>> Earlier I had two measurements - one for SELinux configuration/state and
>> another for SELinux policy. selinux_event_name() was used to generate
>> event name for each of them.
>>
>> In this patch set I have included only one measurement - for SELinux
>> policy. I plan to add "SELinux configuration/state" measurement in a
>> separate patch - I can reuse selinux_event_name() in that patch.
>
> I'm curious about this second measurement. My apologies if you posted
> it previously, this patchset has gone through several iterations and
> simply can't recall all the different versions without digging through
> the list archives.
>

The 2nd measurement is for SELinux state data such as "enforcing",
"checkreqprot", policycap[__POLICYDB_CAPABILITY_MAX], etc.

> Is there a reason why the second measurement isn't included in this
> patch? Or this patchset if it is too big to be a single patch?
>

For illustrating the use of the new IMA hook, that my colleague Tushar
has added for measuring kernel critical data, we have included only one
SELinux measurement in this patch set - the measurement of SELinux
policy. This also helped in keeping this patch smaller.

When this patch set is merged, I'll post a separate patch to add
measurement of SELinux state data I have mentioned above.

>> Also, I think the comment in the function header for
>> selinux_event_name() is useful.
>>
>> I prefer to have a separate function, if that's fine by you.
>
> Given just this patch I would prefer if you folded
> selinux_event_name() into selinux_measure_state(). However, I agree
> with you that the comments in the selinux_event_name() header block is
> useful, I would suggest moving those into the body of
> selinux_measure_state() directly above the calls to
> ktime_get_real_ts64() and kasprintf().

Sure - I will make that change.

>
>>> Also, I assume you are not concerned about someone circumventing the
>>> IMA measurements by manipulating the time? In most systems I would
>>> expect the time to be a protected entity, but with many systems
>>> getting their time from remote systems I thought it was worth
>>> mentioning.
>>
>> I am using time function to generate a unique name for the IMA
>> measurement event, such as, "selinux-policy-hash-1609790281:860232824".
>> This is to ensure that state changes in SELinux data are always measured.
>>
>> If you think time manipulation can be an issue, please let me know a
>> better way to generate unique event names.
>
> Yes, I understand that you are using the time value as a way of
> ensuring you always have a different event name and hence a new
> measurement. However, I was wondering if you would be okay if the
> time was adjusted such that an event name was duplicated and a
> measurement missed? Is that a problem for you? It seems like it
> might be an issue, but you and Mimi know IMA better than I do.

If the system time was adjusted such that the event name is duplicated,
we could miss measurements - this is not okay.

For example:
#1 Say, at time T1 SELinux state being measured is "foo" - IMA will
measure it.
#2 at time T2, the state changes to "bar" - IMA will measure it
#3 at time T3, the state changes from "bar" to "foo" again. Unless the
"event name" passed in the measurement call is different from what was
passed in step #1, IMA will not measure it and hence we'll miss the
state change.

If system time can be manipulated to return the same "timer tick" on
every call to ktime_get_real_ts64(), we will lose measurement in Step #3
above.

But given that we are using ktime_get_real_ts64() to get the timer tick,
is it possible to manipulate the system time without compromising the
overall functioning of the rest of the system? If yes, then it is an
issue - I mean, there is a possibility of losing some measurements.

>
>>>> diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
>>>> index 9704c8a32303..dfa2e00894ae 100644
>>>> --- a/security/selinux/ss/services.c
>>>> +++ b/security/selinux/ss/services.c
>>>> @@ -3875,8 +3876,33 @@ int security_netlbl_sid_to_secattr(struct selinux_state *state,
>>>> }
>>>> #endif /* CONFIG_NETLABEL */
>>>>
>>>> +/**
>>>> + * security_read_selinux_policy - read the policy.
>>>> + * @policy: SELinux policy
>>>> + * @data: binary policy data
>>>> + * @len: length of data in bytes
>>>> + *
>>>> + */
>>>> +static int security_read_selinux_policy(struct selinux_policy *policy,
>>>> + void *data, size_t *len)
>>>
>>> Let's just call this "security_read_policy()".
>> There is another function in this file with the name security_read_policy().
>>
>> How about changing the above function name to "read_selinux_policy()"
>> since this is a local/static function.
>
> Ooops, sorry about that! I'm not sure what I was thinking there :)
>
> How about "__security_read_policy()"?
>

Sure - I will change the function name to "__security_read_policy()".

thanks,
-lakshmi

2021-01-05 23:01:55

by Tushar Sugandhi

[permalink] [raw]
Subject: Re: [PATCH v9 7/8] IMA: define a builtin critical data measurement policy



On 2020-12-24 6:41 a.m., Mimi Zohar wrote:
> On Sat, 2020-12-12 at 10:02 -0800, Tushar Sugandhi wrote:
>> From: Lakshmi Ramasubramanian <[email protected]>
>>
>> Define a new critical data builtin policy to allow measuring
>> early kernel integrity critical data before a custom IMA policy
>> is loaded.
>>
>> Add critical data to built-in IMA rules if the kernel command line
>> contains "ima_policy=critical_data".
>
> This sentence isn't really necessary.
>
Will remove.
>>
>> Update the documentation on kernel parameters to document
>> the new critical data builtin policy.
>>
>> Signed-off-by: Lakshmi Ramasubramanian <[email protected]>
>> Reviewed-by: Tyler Hicks <[email protected]>
>
> Otherwise,
> Reviewed-by: Mimi Zohar <[email protected]>
Thanks again for the "Reviewed-by" tag.

Thanks,
Tushar
>
> thanks,
>
> Mimi
>