From: "Mickaël Salaün" <mic@digikod.net>
To: Kees Cook <keescook@chromium.org>
Cc: Pavel Machek <pavel@ucw.cz>, LKML <linux-kernel@vger.kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Andy Lutomirski <luto@amacapital.net>,
Arnd Bergmann <arnd@arndb.de>,
Casey Schaufler <casey@schaufler-ca.com>,
Daniel Borkmann <daniel@iogearbox.net>,
Daniel Mack <daniel@zonque.org>,
David Drysdale <drysdale@google.com>,
"David S . Miller" <davem@davemloft.net>,
Elena Reshetova <elena.reshetova@intel.com>,
James Morris <james.l.morris@oracle.com>,
Paul Moore <pmoore@redhat.com>, Sargun Dhillon <sargun@sargun.me>,
"Serge E . Hallyn" <serge@hallyn.com>,
Will Drewry <wad@chromium.org>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>,
Linux API <linux-api@vger.kernel.org>,
linux-security-module <linux-security-module@vger.kernel.org>,
Network Development <netdev@vger.kernel.org>
Subject: Re: [RFC v2 00/10] Landlock LSM: Unprivileged sandboxing
Date: Wed, 5 Oct 2016 22:30:02 +0200 [thread overview]
Message-ID: <57F562CA.7080300@digikod.net> (raw)
In-Reply-To: <CAGXu5jLp=GMpjqdCCPWeKHNseEv5DLPC7YN6EwhR1PJsei5cHw@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1931 bytes --]
On 04/10/2016 00:56, Kees Cook wrote:
> On Tue, Sep 20, 2016 at 10:08 AM, Mickaël Salaün <mic@digikod.net> wrote:
>>
>> On 15/09/2016 11:19, Pavel Machek wrote:
>>> Hi!
>>>
>>>> This series is a proof of concept to fill some missing part of seccomp as the
>>>> ability to check syscall argument pointers or creating more dynamic security
>>>> policies. The goal of this new stackable Linux Security Module (LSM) called
>>>> Landlock is to allow any process, including unprivileged ones, to create
>>>> powerful security sandboxes comparable to the Seatbelt/XNU Sandbox or the
>>>> OpenBSD Pledge. This kind of sandbox help to mitigate the security impact of
>>>> bugs or unexpected/malicious behaviors in userland applications.
>>>>
>>>> The first RFC [1] was focused on extending seccomp while staying at the syscall
>>>> level. This brought a working PoC but with some (mitigated) ToCToU race
>>>> conditions due to the seccomp ptrace hole (now fixed) and the non-atomic
>>>> syscall argument evaluation (hence the LSM hooks).
>>>
>>> Long and nice description follows. Should it go to Documentation/
>>> somewhere?
>>>
>>> Because some documentation would be useful...
>>> Pavel
>>
>> Right, but I was looking for feedback before investing in documentation. :)
>
> Heh, understood. There are a number of grammar issues that slow me
> down when reading this, so when it does move into Documentation/, I'll
> have some English nit-picks. :)
>
> While reading I found myself wanting an explicit list of "guiding
> principles" for anyone implementing new hooks. It is touched on in
> several places (don't expose things, don't allow for privilege
> changes, etc). Having that spelled out somewhere would be nice.
Right, I'm going to try to create a more consistent documentation with
the "guiding principles".
Mickaël
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: "Mickaël Salaün" <mic@digikod.net>
To: Kees Cook <keescook@chromium.org>
Cc: Pavel Machek <pavel@ucw.cz>, LKML <linux-kernel@vger.kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Andy Lutomirski <luto@amacapital.net>,
Arnd Bergmann <arnd@arndb.de>,
Casey Schaufler <casey@schaufler-ca.com>,
Daniel Borkmann <daniel@iogearbox.net>,
Daniel Mack <daniel@zonque.org>,
David Drysdale <drysdale@google.com>,
"David S . Miller" <davem@davemloft.net>,
Elena Reshetova <elena.reshetova@intel.com>,
James Morris <james.l.morris@oracle.com>,
Paul Moore <pmoore@redhat.com>, Sargun Dhillon <sargun@sargun.me>,
"Serge E . Hallyn" <serge@hallyn.com>,
Will Drewry <wad@chromium.org>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>,
Linux API <linux-api@vger.kernel.org>,
linux-security-module <linux-security-module@vger.kernel.org>,
Network Dev
Subject: Re: [RFC v2 00/10] Landlock LSM: Unprivileged sandboxing
Date: Wed, 5 Oct 2016 22:30:02 +0200 [thread overview]
Message-ID: <57F562CA.7080300@digikod.net> (raw)
In-Reply-To: <CAGXu5jLp=GMpjqdCCPWeKHNseEv5DLPC7YN6EwhR1PJsei5cHw@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1931 bytes --]
On 04/10/2016 00:56, Kees Cook wrote:
> On Tue, Sep 20, 2016 at 10:08 AM, Mickaël Salaün <mic@digikod.net> wrote:
>>
>> On 15/09/2016 11:19, Pavel Machek wrote:
>>> Hi!
>>>
>>>> This series is a proof of concept to fill some missing part of seccomp as the
>>>> ability to check syscall argument pointers or creating more dynamic security
>>>> policies. The goal of this new stackable Linux Security Module (LSM) called
>>>> Landlock is to allow any process, including unprivileged ones, to create
>>>> powerful security sandboxes comparable to the Seatbelt/XNU Sandbox or the
>>>> OpenBSD Pledge. This kind of sandbox help to mitigate the security impact of
>>>> bugs or unexpected/malicious behaviors in userland applications.
>>>>
>>>> The first RFC [1] was focused on extending seccomp while staying at the syscall
>>>> level. This brought a working PoC but with some (mitigated) ToCToU race
>>>> conditions due to the seccomp ptrace hole (now fixed) and the non-atomic
>>>> syscall argument evaluation (hence the LSM hooks).
>>>
>>> Long and nice description follows. Should it go to Documentation/
>>> somewhere?
>>>
>>> Because some documentation would be useful...
>>> Pavel
>>
>> Right, but I was looking for feedback before investing in documentation. :)
>
> Heh, understood. There are a number of grammar issues that slow me
> down when reading this, so when it does move into Documentation/, I'll
> have some English nit-picks. :)
>
> While reading I found myself wanting an explicit list of "guiding
> principles" for anyone implementing new hooks. It is touched on in
> several places (don't expose things, don't allow for privilege
> changes, etc). Having that spelled out somewhere would be nice.
Right, I'm going to try to create a more consistent documentation with
the "guiding principles".
Mickaël
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: "Mickaël Salaün" <mic@digikod.net>
To: Kees Cook <keescook@chromium.org>
Cc: Pavel Machek <pavel@ucw.cz>, LKML <linux-kernel@vger.kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Andy Lutomirski <luto@amacapital.net>,
Arnd Bergmann <arnd@arndb.de>,
Casey Schaufler <casey@schaufler-ca.com>,
Daniel Borkmann <daniel@iogearbox.net>,
Daniel Mack <daniel@zonque.org>,
David Drysdale <drysdale@google.com>,
"David S . Miller" <davem@davemloft.net>,
Elena Reshetova <elena.reshetova@intel.com>,
James Morris <james.l.morris@oracle.com>,
Paul Moore <pmoore@redhat.com>, Sargun Dhillon <sargun@sargun.me>,
"Serge E . Hallyn" <serge@hallyn.com>,
Will Drewry <wad@chromium.org>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>,
Linux API <linux-api@vger.kernel.org>,
linux-security-module <linux-security-module@vger.kernel.org>,
Network
Subject: Re: [RFC v2 00/10] Landlock LSM: Unprivileged sandboxing
Date: Wed, 5 Oct 2016 22:30:02 +0200 [thread overview]
Message-ID: <57F562CA.7080300@digikod.net> (raw)
In-Reply-To: <CAGXu5jLp=GMpjqdCCPWeKHNseEv5DLPC7YN6EwhR1PJsei5cHw@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1931 bytes --]
On 04/10/2016 00:56, Kees Cook wrote:
> On Tue, Sep 20, 2016 at 10:08 AM, Mickaël Salaün <mic@digikod.net> wrote:
>>
>> On 15/09/2016 11:19, Pavel Machek wrote:
>>> Hi!
>>>
>>>> This series is a proof of concept to fill some missing part of seccomp as the
>>>> ability to check syscall argument pointers or creating more dynamic security
>>>> policies. The goal of this new stackable Linux Security Module (LSM) called
>>>> Landlock is to allow any process, including unprivileged ones, to create
>>>> powerful security sandboxes comparable to the Seatbelt/XNU Sandbox or the
>>>> OpenBSD Pledge. This kind of sandbox help to mitigate the security impact of
>>>> bugs or unexpected/malicious behaviors in userland applications.
>>>>
>>>> The first RFC [1] was focused on extending seccomp while staying at the syscall
>>>> level. This brought a working PoC but with some (mitigated) ToCToU race
>>>> conditions due to the seccomp ptrace hole (now fixed) and the non-atomic
>>>> syscall argument evaluation (hence the LSM hooks).
>>>
>>> Long and nice description follows. Should it go to Documentation/
>>> somewhere?
>>>
>>> Because some documentation would be useful...
>>> Pavel
>>
>> Right, but I was looking for feedback before investing in documentation. :)
>
> Heh, understood. There are a number of grammar issues that slow me
> down when reading this, so when it does move into Documentation/, I'll
> have some English nit-picks. :)
>
> While reading I found myself wanting an explicit list of "guiding
> principles" for anyone implementing new hooks. It is touched on in
> several places (don't expose things, don't allow for privilege
> changes, etc). Having that spelled out somewhere would be nice.
Right, I'm going to try to create a more consistent documentation with
the "guiding principles".
Mickaël
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: "Mickaël Salaün" <mic@digikod.net>
To: Kees Cook <keescook@chromium.org>
Cc: Pavel Machek <pavel@ucw.cz>, LKML <linux-kernel@vger.kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Andy Lutomirski <luto@amacapital.net>,
Arnd Bergmann <arnd@arndb.de>,
Casey Schaufler <casey@schaufler-ca.com>,
Daniel Borkmann <daniel@iogearbox.net>,
Daniel Mack <daniel@zonque.org>,
David Drysdale <drysdale@google.com>,
"David S . Miller" <davem@davemloft.net>,
Elena Reshetova <elena.reshetova@intel.com>,
James Morris <james.l.morris@oracle.com>,
Paul Moore <pmoore@redhat.com>, Sargun Dhillon <sargun@sargun.me>,
"Serge E . Hallyn" <serge@hallyn.com>,
Will Drewry <wad@chromium.org>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>,
Linux API <linux-api@vger.kernel.org>,
linux-security-module <linux-security-module@vger.kernel.org>,
Network Development <netdev@vger.kernel.org>
Subject: [kernel-hardening] Re: [RFC v2 00/10] Landlock LSM: Unprivileged sandboxing
Date: Wed, 5 Oct 2016 22:30:02 +0200 [thread overview]
Message-ID: <57F562CA.7080300@digikod.net> (raw)
In-Reply-To: <CAGXu5jLp=GMpjqdCCPWeKHNseEv5DLPC7YN6EwhR1PJsei5cHw@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1931 bytes --]
On 04/10/2016 00:56, Kees Cook wrote:
> On Tue, Sep 20, 2016 at 10:08 AM, Mickaël Salaün <mic@digikod.net> wrote:
>>
>> On 15/09/2016 11:19, Pavel Machek wrote:
>>> Hi!
>>>
>>>> This series is a proof of concept to fill some missing part of seccomp as the
>>>> ability to check syscall argument pointers or creating more dynamic security
>>>> policies. The goal of this new stackable Linux Security Module (LSM) called
>>>> Landlock is to allow any process, including unprivileged ones, to create
>>>> powerful security sandboxes comparable to the Seatbelt/XNU Sandbox or the
>>>> OpenBSD Pledge. This kind of sandbox help to mitigate the security impact of
>>>> bugs or unexpected/malicious behaviors in userland applications.
>>>>
>>>> The first RFC [1] was focused on extending seccomp while staying at the syscall
>>>> level. This brought a working PoC but with some (mitigated) ToCToU race
>>>> conditions due to the seccomp ptrace hole (now fixed) and the non-atomic
>>>> syscall argument evaluation (hence the LSM hooks).
>>>
>>> Long and nice description follows. Should it go to Documentation/
>>> somewhere?
>>>
>>> Because some documentation would be useful...
>>> Pavel
>>
>> Right, but I was looking for feedback before investing in documentation. :)
>
> Heh, understood. There are a number of grammar issues that slow me
> down when reading this, so when it does move into Documentation/, I'll
> have some English nit-picks. :)
>
> While reading I found myself wanting an explicit list of "guiding
> principles" for anyone implementing new hooks. It is touched on in
> several places (don't expose things, don't allow for privilege
> changes, etc). Having that spelled out somewhere would be nice.
Right, I'm going to try to create a more consistent documentation with
the "guiding principles".
Mickaël
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
next prev parent reply other threads:[~2016-10-05 20:31 UTC|newest]
Thread overview: 180+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-25 10:32 [RFC v2 00/10] Landlock LSM: Unprivileged sandboxing Mickaël Salaün
2016-08-25 10:32 ` [kernel-hardening] " Mickaël Salaün
2016-08-25 10:32 ` [RFC v2 01/10] landlock: Add Kconfig Mickaël Salaün
2016-08-25 10:32 ` [kernel-hardening] " Mickaël Salaün
2016-08-25 10:32 ` [RFC v2 02/10] bpf: Move u64_to_ptr() to BPF headers and inline it Mickaël Salaün
2016-08-25 10:32 ` [kernel-hardening] " Mickaël Salaün
2016-08-25 10:32 ` [RFC v2 03/10] bpf,landlock: Add a new arraymap type to deal with (Landlock) handles Mickaël Salaün
2016-08-25 10:32 ` [kernel-hardening] " Mickaël Salaün
2016-08-25 10:32 ` [RFC v2 04/10] seccomp: Split put_seccomp_filter() with put_seccomp() Mickaël Salaün
2016-08-25 10:32 ` [kernel-hardening] " Mickaël Salaün
2016-08-25 10:32 ` [RFC v2 05/10] seccomp: Handle Landlock Mickaël Salaün
2016-08-25 10:32 ` [kernel-hardening] " Mickaël Salaün
2016-08-25 10:32 ` Mickaël Salaün
2016-08-25 10:32 ` [RFC v2 06/10] landlock: Add LSM hooks Mickaël Salaün
2016-08-25 10:32 ` [kernel-hardening] " Mickaël Salaün
2016-08-30 18:56 ` Andy Lutomirski
2016-08-30 18:56 ` [kernel-hardening] " Andy Lutomirski
2016-08-30 18:56 ` Andy Lutomirski
2016-08-30 18:56 ` Andy Lutomirski
2016-08-30 20:10 ` Mickaël Salaün
2016-08-30 20:10 ` [kernel-hardening] " Mickaël Salaün
2016-08-30 20:10 ` Mickaël Salaün
2016-08-30 20:10 ` Mickaël Salaün
2016-08-30 20:18 ` Andy Lutomirski
2016-08-30 20:18 ` [kernel-hardening] " Andy Lutomirski
2016-08-30 20:18 ` Andy Lutomirski
2016-08-30 20:18 ` Andy Lutomirski
2016-08-30 20:27 ` Mickaël Salaün
2016-08-30 20:27 ` [kernel-hardening] " Mickaël Salaün
2016-08-30 20:27 ` Mickaël Salaün
2016-08-30 20:27 ` Mickaël Salaün
2016-08-25 10:32 ` [RFC v2 07/10] landlock: Add errno check Mickaël Salaün
2016-08-25 10:32 ` [kernel-hardening] " Mickaël Salaün
2016-08-25 11:13 ` Andy Lutomirski
2016-08-25 11:13 ` [kernel-hardening] " Andy Lutomirski
2016-08-25 11:13 ` Andy Lutomirski
2016-08-25 10:32 ` [RFC v2 08/10] landlock: Handle file system comparisons Mickaël Salaün
2016-08-25 10:32 ` [kernel-hardening] " Mickaël Salaün
2016-08-25 11:12 ` Andy Lutomirski
2016-08-25 11:12 ` [kernel-hardening] " Andy Lutomirski
2016-08-25 11:12 ` Andy Lutomirski
2016-08-25 14:10 ` Mickaël Salaün
2016-08-25 14:10 ` [kernel-hardening] " Mickaël Salaün
2016-08-26 14:57 ` Andy Lutomirski
2016-08-26 14:57 ` [kernel-hardening] " Andy Lutomirski
2016-08-27 13:45 ` Mickaël Salaün
2016-08-27 13:45 ` [kernel-hardening] " Mickaël Salaün
2016-08-27 13:45 ` Mickaël Salaün
2016-08-27 13:45 ` Mickaël Salaün
2016-08-25 10:32 ` [RFC v2 09/10] landlock: Handle cgroups Mickaël Salaün
2016-08-25 10:32 ` [kernel-hardening] " Mickaël Salaün
2016-08-25 11:09 ` Andy Lutomirski
2016-08-25 11:09 ` [kernel-hardening] " Andy Lutomirski
2016-08-25 11:09 ` Andy Lutomirski
2016-08-25 14:44 ` Mickaël Salaün
2016-08-25 14:44 ` [kernel-hardening] " Mickaël Salaün
2016-08-26 12:55 ` Tejun Heo
2016-08-26 12:55 ` [kernel-hardening] " Tejun Heo
2016-08-26 12:55 ` Tejun Heo
2016-08-26 12:55 ` Tejun Heo
2016-08-26 14:20 ` Andy Lutomirski
2016-08-26 14:20 ` [kernel-hardening] " Andy Lutomirski
2016-08-26 15:50 ` Tejun Heo
2016-08-26 15:50 ` [kernel-hardening] " Tejun Heo
2016-08-26 2:14 ` Alexei Starovoitov
2016-08-26 2:14 ` [kernel-hardening] " Alexei Starovoitov
2016-08-26 15:10 ` Mickaël Salaün
2016-08-26 15:10 ` [kernel-hardening] " Mickaël Salaün
2016-08-26 15:10 ` Mickaël Salaün
2016-08-26 15:10 ` Mickaël Salaün
2016-08-26 23:05 ` Alexei Starovoitov
2016-08-26 23:05 ` [kernel-hardening] " Alexei Starovoitov
2016-08-27 7:30 ` Andy Lutomirski
2016-08-27 7:30 ` [kernel-hardening] " Andy Lutomirski
2016-08-27 7:30 ` Andy Lutomirski
2016-08-27 18:11 ` Alexei Starovoitov
2016-08-27 18:11 ` [kernel-hardening] " Alexei Starovoitov
2016-08-28 8:14 ` Andy Lutomirski
2016-08-28 8:14 ` [kernel-hardening] " Andy Lutomirski
2016-08-28 8:14 ` Andy Lutomirski
2016-08-27 14:06 ` [RFC v2 09/10] landlock: Handle cgroups (performance) Mickaël Salaün
2016-08-27 14:06 ` [kernel-hardening] " Mickaël Salaün
2016-08-27 18:06 ` Alexei Starovoitov
2016-08-27 18:06 ` [kernel-hardening] " Alexei Starovoitov
2016-08-27 18:06 ` Alexei Starovoitov
2016-08-27 19:35 ` Mickaël Salaün
2016-08-27 19:35 ` [kernel-hardening] " Mickaël Salaün
2016-08-27 20:43 ` Alexei Starovoitov
2016-08-27 20:43 ` [kernel-hardening] " Alexei Starovoitov
2016-08-27 20:43 ` Alexei Starovoitov
2016-08-27 21:14 ` Mickaël Salaün
2016-08-27 21:14 ` [kernel-hardening] " Mickaël Salaün
2016-08-28 8:13 ` Andy Lutomirski
2016-08-28 8:13 ` [kernel-hardening] " Andy Lutomirski
2016-08-28 8:13 ` Andy Lutomirski
2016-08-28 9:42 ` Mickaël Salaün
2016-08-28 9:42 ` [kernel-hardening] " Mickaël Salaün
2016-08-28 9:42 ` Mickaël Salaün
2016-08-30 18:55 ` Andy Lutomirski
2016-08-30 18:55 ` [kernel-hardening] " Andy Lutomirski
2016-08-30 18:55 ` Andy Lutomirski
2016-08-30 20:20 ` Mickaël Salaün
2016-08-30 20:20 ` [kernel-hardening] " Mickaël Salaün
2016-08-30 20:20 ` Mickaël Salaün
2016-08-30 20:23 ` Andy Lutomirski
2016-08-30 20:23 ` [kernel-hardening] " Andy Lutomirski
2016-08-30 20:23 ` Andy Lutomirski
2016-08-30 20:33 ` Mickaël Salaün
2016-08-30 20:33 ` [kernel-hardening] " Mickaël Salaün
2016-08-30 20:33 ` Mickaël Salaün
2016-08-30 20:55 ` Alexei Starovoitov
2016-08-30 20:55 ` [kernel-hardening] " Alexei Starovoitov
2016-08-30 20:55 ` Alexei Starovoitov
2016-08-30 21:45 ` Andy Lutomirski
2016-08-30 21:45 ` [kernel-hardening] " Andy Lutomirski
2016-08-30 21:45 ` Andy Lutomirski
2016-08-31 1:36 ` Alexei Starovoitov
2016-08-31 1:36 ` [kernel-hardening] " Alexei Starovoitov
2016-08-31 3:29 ` Andy Lutomirski
2016-08-31 3:29 ` Andy Lutomirski
2016-08-31 3:29 ` [kernel-hardening] " Andy Lutomirski
2016-08-31 3:29 ` Andy Lutomirski
2016-08-27 14:19 ` [RFC v2 09/10] landlock: Handle cgroups (netfilter match) Mickaël Salaün
2016-08-27 14:19 ` [kernel-hardening] " Mickaël Salaün
2016-08-27 18:32 ` Alexei Starovoitov
2016-08-27 18:32 ` [kernel-hardening] " Alexei Starovoitov
2016-08-27 18:32 ` Alexei Starovoitov
2016-08-27 14:34 ` [RFC v2 09/10] landlock: Handle cgroups (program types) Mickaël Salaün
2016-08-27 14:34 ` [kernel-hardening] " Mickaël Salaün
2016-08-27 18:19 ` Alexei Starovoitov
2016-08-27 18:19 ` [kernel-hardening] " Alexei Starovoitov
2016-08-27 19:55 ` Mickaël Salaün
2016-08-27 19:55 ` [kernel-hardening] " Mickaël Salaün
2016-08-27 20:56 ` Alexei Starovoitov
2016-08-27 20:56 ` [kernel-hardening] " Alexei Starovoitov
2016-08-27 20:56 ` Alexei Starovoitov
2016-08-27 21:18 ` Mickaël Salaün
2016-08-27 21:18 ` [kernel-hardening] " Mickaël Salaün
2016-08-25 10:32 ` [RFC v2 10/10] samples/landlock: Add sandbox example Mickaël Salaün
2016-08-25 10:32 ` [kernel-hardening] " Mickaël Salaün
2016-08-25 11:05 ` [RFC v2 00/10] Landlock LSM: Unprivileged sandboxing Andy Lutomirski
2016-08-25 11:05 ` [kernel-hardening] " Andy Lutomirski
2016-08-25 11:05 ` Andy Lutomirski
2016-08-25 13:57 ` Mickaël Salaün
2016-08-25 13:57 ` [kernel-hardening] " Mickaël Salaün
2016-08-27 7:40 ` Andy Lutomirski
2016-08-27 7:40 ` [kernel-hardening] " Andy Lutomirski
2016-08-27 7:40 ` Andy Lutomirski
2016-08-27 15:10 ` Mickaël Salaün
2016-08-27 15:10 ` [kernel-hardening] " Mickaël Salaün
2016-08-27 15:21 ` [RFC v2 00/10] Landlock LSM: Unprivileged sandboxing (cgroup delegation) Mickaël Salaün
2016-08-27 15:21 ` [kernel-hardening] " Mickaël Salaün
2016-08-27 15:21 ` Mickaël Salaün
2016-08-27 15:21 ` Mickaël Salaün
2016-08-30 16:06 ` [RFC v2 00/10] Landlock LSM: Unprivileged sandboxing Andy Lutomirski
2016-08-30 16:06 ` [kernel-hardening] " Andy Lutomirski
2016-08-30 16:06 ` Andy Lutomirski
2016-08-30 16:06 ` Andy Lutomirski
2016-08-30 19:51 ` Mickaël Salaün
2016-08-30 19:51 ` [kernel-hardening] " Mickaël Salaün
2016-08-30 19:51 ` Mickaël Salaün
2016-08-30 19:55 ` Andy Lutomirski
2016-08-30 19:55 ` [kernel-hardening] " Andy Lutomirski
2016-08-30 19:55 ` Andy Lutomirski
2016-08-30 19:55 ` Andy Lutomirski
2016-09-15 9:19 ` Pavel Machek
2016-09-15 9:19 ` [kernel-hardening] " Pavel Machek
2016-09-20 17:08 ` Mickaël Salaün
2016-09-20 17:08 ` [kernel-hardening] " Mickaël Salaün
2016-09-24 7:45 ` Pavel Machek
2016-09-24 7:45 ` [kernel-hardening] " Pavel Machek
2016-09-24 7:45 ` Pavel Machek
2016-10-03 22:56 ` Kees Cook
2016-10-03 22:56 ` [kernel-hardening] " Kees Cook
2016-10-03 22:56 ` Kees Cook
2016-10-03 22:56 ` Kees Cook
2016-10-05 20:30 ` Mickaël Salaün [this message]
2016-10-05 20:30 ` [kernel-hardening] " Mickaël Salaün
2016-10-05 20:30 ` Mickaël Salaün
2016-10-05 20:30 ` 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=57F562CA.7080300@digikod.net \
--to=mic@digikod.net \
--cc=arnd@arndb.de \
--cc=ast@kernel.org \
--cc=casey@schaufler-ca.com \
--cc=daniel@iogearbox.net \
--cc=daniel@zonque.org \
--cc=davem@davemloft.net \
--cc=drysdale@google.com \
--cc=elena.reshetova@intel.com \
--cc=james.l.morris@oracle.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=netdev@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=pmoore@redhat.com \
--cc=sargun@sargun.me \
--cc=serge@hallyn.com \
--cc=wad@chromium.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
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.