From: "Mickaël Salaün" <mic@digikod.net> To: James Morris <jmorris@namei.org> Cc: linux-kernel@vger.kernel.org, "Al Viro" <viro@zeniv.linux.org.uk>, "Andy Lutomirski" <luto@amacapital.net>, "Arnd Bergmann" <arnd@arndb.de>, "Casey Schaufler" <casey@schaufler-ca.com>, "Jann Horn" <jannh@google.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>, "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@vger.kernel.org, linux-arch@vger.kernel.org, linux-doc@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-security-module@vger.kernel.org, x86@kernel.org Subject: Re: [PATCH v17 02/10] landlock: Add ruleset and domain management Date: Thu, 14 May 2020 12:27:45 +0200 Message-ID: <f646e1c7-33cf-333f-070c-0a40ad0468cd@digikod.net> (raw) In-Reply-To: <alpine.LRH.2.21.2005141302330.30052@namei.org> On 14/05/2020 05:09, James Morris wrote: > On Mon, 11 May 2020, Mickaël Salaün wrote: > >> + * .. warning:: >> + * >> + * It is currently not possible to restrict some file-related actions >> + * accessible through these syscall families: :manpage:`chdir(2)`, >> + * :manpage:`truncate(2)`, :manpage:`stat(2)`, :manpage:`flock(2)`, >> + * :manpage:`chmod(2)`, :manpage:`chown(2)`, :manpage:`setxattr(2)`, >> + * :manpage:`ioctl(2)`, :manpage:`fcntl(2)`. >> + * Future Landlock evolutions will enable to restrict them. > > I have to wonder how useful Landlock will be without more coverage per > the above. This is the result of previous discussions (on mailing lists and conferences) to minimize the code of Landlock to ease review. There is also network and other subsystems which are not covered, the same way other LSMs may not cover everything. However, Landlock is designed to be extensible without breaking user space, so extending this access-control will not be a problem. Previous versions of this patch series handled much more. Moreover, we can compare the current situation with seccomp. Indeed, seccomp only enables to restrict system calls according to their number and their raw arguments. seccomp is designed to limit the attack surface of the kernel but it is also used to remove ways to access kernel resources. Application developers willing to sandbox their products are already using seccomp but there is limitations (e.g. file access control). Landlock addresses such limitations, which improves the current situation. We can also view seccomp as a complementary solution to the current limitations of Landlock. Indeed, seccomp filters can block or restrict the use of syscall families which may not be currently handled by Landlock. > > It would be helpful if you could outline a threat model for this initial > version, so people can get an idea of what kind of useful protection may > be gained from it. The main threat model may be seen as protecting from vulnerable (i.e. malicious) code. But because Landlock policies are defined by application developers, they also define their own threat model. > > Are there any distros or other major users who are planning on enabling or > at least investigating Landlock? I think the question should be: is there any distros which are not interested to improve the security of their users? :) Landlock is mainly designed for application developers, and most Linux distros rely on applications which are not developed by themselves. Some hardened distros such as CLIP OS and Chrome OS are interested to extend the security of the whole system with tailored sandboxing (e.g. internal and critical services, security brokers). For example, Chrome OS folks investigated with a previous version of Landlock: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel-next/+/658517/ I'm sure there is other tailored distros which will be interested once Landlock will be upstream (e.g. Tails, Qubes OS, Subgraph OS, etc.). > > Do you have any examples of a practical application of this scheme? We can start with applications with builtin sandboxing, like web browsers, web services, email services, SSH, etc. There is also all system services handled by an init system which provides security features (e.g. systemd). There is also the security sandbox tools (e.g. Minijail [1], Firejail [2], nsjail [3], Flatpak [4], etc.). And finally, security-oriented APIs such as Sandboxed API [5]. Most of them should welcome new Linux sandboxing features provided by Landlock. [1] https://android.googlesource.com/platform/external/minijail [2] https://firejail.wordpress.com/ [3] https://nsjail.dev/ [4] https://flatpak.org/ [5] https://github.com/google/sandboxed-api
next prev parent reply index Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-05-11 19:21 [PATCH v17 00/10] Landlock LSM Mickaël Salaün 2020-05-11 19:21 ` [PATCH v17 01/10] landlock: Add object management Mickaël Salaün 2020-05-11 19:21 ` [PATCH v17 02/10] landlock: Add ruleset and domain management Mickaël Salaün 2020-05-14 3:09 ` James Morris 2020-05-14 10:27 ` Mickaël Salaün [this message] 2020-05-11 19:21 ` [PATCH v17 03/10] landlock: Set up the security framework and manage credentials Mickaël Salaün 2020-05-11 19:21 ` [PATCH v17 04/10] landlock: Add ptrace restrictions Mickaël Salaün 2020-05-11 19:21 ` [PATCH v17 05/10] fs,landlock: Support filesystem access-control Mickaël Salaün 2020-05-14 3:37 ` James Morris 2020-05-14 10:39 ` Mickaël Salaün 2020-05-14 15:58 ` Casey Schaufler 2020-05-14 18:46 ` Mickaël Salaün 2020-05-14 17:31 ` James Morris 2020-05-14 18:49 ` Mickaël Salaün 2020-05-14 19:37 ` James Morris 2020-05-11 19:21 ` [PATCH v17 06/10] landlock: Add syscall implementation Mickaël Salaün 2020-05-11 19:21 ` [PATCH v17 07/10] arch: Wire up landlock() syscall Mickaël Salaün 2020-05-11 19:21 ` [PATCH v17 08/10] selftests/landlock: Add initial tests Mickaël Salaün 2020-05-11 19:21 ` [PATCH v17 09/10] samples/landlock: Add a sandbox manager example Mickaël Salaün 2020-05-11 19:21 ` [PATCH v17 10/10] landlock: Add user and kernel documentation Mickaël Salaün 2020-05-11 21:54 ` [PATCH v17 00/10] Landlock LSM 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=f646e1c7-33cf-333f-070c-0a40ad0468cd@digikod.net \ --to=mic@digikod.net \ --cc=arnd@arndb.de \ --cc=casey@schaufler-ca.com \ --cc=corbet@lwn.net \ --cc=jannh@google.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=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 git clone --mirror https://lore.kernel.org/lkml/9 lkml/git/9.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