LKML Archive on lore.kernel.org
 help / color / Atom feed
From: "Mickaël Salaün" <mic@digikod.net>
To: Amir Goldstein <amir73il@gmail.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
	"Al Viro" <viro@zeniv.linux.org.uk>,
	"Andy Lutomirski" <luto@amacapital.net>,
	"Anton Ivanov" <anton.ivanov@cambridgegreys.com>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Casey Schaufler" <casey@schaufler-ca.com>,
	"James Morris" <jmorris@namei.org>,
	"Jann Horn" <jannh@google.com>, "Jeff Dike" <jdike@addtoit.com>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Kees Cook" <keescook@chromium.org>,
	"Michael Kerrisk" <mtk.manpages@gmail.com>,
	"Mickaël Salaün" <mickael.salaun@ssi.gouv.fr>,
	"Richard Weinberger" <richard@nod.at>,
	"Serge E . Hallyn" <serge@hallyn.com>,
	"Shuah Khan" <shuah@kernel.org>,
	"Vincent Dagonneau" <vincent.dagonneau@ssi.gouv.fr>,
	kernel-hardening@lists.openwall.com,
	"Linux API" <linux-api@vger.kernel.org>,
	linux-arch@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	linux-kselftest@vger.kernel.org,
	"LSM List" <linux-security-module@vger.kernel.org>,
	x86@kernel.org
Subject: Re: [PATCH v18 07/12] landlock: Support filesystem access-control
Date: Fri, 29 May 2020 13:29:20 +0200
Message-ID: <8e76c2ed-1725-f0a5-bcfc-317c4277af3b@digikod.net> (raw)
In-Reply-To: <CAOQ4uxibpDTyjCJWLGG9jr-Gv9PwO==o50b9O8HGQeUfVMDFag@mail.gmail.com>


On 27/05/2020 05:07, Amir Goldstein wrote:
> On Wed, May 27, 2020 at 3:36 AM Mickaël Salaün <mic@digikod.net> wrote:
>>
>> Thanks to the Landlock objects and ruleset, it is possible to identify
>> inodes according to a process's domain.  To enable an unprivileged
>> process to express a file hierarchy, it first needs to open a directory
>> (or a file) and pass this file descriptor to the kernel through
>> landlock(2).  When checking if a file access request is allowed, we walk
>> from the requested dentry to the real root, following the different
>> mount layers.  The access to each "tagged" inodes are collected
>> according to their rule layer level, and ANDed to create access to the
>> requested file hierarchy.  This makes possible to identify a lot of
>> files without tagging every inodes nor modifying the filesystem, while
>> still following the view and understanding the user has from the
>> filesystem.
>>
> 
> Hi Mickael,
> 
> Nice work! I am interested in the problem of system wide file access
> rules based on directory hierarchy [1][2]. Not the same problem, but
> with obvious overlaps.

Interesting. Landlock's goal is to restrict a set of processes, which
can be a container.

> 
> I sketched this untested POC [2] a while ago -
> It introduces the concept of "border control" LSM hooks to avoid the
> need to check which sections in the hierarchy an inode belongs to
> on every syscall.
> 
> With this, you could cache a topology with id's per section and
> cache the section id + topology generation in the inode's security state.
> When inode crosses border control hooks, it's section id is updated.
> When directory hierarchy topology changes, some or all of the cached
> section id's are invalidated and rules <-> sections relations may need
> to be changed.
> 
> Do you think something like that could be useful for landlock?

Because Landlock deals with unprivileged sandboxing, we must manage
multiple layers. The current implementation in Landlock, according to
the unprivileged constraints, is explained here:
https://lore.kernel.org/lkml/e07fe473-1801-01cc-12ae-b3167f95250e@digikod.net/

As briefly explained in this patch [1] [2], in the case of Landlock,
being able to change the filesystem layout/topology may lead to
privilege escalation. Currently, Landlock forbids inode reparenting, but
I plan to implement a multilayer partial ordering mechanism to relax
this constraint while still enforcing all layered policies. A short-term
approach could also relaxes the first layer, but we need to think
carefully about the potential implications (including ABI compatibility).

[1]
https://github.com/landlock-lsm/linux/commit/b670df6c5add5cf96870327871c35fccb97a0dd8#diff-39adb7412180a73fe7c6b91ae5435a5bR354
(must clic on "Load diff")
[2]
https://github.com/landlock-lsm/linux/commit/b670df6c5add5cf96870327871c35fccb97a0dd8#diff-39adb7412180a73fe7c6b91ae5435a5bR450
(must clic on "Load diff")

I think Landlock could help in your use case, but could you clarify your
thread model please?

The main issue right now with Landlock is to deal with overlayfs.
Indeed, Landlock's check_access_path() does not work with
orphaned/private mounts like overlayfs layers (cf. ovl_path_real() and
ovl_path_open()). Do you have an idea how to solve this properly? Could
we add a "virtual" mount point to these layers to identify dentries they
are anchored to?

> 
> Note that the POC is using d_mountpoint() as the only type of "fence"
> mark. It is sufficient for controlling rename in and out of containers, so
> I just used an already available dentry flag for "fence".
> If the border control hook concept is useful, this could be extended to
> a more generic d_border_passing(), with some internal kernel API
> to manage it and with all the bike shedding that comes with it...

Why not just compare struct path->mnt using the current hooks?

About performances, I also thought that walking through every path
directories would be an important issue, but after some quick benchmark
(with and for Landlock) I'm not sure anymore. A caching mechanism may be
useful but it should not be needed from the start.

> 
> Thanks,
> Amir.

I would like to be in Cc in your next "fanotify and LSM path hooks"
emails. Thanks.

> 
> [1] https://lore.kernel.org/linux-fsdevel/CAOQ4uxhBVhyyJv0+xSFQiGQEj60AbD3SADfKK40uAiC4GF2p9Q@mail.gmail.com/
> [2] https://lore.kernel.org/linux-fsdevel/CAOQ4uxgn=YNj8cJuccx2KqxEVGZy1z3DBVYXrD=Mc7Dc=Je+-w@mail.gmail.com/
> [3] https://github.com/amir73il/linux/commits/rename_xmnt
> 

  reply index

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-26 20:53 [PATCH v18 00/12] Landlock LSM Mickaël Salaün
2020-05-26 20:53 ` [PATCH v18 01/12] landlock: Add object management Mickaël Salaün
2020-05-26 20:53 ` [PATCH v18 02/12] landlock: Add ruleset and domain management Mickaël Salaün
2020-05-26 20:53 ` [PATCH v18 03/12] landlock: Set up the security framework and manage credentials Mickaël Salaün
2020-05-26 20:53 ` [PATCH v18 04/12] landlock: Add ptrace restrictions Mickaël Salaün
2020-05-26 20:53 ` [PATCH v18 05/12] LSM: Infrastructure management of the superblock Mickaël Salaün
2020-05-26 20:53 ` [PATCH v18 06/12] fs,security: Add sb_delete hook Mickaël Salaün
2020-05-26 20:53 ` [PATCH v18 07/12] landlock: Support filesystem access-control Mickaël Salaün
2020-05-27  3:07   ` Amir Goldstein
2020-05-29 11:29     ` Mickaël Salaün [this message]
2020-05-26 20:53 ` [PATCH v18 08/12] landlock: Add syscall implementation Mickaël Salaün
2020-05-26 20:53 ` [PATCH v18 09/12] arch: Wire up landlock() syscall Mickaël Salaün
2020-05-26 20:53 ` [PATCH v18 10/12] selftests/landlock: Add initial tests Mickaël Salaün
2020-05-26 20:53 ` [PATCH v18 11/12] samples/landlock: Add a sandbox manager example Mickaël Salaün
2020-05-26 20:53 ` [PATCH v18 12/12] landlock: Add user and kernel documentation 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=8e76c2ed-1725-f0a5-bcfc-317c4277af3b@digikod.net \
    --to=mic@digikod.net \
    --cc=amir73il@gmail.com \
    --cc=anton.ivanov@cambridgegreys.com \
    --cc=arnd@arndb.de \
    --cc=casey@schaufler-ca.com \
    --cc=corbet@lwn.net \
    --cc=jannh@google.com \
    --cc=jdike@addtoit.com \
    --cc=jmorris@namei.org \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mickael.salaun@ssi.gouv.fr \
    --cc=mtk.manpages@gmail.com \
    --cc=richard@nod.at \
    --cc=serge@hallyn.com \
    --cc=shuah@kernel.org \
    --cc=vincent.dagonneau@ssi.gouv.fr \
    --cc=viro@zeniv.linux.org.uk \
    --cc=x86@kernel.org \
    /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

LKML Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git
	git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git
	git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git
	git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git
	git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git
	git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git
	git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git
	git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git
	git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \
		linux-kernel@vger.kernel.org
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git