From: Lakshmi Ramasubramanian <email@example.com>
To: Paul Moore <firstname.lastname@example.org>
Cc: Tushar Sugandhi <email@example.com>,
Stephen Smalley <firstname.lastname@example.org>,
email@example.com, firstname.lastname@example.org, email@example.com,
firstname.lastname@example.org, James Morris <email@example.com>,
Subject: Re: [PATCH v9 8/8] selinux: include a consumer of the new IMA critical data hook
Date: Mon, 4 Jan 2021 21:24:58 -0800 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
On 1/4/21 6:13 PM, Paul Moore wrote:
> On Mon, Jan 4, 2021 at 6:30 PM Lakshmi Ramasubramanian
> <email@example.com> wrote:
>> On 12/23/20 1:10 PM, Paul Moore wrote:
>> Hi Paul,
>>>> 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
>> 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.
#1 Say, at time T1 SELinux state being measured is "foo" - IMA will
#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
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
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()".
prev parent reply other threads:[~2021-01-05 5:25 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-12 18:02 [PATCH v9 0/8] IMA: support for measuring kernel integrity critical data Tushar Sugandhi
2020-12-12 18:02 ` [PATCH v9 1/8] IMA: generalize keyring specific measurement constructs Tushar Sugandhi
2020-12-24 13:06 ` Mimi Zohar
2021-01-05 18:48 ` Tushar Sugandhi
2020-12-12 18:02 ` [PATCH v9 2/8] IMA: add support to measure buffer data hash Tushar Sugandhi
2020-12-24 0:03 ` Mimi Zohar
2021-01-05 18:53 ` Tushar Sugandhi
2021-01-06 5:00 ` Tushar Sugandhi
2020-12-12 18:02 ` [PATCH v9 3/8] IMA: define a hook to measure kernel integrity critical data Tushar Sugandhi
2020-12-24 13:04 ` Mimi Zohar
2021-01-05 20:01 ` Tushar Sugandhi
2021-01-05 20:16 ` Mimi Zohar
2021-01-05 20:19 ` Tushar Sugandhi
2020-12-12 18:02 ` [PATCH v9 4/8] IMA: add policy rule to measure " Tushar Sugandhi
2020-12-12 19:20 ` Tyler Hicks
2020-12-13 1:21 ` Tushar Sugandhi
2020-12-24 13:48 ` Mimi Zohar
2021-01-05 20:12 ` Tushar Sugandhi
2020-12-12 18:02 ` [PATCH v9 5/8] IMA: limit critical data measurement based on a label Tushar Sugandhi
2020-12-12 19:20 ` Tyler Hicks
2020-12-13 1:21 ` Tushar Sugandhi
2020-12-24 14:29 ` Mimi Zohar
2021-01-05 20:28 ` Tushar Sugandhi
2020-12-12 18:02 ` [PATCH v9 6/8] IMA: extend critical data hook to limit the " Tushar Sugandhi
2020-12-12 18:02 ` [PATCH v9 7/8] IMA: define a builtin critical data measurement policy Tushar Sugandhi
2020-12-24 14:41 ` Mimi Zohar
2021-01-05 20:30 ` Tushar Sugandhi
2020-12-12 18:02 ` [PATCH v9 8/8] selinux: include a consumer of the new IMA critical data hook Tushar Sugandhi
2020-12-23 21:10 ` Paul Moore
2021-01-04 23:30 ` Lakshmi Ramasubramanian
2021-01-05 2:13 ` Paul Moore
2021-01-05 5:24 ` Lakshmi Ramasubramanian [this message]
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).