All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Mickaël Salaün" <mic@digikod.net>
To: Christian Brauner <brauner@kernel.org>,
	Xiu Jianfeng <xiujianfeng@huawei.com>
Cc: gregkh@linuxfoundation.org, rafael@kernel.org,
	viro@zeniv.linux.org.uk, dhowells@redhat.com, code@tyhicks.com,
	hirofumi@mail.parknet.co.jp, linkinjeon@kernel.org,
	sfrench@samba.org, senozhatsky@chromium.org, tom@talpey.com,
	chuck.lever@oracle.com, jlayton@kernel.org, miklos@szeredi.hu,
	paul@paul-moore.com, jmorris@namei.org, serge@hallyn.com,
	stephen.smalley.work@gmail.com, eparis@parisplace.org,
	casey@schaufler-ca.com, dchinner@redhat.com,
	john.johansen@canonical.com, mcgrof@kernel.org,
	mortonm@chromium.org, fred@cloudflare.com, mpe@ellerman.id.au,
	nathanl@linux.ibm.com, gnoack3000@gmail.com,
	roberto.sassu@huawei.com, linux-kernel@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, linux-cachefs@redhat.com,
	ecryptfs@vger.kernel.org, linux-cifs@vger.kernel.org,
	linux-nfs@vger.kernel.org, linux-unionfs@vger.kernel.org,
	linux-security-module@vger.kernel.org, selinux@vger.kernel.org,
	wangweiyang2@huawei.com
Subject: Re: [PATCH -next 0/2] lsm: Change inode_setattr() to take struct
Date: Fri, 26 May 2023 18:33:05 +0200	[thread overview]
Message-ID: <75b4746d-d41e-7c9f-4bb0-42a46bda7f17@digikod.net> (raw)
In-Reply-To: <20230515-nutzen-umgekehrt-eee629a0101e@brauner>


On 15/05/2023 17:12, Christian Brauner wrote:
> On Fri, May 05, 2023 at 04:11:58PM +0800, Xiu Jianfeng wrote:
>> Hi,
>>
>> I am working on adding xattr/attr support for landlock [1], so we can
>> control fs accesses such as chmod, chown, uptimes, setxattr, etc.. inside
>> landlock sandbox. the LSM hooks as following are invoved:
>> 1.inode_setattr
>> 2.inode_setxattr
>> 3.inode_removexattr
>> 4.inode_set_acl
>> 5.inode_remove_acl
>> which are controlled by LANDLOCK_ACCESS_FS_WRITE_METADATA.
>>
>> and
>> 1.inode_getattr
>> 2.inode_get_acl
>> 3.inode_getxattr
>> 4.inode_listxattr
>> which are controlled by LANDLOCK_ACCESS_FS_READ_METADATA
> 
> It would be helpful to get the complete, full picture.
> 
> Piecemeal extending vfs helpers with struct path arguments is costly,
> will cause a lot of churn and will require a lot of review time from us.
> 
> Please give us the list of all security hooks to which you want to pass
> a struct path (if there are more to come apart from the ones listed
> here). Then please follow all callchains and identify the vfs helpers
> that would need to be updated. Then please figure out where those
> vfs helpers are called from and follow all callchains finding all
> inode_operations that would have to be updated and passed a struct path
> argument. So ultimately we'll end up with a list of vfs helpers and
> inode_operations that would have to be changed.
> 
> I'm very reluctant to see anything merged without knowing _exactly_ what
> you're getting us into.

Ultimately we'd like the path-based LSMs to reach parity with the 
inode-based LSMs. This proposal's goal is to provide users the ability 
to control (in a complete and easy way) file metadata access. For these 
we need to extend the inode_*attr hooks and inode_*acl hooks to handle 
paths. The chown/chmod hooks are already good.

In the future, I'd also like to be able to control directory traversals 
(e.g. chdir), which currently only calls inode_permission().

What would be the best way to reach this goal?

  reply	other threads:[~2023-05-26 16:42 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-05  8:11 [PATCH -next 0/2] lsm: Change inode_setattr() to take struct Xiu Jianfeng
2023-05-05  8:11 ` [PATCH -next 1/2] fs: Change notify_change() to take struct path argument Xiu Jianfeng
2023-05-05 17:22   ` [PATCH -next 1/2] " Chuck Lever III
2023-05-05  8:12 ` [PATCH -next 2/2] lsm: Change inode_setattr hook " Xiu Jianfeng
2023-05-10  0:58 ` [PATCH -next 0/2] lsm: Change inode_setattr() to take struct xiujianfeng
2023-05-15 15:12 ` Christian Brauner
2023-05-26 16:33   ` Mickaël Salaün [this message]
2023-05-30 13:58     ` Christian Brauner
2023-05-30 14:28       ` Christoph Hellwig
2023-05-30 14:55         ` Casey Schaufler
2023-05-30 16:01           ` Christian Brauner
2023-05-30 22:15             ` Casey Schaufler
2023-05-31  8:36               ` Christian Brauner
2023-05-31 16:44                 ` Casey Schaufler
2023-05-31 13:22           ` Christoph Hellwig
2023-05-31 14:17             ` Casey Schaufler
2023-05-31 15:22         ` 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=75b4746d-d41e-7c9f-4bb0-42a46bda7f17@digikod.net \
    --to=mic@digikod.net \
    --cc=brauner@kernel.org \
    --cc=casey@schaufler-ca.com \
    --cc=chuck.lever@oracle.com \
    --cc=code@tyhicks.com \
    --cc=dchinner@redhat.com \
    --cc=dhowells@redhat.com \
    --cc=ecryptfs@vger.kernel.org \
    --cc=eparis@parisplace.org \
    --cc=fred@cloudflare.com \
    --cc=gnoack3000@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hirofumi@mail.parknet.co.jp \
    --cc=jlayton@kernel.org \
    --cc=jmorris@namei.org \
    --cc=john.johansen@canonical.com \
    --cc=linkinjeon@kernel.org \
    --cc=linux-cachefs@redhat.com \
    --cc=linux-cifs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=mortonm@chromium.org \
    --cc=mpe@ellerman.id.au \
    --cc=nathanl@linux.ibm.com \
    --cc=paul@paul-moore.com \
    --cc=rafael@kernel.org \
    --cc=roberto.sassu@huawei.com \
    --cc=selinux@vger.kernel.org \
    --cc=senozhatsky@chromium.org \
    --cc=serge@hallyn.com \
    --cc=sfrench@samba.org \
    --cc=stephen.smalley.work@gmail.com \
    --cc=tom@talpey.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=wangweiyang2@huawei.com \
    --cc=xiujianfeng@huawei.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.