* Re: [GIT PULL] Kernel lockdown for secure boot
From: David Howells @ 2018-04-04 14:44 UTC (permalink / raw)
To: Andy Lutomirski
Cc: dhowells, Andy Lutomirski, Jann Horn, Linus Torvalds,
Matthew Garrett, Ard Biesheuvel, James Morris, Alan Cox,
Greg Kroah-Hartman, Linux Kernel Mailing List, Justin Forbes,
linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi
In-Reply-To: <CALCETrUaKOG1q43W=UBPue5TAL61zzwzgr8QeH3Yh6KsMUA2aQ@mail.gmail.com>
Andy Lutomirski <luto@amacapital.net> wrote:
> > Andy Lutomirski <luto@kernel.org> wrote:
> >
> >> As far as I can tell, what's really going on here is that there's a
> >> significant contingent here that wants to prevent Linux from
> >> chainloading something that isn't Linux.
> >
> > You have completely the wrong end of the stick. No one has said that or
> > even implied that. You are alleging dishonesty on our part.
>
> I'm alleging that the idea that Linux seems some particular policy to
> avoid being blacklisted keeps being brought up as a justification for
> these patches.
No, you were alleging that "[we want] to prevent Linux from chainloading
something that isn't Linux.".
This is not true - at least, it's not true on my part; I cannot speak for what
other people may think privately.
David
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Andy Lutomirski @ 2018-04-04 14:35 UTC (permalink / raw)
To: David Howells
Cc: Andy Lutomirski, Jann Horn, Linus Torvalds, Matthew Garrett,
Ard Biesheuvel, James Morris, Alan Cox, Greg Kroah-Hartman,
Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli,
LSM List, Linux API, Kees Cook, linux-efi
In-Reply-To: <20736.1522829117@warthog.procyon.org.uk>
I've reordered your email to make my email more coherent.
> On Apr 4, 2018, at 1:05 AM, David Howells <dhowells@redhat.com> wrote:
>
>
> What we *have* said is that *if* we want to pass the secure boot state across
> kexec, then we have to make sure that:
>
What do you even mean "pass the secure boot state across kexec"? All
I can come up with is that you want a kexeced Linux kernel to also be
passed a flag saying "I was secure booted" and to enable or disable
lockdown accordingly. Let's consider the cases:
1. First kernel is verified (secure boot or otherwise) and locked
down. Certainly that lock down needs to enforce that the next kernel
in the chain is locked down, otherwise lockdown gets defeated.
2. First kernel is not verified but is locked down. It still needs to
enforce that the next kernel is verified and locked down, otherwise
lockdown gets defeated.
3. First kernel is verified but not locked down. There's very little
point in trying to force the next kernel to be locked down.
4. First kernel is neither verified nor locked down. There's still no
point in trying to force the next kernel to be locked down.
Isn't the right solution to have a flag saying "force lockdown" that
kexec can pass to the child kernel? A locked down parent kernel would
refuse to load an unsigned child kernel and would always set that
flag.
> Andy Lutomirski <luto@kernel.org> wrote:
>
>> As far as I can tell, what's really going on here is that there's a
>> significant contingent here that wants to prevent Linux from
>> chainloading something that isn't Linux.
>
> You have completely the wrong end of the stick. No one has said that or even
> implied that. You are alleging dishonesty on our part.
I'm alleging that the idea that Linux seems some particular policy to
avoid being blacklisted keeps being brought up as a justification for
these patches. And, in fact, you bring it up again right here:
>
> And if someone tampers with the aim of breaking, say, Windows, then someone,
> e.g. Microsoft, might blacklist the shim.
In other words, if you chainload an intentionally corrupted copy of
Windows, you get blacklisted? This sounds awfully like what I said
upthread. Is this actually a real concern? Greg seems quite
convinced that it isn't.
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Greg Kroah-Hartman @ 2018-04-04 13:57 UTC (permalink / raw)
To: Theodore Y. Ts'o, Matthew Garrett, Linus Torvalds, luto,
David Howells, Ard Biesheuvel, jmorris, Alan Cox,
Linux Kernel Mailing List, jforbes, linux-man, jlee, LSM List,
linux-api, Kees Cook, linux-efi
In-Reply-To: <20180404133411.GC16242@thunk.org>
On Wed, Apr 04, 2018 at 09:34:11AM -0400, Theodore Y. Ts'o wrote:
> On Wed, Apr 04, 2018 at 03:02:33PM +0200, Greg Kroah-Hartman wrote:
> > On Wed, Apr 04, 2018 at 08:57:43AM -0400, Theodore Y. Ts'o wrote:
> > > On Wed, Apr 04, 2018 at 04:30:18AM +0000, Matthew Garrett wrote:
> > > > What I'm afraid of is this turning into a "security" feature that ends up
> > > > being circumvented in most scenarios where it's currently deployed - eg,
> > > > module signatures are mostly worthless in the non-lockdown case because you
> > > > can just grab the sig_enforce symbol address and then kexec a preamble that
> > > > flips it back to N regardless of the kernel config.
> > >
> > > Whoa. Why doesn't lockdown prevent kexec? Put another away, why
> > > isn't this a problem for people who are fearful that Linux could be
> > > used as part of a Windows boot virus in a Secure UEFI context?
> >
> > Because no one is afraid of that :)
>
> Well, this is the excuse used by Windows.
Really? Every time I have tried to actually follow up on this
statement, it turns into an urban myth. If you have proof of this,
please let me know, otherwise I am going to keep saying it is false.
> Some more cynical people
> believe it's really an anti-competitvie thing, but we should
> acknowledge this is what is causing the fear that some distros have
> that their UEFI secure boot certs will be revoked by Microsoft if they
> don't have this crazy lockdown enforcement for UEFI Secure Boot.
Unsubstantiated fear of relying on another company's signing key to
suddenly stop working is worrying. But it's just that, fear, and not
anything that is actually true. We have a working shim binary that is
signed, in use by all distros and other operating systems (community and
corporate). To revoke that key now would be insane on a variety of
levels.
So let's stop playing the myth and fear card people, and focus on the
actual facts here.
> And I would all be for having the Kconfig description says, "This
> config option is only needed by distros who are fearful of Microsoft
> revoking their UEFI secure boot certificate."
Again, no fear please, facts only.
thanks,
greg k-h
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: David Howells @ 2018-04-04 13:57 UTC (permalink / raw)
To: Theodore Y. Ts'o
Cc: dhowells, Matthew Garrett, Linus Torvalds, luto, Ard Biesheuvel,
jmorris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List,
jforbes, linux-man, jlee, LSM List, linux-api, Kees Cook,
linux-efi
In-Reply-To: <20180404135251.GD16242@thunk.org>
Theodore Y. Ts'o <tytso@mit.edu> wrote:
> > Lockdown mode restricts kexec to booting an authorised image (where the
> > authorisation may be by signature or by IMA).
>
> If that's true, then Matthew's assertion that lockdown w/o secure boot
> is insecure goes away, no?
No.
Lockdown prevents the running kernel from being modified (or, at least, that's
the hope).
But it doesn't do anything to prevent the kernel being modified before
lockdown is engaged.
We are trying to use secureboot to protect the system to the point that
lockdown can take over.
David
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Theodore Y. Ts'o @ 2018-04-04 13:52 UTC (permalink / raw)
To: David Howells
Cc: Matthew Garrett, Linus Torvalds, luto, Ard Biesheuvel, jmorris,
Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes,
linux-man, jlee, LSM List, linux-api, Kees Cook, linux-efi
In-Reply-To: <24353.1522848817@warthog.procyon.org.uk>
On Wed, Apr 04, 2018 at 02:33:37PM +0100, David Howells wrote:
> Theodore Y. Ts'o <tytso@mit.edu> wrote:
>
> > Whoa. Why doesn't lockdown prevent kexec? Put another away, why
> > isn't this a problem for people who are fearful that Linux could be
> > used as part of a Windows boot virus in a Secure UEFI context?
>
> Lockdown mode restricts kexec to booting an authorised image (where the
> authorisation may be by signature or by IMA).
If that's true, then Matthew's assertion that lockdown w/o secure boot
is insecure goes away, no?
- Ted
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Theodore Y. Ts'o @ 2018-04-04 13:34 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Matthew Garrett, Linus Torvalds, luto, David Howells,
Ard Biesheuvel, jmorris, Alan Cox, Linux Kernel Mailing List,
jforbes, linux-man, jlee, LSM List, linux-api, Kees Cook,
linux-efi
In-Reply-To: <20180404130233.GA24008@kroah.com>
On Wed, Apr 04, 2018 at 03:02:33PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Apr 04, 2018 at 08:57:43AM -0400, Theodore Y. Ts'o wrote:
> > On Wed, Apr 04, 2018 at 04:30:18AM +0000, Matthew Garrett wrote:
> > > What I'm afraid of is this turning into a "security" feature that ends up
> > > being circumvented in most scenarios where it's currently deployed - eg,
> > > module signatures are mostly worthless in the non-lockdown case because you
> > > can just grab the sig_enforce symbol address and then kexec a preamble that
> > > flips it back to N regardless of the kernel config.
> >
> > Whoa. Why doesn't lockdown prevent kexec? Put another away, why
> > isn't this a problem for people who are fearful that Linux could be
> > used as part of a Windows boot virus in a Secure UEFI context?
>
> Because no one is afraid of that :)
Well, this is the excuse used by Windows. Some more cynical people
believe it's really an anti-competitvie thing, but we should
acknowledge this is what is causing the fear that some distros have
that their UEFI secure boot certs will be revoked by Microsoft if they
don't have this crazy lockdown enforcement for UEFI Secure Boot.
So how about this as a compromise. We can have a config option for
the behavior that those distros (and Matthew) want, and we can have
separate config options that turn things on in what others would say
is a more rational way.
And I would all be for having the Kconfig description says, "This
config option is only needed by distros who are fearful of Microsoft
revoking their UEFI secure boot certificate."
- Ted
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: David Howells @ 2018-04-04 13:33 UTC (permalink / raw)
To: Theodore Y. Ts'o
Cc: dhowells, Matthew Garrett, Linus Torvalds, luto, Ard Biesheuvel,
jmorris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List,
jforbes, linux-man, jlee, LSM List, linux-api, Kees Cook,
linux-efi
In-Reply-To: <20180404125743.GB16242@thunk.org>
Theodore Y. Ts'o <tytso@mit.edu> wrote:
> Whoa. Why doesn't lockdown prevent kexec? Put another away, why
> isn't this a problem for people who are fearful that Linux could be
> used as part of a Windows boot virus in a Secure UEFI context?
Lockdown mode restricts kexec to booting an authorised image (where the
authorisation may be by signature or by IMA).
David
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Mike Galbraith @ 2018-04-04 13:29 UTC (permalink / raw)
To: Theodore Y. Ts'o, Matthew Garrett
Cc: Linus Torvalds, luto, David Howells, Ard Biesheuvel, jmorris,
Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes,
linux-man, jlee, LSM List, linux-api, Kees Cook, linux-efi
In-Reply-To: <20180404125743.GB16242@thunk.org>
On Wed, 2018-04-04 at 08:57 -0400, Theodore Y. Ts'o wrote:
> On Wed, Apr 04, 2018 at 04:30:18AM +0000, Matthew Garrett wrote:
> > What I'm afraid of is this turning into a "security" feature that ends up
> > being circumvented in most scenarios where it's currently deployed - eg,
> > module signatures are mostly worthless in the non-lockdown case because you
> > can just grab the sig_enforce symbol address and then kexec a preamble that
> > flips it back to N regardless of the kernel config.
>
> Whoa. Why doesn't lockdown prevent kexec? Put another away, why
> isn't this a problem for people who are fearful that Linux could be
> used as part of a Windows boot virus in a Secure UEFI context?
>
> If lockdown simply included a requirement for a signed kernel for
> kexec --- and if kernel signing aren't available, to simply not alow
> kexec, wouldn't that take care of this case?
>
> This wouldn't even be all that much of a burden for non-distro users
> with lockdown enabled, since in my experience outside of enterprise
> and data center use cases, kexec isn't used...
Lots of folks use kdump, ergo kexec.
-Mike
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Greg Kroah-Hartman @ 2018-04-04 13:02 UTC (permalink / raw)
To: Theodore Y. Ts'o, Matthew Garrett, Linus Torvalds, luto,
David Howells, Ard Biesheuvel, jmorris, Alan Cox,
Linux Kernel Mailing List, jforbes, linux-man, jlee, LSM List,
linux-api, Kees Cook, linux-efi
In-Reply-To: <20180404125743.GB16242@thunk.org>
On Wed, Apr 04, 2018 at 08:57:43AM -0400, Theodore Y. Ts'o wrote:
> On Wed, Apr 04, 2018 at 04:30:18AM +0000, Matthew Garrett wrote:
> > What I'm afraid of is this turning into a "security" feature that ends up
> > being circumvented in most scenarios where it's currently deployed - eg,
> > module signatures are mostly worthless in the non-lockdown case because you
> > can just grab the sig_enforce symbol address and then kexec a preamble that
> > flips it back to N regardless of the kernel config.
>
> Whoa. Why doesn't lockdown prevent kexec? Put another away, why
> isn't this a problem for people who are fearful that Linux could be
> used as part of a Windows boot virus in a Secure UEFI context?
Because no one is afraid of that :)
greg k-h
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Theodore Y. Ts'o @ 2018-04-04 12:57 UTC (permalink / raw)
To: Matthew Garrett
Cc: Linus Torvalds, luto, David Howells, Ard Biesheuvel, jmorris,
Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes,
linux-man, jlee, LSM List, linux-api, Kees Cook, linux-efi
In-Reply-To: <CACdnJutuBaE3RaDx0KM5vDF9Sinrp=3tG9csrS-H3eU-J7-Utw@mail.gmail.com>
On Wed, Apr 04, 2018 at 04:30:18AM +0000, Matthew Garrett wrote:
> What I'm afraid of is this turning into a "security" feature that ends up
> being circumvented in most scenarios where it's currently deployed - eg,
> module signatures are mostly worthless in the non-lockdown case because you
> can just grab the sig_enforce symbol address and then kexec a preamble that
> flips it back to N regardless of the kernel config.
Whoa. Why doesn't lockdown prevent kexec? Put another away, why
isn't this a problem for people who are fearful that Linux could be
used as part of a Windows boot virus in a Secure UEFI context?
If lockdown simply included a requirement for a signed kernel for
kexec --- and if kernel signing aren't available, to simply not alow
kexec, wouldn't that take care of this case?
This wouldn't even be all that much of a burden for non-distro users
with lockdown enabled, since in my experience outside of enterprise
and data center use cases, kexec isn't used --- and in fact, very
often kexec doesn't even work outside of a very carefully selected and
bug-fixed set of device drivers. (It often doesn't work in non-distro
kernels because very few upstream developers really care about kexec.)
- Ted
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Greg Kroah-Hartman @ 2018-04-04 9:04 UTC (permalink / raw)
To: Matthew Garrett
Cc: luto, Linus Torvalds, David Howells, Ard Biesheuvel, jmorris,
Alan Cox, Linux Kernel Mailing List, jforbes, linux-man, jlee,
LSM List, linux-api, Kees Cook, linux-efi
In-Reply-To: <CACdnJutmTU4U0nMik0oqGHDEd-xd4Vhi06t3RsZ5tpUgugfNbQ@mail.gmail.com>
On Wed, Apr 04, 2018 at 12:19:35AM +0000, Matthew Garrett wrote:
> On Tue, Apr 3, 2018 at 5:18 PM Andy Lutomirski <luto@kernel.org> wrote:
>
> > if your secure boot-enabled bootloader can't prevent a bad guy from
> > using malicious kernel command line parameters, then fix it.
>
> How is a bootloader supposed to know what the set of malicious kernel
> command line parameters is?
It wouldn't, it, if it really were "secure", would not allow any command
line parameters to be changed. Which is exactly what those bootloaders
who "claim" to be secure do.
And, just to butt in here, there is no requirement that I have ever
heard of from anyone at UEFI or Microsoft that this type of "kernel
feature" is a requirement to allow for a bootloader/kernel to be signed
with their key. So that should take the "politics" reason off the table
here, if people thought that somehow it was even a viable reason...
thanks,
greg k-h
^ permalink raw reply
* Re: [RESEND PATCH V4] pidns: introduce syscall translate_pid
From: Konstantin Khlebnikov @ 2018-04-04 8:28 UTC (permalink / raw)
To: Nagarathnam Muthusamy, Andrew Morton
Cc: linux-api, linux-kernel, ebiederm, serge.hallyn, oleg, luto,
jannh, prakash.sangappa
In-Reply-To: <6a117d9a-f005-e1ae-5632-25e5c61dcb8f@oracle.com>
On 04.04.2018 00:51, Nagarathnam Muthusamy wrote:
>
>
> On 04/03/2018 02:52 PM, Andrew Morton wrote:
>> On Tue, 3 Apr 2018 14:45:28 -0700 Nagarathnam Muthusamy <nagarathnam.muthusamy@oracle.com> wrote:
>>
>>>> This changelog doesn't explain what the value is to our users. I
>>>> assume it is a performance optimization because "backward translation
>>>> requires scanning all tasks"? If so, please show us real-world
>>>> examples of the performance benefit from this patch, and please go to
>>>> great lengths to explain to us why this optimisation is needed by our
>>>> users.
>>> One of the usecase by Oracle database involves multiple levels of
>>> nested pid namespaces and we require pid translation between the
>>> levels. Discussions on the particular usecase, why any of the existing
>>> methods was not usable happened in the following thread.
>>>
>>> https://patchwork.kernel.org/patch/10276785/
>>>
>>> At the end, it was agreed that this patch along with flocks will solve the
>>> issue.
>> Nobody who reads this patch's changelog will know any of this. Please
>> let's get all this information into the proper place.
> Sure! Will resend the patch with updated change log.
I have v5 version of this proposal in work.
I've redesigned interface to be more convenient for cases where
strict race-protection isn't required and pid-ns could be referenced pid.
It has 5 arguments rather than 3 because types of references are
defined explicitly rather than magic like -1, >0, <0.
This more verbose but protects against errors like passing -1 from
failed previous syscall as argument.
kind of
translate_pid(pid, TRANSLATE_PID_FD_PIDNS, ns_fd, TRANSLATE_PID_CURRENT_PIDNS, 0)
I'll send it today with including more detailed motivation for patch.
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: David Howells @ 2018-04-04 8:05 UTC (permalink / raw)
To: Andy Lutomirski
Cc: dhowells, Jann Horn, Linus Torvalds, Matthew Garrett,
Ard Biesheuvel, James Morris, Alan Cox, Greg Kroah-Hartman,
Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli,
LSM List, Linux API, Kees Cook, linux-efi
In-Reply-To: <CALCETrXZWU1MC8LbLCg7VTVHMqKpXh51amnTjKePRCJ31jRiwg@mail.gmail.com>
Andy Lutomirski <luto@kernel.org> wrote:
> As far as I can tell, what's really going on here is that there's a
> significant contingent here that wants to prevent Linux from
> chainloading something that isn't Linux.
You have completely the wrong end of the stick. No one has said that or even
implied that. You are alleging dishonesty on our part.
What we *have* said is that *if* we want to pass the secure boot state across
kexec, then we have to make sure that:
(1) no one tampers with the intermediate kernel between boot and kexec
otherwise the secure boot state is effectively invalidated, and
(2) the image that gets kexec'ed is trusted.
Remember: you cannot know (2) if you don't have (1).
And if someone tampers with the aim of breaking, say, Windows, then someone,
e.g. Microsoft, might blacklist the shim.
David
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Peter Dolding @ 2018-04-04 6:56 UTC (permalink / raw)
To: Matthew Garrett
Cc: Linus Torvalds, luto, David Howells, Ard Biesheuvel, James Morris,
Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes,
linux-man, jlee, LSM List, linux-api, Kees Cook, linux-efi
In-Reply-To: <CACdnJuuek-sS3esmomNOkjBMV_6VPL2NFCzRd+UGxbZrMe=4nw@mail.gmail.com>
.
On Wed, Apr 4, 2018 at 11:13 AM, Matthew Garrett <mjg59@google.com> wrote:
> There are four cases:
>
> Verified Boot off, lockdown off: Status quo in distro and mainline kernels
> Verified Boot off, lockdown on: Perception of security improvement that's
> trivially circumvented (and so bad)
> Verified Boot on, lockdown off: Perception of security improvement that's
> trivially circumvented (and so bad), status quo in mainline kernels
> Verified Boot on, lockdown on: Security improvement, status quo in distro
> kernels
>
> Of these four options, only two make sense. The most common implementation
> of Verified Boot on x86 platforms is UEFI Secure Boot,
Stop right there. Verified boot does not have to be UEFI secureboot.
You could be using a uboot verified boot or
https://www.coreboot.org/git-docs/Intel/vboot.html google vboot.
Neither of these provide flags to kernel to say they have been
performed.
So Verified boot looking off to kernel yet lockdown needing to be on
is one very valid combination and must be supported because the Linux
kernel does not always know when it verified boot environment. When
the Linux kernel thinks verified boot is off it may not be trivial to
circumvent.
Now Verified Boot on, lockdown off. Insanely this can be required in
diagnostic on some embedded platform because EFI secureboot does not
have a off switch. These are platforms where they don't boot if
they don't have a PK and KEK set installed. Yes some of these is jtag
the PK and KEK set in.
The fact that this Verified Boot on, lockdown off causes trouble
points to a clear problem. User owns the hardware they should have
the right to defeat secureboot if they wish to.
In fact the issue that you can not install a KEK per operating system
installed shows a problem as well.
So all OS use the same KEK for their installers and then you have all
non Microsoft in a lot of cases the same KEK for booting OS. Any of
these bootloaders/kernels with defect will end up with the security
being exactly like Verified Boot on, lockdown off. Remember attackers
will send around copies of what ever they need to so they can breach a
system so they find a defective solution some where they will ship it
everywhere. Attackers that secureboot is attempted to prevent are
criminal anyhow what is a little bit of copyright violation to them..
So when the current UEFI design is security theatre there should not
be any special effort to support it.
If UEFI was not security theatre there would be a clean way for people
install and setup up their systems to list what operating system KEK
should be accepted so allowing attack surface area to be minimised and
the damaged form any flawed implementation to also be limited. This
way end users could opt in or out of operating systems based on
security. If user has opted out of all operating systems doing
Verified Boot on, lockdown off: those are not a threat. Also any OS
with defective kernel or bootloader that the system has not allowed
the KEK of would also not be a threat.
Really I see no reason to be bending over in the Linux kernel for UEFI
secureboot. You list all 4 types need to exist for different usage
case of the Linux kernel. The fact UEFI secureboot currently is
implemented on x86 does not handle the fact all 4 use cases need to
exist is really a issue with UEFI Secureboot that needs to be fixed by
those designing UEFI for the future.
Allowing the kernel to be configured the 4 different ways does not
mean a party like Microsoft has to sign off on everything the Linux
kernel can do. Its not like android/IOT vendors have to bow to
Microsoft.
The Linux kernel should not show favouritism. This does mean that
all 4 modes should be in the kernel configuration options.
Matthew Garrett your mistake is that only 2 are valid when all 4 are
valid in different usage cases. Circumventing security is sometimes
required accepting that case is hard for some people. Of course
when a party need perform circumventing security the fact that it
currently gives out the keys to world of UEFI systems is a very big
security design flaw in UEFI.
Why should the Linux kernel contain code to work around defective
design of UEFI and limit what users not using UEFI and using UEFI can
do?
Peter Dolding
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Matthew Garrett @ 2018-04-04 4:31 UTC (permalink / raw)
To: alexei.starovoitov
Cc: luto, David Howells, Ard Biesheuvel, jmorris, Alan Cox,
Linus Torvalds, Greg Kroah-Hartman, Linux Kernel Mailing List,
jforbes, linux-man, jlee, LSM List, linux-api, Kees Cook,
linux-efi
In-Reply-To: <CAADnVQLu5EZLJ1C9-dd4=K+sed6+38oy047+nqCMfuPFB=wttw@mail.gmail.com>
On Tue, Apr 3, 2018 at 7:34 PM Alexei Starovoitov <
alexei.starovoitov@gmail.com> wrote:
> If the only thing that folks are paranoid about is reading
> arbitrary kernel memory with bpf_probe_read() helper
> then preferred patch would be to disable it during verification
> when in lockdown mode.
> No run-time overhead and android folks will be happy
> that lockdown doesn't break their work.
> They converted out-of-tree networking accounting
> module and corresponding user daemon to use bpf:
https://www.linuxplumbersconf.org/2017/ocw/system/presentations/4791/original/eBPF%20cgroup%20filters%20for%20data%20usage%20accounting%20on%20Android.pdf
An alternative would be to only disable kernel reads if the kernel contains
secrets that aren't supposed to be readable by root. If the keyring is
configured such that root can read everything, it seems like less of a
concern?
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Matthew Garrett @ 2018-04-04 4:30 UTC (permalink / raw)
To: Linus Torvalds
Cc: luto, David Howells, Ard Biesheuvel, jmorris, Alan Cox,
Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man,
jlee, LSM List, linux-api, Kees Cook, linux-efi
In-Reply-To: <CA+55aFxgrh5eeG9MRSEsJtyL5yTe0TehZ=BS2josGJaLxoMMBQ@mail.gmail.com>
On Tue, Apr 3, 2018 at 6:43 PM Linus Torvalds
<torvalds@linux-foundation.org>
wrote:
> On Tue, Apr 3, 2018 at 6:13 PM, Matthew Garrett <mjg59@google.com> wrote:
> >
> > There are four cases:
> No.
> Matthew., stop with the agenda already.
> This shit is what I'm talking about:
> > Verified Boot off, lockdown on: Perception of security improvement
that's
> > trivially circumvented (and so bad)
> You're doing some serious value judgement that is simply bogus.
> If lockdown actually helps avoid CPL0 execution attacks, then it helps
> even if secure more is off.
Bear in mind that I'm talking about defaults here - in more constrained
configurations the answers may change. But the kernel has no way of knowing
whether it's in one of those configurations, and as a result there's an
argument for not overpromising on the security that you're providing users.
If a user has a configuration where you're able to verify that userspace
has some degree of protection (eg, disk encryption keys are in the TPM and
won't unseal if someone's switched out the kernel) then it's reasonable for
userland (or a kernel command line option) to enable the functionality.
What I'm afraid of is this turning into a "security" feature that ends up
being circumvented in most scenarios where it's currently deployed - eg,
module signatures are mostly worthless in the non-lockdown case because you
can just grab the sig_enforce symbol address and then kexec a preamble that
flips it back to N regardless of the kernel config. This is the sort of
thing that's not obvious to most users, and it potentially causes them to
make worse security decisions as a result. The goal for this part of the
patchset isn't to cover every single conceivable case, it's to provide
reasonable defaults in a way that makes life easier for distributions.
> Or think of virtual machines - which people often use on purpose for
> security things. Again, they very much are _not_ going to have secure
> boot, but it's not necessarily even possible to "replace the kernel
> and reboot" at all, because the kernel came from outside the virtual
> machine entirely, and rebooting might just kill the VM rather than
> restart anything.
And where you have a trustworthy external thing providing your kernel,
yeah, that's also an argument - and having a kernel command line argument
that enables it in this case also seems entirely reasonable.
> This is what I mean by having an agenda. We all know you are a big
> proponent of secure boot. But it seems to cloud your arguments, by
> turning your assumptions and your agenda into an "argument" that is
> simply not even TRUE.
I'm making this argument from the perspective of "What should the kernel do
when it has no additional information". Having the kernel automatically
enable lockdown without the user being aware of which guarantees their
environment is providing risks giving users the impression of security that
they may not have - in that case it makes more sense to have the user make
an explicit decision to enable it.
> See what I'm unhappy about?
> > Verified Boot on, lockdown off: Perception of security improvement
that's
> > trivially circumvented (and so bad), status quo in mainline kernels
> I think this is entirely false too. Again, the "trivial circumvention"
> shows a bias and agenda that isn't really all that true.
> > Of these four options, only two make sense.
> No.
> You say that, because you have that bias and that agenda.
Ok. Only two make sense *in the absence of additional information about
local configuration*. Distributions have to make reasonable choices here,
and where a configuration choice decreases functionality and provides what
may only be a marginal increase in security it's not a good configuration
choice to make by default.
> That said, wouldn't it be equally good to just make the whole thing be
> a protected EFI variable instead? Once you have physical access to the
> EFI shell (to turn off secure boot) you have access to that too.
That's pretty much exactly what mokutil does, without you needing to find a
copy of the UEFI shell to install first. If you think there's a strong
enough need for it, we could definitely add an additional variable that
allowed you to disable lockdown without disabling signature validation.
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Alexei Starovoitov @ 2018-04-04 2:34 UTC (permalink / raw)
To: Andy Lutomirski
Cc: David Howells, Ard Biesheuvel, James Morris, One Thousand Gnomes,
Linus Torvalds, Matthew Garrett, Greg KH, LKML, Justin Forbes,
linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi
On Tue, Apr 3, 2018 at 9:26 AM, Andy Lutomirski <luto@kernel.org> wrote:
> On Tue, Apr 3, 2018 at 8:41 AM, Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
>> On Tue, Apr 03, 2018 at 08:11:07AM -0700, Andy Lutomirski wrote:
>>> >
>>> >> "bpf: Restrict kernel image access functions when the kernel is locked down":
>>> >> This patch just sucks in general.
>>> >
>>> > Yes - but that's what Alexei Starovoitov specified. bpf kind of sucks since
>>> > it gives you unrestricted access to the kernel.
>>>
>>> bpf, in certain contexts, gives you unrestricted access to *reading*
>>> kernel memory. bpf should, under no circumstances, let you write to
>>> the kernel unless you're using fault injection or similar.
>>>
>>> I'm surprised that Alexei acked this patch. If something like XDP or
>>> bpfilter starts becoming widely used, this patch will require a lot of
>>> reworking to avoid breaking standard distros.
>>
>> my understanding was that this lockdown set attemps to disallow _reads_
>> of kernel memory from anything, so first version of patch was adding
>> run-time checks for bpf_probe_read() which is no-go
>> and without this helper the bpf for tracing is losing a lot of its power,
>> so the easiest is to disable it all.
>
> Fair enough.
Actually looking at the patch again:
https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/commit/?h=efi-lock-down&id=78bb0059c3b8304a8d124b55feebc780fb3e0500
If the only thing that folks are paranoid about is reading
arbitrary kernel memory with bpf_probe_read() helper
then preferred patch would be to disable it during verification
when in lockdown mode.
No run-time overhead and android folks will be happy
that lockdown doesn't break their work.
They converted out-of-tree networking accounting
module and corresponding user daemon to use bpf:
https://www.linuxplumbersconf.org/2017/ocw/system/presentations/4791/original/eBPF%20cgroup%20filters%20for%20data%20usage%20accounting%20on%20Android.pdf
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Linus Torvalds @ 2018-04-04 1:58 UTC (permalink / raw)
To: Justin Forbes
Cc: Matthew Garrett, Andrew Lutomirski, David Howells, Ard Biesheuvel,
James Morris, Alan Cox, Greg Kroah-Hartman,
Linux Kernel Mailing List, linux-man, joeyli, LSM List, Linux API,
Kees Cook, linux-efi
In-Reply-To: <CAFbkSA0ursG3RGWU19LQiD6u30h5V=Aqj3oVyHQCiX6MLopYUg@mail.gmail.com>
On Tue, Apr 3, 2018 at 6:30 PM, Justin Forbes <jforbes@redhat.com> wrote:
>>
>> If there actually was a good explanation for the tie-in, it should
>> have been front-and-center and explained as such.
>>
> Honestly, yes, the major distros have been shipping this patch set for years
> now, and every time it comes to upstream, the same damn arguments emerge.
Well, I think it's because the explanations have been bogus.
Just look at this thread. It took closer to a hundred emails (ok, so
I'm exaggerating, but not _that_ much) until the *real* reason for the
tie-in was actually exposed.
For the first 50+ emails, the explanation was "oh, only if you do
secure boot does this make sense".
Which is still pure BULLSHIT. Of _course_ that kind of stuff raises
peoples hackles and makes people not trust the messenger - he's
clearly being evasive and there must be something else going on.
So instead of the bullshit explanations, just explain the purely
_practical_ side.
Because I find it a *lot* more convincing to hear:
"We'd like to just enable it all the time, but it's known to break
some unusual hardware cases that we can't fix in software, and we
wanted *some* way to disable it that requires explicit and verified
user intervention to do that, and disabling secure boot is the
easiest hack we could come up with".
See? No bullshit. Just straight talk about the *actual* reason why
people decided on this particular tie-in, and admitting that it's a
hack, but also clearly stating the reason for the hack.
Now, I still don't necessarily agree that it's the best possible
option, but when stated in those terms I at least understand why that
option was picked as a reasonable one, and it changes the discussion a
lot, and (at least for me) makes it much more palatable.
Because as long as the explanation is just some "you must use secure
boot or you've already lost and further security is pointless"
hocus-pocus magical thinking, I immediately go "no, that sounds
completely bogus, and it makes testing and coverage much worse, we've
done other things quite like that without this secure boot tie-in".
Linus
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Linus Torvalds @ 2018-04-04 1:43 UTC (permalink / raw)
To: Matthew Garrett
Cc: Andrew Lutomirski, David Howells, Ard Biesheuvel, James Morris,
Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List,
Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook,
linux-efi
In-Reply-To: <CACdnJuuek-sS3esmomNOkjBMV_6VPL2NFCzRd+UGxbZrMe=4nw@mail.gmail.com>
On Tue, Apr 3, 2018 at 6:13 PM, Matthew Garrett <mjg59@google.com> wrote:
>
> There are four cases:
No.
Matthew., stop with the agenda already.
This shit is what I'm talking about:
> Verified Boot off, lockdown on: Perception of security improvement that's
> trivially circumvented (and so bad)
You're doing some serious value judgement that is simply bogus.
If lockdown actually helps avoid CPL0 execution attacks, then it helps
even if secure more is off.
Sure, you can do things like try to install kernels and reboot, but
honestly, that's not "trivially circumvented". It can be quite hard to
hide even if you don't have secure boot. Things like disk encryption
(common for a lot of people) for example means that you simply won't
be booting that machine without the user noticing.
Or think of virtual machines - which people often use on purpose for
security things. Again, they very much are _not_ going to have secure
boot, but it's not necessarily even possible to "replace the kernel
and reboot" at all, because the kernel came from outside the virtual
machine entirely, and rebooting might just kill the VM rather than
restart anything.
So I really think you're pushing this whole "not secure boot" means
"trivial circumvention" much much too hard.
To the point of it being an outright lie.
I think the kind of people who run stuff in virtual machines could
easily want to also enable lockdown measures, simply to reduce the
attack window within that VM. Wouldn't you agree? Those are often
security-conscious people.
This is what I mean by having an agenda. We all know you are a big
proponent of secure boot. But it seems to cloud your arguments, by
turning your assumptions and your agenda into an "argument" that is
simply not even TRUE.
See what I'm unhappy about?
> Verified Boot on, lockdown off: Perception of security improvement that's
> trivially circumvented (and so bad), status quo in mainline kernels
I think this is entirely false too. Again, the "trivial circumvention"
shows a bias and agenda that isn't really all that true.
> Of these four options, only two make sense.
No.
You say that, because you have that bias and that agenda.
But that simply doesn't make it true.
Now, what actually seems to be a real and valid argument is *this* part:
> This makes it easy for a user to switch
> between the two states that make sense by running a single command and then
> following some prompts on the next reboot. The alternative would be to
> provide a signed kernel that always enabled lockdown and an unsigned kernel
> that didn't, which would (a) increase load on distributions and (b) force
> users to both run mokutil --disable-validation and also install a different
> kernel.
THAT is an actual argument. Admittedly I think it's a horrible hack,
but it's a hack that can be explained without outright lying. And it
may be a hack that is "the best we can reasonably do"
See what I'm saying?
One argument is based on your value judgments that not everybody else
believes in.
The other argument is based purely on cold hard particular facts.
Guess which argument is better for people who aren't Matthew Garrett?
That said, wouldn't it be equally good to just make the whole thing be
a protected EFI variable instead? Once you have physical access to the
EFI shell (to turn off secure boot) you have access to that too.
Which would allow the "switch off/on" case even if there are other
reasons why changing secure boot isn't a great option (possibly
because secure boot isn't an option to begin with due to being so
invonvenient).
Linus
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Justin Forbes @ 2018-04-04 1:36 UTC (permalink / raw)
To: Linus Torvalds
Cc: Matthew Garrett, Andrew Lutomirski, David Howells, Ard Biesheuvel,
James Morris, Alan Cox, Greg Kroah-Hartman,
Linux Kernel Mailing List, linux-man, joeyli, LSM List, Linux API,
Kees Cook, linux-efi
In-Reply-To: <CA+55aFwhi=gz3HLoGST9--n1_kLJNP6jsf8GSesSFxTDCdPdtQ@mail.gmail.com>
On Tue, Apr 3, 2018 at 7:56 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Tue, Apr 3, 2018 at 5:46 PM, Matthew Garrett <mjg59@google.com> wrote:
>>
>> The generic distros have been shipping this policy for the past 5 years.
>
> .. so apparently it doesn't actually break things? Why not enable it
> by default then?
>
> And if "turn off secure boot" really is the accepted - and actuially
> used - workaround for the breakage, then
>
While there is very little breakage in the *years* we have been
shipping this in distro kernels, the accepted and used workaround has
always been "turn off secure boot" or sign/import your own keys,
depending on the problems encountered.
> WHY THE HELL DIDN'T YOU START OFF BY EXPLAINING THAT IN THE FIRST
> PLACE WHEN PEOPLE ASKED WHY THE TIE-IN EXISTED?
>
> Sorry for shouting, but really. We have a thread of just *how* many
> email messages that asked for the explanation for this? All we got was
> incomprehensible and illogical crap explanations.
>
> If there actually was a good explanation for the tie-in, it should
> have been front-and-center and explained as such.
>
Honestly, yes, the major distros have been shipping this patch set for
years now, and every time it comes to upstream, the same damn
arguments emerge. I do not disagree that there are uses for lockdown
outside of secure boot, provided you have some other mechanism to
verify your chain, I believe chrome OS does. But the tie to secure
boot is because that is the use case that users have been using for
years, it was discussed at kernel summit quite a while ago, plans went
forward there seemed to be agreement, and when it comes time for a
pull request, people come out of the woodwork with an expectation that
it solves every problem or it doesn't need to exist. What is here is a
good starting point. I would expect that if it were merged, others
would build upon that and use much of the code already in place to
extend it. It is tied to secure boot because that is what has been
using this for years as it never seems to get upstream. I am sure
that once it does finally land, it can and will be extended to other
things, but I don't think I would want to spend a lot of time trying
to leverage another external patch set that has been delayed upstream
so many times until it actually did land.
As for the ties to MS that come up every time, and have here as well,
there is no requirement on the MS signature. You can import your own
keys if you don't want them involved, I keep a "test key" imported for
actually running what I build locally.
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Matthew Garrett @ 2018-04-04 1:13 UTC (permalink / raw)
To: Linus Torvalds
Cc: luto, David Howells, Ard Biesheuvel, jmorris, Alan Cox,
Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man,
jlee, LSM List, linux-api, Kees Cook, linux-efi
In-Reply-To: <CA+55aFwhi=gz3HLoGST9--n1_kLJNP6jsf8GSesSFxTDCdPdtQ@mail.gmail.com>
On Tue, Apr 3, 2018 at 5:56 PM Linus Torvalds
<torvalds@linux-foundation.org>
wrote:
> On Tue, Apr 3, 2018 at 5:46 PM, Matthew Garrett <mjg59@google.com> wrote:
> >
> > The generic distros have been shipping this policy for the past 5 years.
> .. so apparently it doesn't actually break things? Why not enable it
> by default then?
Because it does break things, and the documented fix is "Disable Secure
Boot by running mokutil --disable-validation".
> And if "turn off secure boot" really is the accepted - and actuially
> used - workaround for the breakage, then
> WHY THE HELL DIDN'T YOU START OFF BY EXPLAINING THAT IN THE FIRST
> PLACE WHEN PEOPLE ASKED WHY THE TIE-IN EXISTED?
> Sorry for shouting, but really. We have a thread of just *how* many
> email messages that asked for the explanation for this? All we got was
> incomprehensible and illogical crap explanations.
There are four cases:
Verified Boot off, lockdown off: Status quo in distro and mainline kernels
Verified Boot off, lockdown on: Perception of security improvement that's
trivially circumvented (and so bad)
Verified Boot on, lockdown off: Perception of security improvement that's
trivially circumvented (and so bad), status quo in mainline kernels
Verified Boot on, lockdown on: Security improvement, status quo in distro
kernels
Of these four options, only two make sense. The most common implementation
of Verified Boot on x86 platforms is UEFI Secure Boot, so this patchset
includes an option that (if set) results in the kernel doing the right
thing without user intervention. This makes it easy for a user to switch
between the two states that make sense by running a single command and then
following some prompts on the next reboot. The alternative would be to
provide a signed kernel that always enabled lockdown and an unsigned kernel
that didn't, which would (a) increase load on distributions and (b) force
users to both run mokutil --disable-validation and also install a different
kernel.
I'm sorry if I've appeared tetchy in this discussion - having several of my
coworkers shot has not done wonders for my mood.
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Linus Torvalds @ 2018-04-04 0:56 UTC (permalink / raw)
To: Matthew Garrett
Cc: Andrew Lutomirski, David Howells, Ard Biesheuvel, James Morris,
Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List,
Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook,
linux-efi
In-Reply-To: <CACdnJuti5Riqoi1sesqPALYHq9LT87o4MFj-0Y5BZqqzJ5579g@mail.gmail.com>
On Tue, Apr 3, 2018 at 5:46 PM, Matthew Garrett <mjg59@google.com> wrote:
>
> The generic distros have been shipping this policy for the past 5 years.
.. so apparently it doesn't actually break things? Why not enable it
by default then?
And if "turn off secure boot" really is the accepted - and actuially
used - workaround for the breakage, then
WHY THE HELL DIDN'T YOU START OFF BY EXPLAINING THAT IN THE FIRST
PLACE WHEN PEOPLE ASKED WHY THE TIE-IN EXISTED?
Sorry for shouting, but really. We have a thread of just *how* many
email messages that asked for the explanation for this? All we got was
incomprehensible and illogical crap explanations.
If there actually was a good explanation for the tie-in, it should
have been front-and-center and explained as such.
Linus
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Matthew Garrett @ 2018-04-04 0:46 UTC (permalink / raw)
To: Linus Torvalds
Cc: luto, David Howells, Ard Biesheuvel, jmorris, Alan Cox,
Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man,
jlee, LSM List, linux-api, Kees Cook, linux-efi
In-Reply-To: <CA+55aFzJ2sQR13T+20MKEJ5co-f3Ev8rRxQkRCWVaeDSUU3yhQ@mail.gmail.com>
On Tue, Apr 3, 2018 at 5:33 PM Linus Torvalds
<torvalds@linux-foundation.org>
wrote:
> In contrast, the generic distros can't enable it anyway if it breaks
> random hardware. And it wouldn't be about secure boot or not, but
> about the random hardware choice.
The generic distros have been shipping this policy for the past 5 years.
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Linus Torvalds @ 2018-04-04 0:33 UTC (permalink / raw)
To: Matthew Garrett
Cc: Andrew Lutomirski, David Howells, Ard Biesheuvel, James Morris,
Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List,
Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook,
linux-efi
In-Reply-To: <CA+55aFwvuoSHhKnn82VnDndZ6oXMJgwHF604gZ=h3ehHyC600A@mail.gmail.com>
On Tue, Apr 3, 2018 at 5:25 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Honestly, I don't think the patchset is viable at all in that case.
.. or rather, it's probably viable only for distributions that already
have reasons to only care about controlled hardware environments, ie
Chromebooks etc.
But a chome OS install wouldn't care about the whole "secure boot or
not" issue anyway, because they'd also control that side, an they
might as well just enable it unconditionally.
In contrast, the generic distros can't enable it anyway if it breaks
random hardware. And it wouldn't be about secure boot or not, but
about the random hardware choice.
Linus
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Linus Torvalds @ 2018-04-04 0:25 UTC (permalink / raw)
To: Matthew Garrett
Cc: Andrew Lutomirski, David Howells, Ard Biesheuvel, James Morris,
Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List,
Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook,
linux-efi
In-Reply-To: <CACdnJuv-VpdhjEe1cMysdHb6Oy67jQqg-_TVHbUrOfH9GmCVvg@mail.gmail.com>
On Tue, Apr 3, 2018 at 5:16 PM, Matthew Garrett <mjg59@google.com> wrote:
>
> I ignored it because it's not a viable option. Part of the patchset
> disables various kernel command line options. If there's a kernel command
> line option that disables the patchset then it's pointless.
Honestly, I don't think the patchset is viable at all in that case.
No way will any sane distribution take it, potentially breaking a lot
of machines, and have no way to unbreak them except for "oh, btw, you
have to disable secure boot to get things to work again".
That would be insane.
So you'd better allow some command line options.
One reasonable option may be to just disable lockdown by default (to
make machines work reliably), and then have a "if you're anal about
security, add 'lockdown' to the kernel command line".
People who care about this already need to check the secure boot
status, so this would be just one more thing they'd check.
Linus
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox