From: Djalal Harouni <tixxdz@gmail.com>
To: Kees Cook <keescook@chromium.org>
Cc: Andy Lutomirski <luto@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>,
LSM List <linux-security-module@vger.kernel.org>,
Linux API <linux-api@vger.kernel.org>,
Dongsu Park <dpark@posteo.net>,
Casey Schaufler <casey@schaufler-ca.com>,
James Morris <james.l.morris@oracle.com>,
Paul Moore <paul@paul-moore.com>,
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jonathan Corbet <corbet@lwn.net>, Jessica Yu <jeyu@redhat.com>,
Rusty Russell <rusty@rustcorp.com.au>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Ingo Molnar <mingo@kernel.org>,
belakhdar abdeldjalil <zendyani@gmail.com>,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH v3 2/2] modules:capabilities: add a per-task modules autoload restriction
Date: Mon, 24 Apr 2017 20:35:06 +0200 [thread overview]
Message-ID: <CAEiveUevKr4FR49PnvKU2f3YzUF2SUvcxjq8Gpsj=Qf1ty+AGg@mail.gmail.com> (raw)
In-Reply-To: <CAGXu5jL_-cxidy_O4ORaN0iX9o7=hsi3DYTRvQs5w5363Z+MVg@mail.gmail.com>
On Mon, Apr 24, 2017 at 8:02 PM, Kees Cook <keescook@chromium.org> wrote:
> On Mon, Apr 24, 2017 at 7:25 AM, Djalal Harouni <tixxdz@gmail.com> wrote:
>> On Sat, Apr 22, 2017 at 9:29 PM, Kees Cook <keescook@chromium.org> wrote:
>>> On Fri, Apr 21, 2017 at 11:51 PM, Andy Lutomirski <luto@kernel.org> wrote:
>>>> On Fri, Apr 21, 2017 at 5:12 PM, Djalal Harouni <tixxdz@gmail.com> wrote:
>>>>> On Sat, Apr 22, 2017 at 1:51 AM, Andy Lutomirski <luto@kernel.org> wrote:
>>>>>
>> [...]
>>>>> * DCCP use after free CVE-2017-6074
>>>>> * n_hldc CVE-2017-2636
>>>>> * XFRM framework CVE-2017-7184
>>>>> * L2TPv3 CVE-2016-10200
>>>>>
>>>>> Most of these need CAP_NET_ADMIN to be autoloaded, however we also
>>>>> need CAP_NET_ADMIN for other things... therefore it is better to have
>>>>> an extra facility that could coexist with CAP_NET_ADMIN and other
>>>>> sandbox features.
>>>>>
>>>>
>>>> I agree that the feature is important, but I think your implementation
>>>> is needlessly dangerous. I imagine that the main uses that you care
>>>> about involve containers. How about doing it in a safer way that
>>>> works for containers? I can think of a few. For example:
>>>>
>>>> 1. A sysctl that, if set, prevents autoloading outside the root
>>>> userns. This isn't very flexible at all, but it might work.
>>>>
>>>> 2. Your patch, but require privilege within the calling namespace to
>>>> set the prctl.
>>>
>>> How about CAP_SYS_ADMIN || no_new_privs?
>>>
>>> -Kees
>>>
>>
>> Yes I can update as per Andy suggestion to require privileges inside
>> the calling namespace to set prctl. Other options that are not prctl
>> based have more variants, that make them hard to use.
>>
>> So I would got with CAP_SYS_ADMIN in the calling userns ||
>> no_new_privs , I would have said CAP_SYS_MODULE in the userns but it
>> seems better to standardize on CAP_SYS_ADMIN to set the prctl.
>
> Andy's concern is that it would provide an escalation from SYS_MODULE
> to SYS_ADMIN through some privileged process being tricked through a
> missing API provided by modules, so we have to use either SYS_ADMIN ||
> nnp.
Yes, I would say that programs expect that maybe such functionality is
not provided, but we don't know. I will update.
Thanks!
--
tixxdz
WARNING: multiple messages have this Message-ID (diff)
From: Djalal Harouni <tixxdz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Cc: Andy Lutomirski <luto-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Linux Kernel Mailing List
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Andrew Morton
<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
"Serge E. Hallyn" <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>,
"kernel-hardening-ZwoEplunGu1jrUoiu81ncdBPR1lH4CV8@public.gmane.org"
<kernel-hardening-ZwoEplunGu1jrUoiu81ncdBPR1lH4CV8@public.gmane.org>,
LSM List
<linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Linux API <linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Dongsu Park <dpark-VwIFZPTo/vqsTnJN9+BGXg@public.gmane.org>,
Casey Schaufler <casey-iSGtlc1asvQWG2LlvL+J4A@public.gmane.org>,
James Morris
<james.l.morris-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>,
Paul Moore <paul-r2n+y4ga6xFZroRs9YW3xA@public.gmane.org>,
Tetsuo Handa
<penguin-kernel-1yMVhJb1mP/7nzcFbJAaVXf5DAMn2ifp@public.gmane.org>,
Greg Kroah-Hartman
<gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>,
Jonathan Corbet <corbet-T1hC0tSOHrs@public.gmane.org>,
Jessica Yu <jeyu-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
Rusty Russell <rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>,
Arnaldo Carvalho de Melo
<acme-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
Mauro
Subject: Re: [PATCH v3 2/2] modules:capabilities: add a per-task modules autoload restriction
Date: Mon, 24 Apr 2017 20:35:06 +0200 [thread overview]
Message-ID: <CAEiveUevKr4FR49PnvKU2f3YzUF2SUvcxjq8Gpsj=Qf1ty+AGg@mail.gmail.com> (raw)
In-Reply-To: <CAGXu5jL_-cxidy_O4ORaN0iX9o7=hsi3DYTRvQs5w5363Z+MVg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Apr 24, 2017 at 8:02 PM, Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:
> On Mon, Apr 24, 2017 at 7:25 AM, Djalal Harouni <tixxdz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On Sat, Apr 22, 2017 at 9:29 PM, Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:
>>> On Fri, Apr 21, 2017 at 11:51 PM, Andy Lutomirski <luto-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>>>> On Fri, Apr 21, 2017 at 5:12 PM, Djalal Harouni <tixxdz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>>> On Sat, Apr 22, 2017 at 1:51 AM, Andy Lutomirski <luto-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>>>>>
>> [...]
>>>>> * DCCP use after free CVE-2017-6074
>>>>> * n_hldc CVE-2017-2636
>>>>> * XFRM framework CVE-2017-7184
>>>>> * L2TPv3 CVE-2016-10200
>>>>>
>>>>> Most of these need CAP_NET_ADMIN to be autoloaded, however we also
>>>>> need CAP_NET_ADMIN for other things... therefore it is better to have
>>>>> an extra facility that could coexist with CAP_NET_ADMIN and other
>>>>> sandbox features.
>>>>>
>>>>
>>>> I agree that the feature is important, but I think your implementation
>>>> is needlessly dangerous. I imagine that the main uses that you care
>>>> about involve containers. How about doing it in a safer way that
>>>> works for containers? I can think of a few. For example:
>>>>
>>>> 1. A sysctl that, if set, prevents autoloading outside the root
>>>> userns. This isn't very flexible at all, but it might work.
>>>>
>>>> 2. Your patch, but require privilege within the calling namespace to
>>>> set the prctl.
>>>
>>> How about CAP_SYS_ADMIN || no_new_privs?
>>>
>>> -Kees
>>>
>>
>> Yes I can update as per Andy suggestion to require privileges inside
>> the calling namespace to set prctl. Other options that are not prctl
>> based have more variants, that make them hard to use.
>>
>> So I would got with CAP_SYS_ADMIN in the calling userns ||
>> no_new_privs , I would have said CAP_SYS_MODULE in the userns but it
>> seems better to standardize on CAP_SYS_ADMIN to set the prctl.
>
> Andy's concern is that it would provide an escalation from SYS_MODULE
> to SYS_ADMIN through some privileged process being tricked through a
> missing API provided by modules, so we have to use either SYS_ADMIN ||
> nnp.
Yes, I would say that programs expect that maybe such functionality is
not provided, but we don't know. I will update.
Thanks!
--
tixxdz
WARNING: multiple messages have this Message-ID (diff)
From: tixxdz@gmail.com (Djalal Harouni)
To: linux-security-module@vger.kernel.org
Subject: [PATCH v3 2/2] modules:capabilities: add a per-task modules autoload restriction
Date: Mon, 24 Apr 2017 20:35:06 +0200 [thread overview]
Message-ID: <CAEiveUevKr4FR49PnvKU2f3YzUF2SUvcxjq8Gpsj=Qf1ty+AGg@mail.gmail.com> (raw)
In-Reply-To: <CAGXu5jL_-cxidy_O4ORaN0iX9o7=hsi3DYTRvQs5w5363Z+MVg@mail.gmail.com>
On Mon, Apr 24, 2017 at 8:02 PM, Kees Cook <keescook@chromium.org> wrote:
> On Mon, Apr 24, 2017 at 7:25 AM, Djalal Harouni <tixxdz@gmail.com> wrote:
>> On Sat, Apr 22, 2017 at 9:29 PM, Kees Cook <keescook@chromium.org> wrote:
>>> On Fri, Apr 21, 2017 at 11:51 PM, Andy Lutomirski <luto@kernel.org> wrote:
>>>> On Fri, Apr 21, 2017 at 5:12 PM, Djalal Harouni <tixxdz@gmail.com> wrote:
>>>>> On Sat, Apr 22, 2017 at 1:51 AM, Andy Lutomirski <luto@kernel.org> wrote:
>>>>>
>> [...]
>>>>> * DCCP use after free CVE-2017-6074
>>>>> * n_hldc CVE-2017-2636
>>>>> * XFRM framework CVE-2017-7184
>>>>> * L2TPv3 CVE-2016-10200
>>>>>
>>>>> Most of these need CAP_NET_ADMIN to be autoloaded, however we also
>>>>> need CAP_NET_ADMIN for other things... therefore it is better to have
>>>>> an extra facility that could coexist with CAP_NET_ADMIN and other
>>>>> sandbox features.
>>>>>
>>>>
>>>> I agree that the feature is important, but I think your implementation
>>>> is needlessly dangerous. I imagine that the main uses that you care
>>>> about involve containers. How about doing it in a safer way that
>>>> works for containers? I can think of a few. For example:
>>>>
>>>> 1. A sysctl that, if set, prevents autoloading outside the root
>>>> userns. This isn't very flexible at all, but it might work.
>>>>
>>>> 2. Your patch, but require privilege within the calling namespace to
>>>> set the prctl.
>>>
>>> How about CAP_SYS_ADMIN || no_new_privs?
>>>
>>> -Kees
>>>
>>
>> Yes I can update as per Andy suggestion to require privileges inside
>> the calling namespace to set prctl. Other options that are not prctl
>> based have more variants, that make them hard to use.
>>
>> So I would got with CAP_SYS_ADMIN in the calling userns ||
>> no_new_privs , I would have said CAP_SYS_MODULE in the userns but it
>> seems better to standardize on CAP_SYS_ADMIN to set the prctl.
>
> Andy's concern is that it would provide an escalation from SYS_MODULE
> to SYS_ADMIN through some privileged process being tricked through a
> missing API provided by modules, so we have to use either SYS_ADMIN ||
> nnp.
Yes, I would say that programs expect that maybe such functionality is
not provided, but we don't know. I will update.
Thanks!
--
tixxdz
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Djalal Harouni <tixxdz@gmail.com>
To: Kees Cook <keescook@chromium.org>
Cc: Andy Lutomirski <luto@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>,
LSM List <linux-security-module@vger.kernel.org>,
Linux API <linux-api@vger.kernel.org>,
Dongsu Park <dpark@posteo.net>,
Casey Schaufler <casey@schaufler-ca.com>,
James Morris <james.l.morris@oracle.com>,
Paul Moore <paul@paul-moore.com>,
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jonathan Corbet <corbet@lwn.net>, Jessica Yu <jeyu@redhat.com>,
Rusty Russell <rusty@rustcorp.com.au>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Ingo Molnar <mingo@kernel.org>,
belakhdar abdeldjalil <zendyani@gmail.com>,
Peter Zijlstra <peterz@infradead.org>
Subject: [kernel-hardening] Re: [PATCH v3 2/2] modules:capabilities: add a per-task modules autoload restriction
Date: Mon, 24 Apr 2017 20:35:06 +0200 [thread overview]
Message-ID: <CAEiveUevKr4FR49PnvKU2f3YzUF2SUvcxjq8Gpsj=Qf1ty+AGg@mail.gmail.com> (raw)
In-Reply-To: <CAGXu5jL_-cxidy_O4ORaN0iX9o7=hsi3DYTRvQs5w5363Z+MVg@mail.gmail.com>
On Mon, Apr 24, 2017 at 8:02 PM, Kees Cook <keescook@chromium.org> wrote:
> On Mon, Apr 24, 2017 at 7:25 AM, Djalal Harouni <tixxdz@gmail.com> wrote:
>> On Sat, Apr 22, 2017 at 9:29 PM, Kees Cook <keescook@chromium.org> wrote:
>>> On Fri, Apr 21, 2017 at 11:51 PM, Andy Lutomirski <luto@kernel.org> wrote:
>>>> On Fri, Apr 21, 2017 at 5:12 PM, Djalal Harouni <tixxdz@gmail.com> wrote:
>>>>> On Sat, Apr 22, 2017 at 1:51 AM, Andy Lutomirski <luto@kernel.org> wrote:
>>>>>
>> [...]
>>>>> * DCCP use after free CVE-2017-6074
>>>>> * n_hldc CVE-2017-2636
>>>>> * XFRM framework CVE-2017-7184
>>>>> * L2TPv3 CVE-2016-10200
>>>>>
>>>>> Most of these need CAP_NET_ADMIN to be autoloaded, however we also
>>>>> need CAP_NET_ADMIN for other things... therefore it is better to have
>>>>> an extra facility that could coexist with CAP_NET_ADMIN and other
>>>>> sandbox features.
>>>>>
>>>>
>>>> I agree that the feature is important, but I think your implementation
>>>> is needlessly dangerous. I imagine that the main uses that you care
>>>> about involve containers. How about doing it in a safer way that
>>>> works for containers? I can think of a few. For example:
>>>>
>>>> 1. A sysctl that, if set, prevents autoloading outside the root
>>>> userns. This isn't very flexible at all, but it might work.
>>>>
>>>> 2. Your patch, but require privilege within the calling namespace to
>>>> set the prctl.
>>>
>>> How about CAP_SYS_ADMIN || no_new_privs?
>>>
>>> -Kees
>>>
>>
>> Yes I can update as per Andy suggestion to require privileges inside
>> the calling namespace to set prctl. Other options that are not prctl
>> based have more variants, that make them hard to use.
>>
>> So I would got with CAP_SYS_ADMIN in the calling userns ||
>> no_new_privs , I would have said CAP_SYS_MODULE in the userns but it
>> seems better to standardize on CAP_SYS_ADMIN to set the prctl.
>
> Andy's concern is that it would provide an escalation from SYS_MODULE
> to SYS_ADMIN through some privileged process being tricked through a
> missing API provided by modules, so we have to use either SYS_ADMIN ||
> nnp.
Yes, I would say that programs expect that maybe such functionality is
not provided, but we don't know. I will update.
Thanks!
--
tixxdz
next prev parent reply other threads:[~2017-04-24 18:35 UTC|newest]
Thread overview: 147+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-19 22:20 [PATCH v3 0/2] modules:capabilities: automatic module loading restrictions Djalal Harouni
2017-04-19 22:20 ` [kernel-hardening] " Djalal Harouni
2017-04-19 22:20 ` Djalal Harouni
2017-04-19 22:20 ` Djalal Harouni
2017-04-19 22:20 ` [PATCH v3 1/2] modules:capabilities: automatic module loading restriction Djalal Harouni
2017-04-19 22:20 ` [kernel-hardening] " Djalal Harouni
2017-04-19 22:20 ` Djalal Harouni
2017-04-19 22:20 ` Djalal Harouni
2017-04-19 23:16 ` Andy Lutomirski
2017-04-19 23:16 ` [kernel-hardening] " Andy Lutomirski
2017-04-19 23:16 ` Andy Lutomirski
2017-04-19 23:16 ` Andy Lutomirski
2017-04-20 2:22 ` Ben Hutchings
2017-04-20 2:22 ` [kernel-hardening] " Ben Hutchings
2017-04-20 2:22 ` Ben Hutchings
2017-04-20 12:44 ` [kernel-hardening] " Djalal Harouni
2017-04-20 12:44 ` Djalal Harouni
2017-04-20 12:44 ` Djalal Harouni
2017-04-20 15:02 ` Ben Hutchings
2017-04-20 15:02 ` Ben Hutchings
2017-04-20 15:02 ` Ben Hutchings
2017-04-20 20:39 ` [kernel-hardening] " Djalal Harouni
2017-04-20 20:39 ` Djalal Harouni
2017-04-20 20:39 ` Djalal Harouni
2017-04-20 21:28 ` Kees Cook
2017-04-20 21:28 ` Kees Cook
2017-04-20 21:28 ` Kees Cook
2017-04-20 21:28 ` Kees Cook
2017-04-19 22:20 ` [PATCH v3 2/2] modules:capabilities: add a per-task modules autoload restriction Djalal Harouni
2017-04-19 22:20 ` [kernel-hardening] " Djalal Harouni
2017-04-19 22:20 ` Djalal Harouni
2017-04-19 22:20 ` Djalal Harouni
2017-04-19 22:38 ` Djalal Harouni
2017-04-19 22:38 ` [kernel-hardening] " Djalal Harouni
2017-04-19 22:38 ` Djalal Harouni
2017-04-19 22:38 ` Djalal Harouni
2017-04-19 23:15 ` Andy Lutomirski
2017-04-19 23:15 ` [kernel-hardening] " Andy Lutomirski
2017-04-19 23:15 ` Andy Lutomirski
2017-04-19 23:15 ` Andy Lutomirski
2017-04-19 23:43 ` Kees Cook
2017-04-19 23:43 ` [kernel-hardening] " Kees Cook
2017-04-19 23:43 ` Kees Cook
2017-04-19 23:43 ` Kees Cook
2017-04-20 2:41 ` Andy Lutomirski
2017-04-20 2:41 ` [kernel-hardening] " Andy Lutomirski
2017-04-20 2:41 ` Andy Lutomirski
2017-04-20 2:41 ` Andy Lutomirski
2017-04-21 23:19 ` Kees Cook
2017-04-21 23:19 ` [kernel-hardening] " Kees Cook
2017-04-21 23:19 ` Kees Cook
2017-04-21 23:19 ` Kees Cook
2017-04-21 23:28 ` Andy Lutomirski
2017-04-21 23:28 ` [kernel-hardening] " Andy Lutomirski
2017-04-21 23:28 ` Andy Lutomirski
2017-04-21 23:28 ` Andy Lutomirski
2017-04-21 23:40 ` Kees Cook
2017-04-21 23:40 ` [kernel-hardening] " Kees Cook
2017-04-21 23:40 ` Kees Cook
2017-04-21 23:40 ` Kees Cook
2017-04-21 23:51 ` Andy Lutomirski
2017-04-21 23:51 ` [kernel-hardening] " Andy Lutomirski
2017-04-21 23:51 ` Andy Lutomirski
2017-04-21 23:51 ` Andy Lutomirski
2017-04-22 0:12 ` Djalal Harouni
2017-04-22 0:12 ` [kernel-hardening] " Djalal Harouni
2017-04-22 0:12 ` Djalal Harouni
2017-04-22 0:12 ` Djalal Harouni
2017-04-22 1:19 ` Djalal Harouni
2017-04-22 1:19 ` [kernel-hardening] " Djalal Harouni
2017-04-22 1:19 ` Djalal Harouni
2017-04-22 1:19 ` Djalal Harouni
2017-04-22 6:51 ` Andy Lutomirski
2017-04-22 6:51 ` [kernel-hardening] " Andy Lutomirski
2017-04-22 6:51 ` Andy Lutomirski
2017-04-22 6:51 ` Andy Lutomirski
2017-04-22 19:29 ` Kees Cook
2017-04-22 19:29 ` [kernel-hardening] " Kees Cook
2017-04-22 19:29 ` Kees Cook
2017-04-22 19:29 ` Kees Cook
2017-04-24 14:25 ` Djalal Harouni
2017-04-24 14:25 ` [kernel-hardening] " Djalal Harouni
2017-04-24 14:25 ` Djalal Harouni
2017-04-24 14:25 ` Djalal Harouni
2017-04-24 18:02 ` Kees Cook
2017-04-24 18:02 ` [kernel-hardening] " Kees Cook
2017-04-24 18:02 ` Kees Cook
2017-04-24 18:02 ` Kees Cook
2017-04-24 18:35 ` Djalal Harouni [this message]
2017-04-24 18:35 ` [kernel-hardening] " Djalal Harouni
2017-04-24 18:35 ` Djalal Harouni
2017-04-24 18:35 ` Djalal Harouni
2017-04-21 23:52 ` Casey Schaufler
2017-04-21 23:52 ` [kernel-hardening] " Casey Schaufler
2017-04-21 23:52 ` Casey Schaufler
2017-04-21 23:52 ` Casey Schaufler
2017-04-22 0:00 ` Andy Lutomirski
2017-04-22 0:00 ` [kernel-hardening] " Andy Lutomirski
2017-04-22 0:00 ` Andy Lutomirski
2017-04-22 0:00 ` Andy Lutomirski
2017-04-22 0:13 ` Casey Schaufler
2017-04-22 0:13 ` [kernel-hardening] " Casey Schaufler
2017-04-22 0:13 ` Casey Schaufler
2017-04-22 0:13 ` Casey Schaufler
2017-04-22 6:45 ` Andy Lutomirski
2017-04-22 6:45 ` [kernel-hardening] " Andy Lutomirski
2017-04-22 6:45 ` Andy Lutomirski
2017-04-22 6:45 ` Andy Lutomirski
2017-04-22 12:17 ` Djalal Harouni
2017-04-22 12:17 ` [kernel-hardening] " Djalal Harouni
2017-04-22 12:17 ` Djalal Harouni
2017-04-22 12:17 ` Djalal Harouni
2017-05-04 13:07 ` Djalal Harouni
2017-05-04 13:07 ` [kernel-hardening] " Djalal Harouni
2017-05-04 13:07 ` Djalal Harouni
2017-05-04 13:07 ` Djalal Harouni
2017-05-04 14:58 ` Serge E. Hallyn
2017-05-04 14:58 ` [kernel-hardening] " Serge E. Hallyn
2017-05-04 14:58 ` Serge E. Hallyn
2017-05-04 14:58 ` Serge E. Hallyn
2017-05-05 13:06 ` Djalal Harouni
2017-05-05 13:06 ` [kernel-hardening] " Djalal Harouni
2017-05-05 13:06 ` Djalal Harouni
2017-05-05 13:06 ` Djalal Harouni
2017-05-05 16:18 ` Andy Lutomirski
2017-05-05 16:18 ` [kernel-hardening] " Andy Lutomirski
2017-05-05 16:18 ` Andy Lutomirski
2017-05-05 16:18 ` Andy Lutomirski
2017-04-20 1:57 ` kbuild test robot
2017-04-20 1:57 ` [kernel-hardening] " kbuild test robot
2017-04-20 1:57 ` kbuild test robot
2017-04-20 1:57 ` kbuild test robot
2017-04-24 4:29 ` Rusty Russell
2017-04-24 4:29 ` [kernel-hardening] " Rusty Russell
2017-04-24 4:29 ` Rusty Russell
2017-04-24 4:29 ` Rusty Russell
2017-04-26 9:06 ` Djalal Harouni
2017-04-26 9:06 ` [kernel-hardening] " Djalal Harouni
2017-04-26 9:06 ` Djalal Harouni
2017-04-27 2:07 ` Rusty Russell
2017-04-27 2:07 ` [kernel-hardening] " Rusty Russell
2017-04-27 2:07 ` Rusty Russell
2017-04-27 2:07 ` Rusty Russell
2017-04-27 13:16 ` Djalal Harouni
2017-04-27 13:16 ` [kernel-hardening] " Djalal Harouni
2017-04-27 13:16 ` Djalal Harouni
2017-04-27 13:16 ` Djalal Harouni
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='CAEiveUevKr4FR49PnvKU2f3YzUF2SUvcxjq8Gpsj=Qf1ty+AGg@mail.gmail.com' \
--to=tixxdz@gmail.com \
--cc=acme@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=casey@schaufler-ca.com \
--cc=corbet@lwn.net \
--cc=dpark@posteo.net \
--cc=gregkh@linuxfoundation.org \
--cc=james.l.morris@oracle.com \
--cc=jeyu@redhat.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@kernel.org \
--cc=mchehab@kernel.org \
--cc=mingo@kernel.org \
--cc=paul@paul-moore.com \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=peterz@infradead.org \
--cc=rusty@rustcorp.com.au \
--cc=serge@hallyn.com \
--cc=zendyani@gmail.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.