All of lore.kernel.org
 help / color / mirror / Atom feed
From: Djalal Harouni <tixxdz@gmail.com>
To: Andy Lutomirski <luto@kernel.org>
Cc: Kees Cook <keescook@chromium.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: Sat, 22 Apr 2017 03:19:55 +0200	[thread overview]
Message-ID: <CAEiveUeHk4TkfGbLzomDUB3WB7eV=ts_64BL3SDVvrCKkrPW=Q@mail.gmail.com> (raw)
In-Reply-To: <CAEiveUcx8fwQgXdLPeMNsTjX2KPhQKH__a-XzcHko_1aCmh4sg@mail.gmail.com>

On Sat, Apr 22, 2017 at 2:12 AM, Djalal Harouni <tixxdz@gmail.com> wrote:
> On Sat, Apr 22, 2017 at 1:51 AM, Andy Lutomirski <luto@kernel.org> wrote:
> [...]
>>>> I personally like my implicit_rights idea, and it might be interesting
>>>> to prototype it.
>>>
>>> I don't like blocking a needed feature behind a large super-feature
>>> that doesn't exist yet. We'd be able to refactor this code into using
>>> such a thing in the future, so I'd prefer to move ahead with this
>>> since it would stop actual exploits.
>>
>> I don't think the super-feature is so hard, and I think we should not
>> add the per-task thing the way it's done in this patch.  Let's not add
>> per-task things where the best argument for their security is "not
>> sure how it would be exploited".
>
> Actually the XFRM framework CVE-2017-7184 [1] is one real example, of
> course there are others. The exploit was used on a generic distro
> during a security contest that distro is Ubuntu. That distro will
> never provide a module autoloading restriction by default to not harm
> it's users. Consumers or containers/sandboxes then can run their
> confined apps using such facilities.
>
> These bugs will stay in embedded devices that use these generic
> distros for ever.

The DCCP CVE-2017-6074 exploit:
http://seclists.org/oss-sec/2017/q1/503

Well, pretty sure there is more... the bugs are real, as their
exploits. Anyway I think these features can coexist as they are
optional, and most process trees protections can get along by design.


-- 
tixxdz

WARNING: multiple messages have this Message-ID (diff)
From: Djalal Harouni <tixxdz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Andy Lutomirski <luto-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@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: Sat, 22 Apr 2017 03:19:55 +0200	[thread overview]
Message-ID: <CAEiveUeHk4TkfGbLzomDUB3WB7eV=ts_64BL3SDVvrCKkrPW=Q@mail.gmail.com> (raw)
In-Reply-To: <CAEiveUcx8fwQgXdLPeMNsTjX2KPhQKH__a-XzcHko_1aCmh4sg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On Sat, Apr 22, 2017 at 2:12 AM, 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:
> [...]
>>>> I personally like my implicit_rights idea, and it might be interesting
>>>> to prototype it.
>>>
>>> I don't like blocking a needed feature behind a large super-feature
>>> that doesn't exist yet. We'd be able to refactor this code into using
>>> such a thing in the future, so I'd prefer to move ahead with this
>>> since it would stop actual exploits.
>>
>> I don't think the super-feature is so hard, and I think we should not
>> add the per-task thing the way it's done in this patch.  Let's not add
>> per-task things where the best argument for their security is "not
>> sure how it would be exploited".
>
> Actually the XFRM framework CVE-2017-7184 [1] is one real example, of
> course there are others. The exploit was used on a generic distro
> during a security contest that distro is Ubuntu. That distro will
> never provide a module autoloading restriction by default to not harm
> it's users. Consumers or containers/sandboxes then can run their
> confined apps using such facilities.
>
> These bugs will stay in embedded devices that use these generic
> distros for ever.

The DCCP CVE-2017-6074 exploit:
http://seclists.org/oss-sec/2017/q1/503

Well, pretty sure there is more... the bugs are real, as their
exploits. Anyway I think these features can coexist as they are
optional, and most process trees protections can get along by design.


-- 
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: Sat, 22 Apr 2017 03:19:55 +0200	[thread overview]
Message-ID: <CAEiveUeHk4TkfGbLzomDUB3WB7eV=ts_64BL3SDVvrCKkrPW=Q@mail.gmail.com> (raw)
In-Reply-To: <CAEiveUcx8fwQgXdLPeMNsTjX2KPhQKH__a-XzcHko_1aCmh4sg@mail.gmail.com>

On Sat, Apr 22, 2017 at 2:12 AM, Djalal Harouni <tixxdz@gmail.com> wrote:
> On Sat, Apr 22, 2017 at 1:51 AM, Andy Lutomirski <luto@kernel.org> wrote:
> [...]
>>>> I personally like my implicit_rights idea, and it might be interesting
>>>> to prototype it.
>>>
>>> I don't like blocking a needed feature behind a large super-feature
>>> that doesn't exist yet. We'd be able to refactor this code into using
>>> such a thing in the future, so I'd prefer to move ahead with this
>>> since it would stop actual exploits.
>>
>> I don't think the super-feature is so hard, and I think we should not
>> add the per-task thing the way it's done in this patch.  Let's not add
>> per-task things where the best argument for their security is "not
>> sure how it would be exploited".
>
> Actually the XFRM framework CVE-2017-7184 [1] is one real example, of
> course there are others. The exploit was used on a generic distro
> during a security contest that distro is Ubuntu. That distro will
> never provide a module autoloading restriction by default to not harm
> it's users. Consumers or containers/sandboxes then can run their
> confined apps using such facilities.
>
> These bugs will stay in embedded devices that use these generic
> distros for ever.

The DCCP CVE-2017-6074 exploit:
http://seclists.org/oss-sec/2017/q1/503

Well, pretty sure there is more... the bugs are real, as their
exploits. Anyway I think these features can coexist as they are
optional, and most process trees protections can get along by design.


-- 
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: Andy Lutomirski <luto@kernel.org>
Cc: Kees Cook <keescook@chromium.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: Sat, 22 Apr 2017 03:19:55 +0200	[thread overview]
Message-ID: <CAEiveUeHk4TkfGbLzomDUB3WB7eV=ts_64BL3SDVvrCKkrPW=Q@mail.gmail.com> (raw)
In-Reply-To: <CAEiveUcx8fwQgXdLPeMNsTjX2KPhQKH__a-XzcHko_1aCmh4sg@mail.gmail.com>

On Sat, Apr 22, 2017 at 2:12 AM, Djalal Harouni <tixxdz@gmail.com> wrote:
> On Sat, Apr 22, 2017 at 1:51 AM, Andy Lutomirski <luto@kernel.org> wrote:
> [...]
>>>> I personally like my implicit_rights idea, and it might be interesting
>>>> to prototype it.
>>>
>>> I don't like blocking a needed feature behind a large super-feature
>>> that doesn't exist yet. We'd be able to refactor this code into using
>>> such a thing in the future, so I'd prefer to move ahead with this
>>> since it would stop actual exploits.
>>
>> I don't think the super-feature is so hard, and I think we should not
>> add the per-task thing the way it's done in this patch.  Let's not add
>> per-task things where the best argument for their security is "not
>> sure how it would be exploited".
>
> Actually the XFRM framework CVE-2017-7184 [1] is one real example, of
> course there are others. The exploit was used on a generic distro
> during a security contest that distro is Ubuntu. That distro will
> never provide a module autoloading restriction by default to not harm
> it's users. Consumers or containers/sandboxes then can run their
> confined apps using such facilities.
>
> These bugs will stay in embedded devices that use these generic
> distros for ever.

The DCCP CVE-2017-6074 exploit:
http://seclists.org/oss-sec/2017/q1/503

Well, pretty sure there is more... the bugs are real, as their
exploits. Anyway I think these features can coexist as they are
optional, and most process trees protections can get along by design.


-- 
tixxdz

  reply	other threads:[~2017-04-22  1:19 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 [this message]
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
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='CAEiveUeHk4TkfGbLzomDUB3WB7eV=ts_64BL3SDVvrCKkrPW=Q@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.