SELinux stores the configuration state and the policy capabilities
in kernel memory. Changes to this data at runtime would have an impact
on the security guarantees provided by SELinux. Measuring this data
through IMA subsystem provides a tamper-resistant way for
an attestation service to remotely validate it at runtime.
Measure the configuration state and policy capabilities by calling
the IMA hook ima_measure_critical_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.11.0-rc3+ 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 label=selinux
Sample measurement of SELinux state and policy capabilities:
10 2122...65d8 ima-buf sha256:13c2...1292 selinux-state 696e...303b
Execute the following command to extract the measured data
from the IMA's runtime measurements list:
grep "selinux-state" /sys/kernel/security/integrity/ima/ascii_runtime_measurements | tail -1 | cut -d' ' -f 6 | xxd -r -p
The output should be a list of key-value pairs. For example,
initialized=1;enforcing=0;checkreqprot=1;network_peer_controls=1;open_perms=1;extended_socket_class=1;always_check_network=0;cgroup_seclabel=1;nnp_nosuid_transition=1;genfs_seclabel_symlinks=0;
To verify the measurement is consistent with the current SELinux state
reported on the system, compare the integer values in the following
files with those set in the IMA measurement (using the following commands):
- cat /sys/fs/selinux/enforce
- cat /sys/fs/selinux/checkreqprot
- cat /sys/fs/selinux/policy_capabilities/[capability_file]
Note that the actual verification would be against an expected state
and done on a separate system (likely an attestation server) requiring
"initialized=1;enforcing=1;checkreqprot=0;"
for a secure state and then whatever policy capabilities are actually
set in the expected policy (which can be extracted from the policy
itself via seinfo, for example).
Signed-off-by: Lakshmi Ramasubramanian <[email protected]>
Suggested-by: Stephen Smalley <[email protected]>
Suggested-by: Paul Moore <[email protected]>
---
security/selinux/ima.c | 87 ++++++++++++++++++++++++++++++++--
security/selinux/include/ima.h | 6 +++
security/selinux/selinuxfs.c | 6 +++
security/selinux/ss/services.c | 2 +-
4 files changed, 96 insertions(+), 5 deletions(-)
diff --git a/security/selinux/ima.c b/security/selinux/ima.c
index 03715893ff97..34d421861bfc 100644
--- a/security/selinux/ima.c
+++ b/security/selinux/ima.c
@@ -13,18 +13,83 @@
#include "ima.h"
/*
- * selinux_ima_measure_state - Measure hash of the SELinux policy
+ * selinux_ima_collect_state - Read selinux configuration settings
*
- * @state: selinux state struct
+ * @state: selinux_state
*
- * NOTE: This function must be called with policy_mutex held.
+ * On success returns the configuration settings string.
+ * On error, returns NULL.
*/
-void selinux_ima_measure_state(struct selinux_state *state)
+static char *selinux_ima_collect_state(struct selinux_state *state)
{
+ const char *on = "=1;", *off = "=0;";
+ char *buf;
+ int buf_len, len, i, rc;
+
+ buf_len = strlen("initialized=0;enforcing=0;checkreqprot=0;") + 1;
+
+ len = strlen(on);
+ for (i = 0; i < __POLICYDB_CAPABILITY_MAX; i++)
+ buf_len += strlen(selinux_policycap_names[i]) + len;
+
+ buf = kzalloc(buf_len, GFP_KERNEL);
+ if (!buf)
+ return NULL;
+
+ rc = strscpy(buf, "initialized", buf_len);
+ WARN_ON(rc < 0);
+
+ rc = strlcat(buf, selinux_initialized(state) ? on : off, buf_len);
+ WARN_ON(rc >= buf_len);
+
+ rc = strlcat(buf, "enforcing", buf_len);
+ WARN_ON(rc >= buf_len);
+
+ rc = strlcat(buf, enforcing_enabled(state) ? on : off, buf_len);
+ WARN_ON(rc >= buf_len);
+
+ rc = strlcat(buf, "checkreqprot", buf_len);
+ WARN_ON(rc >= buf_len);
+
+ rc = strlcat(buf, checkreqprot_get(state) ? on : off, buf_len);
+ WARN_ON(rc >= buf_len);
+
+ for (i = 0; i < __POLICYDB_CAPABILITY_MAX; i++) {
+ rc = strlcat(buf, selinux_policycap_names[i], buf_len);
+ WARN_ON(rc >= buf_len);
+
+ rc = strlcat(buf, state->policycap[i] ? on : off, buf_len);
+ WARN_ON(rc >= buf_len);
+ }
+
+ return buf;
+}
+
+/*
+ * selinux_ima_measure_state_locked - Measure SELinux state and hash of policy
+ *
+ * @state: selinux state struct
+ */
+void selinux_ima_measure_state_locked(struct selinux_state *state)
+{
+ char *state_str = NULL;
void *policy = NULL;
size_t policy_len;
int rc = 0;
+ WARN_ON(!mutex_is_locked(&state->policy_mutex));
+
+ state_str = selinux_ima_collect_state(state);
+ if (!state_str) {
+ pr_err("SELinux: %s: failed to read state.\n", __func__);
+ return;
+ }
+
+ ima_measure_critical_data("selinux", "selinux-state",
+ state_str, strlen(state_str), false);
+
+ kfree(state_str);
+
/*
* Measure SELinux policy only after initialization is completed.
*/
@@ -42,3 +107,17 @@ void selinux_ima_measure_state(struct selinux_state *state)
vfree(policy);
}
+
+/*
+ * selinux_ima_measure_state - Measure SELinux state and hash of policy
+ *
+ * @state: selinux state struct
+ */
+void selinux_ima_measure_state(struct selinux_state *state)
+{
+ WARN_ON(mutex_is_locked(&state->policy_mutex));
+
+ mutex_lock(&state->policy_mutex);
+ selinux_ima_measure_state_locked(state);
+ mutex_unlock(&state->policy_mutex);
+}
diff --git a/security/selinux/include/ima.h b/security/selinux/include/ima.h
index d69c36611423..75ca92b4a462 100644
--- a/security/selinux/include/ima.h
+++ b/security/selinux/include/ima.h
@@ -15,10 +15,16 @@
#ifdef CONFIG_IMA
extern void selinux_ima_measure_state(struct selinux_state *selinux_state);
+extern void selinux_ima_measure_state_locked(
+ struct selinux_state *selinux_state);
#else
static inline void selinux_ima_measure_state(struct selinux_state *selinux_state)
{
}
+static inline void selinux_ima_measure_state_locked(
+ struct selinux_state *selinux_state)
+{
+}
#endif
#endif /* _SELINUX_IMA_H_ */
diff --git a/security/selinux/selinuxfs.c b/security/selinux/selinuxfs.c
index 4bde570d56a2..26ec58593ba1 100644
--- a/security/selinux/selinuxfs.c
+++ b/security/selinux/selinuxfs.c
@@ -41,6 +41,7 @@
#include "security.h"
#include "objsec.h"
#include "conditional.h"
+#include "ima.h"
enum sel_inos {
SEL_ROOT_INO = 2,
@@ -182,6 +183,8 @@ static ssize_t sel_write_enforce(struct file *file, const char __user *buf,
selinux_status_update_setenforce(state, new_value);
if (!new_value)
call_blocking_lsm_notifier(LSM_POLICY_CHANGE, NULL);
+
+ selinux_ima_measure_state(state);
}
length = count;
out:
@@ -762,6 +765,9 @@ static ssize_t sel_write_checkreqprot(struct file *file, const char __user *buf,
checkreqprot_set(fsi->state, (new_value ? 1 : 0));
length = count;
+
+ selinux_ima_measure_state(fsi->state);
+
out:
kfree(page);
return length;
diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
index 2106b5d383e7..cb2866489363 100644
--- a/security/selinux/ss/services.c
+++ b/security/selinux/ss/services.c
@@ -2179,7 +2179,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_ima_measure_state(state);
+ selinux_ima_measure_state_locked(state);
}
void selinux_policy_commit(struct selinux_state *state,
--
2.30.0
On 2/12/21 8:37 AM, Lakshmi Ramasubramanian wrote:
Hi Paul,
> SELinux stores the configuration state and the policy capabilities
> in kernel memory. Changes to this data at runtime would have an impact
> on the security guarantees provided by SELinux. Measuring this data
> through IMA subsystem provides a tamper-resistant way for
> an attestation service to remotely validate it at runtime.
>
> Measure the configuration state and policy capabilities by calling
> the IMA hook ima_measure_critical_data().
>
I have addressed your comments on the v2 patch for selinux measurement
using IMA. Could you please let me know if there are any other comments
that I need to address in this patch?
Thanks for your review and help so far.
-lakshmi
>
> Signed-off-by: Lakshmi Ramasubramanian <[email protected]>
> Suggested-by: Stephen Smalley <[email protected]>
> Suggested-by: Paul Moore <[email protected]>
> ---
> security/selinux/ima.c | 87 ++++++++++++++++++++++++++++++++--
> security/selinux/include/ima.h | 6 +++
> security/selinux/selinuxfs.c | 6 +++
> security/selinux/ss/services.c | 2 +-
> 4 files changed, 96 insertions(+), 5 deletions(-)
>
> diff --git a/security/selinux/ima.c b/security/selinux/ima.c
> index 03715893ff97..34d421861bfc 100644
> --- a/security/selinux/ima.c
> +++ b/security/selinux/ima.c
> @@ -13,18 +13,83 @@
> #include "ima.h"
>
> /*
> - * selinux_ima_measure_state - Measure hash of the SELinux policy
> + * selinux_ima_collect_state - Read selinux configuration settings
> *
> - * @state: selinux state struct
> + * @state: selinux_state
> *
> - * NOTE: This function must be called with policy_mutex held.
> + * On success returns the configuration settings string.
> + * On error, returns NULL.
> */
> -void selinux_ima_measure_state(struct selinux_state *state)
> +static char *selinux_ima_collect_state(struct selinux_state *state)
> {
> + const char *on = "=1;", *off = "=0;";
> + char *buf;
> + int buf_len, len, i, rc;
> +
> + buf_len = strlen("initialized=0;enforcing=0;checkreqprot=0;") + 1;
> +
> + len = strlen(on);
> + for (i = 0; i < __POLICYDB_CAPABILITY_MAX; i++)
> + buf_len += strlen(selinux_policycap_names[i]) + len;
> +
> + buf = kzalloc(buf_len, GFP_KERNEL);
> + if (!buf)
> + return NULL;
> +
> + rc = strscpy(buf, "initialized", buf_len);
> + WARN_ON(rc < 0);
> +
> + rc = strlcat(buf, selinux_initialized(state) ? on : off, buf_len);
> + WARN_ON(rc >= buf_len);
> +
> + rc = strlcat(buf, "enforcing", buf_len);
> + WARN_ON(rc >= buf_len);
> +
> + rc = strlcat(buf, enforcing_enabled(state) ? on : off, buf_len);
> + WARN_ON(rc >= buf_len);
> +
> + rc = strlcat(buf, "checkreqprot", buf_len);
> + WARN_ON(rc >= buf_len);
> +
> + rc = strlcat(buf, checkreqprot_get(state) ? on : off, buf_len);
> + WARN_ON(rc >= buf_len);
> +
> + for (i = 0; i < __POLICYDB_CAPABILITY_MAX; i++) {
> + rc = strlcat(buf, selinux_policycap_names[i], buf_len);
> + WARN_ON(rc >= buf_len);
> +
> + rc = strlcat(buf, state->policycap[i] ? on : off, buf_len);
> + WARN_ON(rc >= buf_len);
> + }
> +
> + return buf;
> +}
> +
> +/*
> + * selinux_ima_measure_state_locked - Measure SELinux state and hash of policy
> + *
> + * @state: selinux state struct
> + */
> +void selinux_ima_measure_state_locked(struct selinux_state *state)
> +{
> + char *state_str = NULL;
> void *policy = NULL;
> size_t policy_len;
> int rc = 0;
>
> + WARN_ON(!mutex_is_locked(&state->policy_mutex));
> +
> + state_str = selinux_ima_collect_state(state);
> + if (!state_str) {
> + pr_err("SELinux: %s: failed to read state.\n", __func__);
> + return;
> + }
> +
> + ima_measure_critical_data("selinux", "selinux-state",
> + state_str, strlen(state_str), false);
> +
> + kfree(state_str);
> +
> /*
> * Measure SELinux policy only after initialization is completed.
> */
> @@ -42,3 +107,17 @@ void selinux_ima_measure_state(struct selinux_state *state)
>
> vfree(policy);
> }
> +
> +/*
> + * selinux_ima_measure_state - Measure SELinux state and hash of policy
> + *
> + * @state: selinux state struct
> + */
> +void selinux_ima_measure_state(struct selinux_state *state)
> +{
> + WARN_ON(mutex_is_locked(&state->policy_mutex));
> +
> + mutex_lock(&state->policy_mutex);
> + selinux_ima_measure_state_locked(state);
> + mutex_unlock(&state->policy_mutex);
> +}
> diff --git a/security/selinux/include/ima.h b/security/selinux/include/ima.h
> index d69c36611423..75ca92b4a462 100644
> --- a/security/selinux/include/ima.h
> +++ b/security/selinux/include/ima.h
> @@ -15,10 +15,16 @@
>
> #ifdef CONFIG_IMA
> extern void selinux_ima_measure_state(struct selinux_state *selinux_state);
> +extern void selinux_ima_measure_state_locked(
> + struct selinux_state *selinux_state);
> #else
> static inline void selinux_ima_measure_state(struct selinux_state *selinux_state)
> {
> }
> +static inline void selinux_ima_measure_state_locked(
> + struct selinux_state *selinux_state)
> +{
> +}
> #endif
>
> #endif /* _SELINUX_IMA_H_ */
> diff --git a/security/selinux/selinuxfs.c b/security/selinux/selinuxfs.c
> index 4bde570d56a2..26ec58593ba1 100644
> --- a/security/selinux/selinuxfs.c
> +++ b/security/selinux/selinuxfs.c
> @@ -41,6 +41,7 @@
> #include "security.h"
> #include "objsec.h"
> #include "conditional.h"
> +#include "ima.h"
>
> enum sel_inos {
> SEL_ROOT_INO = 2,
> @@ -182,6 +183,8 @@ static ssize_t sel_write_enforce(struct file *file, const char __user *buf,
> selinux_status_update_setenforce(state, new_value);
> if (!new_value)
> call_blocking_lsm_notifier(LSM_POLICY_CHANGE, NULL);
> +
> + selinux_ima_measure_state(state);
> }
> length = count;
> out:
> @@ -762,6 +765,9 @@ static ssize_t sel_write_checkreqprot(struct file *file, const char __user *buf,
>
> checkreqprot_set(fsi->state, (new_value ? 1 : 0));
> length = count;
> +
> + selinux_ima_measure_state(fsi->state);
> +
> out:
> kfree(page);
> return length;
> diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
> index 2106b5d383e7..cb2866489363 100644
> --- a/security/selinux/ss/services.c
> +++ b/security/selinux/ss/services.c
> @@ -2179,7 +2179,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_ima_measure_state(state);
> + selinux_ima_measure_state_locked(state);
> }
>
> void selinux_policy_commit(struct selinux_state *state,
>
On Thu, Mar 4, 2021 at 2:20 PM Lakshmi Ramasubramanian
<[email protected]> wrote:
> On 2/12/21 8:37 AM, Lakshmi Ramasubramanian wrote:
>
> Hi Paul,
>
> > SELinux stores the configuration state and the policy capabilities
> > in kernel memory. Changes to this data at runtime would have an impact
> > on the security guarantees provided by SELinux. Measuring this data
> > through IMA subsystem provides a tamper-resistant way for
> > an attestation service to remotely validate it at runtime.
> >
> > Measure the configuration state and policy capabilities by calling
> > the IMA hook ima_measure_critical_data().
> >
>
> I have addressed your comments on the v2 patch for selinux measurement
> using IMA. Could you please let me know if there are any other comments
> that I need to address in this patch?
The merge window just closed earlier this week, and there were a
handful of bugs that needed to be addressed before I could look at
this patch. If I don't get a chance to review this patch tonight, I
will try to get to it this weekend or early next week.
--
paul moore
http://www.paul-moore.com
On 3/4/21 5:45 PM, Paul Moore wrote:
> On Thu, Mar 4, 2021 at 2:20 PM Lakshmi Ramasubramanian
> <[email protected]> wrote:
>> On 2/12/21 8:37 AM, Lakshmi Ramasubramanian wrote:
>>
>> Hi Paul,
>>
>>> SELinux stores the configuration state and the policy capabilities
>>> in kernel memory. Changes to this data at runtime would have an impact
>>> on the security guarantees provided by SELinux. Measuring this data
>>> through IMA subsystem provides a tamper-resistant way for
>>> an attestation service to remotely validate it at runtime.
>>>
>>> Measure the configuration state and policy capabilities by calling
>>> the IMA hook ima_measure_critical_data().
>>>
>>
>> I have addressed your comments on the v2 patch for selinux measurement
>> using IMA. Could you please let me know if there are any other comments
>> that I need to address in this patch?
>
> The merge window just closed earlier this week, and there were a
> handful of bugs that needed to be addressed before I could look at
> this patch. If I don't get a chance to review this patch tonight, I
> will try to get to it this weekend or early next week.
>
Thanks Paul.
-lakshmi
On Fri, Feb 12, 2021 at 11:37 AM Lakshmi Ramasubramanian
<[email protected]> wrote:
>
> SELinux stores the configuration state and the policy capabilities
> in kernel memory. Changes to this data at runtime would have an impact
> on the security guarantees provided by SELinux. Measuring this data
> through IMA subsystem provides a tamper-resistant way for
> an attestation service to remotely validate it at runtime.
>
> Measure the configuration state and policy capabilities by calling
> the IMA hook ima_measure_critical_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.11.0-rc3+ 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 label=selinux
>
> Sample measurement of SELinux state and policy capabilities:
>
> 10 2122...65d8 ima-buf sha256:13c2...1292 selinux-state 696e...303b
>
> Execute the following command to extract the measured data
> from the IMA's runtime measurements list:
>
> grep "selinux-state" /sys/kernel/security/integrity/ima/ascii_runtime_measurements | tail -1 | cut -d' ' -f 6 | xxd -r -p
>
> The output should be a list of key-value pairs. For example,
> initialized=1;enforcing=0;checkreqprot=1;network_peer_controls=1;open_perms=1;extended_socket_class=1;always_check_network=0;cgroup_seclabel=1;nnp_nosuid_transition=1;genfs_seclabel_symlinks=0;
>
> To verify the measurement is consistent with the current SELinux state
> reported on the system, compare the integer values in the following
> files with those set in the IMA measurement (using the following commands):
>
> - cat /sys/fs/selinux/enforce
> - cat /sys/fs/selinux/checkreqprot
> - cat /sys/fs/selinux/policy_capabilities/[capability_file]
>
> Note that the actual verification would be against an expected state
> and done on a separate system (likely an attestation server) requiring
> "initialized=1;enforcing=1;checkreqprot=0;"
> for a secure state and then whatever policy capabilities are actually
> set in the expected policy (which can be extracted from the policy
> itself via seinfo, for example).
>
> Signed-off-by: Lakshmi Ramasubramanian <[email protected]>
> Suggested-by: Stephen Smalley <[email protected]>
> Suggested-by: Paul Moore <[email protected]>
> ---
> security/selinux/ima.c | 87 ++++++++++++++++++++++++++++++++--
> security/selinux/include/ima.h | 6 +++
> security/selinux/selinuxfs.c | 6 +++
> security/selinux/ss/services.c | 2 +-
> 4 files changed, 96 insertions(+), 5 deletions(-)
This draft seems fine to me, but there is a small logistical blocker
at the moment which means I can't merge this until -rc2 is released,
which likely means this coming Monday. The problem is that this patch
relies on code that went upstream via in the last merge window via the
IMA tree, not the SELinux tree; normally that wouldn't be a problem as
I typically rebase the selinux/next to Linus' -rc1 tag once the merge
window is closed, but in this particular case the -rc1 tag is
dangerously broken for some system configurations (the tag has since
been renamed) so I'm not rebasing onto -rc1 this time around.
Assuming that -rc2 fixes the swapfile/fs-corruption problem, early
next week I'll rebase selinux/next to -rc2 and merge this patch.
However, if the swapfile bug continues past -rc2 we can consider
merging this via the IMA tree, but I'd assume not do that if possible
due to merge conflict and testing reasons.
--
paul moore
http://www.paul-moore.com
On Fri, 2021-03-05 at 12:52 -0500, Paul Moore wrote:
[...]
> This draft seems fine to me, but there is a small logistical blocker
> at the moment which means I can't merge this until -rc2 is released,
> which likely means this coming Monday. The problem is that this
> patch relies on code that went upstream via in the last merge window
> via the IMA tree, not the SELinux tree; normally that wouldn't be a
> problem as I typically rebase the selinux/next to Linus' -rc1 tag
> once the merge window is closed, but in this particular case the -rc1
> tag is dangerously broken for some system configurations (the tag has
> since been renamed) so I'm not rebasing onto -rc1 this time around.
>
> Assuming that -rc2 fixes the swapfile/fs-corruption problem, early
> next week I'll rebase selinux/next to -rc2 and merge this patch.
> However, if the swapfile bug continues past -rc2 we can consider
> merging this via the IMA tree, but I'd assume not do that if possible
> due to merge conflict and testing reasons.
If it helps, we rebased the SCSI tree on top of the merge for the
swapfile fix which is this one, without waiting for -rc2:
commit f69d02e37a85645aa90d18cacfff36dba370f797
Merge: 7a7fd0de4a98 caf6912f3f4a
Author: Linus Torvalds <[email protected]>
Date: Tue Mar 2 18:18:17 2021 -0800
Merge tag 'misc-5.12-2021-03-02' of git://git.kernel.dk/linux-block
James
On Fri, Mar 5, 2021 at 12:57 PM James Bottomley
<[email protected]> wrote:
> On Fri, 2021-03-05 at 12:52 -0500, Paul Moore wrote:
> [...]
> > This draft seems fine to me, but there is a small logistical blocker
> > at the moment which means I can't merge this until -rc2 is released,
> > which likely means this coming Monday. The problem is that this
> > patch relies on code that went upstream via in the last merge window
> > via the IMA tree, not the SELinux tree; normally that wouldn't be a
> > problem as I typically rebase the selinux/next to Linus' -rc1 tag
> > once the merge window is closed, but in this particular case the -rc1
> > tag is dangerously broken for some system configurations (the tag has
> > since been renamed) so I'm not rebasing onto -rc1 this time around.
> >
> > Assuming that -rc2 fixes the swapfile/fs-corruption problem, early
> > next week I'll rebase selinux/next to -rc2 and merge this patch.
> > However, if the swapfile bug continues past -rc2 we can consider
> > merging this via the IMA tree, but I'd assume not do that if possible
> > due to merge conflict and testing reasons.
>
> If it helps, we rebased the SCSI tree on top of the merge for the
> swapfile fix which is this one, without waiting for -rc2:
Considering that -rc2 is only two days away I'm not going to lose a
lot of sleep over it.
--
paul moore
http://www.paul-moore.com
On 3/5/21 11:22 AM, Paul Moore wrote:
Hi Paul,
> On Fri, Mar 5, 2021 at 12:57 PM James Bottomley
> <[email protected]> wrote:
>> On Fri, 2021-03-05 at 12:52 -0500, Paul Moore wrote:
>> [...]
>>> This draft seems fine to me, but there is a small logistical blocker
>>> at the moment which means I can't merge this until -rc2 is released,
>>> which likely means this coming Monday. The problem is that this
>>> patch relies on code that went upstream via in the last merge window
>>> via the IMA tree, not the SELinux tree; normally that wouldn't be a
>>> problem as I typically rebase the selinux/next to Linus' -rc1 tag
>>> once the merge window is closed, but in this particular case the -rc1
>>> tag is dangerously broken for some system configurations (the tag has
>>> since been renamed) so I'm not rebasing onto -rc1 this time around.
>>>
>>> Assuming that -rc2 fixes the swapfile/fs-corruption problem, early
>>> next week I'll rebase selinux/next to -rc2 and merge this patch.
>>> However, if the swapfile bug continues past -rc2 we can consider
>>> merging this via the IMA tree, but I'd assume not do that if possible
>>> due to merge conflict and testing reasons.
>>
>> If it helps, we rebased the SCSI tree on top of the merge for the
>> swapfile fix which is this one, without waiting for -rc2:
>
> Considering that -rc2 is only two days away I'm not going to lose a
> lot of sleep over it.
>
Thanks for reviewing the patch.
I can wait until the swapfile issue is resolved (in rc2 or later) and
you are able to merge this patch. Please take your time.
thanks,
-lakshmi
On Fri, Mar 5, 2021 at 2:29 PM Lakshmi Ramasubramanian
<[email protected]> wrote:
> On 3/5/21 11:22 AM, Paul Moore wrote:
>
> Hi Paul,
>
> > On Fri, Mar 5, 2021 at 12:57 PM James Bottomley
> > <[email protected]> wrote:
> >> On Fri, 2021-03-05 at 12:52 -0500, Paul Moore wrote:
> >> [...]
> >>> This draft seems fine to me, but there is a small logistical blocker
> >>> at the moment which means I can't merge this until -rc2 is released,
> >>> which likely means this coming Monday. The problem is that this
> >>> patch relies on code that went upstream via in the last merge window
> >>> via the IMA tree, not the SELinux tree; normally that wouldn't be a
> >>> problem as I typically rebase the selinux/next to Linus' -rc1 tag
> >>> once the merge window is closed, but in this particular case the -rc1
> >>> tag is dangerously broken for some system configurations (the tag has
> >>> since been renamed) so I'm not rebasing onto -rc1 this time around.
> >>>
> >>> Assuming that -rc2 fixes the swapfile/fs-corruption problem, early
> >>> next week I'll rebase selinux/next to -rc2 and merge this patch.
> >>> However, if the swapfile bug continues past -rc2 we can consider
> >>> merging this via the IMA tree, but I'd assume not do that if possible
> >>> due to merge conflict and testing reasons.
> >>
> >> If it helps, we rebased the SCSI tree on top of the merge for the
> >> swapfile fix which is this one, without waiting for -rc2:
> >
> > Considering that -rc2 is only two days away I'm not going to lose a
> > lot of sleep over it.
> >
>
> Thanks for reviewing the patch.
>
> I can wait until the swapfile issue is resolved (in rc2 or later) and
> you are able to merge this patch. Please take your time.
Thanks for your patience Lakshmi, I just merged this into my local
selinux/next branch and will be pushing it up to kernel.org later
tonight - thank you!
--
paul moore
http://www.paul-moore.com
On 3/8/21 4:42 PM, Paul Moore wrote:
> On Fri, Mar 5, 2021 at 2:29 PM Lakshmi Ramasubramanian
> <[email protected]> wrote:
>> On 3/5/21 11:22 AM, Paul Moore wrote:
>>
>> Hi Paul,
>>
>>> On Fri, Mar 5, 2021 at 12:57 PM James Bottomley
>>> <[email protected]> wrote:
>>>> On Fri, 2021-03-05 at 12:52 -0500, Paul Moore wrote:
>>>> [...]
>>>>> This draft seems fine to me, but there is a small logistical blocker
>>>>> at the moment which means I can't merge this until -rc2 is released,
>>>>> which likely means this coming Monday. The problem is that this
>>>>> patch relies on code that went upstream via in the last merge window
>>>>> via the IMA tree, not the SELinux tree; normally that wouldn't be a
>>>>> problem as I typically rebase the selinux/next to Linus' -rc1 tag
>>>>> once the merge window is closed, but in this particular case the -rc1
>>>>> tag is dangerously broken for some system configurations (the tag has
>>>>> since been renamed) so I'm not rebasing onto -rc1 this time around.
>>>>>
>>>>> Assuming that -rc2 fixes the swapfile/fs-corruption problem, early
>>>>> next week I'll rebase selinux/next to -rc2 and merge this patch.
>>>>> However, if the swapfile bug continues past -rc2 we can consider
>>>>> merging this via the IMA tree, but I'd assume not do that if possible
>>>>> due to merge conflict and testing reasons.
>>>>
>>>> If it helps, we rebased the SCSI tree on top of the merge for the
>>>> swapfile fix which is this one, without waiting for -rc2:
>>>
>>> Considering that -rc2 is only two days away I'm not going to lose a
>>> lot of sleep over it.
>>>
>>
>> Thanks for reviewing the patch.
>>
>> I can wait until the swapfile issue is resolved (in rc2 or later) and
>> you are able to merge this patch. Please take your time.
>
> Thanks for your patience Lakshmi, I just merged this into my local
> selinux/next branch and will be pushing it up to kernel.org later
> tonight - thank you!
>
Thanks Paul.
-lakshmi