From: "Mickaël Salaün" <mic@digikod.net>
To: Casey Schaufler <casey@schaufler-ca.com>, Jeff Xu <jeffxu@chromium.org>
Cc: Paul Moore <paul@paul-moore.com>,
Shervin Oloumi <enlightened@chromium.org>,
linux-security-module@vger.kernel.org, jorgelo@chromium.org,
keescook@chromium.org, groeck@chromium.org,
allenwebb@chromium.org, gnoack3000@gmail.com, areber@redhat.com,
criu@openvz.org, linux-api@vger.kernel.org, jannh@google.com,
brauner@kernel.org
Subject: Re: [PATCH v2] lsm: adds process attribute getter for Landlock
Date: Fri, 2 Jun 2023 00:08:50 +0200 [thread overview]
Message-ID: <5b1b102b-3413-3669-5f3f-3a6987033a2d@digikod.net> (raw)
In-Reply-To: <e83ef047-42f3-260d-1ac1-07c576cce9f8@schaufler-ca.com>
On 01/06/2023 23:34, Casey Schaufler wrote:
> On 6/1/2023 1:48 PM, Jeff Xu wrote:
>> Hi Paul,
>>
>> On Wed, May 31, 2023 at 6:26 AM Mickaël Salaün <mic@digikod.net> wrote:
>>>>>>
>>>>> If I understand correctly:
>>>>> 1> A new lsm syscall - lsm_get_pid_attr(): Landlock will return the
>>>>> process's landlock sandbox status: true/false.
>>>> There would have to be a new LSM_ATTR_ENFORCMENT to query.
I guess there is a misunderstanding. What is the link between global
system enforcement and the status of a sandboxed/restricted/enforced(?)
process?
The attribute would then be something like LSM_ATTR_RESTRICTED to get a
process restriction status, which might be the same for all processes
with system-wide policies (e.g., SELinux) but not for Landlock.
>>>> Each LSM could then report what, if any, value it choose to.
>>>> I can't say whether SELinux would take advantage of this.
>>>> I don't see that Smack would report this attribute.
>>> I think such returned status for LSM_ATTR_ENFORCMENT query would make
>>> sense, but the syscall could also return -EPERM and other error codes.
>>>
>>>
>>>>> Is this a right fit for SELinux to also return the process's enforcing
>>>>> mode ? such as enforcing/permissive.
>>> Paul could answer that, but I think it would be simpler to have two
>>> different queries, something like LSM_ATTR_ENFORCMENT and
>>> LSM_ATTR_PERMISSIVE queries.
>>>
>> Hi Paul, what do you think ? Could SELinux have something like this.
>
> Not Paul, but answering anyway - No, those are system wide attributes, not
> process (task) attributes. You want some other syscall, say lsm_get_system_attr()
> for those.
next prev parent reply other threads:[~2023-06-01 22:08 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20230302185257.850681-1-enlightened@chromium.org>
2023-03-06 19:18 ` [PATCH 0/1] process attribute support for Landlock 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 [this message]
2023-05-24 16:05 ` Mickaël Salaün
2023-05-19 5:22 ` kernel test robot
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=5b1b102b-3413-3669-5f3f-3a6987033a2d@digikod.net \
--to=mic@digikod.net \
--cc=allenwebb@chromium.org \
--cc=areber@redhat.com \
--cc=brauner@kernel.org \
--cc=casey@schaufler-ca.com \
--cc=criu@openvz.org \
--cc=enlightened@chromium.org \
--cc=gnoack3000@gmail.com \
--cc=groeck@chromium.org \
--cc=jannh@google.com \
--cc=jeffxu@chromium.org \
--cc=jorgelo@chromium.org \
--cc=keescook@chromium.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=paul@paul-moore.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 read-only IMAP folder(s) and NNTP newsgroup(s).