> Whether Microsoft would actually follow through on blacklisting their
> own signatures is obviously an unknown - they've told us they would, but
> commercial concerns etc who knows. They *will* blacklist our signatures.
I think that becomes an irrelevant debate. It's going to end up being
argued
On Thu, 2014-03-20 at 10:55 -0400, ty...@mit.edu wrote:
> I disagree; it's highly likely, if not certain that Windows booting
> under UEFI secure boot is going to be able to do some of the things
> that people are proposing that we have to prohibit in the name of
> security. That's because presum
On Wed, Mar 19, 2014 at 01:16:15PM -0700, Kees Cook wrote:
> UEFI is a red herring in both cases. This isn't about UEFI, it just
> happens that one of the things that can assert "trusted_kernel" is the
> UEFI Secure Boot path. Chrome OS would assert "trusted_kernel" by
> passing it on the kernel co
> Capabilities can be seen as related to this patch set, but it cannot
> be seen as a blocker. This logic is needed today, it's implemented,
> and it clearly marks where the known problems are. If an overhaul of
> capabilities happens, it can happen separately.
A working version is needed today -
On Fri, Mar 14, 2014 at 4:18 PM, Theodore Ts'o wrote:
> On Fri, Mar 14, 2014 at 10:08:40PM +, One Thousand Gnomes wrote:
>> > Signed userspace is not a requirement, and therefore any solution that
>> > relies on a signed initrd is inadequate. There are use cases that
>> > require verification
On Fri, Mar 14, 2014 at 3:31 PM, One Thousand Gnomes
wrote:
> On Fri, 14 Mar 2014 22:15:45 +
> Matthew Garrett wrote:
>
>> On Fri, 2014-03-14 at 22:08 +, One Thousand Gnomes wrote:
>> > On Fri, 14 Mar 2014 21:56:33 +
>> > Matthew Garrett wrote:
>> > > Signed userspace is not a requir
* One Thousand Gnomes:
>> For the Chrome OS use-case, it might be better described as "untrusted
>> userspace", but that seems unfriendly. :) The "trusted kernel" name
>> seems fine to me.
>
> Trusted is rather misleading. It's not trusted, it's *measured*.
I don't think anyone is doing any measu
* Theodore Ts'o:
> Right now, even though Lenovo laptops are shipping with Windows
> 8. UEFI secure boot is not made mandatory (although it is on enough to
> brick the laptop when it runs into bugs wwith the UEFI BIOS code,
> sigh). But sooner or later, UEFI secure boot will be on by default,
> a
> So as far as the narrow question of whether we should accept these
> patches, I think it's a good thing. Personally, I'm always going to
> be disabling UEFI secure boot (even if it doesn't brick my laptop),
> because for me, the security guarantees it provides isn't worth it.
> But there will be
On Fri, Mar 14, 2014 at 10:08:40PM +, One Thousand Gnomes wrote:
> > Signed userspace is not a requirement, and therefore any solution that
> > relies on a signed initrd is inadequate. There are use cases that
> > require verification of the initrd and other levels. This isn't one of
> > them.
On Fri, 2014-03-14 at 22:31 +, One Thousand Gnomes wrote:
> On Fri, 14 Mar 2014 22:15:45 +
> Matthew Garrett wrote:
> > The general problem includes having to support this even without an
> > selinux policy.
>
> Yes. No dispute about that. But equally the general solution should allow
> f
On Fri, 14 Mar 2014 22:15:45 +
Matthew Garrett wrote:
> On Fri, 2014-03-14 at 22:08 +, One Thousand Gnomes wrote:
> > On Fri, 14 Mar 2014 21:56:33 +
> > Matthew Garrett wrote:
> > > Signed userspace is not a requirement, and therefore any solution that
> > > relies on a signed initrd
On Fri, 2014-03-14 at 22:08 +, One Thousand Gnomes wrote:
> On Fri, 14 Mar 2014 21:56:33 +
> Matthew Garrett wrote:
> > Signed userspace is not a requirement, and therefore any solution that
> > relies on a signed initrd is inadequate. There are use cases that
> > require verification of t
On Fri, 14 Mar 2014 21:56:33 +
Matthew Garrett wrote:
> On Fri, 2014-03-14 at 21:48 +, One Thousand Gnomes wrote:
>
> > In your particularly implementation maybe you've got a weak setup where
> > you don't measure down to your initrd. That's a *flaw* in your
> > implementation. Don't inf
On Fri, 2014-03-14 at 21:58 +, One Thousand Gnomes wrote:
> On Fri, 14 Mar 2014 19:24:55 +
> Matthew Garrett wrote:
> > As an example, imagine a platform with the bootloader and kernel on
> > read-only media. The platform can assert that the kernel is trusted even
> > if there's no measure
On Fri, 14 Mar 2014 19:24:55 +
Matthew Garrett wrote:
> On Fri, 2014-03-14 at 14:11 -0400, Matthew Garrett wrote:
>
> > The fact that you keep saying measured really does make me suspect that
> > you misunderstand the problem. There's no measurement involved, there's
> > simply an assertion
On Fri, 2014-03-14 at 21:48 +, One Thousand Gnomes wrote:
> In your particularly implementation maybe you've got a weak setup where
> you don't measure down to your initrd. That's a *flaw* in your
> implementation. Don't inflict your limitations on others or on the
> future. EFI is only one (a
> I have a set of patches that appear acceptable to the security
> maintainer. I've rewritten them multiple times in response to various
> levels of bikeshedding. They solve a real problem and are being shipped
> by multiple distributions.
And ? I've seen some of the other "extra" stuff distributi
On Fri, 2014-03-14 at 13:37 -0700, David Lang wrote:
> On Fri, 14 Mar 2014, Matthew Garrett wrote:
> > As an example, imagine a platform with the bootloader and kernel on
> > read-only media. The platform can assert that the kernel is trusted even
> > if there's no measurement of the kernel.
>
> T
On Fri, 14 Mar 2014, Matthew Garrett wrote:
On Fri, 2014-03-14 at 14:11 -0400, Matthew Garrett wrote:
The fact that you keep saying measured really does make me suspect that
you misunderstand the problem. There's no measurement involved, there's
simply an assertion that the firmware (which you
On Fri, 2014-03-14 at 14:11 -0400, Matthew Garrett wrote:
> The fact that you keep saying measured really does make me suspect that
> you misunderstand the problem. There's no measurement involved, there's
> simply an assertion that the firmware (which you're forced to trust)
> chose, via some pol
On Fri, 2014-03-14 at 17:06 +, One Thousand Gnomes wrote:
> > But you keep talking about MSRs despite there being a patch that limits
> > access to MSRs. If you have specific examples of privilege escalations
> > that are possible even with these patches then please, mention them.
>
> I mentio
> But you keep talking about MSRs despite there being a patch that limits
> access to MSRs. If you have specific examples of privilege escalations
> that are possible even with these patches then please, mention them.
I mentioned MSRs once, and then you kept going on about it.
Your patches are a
> The command line problem here is a total red herring. If you've got a
> measured kernel, you have a measured command line. (If not, you don't
That would be the sensible approach, but it has some quite drastic
ramifications.
> have a measured kernel.) Dealing with the command line has nothing to
On Fri, 2014-03-14 at 08:54 -0700, Kees Cook wrote:
> All the more reason to ignore command line at this point. For Chrome
> OS, it's part of our boot state, so we don't care about it. For
> generic Secure Boot, we can add checks for dangerous stuff as we go
> forward. That's why I like this inter
On Fri, Mar 14, 2014 at 8:46 AM, Matthew Garrett
wrote:
> On Fri, 2014-03-14 at 08:23 -0700, Kees Cook wrote:
>
>> The command line problem here is a total red herring. If you've got a
>> measured kernel, you have a measured command line. (If not, you don't
>> have a measured kernel.) Dealing with
On Fri, 2014-03-14 at 08:23 -0700, Kees Cook wrote:
> The command line problem here is a total red herring. If you've got a
> measured kernel, you have a measured command line. (If not, you don't
> have a measured kernel.) Dealing with the command line has nothing to
> do with enforcing the ring0/
On Fri, Mar 14, 2014 at 5:51 AM, Matthew Garrett
wrote:
> On Fri, 2014-03-14 at 12:22 +, One Thousand Gnomes wrote:
>> > Have you actually looked at these patches? I've looked at every case of
>> > RAWIO in the kernel. For cases that are hardware specific and tied to
>> > fairly old hardware,
On Fri, 2014-03-14 at 12:22 +, One Thousand Gnomes wrote:
> > Have you actually looked at these patches? I've looked at every case of
> > RAWIO in the kernel. For cases that are hardware specific and tied to
> > fairly old hardware, I've ignored them. For cases which provide an
>
> Yes I have
> Have you actually looked at these patches? I've looked at every case of
> RAWIO in the kernel. For cases that are hardware specific and tied to
> fairly old hardware, I've ignored them. For cases which provide an
Yes I have - and it's not exactly localised: it modifies stuff all over
the tree wh
On Thu, 2014-03-13 at 23:21 +, One Thousand Gnomes wrote:
> On Thu, 13 Mar 2014 21:30:48 +
> Matthew Garrett wrote:
>
> > On Thu, 2014-03-13 at 21:24 +, One Thousand Gnomes wrote:
> >
> > > If I have CAP_SYS_RAWIO I can make arbitary ring 0 calls from userspace,
> > > trivially and i
On Thu, 13 Mar 2014 21:30:48 +
Matthew Garrett wrote:
> On Thu, 2014-03-13 at 21:24 +, One Thousand Gnomes wrote:
>
> > If I have CAP_SYS_RAWIO I can make arbitary ring 0 calls from userspace,
> > trivially and in a fashion well known and documented.
>
> How?
You want a list... there a
On Thu, 2014-03-13 at 14:28 -0700, H. Peter Anvin wrote:
> On 03/13/2014 02:24 PM, One Thousand Gnomes wrote:
> >
> > If I have CAP_SYS_RAWIO I can make arbitary ring 0 calls from userspace,
> > trivially and in a fashion well known and documented.
> >
>
> ... and once we eliminate CAP_SYS_RAWIO
On Thu, 2014-03-13 at 21:26 +, One Thousand Gnomes wrote:
> > On the other hand, disabling CAP_SYS_RAWIO *definitely* breaks expected
> > functionality - firmware loading and the fibmap ioctl are probably the
> > most obvious. And changing the use of CAP_SYS_RAWIO potentially breaks
> > userspa
On Thu, 2014-03-13 at 21:24 +, One Thousand Gnomes wrote:
> If I have CAP_SYS_RAWIO I can make arbitary ring 0 calls from userspace,
> trivially and in a fashion well known and documented.
How?
> You've missed a few others too - mem= (especially with exactmap) for
> example.
/dev/mem access
On 03/13/2014 02:24 PM, One Thousand Gnomes wrote:
>
> If I have CAP_SYS_RAWIO I can make arbitary ring 0 calls from userspace,
> trivially and in a fashion well known and documented.
>
... and once we eliminate CAP_SYS_RAWIO a bunch of the patches become
redundant.
-hpa
--
To unsubscr
> On the other hand, disabling CAP_SYS_RAWIO *definitely* breaks expected
> functionality - firmware loading and the fibmap ioctl are probably the
> most obvious. And changing the use of CAP_SYS_RAWIO potentially breaks
> userspace expectations, so we're kind of stuck there.
Actually I know how to
On Thu, 13 Mar 2014 15:59:24 +
Matthew Garrett wrote:
> On Thu, 2014-03-13 at 20:33 +1100, James Morris wrote:
>
> > I'll take it, but there's unanswered review feedback (your response to the
> > first question), and Alan raised some doubts about the patches which I'm
> > not sure have bee
On Thu, 2014-03-13 at 20:33 +1100, James Morris wrote:
> I'll take it, but there's unanswered review feedback (your response to the
> first question), and Alan raised some doubts about the patches which I'm
> not sure have been resolved.
The remaining opens seem to be CAP_SYS_RAWIO and firmware
On 03/13/2014 03:12 AM, One Thousand Gnomes wrote:
>
> I would prefer it did the revocation of CAP_SYS_RAWIO or at least
> documented the absolute requirement.
>
Seconded. This has been my opinion, raised over and over and over again.
-hpa
--
To unsubscribe from this list: send the l
On Thu, 13 Mar 2014 20:33:06 +1100 (EST)
James Morris wrote:
> On Wed, 12 Mar 2014, Kees Cook wrote:
>
> > On Wed, Mar 12, 2014 at 10:01 PM, Matthew Garrett
> > wrote:
> > > On Fri, 2014-02-28 at 14:03 +1100, James Morris wrote:
> > >
> > >> Ok, which tree should take this? I'm happy to, altho
On Wed, 12 Mar 2014, Kees Cook wrote:
> On Wed, Mar 12, 2014 at 10:01 PM, Matthew Garrett
> wrote:
> > On Fri, 2014-02-28 at 14:03 +1100, James Morris wrote:
> >
> >> Ok, which tree should take this? I'm happy to, although most of it is
> >> outside security/ .
> >
> > Should I be looking for so
On Wed, Mar 12, 2014 at 10:01 PM, Matthew Garrett
wrote:
> On Fri, 2014-02-28 at 14:03 +1100, James Morris wrote:
>
>> Ok, which tree should take this? I'm happy to, although most of it is
>> outside security/ .
>
> Should I be looking for someone else to take them instead? :)
Andrew, is this se
On Fri, 2014-02-28 at 14:03 +1100, James Morris wrote:
> Ok, which tree should take this? I'm happy to, although most of it is
> outside security/ .
Should I be looking for someone else to take them instead? :)
--
Matthew Garrett
On Thu, Feb 27, 2014 at 2:11 PM, Josh Boyer wrote:
> On Thu, Feb 27, 2014 at 2:07 PM, Greg KH wrote:
>> On Thu, Feb 27, 2014 at 01:04:34PM -0500, Josh Boyer wrote:
>>> On Wed, Feb 26, 2014 at 3:11 PM, Matthew Garrett
>>> wrote:
>>> > The conclusion we came to at Plumbers was that this patchset w
On Fri, 2014-02-28 at 14:03 +1100, James Morris wrote:
> Ok, which tree should take this? I'm happy to, although most of it is
> outside security/ .
Security might make the most sense - I don't think any of the additional
restrictions (beyond kexec, and I think we've hashed that argument out
no
On Thu, 27 Feb 2014, Josh Boyer wrote:
> On Wed, Feb 26, 2014 at 3:11 PM, Matthew Garrett
> wrote:
> > The conclusion we came to at Plumbers was that this patchset was basically
> > fine but that Linus hated the name "securelevel" more than I hate pickled
> > herring, so after thinking about this
On Thu, Feb 27, 2014 at 2:07 PM, Greg KH wrote:
> On Thu, Feb 27, 2014 at 01:04:34PM -0500, Josh Boyer wrote:
>> On Wed, Feb 26, 2014 at 3:11 PM, Matthew Garrett
>> wrote:
>> > The conclusion we came to at Plumbers was that this patchset was basically
>> > fine but that Linus hated the name "secu
On Thu, Feb 27, 2014 at 01:04:34PM -0500, Josh Boyer wrote:
> On Wed, Feb 26, 2014 at 3:11 PM, Matthew Garrett
> wrote:
> > The conclusion we came to at Plumbers was that this patchset was basically
> > fine but that Linus hated the name "securelevel" more than I hate pickled
> > herring, so after
On Wed, Feb 26, 2014 at 3:11 PM, Matthew Garrett
wrote:
> The conclusion we came to at Plumbers was that this patchset was basically
> fine but that Linus hated the name "securelevel" more than I hate pickled
> herring, so after thinking about this for a few months I've come up with
> "Trusted Ker
> > kernel was trusted - untrusted userspace could have set it on an untrusted
> > kernel, but by the same metric an untrusted kernel could just set it itself.
> >
> > If people object to this name then I swear to god that I will open a poll
> > on Phoronix to decide the next attempt and you will l
On Wed, Feb 26, 2014 at 12:11 PM, Matthew Garrett
wrote:
> The conclusion we came to at Plumbers was that this patchset was basically
> fine but that Linus hated the name "securelevel" more than I hate pickled
> herring, so after thinking about this for a few months I've come up with
> "Trusted Ke
The conclusion we came to at Plumbers was that this patchset was basically
fine but that Linus hated the name "securelevel" more than I hate pickled
herring, so after thinking about this for a few months I've come up with
"Trusted Kernel". This flag indicates that the kernel is, via some
external m
53 matches
Mail list logo
