於 二，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 s
On Tue, 2013-09-10 at 16:48 -0700, H. Peter Anvin wrote:
> On 09/10/2013 04:43 PM, Mimi Zohar wrote:
> >
> > Why invent yet another method of verifying the integrity of a file based
> > on a signature? Why not use the existing method for appraising files?
> > Just create a new integrity hook at t
On 09/10/2013 04:43 PM, Mimi Zohar wrote:
>
> Why invent yet another method of verifying the integrity of a file based
> on a signature? Why not use the existing method for appraising files?
> Just create a new integrity hook at the appropriate place.
>
What would the deliverables be from the h
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 chas
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 r
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
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
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
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, Sep 10, 2013 at 11:51 AM, 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 2013, Matthew Garr
On Tue, Sep 10, 2013 at 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 signatu
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
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 t
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 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 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 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, 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, 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, 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
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, 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
>>
>> 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 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 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 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, 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�+{zX����ܨ}���Ơ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
45 matches
Mail list logo
