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
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 ..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
+#include
+#include
+#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(_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
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
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 ..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
> >> +#include
> >> +#include
> >> +#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(_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
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 ..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
+#include
+#include
+#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(_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
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
wrote:
> From: Lakshmi Ramasubramanian
>
> 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
> Suggested-by: Stephen Smalley
> Reviewed-by: Tyler Hicks
> ---
> 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 ..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
> +#include
> +#include
> +#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
[PATCH v9 8/8] selinux: include a consumer of the new IMA critical data hook
From: Lakshmi Ramasubramanian
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
Suggested-by: Stephen Smalley
Reviewed-by: Tyler Hicks
---
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 ..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
+#include
+#include
+#include "security.h"
+
+/*
+ * This function creates a unique name by appending the
