From: "Günther Noack" <gnoack3000@gmail.com>
To: enlightened@chromium.org
Cc: mic@digikod.net, linux-security-module@vger.kernel.org,
jorgelo@chromium.org, keescook@chromium.org, groeck@chromium.org,
jeffxu@chromium.org, allenwebb@chromium.org
Subject: Re: [PATCH 1/1] lsm: adds process attribute getter for Landlock
Date: Fri, 3 Mar 2023 17:39:13 +0100 [thread overview]
Message-ID: <20230303.c98f1b8fa91e@gnoack.org> (raw)
In-Reply-To: <20230302185257.850681-2-enlightened@chromium.org>
Hello Shervin!
On Thu, Mar 02, 2023 at 10:52:57AM -0800, enlightened@chromium.org wrote:
> + if (landlocked(task))
> + val = "landlocked:1";
> + else
> + val = "landlocked:0";
Landlock policies can be stacked on top of each other, similar to
seccomp-bpf.
If a parent process has already enforced a (potentially trivial)
Landlock policy, then you can't tell apart based on this boolean
whether any additional policies are stacked on top. So what does
Chromium do with that information, if the flag is true for all the
involved processes that it manages?
Does this meet the needs of your intended use case? Should your API
expose more information about the stacked policies, so that it becomes
possible to tell it apart?
Thanks,
–Günther
next prev parent reply other threads:[~2023-03-03 16:39 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-02 18:52 [PATCH 0/1] process attribute support for Landlock enlightened
2023-03-02 18:52 ` [PATCH 1/1] lsm: adds process attribute getter " enlightened
2023-03-02 20:24 ` Casey Schaufler
2023-03-03 16:39 ` Günther Noack [this message]
2023-03-02 20:22 ` [PATCH 0/1] process attribute support " Casey Schaufler
2023-03-06 22:40 ` Shervin Oloumi
2023-03-07 17:51 ` Casey Schaufler
2023-03-06 19:18 ` Mickaël Salaün
2023-03-07 14:16 ` Mickaël Salaün
2023-03-08 22:25 ` Shervin Oloumi
2023-03-15 9:56 ` Mickaël Salaün
2023-03-16 6:19 ` Günther Noack
2023-03-17 8:38 ` Mickaël Salaün
2023-05-18 20:44 ` Shervin Oloumi
2023-05-24 16:09 ` Mickaël Salaün
2023-05-24 16:21 ` Mickaël Salaün
2023-05-18 20:45 ` [PATCH v2] lsm: adds process attribute getter " Shervin Oloumi
2023-05-18 21:26 ` Casey Schaufler
2023-05-22 19:56 ` Paul Moore
2023-05-23 6:13 ` Jeff Xu
2023-05-23 15:32 ` Casey Schaufler
2023-05-30 18:02 ` Jeff Xu
2023-05-30 19:05 ` Casey Schaufler
2023-05-31 13:01 ` Mickaël Salaün
2023-06-01 20:45 ` Jeff Xu
2023-06-01 21:30 ` Casey Schaufler
2023-05-23 21:12 ` Paul Moore
2023-05-24 15:38 ` Mickaël Salaün
2023-05-24 16:02 ` Mickaël Salaün
2023-05-25 16:28 ` Casey Schaufler
2023-05-30 18:05 ` Jeff Xu
2023-05-30 19:19 ` Casey Schaufler
2023-05-31 13:26 ` Mickaël Salaün
2023-06-01 20:48 ` Jeff Xu
2023-06-01 21:34 ` Casey Schaufler
2023-06-01 22:08 ` Mickaël Salaün
2023-05-24 16:05 ` Mickaël Salaün
2023-05-24 16:48 ` 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=20230303.c98f1b8fa91e@gnoack.org \
--to=gnoack3000@gmail.com \
--cc=allenwebb@chromium.org \
--cc=enlightened@chromium.org \
--cc=groeck@chromium.org \
--cc=jeffxu@chromium.org \
--cc=jorgelo@chromium.org \
--cc=keescook@chromium.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mic@digikod.net \
/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).