2013/9/5 Matt Fleming m...@console-pimps.org:
On Sat, 03 Aug, at 12:06:23AM, Clea F. Rees wrote:
Matt Fleming asked me to email describing a problem I am experiencing
with the EFI stub loader. Matt has been trying to diagnose the cause
of consistent failures of the stub loader in recent
Permitting write access to MSRs allows userspace to modify the running
kernel. Prevent this if securelevel has been set. Based on a patch by Kees
Cook.
Cc: Kees Cook keesc...@chromium.org
Signed-off-by: Matthew Garrett matthew.garr...@nebula.com
---
arch/x86/kernel/msr.c | 8
1 file
IO port access would permit users to gain access to PCI configuration
registers, which in turn (on a lot of hardware) give access to MMIO register
space. This would potentially permit root to trigger arbitrary DMA, so lock
it down when securelevel is set.
Signed-off-by: Matthew Garrett
Any hardware that can potentially generate DMA has to be locked down from
userspace in order to avoid it being possible for an attacker to modify
kernel code. This should be prevented if securelevel has been set. Default
to paranoid - in future we can potentially relax this for sufficiently
uswsusp allows a user process to dump and then restore kernel state, which
makes it possible to modify the running kernel. Disable this if securelevel
has been set.
Signed-off-by: Matthew Garrett matthew.garr...@nebula.com
---
kernel/power/user.c | 4
1 file changed, 4 insertions(+)
diff
UEFI Secure Boot provides a mechanism for ensuring that the firmware will
only load signed bootloaders and kernels. Certain use cases may also
require that the kernel prevent userspace from inserting untrusted kernel
code at runtime. Add a configuration option that enforces this automatically
when
Allowing users to write to address space provides mechanisms that may permit
modification of the kernel at runtime. Prevent this if securelevel has been
set.
Signed-off-by: Matthew Garrett matthew.garr...@nebula.com
---
drivers/char/mem.c | 6 ++
1 file changed, 6 insertions(+)
diff --git
If securelevel has been set to 1 or greater, require that all modules have
valid signatures.
Signed-off-by: Matthew Garrett matthew.garr...@nebula.com
---
kernel/module.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/module.c b/kernel/module.c
index dc58274..ab126d7
custom_method effectively allows arbitrary access to system memory, making
it possible for an attacker to modify the kernel at runtime. Prevent this
if securelevel has been set.
Signed-off-by: Matthew Garrett matthew.garr...@nebula.com
---
drivers/acpi/custom_method.c | 4
1 file changed, 4
From: Josh Boyer jwbo...@redhat.com
This option allows userspace to pass the RSDP address to the kernel, which
makes it possible for a user to execute arbitrary code in the kernel.
Disable this when securelevel is set.
Signed-off-by: Josh Boyer jwbo...@redhat.com
---
drivers/acpi/osl.c | 3 ++-
Some use cases require the ability to ensure that anything running in ring 0
is trusted code. We have support for signing the kernel and kernel modules,
but there's still a range of exported kernel interfaces that make it easy to
modify the running kernel. Previous attempts to implement a generic
On 09/09/2013 09:30 AM, Matthew Garrett wrote:
On Mon, 2013-09-09 at 09:27 -0700, H. Peter Anvin wrote:
This will break or have to be redefined once you have signed kexec.
Yeah. I wasn't really sure how to define it based on an implementation
that isn't there yet - saying kexec_load() of
On Mon, 2013-09-09 at 09:51 -0700, H. Peter Anvin wrote:
On 09/09/2013 09:44 AM, Matthew Garrett wrote:
On Mon, 2013-09-09 at 09:42 -0700, H. Peter Anvin wrote:
Neither of this tend to be true long time... which leads one back to
capabilities.
We can't use capabilities. Doing so
On Mon, 2013-09-09 at 09:42 -0700, H. Peter Anvin wrote:
Neither of this tend to be true long time... which leads one back to
capabilities.
We can't use capabilities. Doing so breaks existing userspace.
--
Matthew Garrett matthew.garr...@nebula.com
On 09/09/2013 08:49 AM, Matthew Garrett wrote:
Provide a coarse-grained runtime configuration option for restricting
userspace's ability to modify the running kernel.
Signed-off-by: Matthew Garrett matthew.garr...@nebula.com
---
Documentation/security/securelevel.txt | 23 +++
On Mon, 09 Sep 2013 11:49:34 -0400, Matthew Garrett said:
So, this is my final attempt at providing the functionality I'm interested
in without inherently tying it to Secure Boot. There's strong parallels
between the functionality that I'm interested in and the BSD securelevel
interface, so
On Mon, 2013-09-09 at 13:18 -0400, valdis.kletni...@vt.edu wrote:
You may as well bite the bullet on this one, and tie it together. Without
Secure Boot, by the time your code runs it's already too late. That's the
whole point of Secure Boot, after all.
It's already been made clear that
On Mon, 9 Sep 2013, valdis.kletni...@vt.edu wrote:
On Mon, 09 Sep 2013 11:49:34 -0400, Matthew Garrett said:
So, this is my final attempt at providing the functionality I'm interested
in without inherently tying it to Secure Boot. There's strong parallels
between the functionality that I'm
On Mon, 2013-09-09 at 11:25 -0700, David Lang wrote:
Given that we know that people want signed binaries without blocking kexec,
you
should have '1' just enforce module signing and '2' (or higher) implement a
full
lockdown including kexec.
There's already a kernel option for that.
--
On Mon, 2013-09-09 at 11:53 -0700, David Lang wrote:
So is there a way to unify these different things rather than creating yet
another different knob?
We haven't found one that people consider generally acceptable.
--
Matthew Garrett matthew.garr...@nebula.com
On Mon, 9 Sep 2013, Matthew Garrett wrote:
On Mon, 2013-09-09 at 11:40 -0700, David Lang wrote:
On Mon, 9 Sep 2013, Matthew Garrett wrote:
On Mon, 2013-09-09 at 11:25 -0700, David Lang wrote:
Given that we know that people want signed binaries without blocking kexec, you
should have '1'
On Mon, 09 Sep 2013 11:25:38 -0700, David Lang said:
Given that we know that people want signed binaries without blocking kexec,
you
should have '1' just enforce module signing and '2' (or higher) implement a
full
lockdown including kexec.
Or, eliminate the -1 permanently insecure
On Mon, 2013-09-09 at 09:27 -0700, H. Peter Anvin wrote:
On 09/09/2013 08:49 AM, Matthew Garrett wrote:
+1: Secure mode. If set, userspace will be unable to perform direct access
+to PCI devices, port IO access, access system memory directly via
+/dev/mem and /dev/kmem, perform
On Mon, 9 Sep 2013, Matthew Garrett wrote:
On Mon, 2013-09-09 at 11:25 -0700, David Lang wrote:
Given that we know that people want signed binaries without blocking kexec, you
should have '1' just enforce module signing and '2' (or higher) implement a full
lockdown including kexec.
There's
On Mon, 2013-09-09 at 11:40 -0700, David Lang wrote:
On Mon, 9 Sep 2013, Matthew Garrett wrote:
On Mon, 2013-09-09 at 11:25 -0700, David Lang wrote:
Given that we know that people want signed binaries without blocking
kexec, you
should have '1' just enforce module signing and '2' (or
On Mon, 9 Sep 2013, Josh Boyer wrote:
On Mon, Sep 9, 2013 at 3:41 PM, H. Peter Anvin h...@zytor.com wrote:
On 09/09/2013 12:01 PM, valdis.kletni...@vt.edu wrote:
On Mon, 09 Sep 2013 11:25:38 -0700, David Lang said:
Given that we know that people want signed binaries without
blocking kexec,
I.e. capabilities ;)
Circles. All I see here are circles.
Having lived an entire release with a capabilities based mechanism for
this in Fedora, please no.
And if you are talking about non-POSIX capabilities as you mentioned
earlier, that seems to be no different than having
On Mon, 2013-09-09 at 12:59 -0700, David Lang wrote:
At least you should be able to unify the implementation, even if you don't
unify
the user visible knob
Well sure, I could take this integer and merge another integer into it,
but now you have the same value being modified by two different
On 09/09/2013 12:58 PM, Josh Boyer wrote:
This is the term capability in the general sense, not the POSIX
implementation thereof.
See the whole last paragraph. Particularly the last sentence.
Yes. I disagree with not being able to use standard terminology.
-hpa
--
To
On Mon, 9 Sep 2013, Matthew Garrett wrote:
On Mon, 2013-09-09 at 11:53 -0700, David Lang wrote:
So is there a way to unify these different things rather than creating yet
another different knob?
We haven't found one that people consider generally acceptable.
At least you should be able to
On Mon, 2013-09-09 at 13:15 -0700, David Lang wrote:
On Mon, 9 Sep 2013, Matthew Garrett wrote:
On Mon, 2013-09-09 at 12:59 -0700, David Lang wrote:
At least you should be able to unify the implementation, even if you don't
unify
the user visible knob
Well sure, I could take this
On Mon, Sep 9, 2013 at 4:10 PM, David Lang da...@lang.hm wrote:
On Mon, 9 Sep 2013, Josh Boyer wrote:
On Mon, Sep 9, 2013 at 3:41 PM, H. Peter Anvin h...@zytor.com wrote:
On 09/09/2013 12:01 PM, valdis.kletni...@vt.edu wrote:
On Mon, 09 Sep 2013 11:25:38 -0700, David Lang said:
Given that
On Mon, 9 Sep 2013, Matthew Garrett wrote:
On Mon, 2013-09-09 at 12:59 -0700, David Lang wrote:
At least you should be able to unify the implementation, even if you don't unify
the user visible knob
Well sure, I could take this integer and merge another integer into it,
but now you have the
On 09/09/2013 12:01 PM, valdis.kletni...@vt.edu wrote:
On Mon, 09 Sep 2013 11:25:38 -0700, David Lang said:
Given that we know that people want signed binaries without
blocking kexec, you should have '1' just enforce module signing
and '2' (or higher) implement a full lockdown including
On Mon, 2013-09-09 at 11:49 -0400, Matthew Garrett wrote:
Some use cases require the ability to ensure that anything running in ring 0
is trusted code. We have support for signing the kernel and kernel modules,
but there's still a range of exported kernel interfaces that make it easy to
modify
On Mon, 2013-09-09 at 11:25 -0700, David Lang wrote:
1 lock down modules
2 lock down kexec
Having thought about this, the answer is no. It presents exactly the
same problem as capabilities do - the set can never be meaningfully
extended. If an application sets only the bits it knows about, and
On Mon, 9 Sep 2013, Matthew Garrett wrote:
On Mon, 2013-09-09 at 11:25 -0700, David Lang wrote:
1 lock down modules
2 lock down kexec
Having thought about this, the answer is no. It presents exactly the
same problem as capabilities do - the set can never be meaningfully
extended. If an
On Mon, 2013-09-09 at 16:20 -0700, Kees Cook wrote:
On Mon, Sep 9, 2013 at 4:19 PM, David Lang da...@lang.hm wrote:
On Mon, 9 Sep 2013, Matthew Garrett wrote:
On Mon, 2013-09-09 at 11:25 -0700, David Lang wrote:
1 lock down modules
2 lock down kexec
Having thought about this,
On Mon, Sep 9, 2013 at 4:30 PM, James Bottomley
james.bottom...@hansenpartnership.com wrote:
On Mon, 2013-09-09 at 16:20 -0700, Kees Cook wrote:
On Mon, Sep 9, 2013 at 4:19 PM, David Lang da...@lang.hm wrote:
And if SELinux can do the job, what is the reason for creating this new
option?
On Mon, 2013-09-09 at 16:19 -0700, David Lang wrote:
On Mon, 9 Sep 2013, Matthew Garrett wrote:
Having thought about this, the answer is no. It presents exactly the
same problem as capabilities do - the set can never be meaningfully
extended. If an application sets only the bits it knows
On Tue, 10 Sep 2013, Matthew Garrett wrote:
On Mon, 2013-09-09 at 19:44 -0700, David Lang wrote:
On Tue, 10 Sep 2013, Matthew Garrett wrote:
No. Say someone adds an additional lockdown bit to forbid raw access to
mounted block devices. The Turn everything off approach now means that
I won't
On Mon, 2013-09-09 at 20:09 -0700, David Lang wrote:
On Tue, 10 Sep 2013, Matthew Garrett wrote:
Someone adds a new install_evil() syscall and adds a disable bit. If I
don't disable it, I'm now vulnerable. Please pay attention to earlier
discussion.
so instead they add install_evil()
42 matches
Mail list logo
