linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Luca Boccassi <luca.boccassi@gmail.com>
To: Fan Wu <wufan@linux.microsoft.com>
Cc: linux-security-module@vger.kernel.org, paul@paul-moore.com
Subject: Re: [PATCH 2/2] ipe: also reject policy updates with the same version
Date: Mon, 23 Sep 2024 23:48:10 +0200	[thread overview]
Message-ID: <CAMw=ZnR0M+tsLnoNAeb_+NNw4167qtU-O_Pm3NiFjwaGY5AXWQ@mail.gmail.com> (raw)
In-Reply-To: <4a8414c5-6df1-40aa-b538-a1b4c48f8f1f@linux.microsoft.com>

On Mon, 23 Sept 2024 at 20:01, Fan Wu <wufan@linux.microsoft.com> wrote:
>
>
>
> On 9/22/2024 6:56 AM, luca.boccassi@gmail.com wrote:
> > From: Luca Boccassi <bluca@debian.org>
> >
> > Currently IPE accepts an update that has the same version as the policy
> > being updated, but it doesn't make it a no-op nor it checks that the
> > old and new policyes are the same. So it is possible to change the
> > content of a policy, without changing its version. This is very
> > confusing from userspace when managing policies.
> > Instead change the update logic to reject updates that have the same
> > version with ESTALE, as that is much clearer and intuitive behaviour.
> >
> > Signed-off-by: Luca Boccassi <bluca@debian.org>
> > ---
> >   security/ipe/policy.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/security/ipe/policy.c b/security/ipe/policy.c
> > index 5de64441dfe7..01da3a377e7f 100644
> > --- a/security/ipe/policy.c
> > +++ b/security/ipe/policy.c
> > @@ -115,7 +115,7 @@ int ipe_update_policy(struct inode *root, const char *text, size_t textlen,
> >               goto err;
> >       }
> >
> > -     if (ver_to_u64(old) > ver_to_u64(new)) {
> > +     if (ver_to_u64(old) >= ver_to_u64(new)) {
> >               rc = -ESTALE;
> >               goto err;
> >       }
> Hi Luca,
>
> Can you elaborate more about the potential confusion for the userspace
> users?
>
> The policy version is currently used to prevent the activation of
> outdated or vulnerable policies (e.g., to avoid activating a policy
> trusting a compromised device). The version is not incremented unless a
> vulnerability is identified. Essentially, version comparison acts as a
> minimum threshold, ensuring only policies that meet or exceed this
> version can be activated.

"Version" suggests something that is bumped every time there is a
change, that's usually what the term is used for. The fact that one
can change the policy without changing the version confused me a lot.
Perhaps it should be renamed to "generation" or so, to make it more
clear that it is not intended to be changed every time, but just to
signal the start of a new generation to avoid downgrade attacks?

> Additionally, the version check is performed in ipe_set_active_pol(), so
> it will need to be updated accordingly. The documentation should also be
> refreshed to reflect these changes and ensure consistency with the new
> version handling process.
>
> -Fan

  reply	other threads:[~2024-09-23 21:48 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-22 13:56 [PATCH 1/2] ipe: return -ESTALE instead of -EINVAL on update when new policy has a lower version luca.boccassi
2024-09-22 13:56 ` [PATCH 2/2] ipe: also reject policy updates with the same version luca.boccassi
2024-09-22 15:42   ` Serge E. Hallyn
2024-09-23 18:01   ` Fan Wu
2024-09-23 21:48     ` Luca Boccassi [this message]
2024-09-24 16:32       ` Fan Wu
2024-09-25 20:43         ` Luca Boccassi

Reply instructions:

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAMw=ZnR0M+tsLnoNAeb_+NNw4167qtU-O_Pm3NiFjwaGY5AXWQ@mail.gmail.com' \
    --to=luca.boccassi@gmail.com \
    --cc=linux-security-module@vger.kernel.org \
    --cc=paul@paul-moore.com \
    --cc=wufan@linux.microsoft.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).