From: "Günther Noack" <gnoack3000@gmail.com>
To: Paul Moore <paul@paul-moore.com>
Cc: "Mickaël Salaün" <mic@digikod.net>,
"James Morris" <jmorris@namei.org>,
"Serge E . Hallyn" <serge@hallyn.com>,
linux-security-module@vger.kernel.org
Subject: Re: [PATCH v1] landlock: Fix file reparenting without explicit LANDLOCK_ACCESS_FS_REFER
Date: Tue, 30 Aug 2022 20:25:26 +0200 [thread overview]
Message-ID: <Yw5WFjiRBTiESwcd@nuc> (raw)
In-Reply-To: <CAHC9VhQy9nf+v0hp3fVofPvf3vTsWWor-fexqXLi+42CKSK=gQ@mail.gmail.com>
On Fri, Aug 26, 2022 at 10:39:56AM -0400, Paul Moore wrote:
> On Thu, Aug 25, 2022 at 6:27 PM Mickaël Salaün <mic@digikod.net> wrote:
> > This patch fixes the (absolute) rule access rights, which now always
> > forbid LANDLOCK_ACCESS_FS_REFER except when it is explicitely allowed
> > when creating a rule. Making all domain handle LANDLOCK_ACCESS_FS_REFER
> > was may initial approach but there is two downsides:
> > - it makes the code more complex because we still want to check that a
> > rule allowing LANDLOCK_ACCESS_FS_REFER is legitimate according to the
> > ruleset's handled access rights (i.e. ABI v1 != ABI v2);
> > - it would not allow to identify if the user created a ruleset
> > explicitely handling LANDLOCK_ACCESS_FS_REFER or not, which will be an
> > issue to audit Landlock (not really possible right now but soon ;) ).
>
> I like this explanation much better!
+1 I agree.
Phrasing wise, I'd also recommend to put the summary first, for example:
This patch fixes a mis-handling of the refer right when multiple
rulesets are layered. The expected behaviour was that an additional
ruleset can only restrict the set of permitted operations, but in this
particular case, it was possible to re-gain the "refer" right.
Does that sound like a reasonable summary?
--
next prev parent reply other threads:[~2022-08-30 18:25 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-23 14:41 [PATCH v1] landlock: Fix file reparenting without explicit LANDLOCK_ACCESS_FS_REFER Mickaël Salaün
2022-08-23 20:07 ` Günther Noack
2022-08-24 9:04 ` Mickaël Salaün
2022-08-25 20:16 ` Paul Moore
2022-08-25 22:12 ` Mickaël Salaün
2022-08-25 21:00 ` Paul Moore
2022-08-25 22:16 ` Günther Noack
2022-08-25 22:27 ` Mickaël Salaün
2022-08-26 14:39 ` Paul Moore
2022-08-30 18:25 ` Günther Noack [this message]
2022-08-31 17:17 ` Mickaël Salaün
2022-08-30 20:01 ` Günther Noack
2022-08-31 20:10 ` Mickaël Salaün
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=Yw5WFjiRBTiESwcd@nuc \
--to=gnoack3000@gmail.com \
--cc=jmorris@namei.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mic@digikod.net \
--cc=paul@paul-moore.com \
--cc=serge@hallyn.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).