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
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 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 be able to perform raw access to mo
On Tue, 10 Sep 2013, Matthew Garrett wrote:
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 a
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 kn
On Mon, Sep 9, 2013 at 4:30 PM, James Bottomley
wrote:
> On Mon, 2013-09-09 at 16:20 -0700, Kees Cook wrote:
>> On Mon, Sep 9, 2013 at 4:19 PM, David Lang wrote:
>> > And if SELinux can do the job, what is the reason for creating this new
>> > option?
>>
>> Not everyone uses SELinux. :) Also, it'
On Mon, 2013-09-09 at 16:20 -0700, Kees Cook wrote:
> On Mon, Sep 9, 2013 at 4:19 PM, David Lang 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
On Mon, Sep 9, 2013 at 4:19 PM, David Lang 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, the answer is no. It presents exactly the
>> same problem as
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 appli
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, an
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
> mod
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 includi
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 Mon, Sep 9, 2013 at 4:10 PM, David Lang wrote:
> On Mon, 9 Sep 2013, Josh Boyer wrote:
>
>> On Mon, Sep 9, 2013 at 3:41 PM, H. Peter Anvin 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, 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,
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, Sep 9, 2013 at 3:41 PM, H. Peter Anvin 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, you should have '1' just enforce module sign
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
--
T
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 differe
On Mon, Sep 9, 2013 at 3:56 PM, H. Peter Anvin wrote:
>>>
>>> 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
>>
>> 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 havi
On Mon, 9 Sep 2013, Josh Boyer wrote:
On Mon, Sep 9, 2013 at 3:41 PM, H. Peter Anvin 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, you should have
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 signi
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 a
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, perf
On Mon, 2013-09-09 at 15:01 -0400, 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
> > f
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 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
N�r��yb�X��ǧv�^�){.n�+{�y^n�r���z���
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' jus
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, 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 int
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 no
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, s
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
> ---
> Documentation/security/securelevel.txt | 23 +++
> include/linux/security.h
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 untrusted binaries"
implies that there's some way to
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
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
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 breaks existing userspace.
>
Capabilities don't have to me
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
kexec permits the loading and execution of arbitrary code in ring 0, which
permits the modification of the running kernel. Prevent this if securelevel
has been set.
Signed-off-by: Matthew Garrett
---
kernel/kexec.c | 4
1 file changed, 4 insertions(+)
diff --git a/kernel/kexec.c b/kernel/k
From: Josh Boyer
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
---
drivers/acpi/osl.c | 3 ++-
1 file changed, 2 insertions(+), 1 d
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
---
drivers/acpi/custom_method.c | 4
1 file changed, 4 insertions(+)
diff --git
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
---
drivers/char/mem.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/char/mem.c b/drive
Provide a coarse-grained runtime configuration option for restricting
userspace's ability to modify the running kernel.
Signed-off-by: Matthew Garrett
---
Documentation/security/securelevel.txt | 23 +++
include/linux/security.h | 8 +++
security/Kconfig
If securelevel has been set to 1 or greater, require that all modules have
valid signatures.
Signed-off-by: Matthew Garrett
---
kernel/module.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/module.c b/kernel/module.c
index dc58274..ab126d7 100644
--- a/kernel/module.
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 i
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
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
---
kernel/power/user.c | 4
1 file changed, 4 insertions(+)
diff --git a/kernel/power/user.c
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
IOMMU-i
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
Signed-off-by: Matthew Garrett
---
arch/x86/kernel/msr.c | 8
1 file changed, 8 insertions(+)
diff --git a/arch/x86/ker
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
---
arch/
We have no way of validating what all of the Asus WMI methods do on a
given machine, and there's a risk that some will allow hardware state to
be manipulated in such a way that arbitrary code can be executed in the
kernel. Prevent that if securelevel is set.
Signed-off-by: Matthew Garrett
---
dr
2013/9/5 Matt Fleming :
> 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 kernels on my
>> machi
53 matches
Mail list logo
