於 二，2013-09-10 於 18:26 +，Matthew Garrett 提到：
On Tue, 2013-09-10 at 14:23 -0300, Henrique de Moraes Holschuh wrote:
On Tue, 10 Sep 2013, Matthew Garrett wrote:
That's why modern systems require signed firmware updates.
Linux doesn't. Is someone working on adding signature support to
On Tue, 10 Sep 2013, Matthew Garrett wrote:
That's why modern systems require signed firmware updates.
Linux doesn't. Is someone working on adding signature support to the
runtime firmware loader?
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the
On Tue, 2013-09-10 at 14:23 -0300, Henrique de Moraes Holschuh wrote:
On Tue, 10 Sep 2013, Matthew Garrett wrote:
That's why modern systems require signed firmware updates.
Linux doesn't. Is someone working on adding signature support to the
runtime firmware loader?
It'd be simple to do
On 09/10/2013 11:26 AM, Matthew Garrett wrote:
On Tue, 2013-09-10 at 14:23 -0300, Henrique de Moraes Holschuh wrote:
On Tue, 10 Sep 2013, Matthew Garrett wrote:
That's why modern systems require signed firmware updates.
Linux doesn't. Is someone working on adding signature support to the
On Tue, Sep 10, 2013 at 11:51 AM, gre...@linuxfoundation.org
gre...@linuxfoundation.org wrote:
On Tue, Sep 10, 2013 at 11:29:45AM -0700, H. Peter Anvin wrote:
On 09/10/2013 11:26 AM, Matthew Garrett wrote:
On Tue, 2013-09-10 at 14:23 -0300, Henrique de Moraes Holschuh wrote:
On Tue, 10 Sep
On Tue, Sep 10, 2013 at 11:29:45AM -0700, H. Peter Anvin wrote:
On 09/10/2013 11:26 AM, Matthew Garrett wrote:
On Tue, 2013-09-10 at 14:23 -0300, Henrique de Moraes Holschuh wrote:
On Tue, 10 Sep 2013, Matthew Garrett wrote:
That's why modern systems require signed firmware updates.
On Tue, 10 Sep 2013, Kees Cook wrote:
Subject: Re: [PATCH 00/12] One more attempt at useful kernel lockdown
On Tue, Sep 10, 2013 at 11:51 AM, gre...@linuxfoundation.org
gre...@linuxfoundation.org wrote:
On Tue, Sep 10, 2013 at 11:29:45AM -0700, H. Peter Anvin wrote:
On 09/10/2013 11:26 AM
On 09/10/2013 12:17 PM, David Lang wrote:
In theory these blobs are traceable to a manufacturer. It's not really
an indication that it's safe more than it's an indication that it
hasn't been changed. But I haven't chased this very hard yet because
of below...
well, not if you are trying to
On 09/10/2013 04:55 PM, Mimi Zohar wrote:
What would the deliverables be from the hardware vendor and what tools
would you expect them to need on their end?
The package installer needs to not only install files, but file metadata
as well. Elena Reshetova (Intel) has already added rpm hooks
On Tue, 2013-09-10 at 12:44 -0700, H. Peter Anvin wrote:
On 09/10/2013 12:17 PM, David Lang wrote:
In theory these blobs are traceable to a manufacturer. It's not really
an indication that it's safe more than it's an indication that it
hasn't been changed. But I haven't chased this very
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 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, 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()
37 matches
Mail list logo
