> You have a fair chance of protecting via physical means (Locked rooms,
> Background checks on users etc.) of preventing a user with malicious intent
> to access the local machine.
So called "secure boot" doesn't deal with any kind of physical access,
which also means its useless if a device is l
Hi,
The basis for any secure boot is a way to detect that the system has
been tampered with or not. "Tamper Evidence".
There are two main vectors for a system to be tampered with. Someone
local to the machine and remote users who can access the machine
across a network interface. (this includes th
On Wed, Nov 07, 2012 at 09:19:35AM +0100, Olivier Galibert wrote:
> On Tue, Nov 6, 2012 at 11:47 PM, Matthew Garrett wrote:
>
> > Sure, and scripts run as root can wipe your files too. That's really not
> > what this is all about.
>
> What it is about then? What is secure boot supposed to do for
Sure, and scripts run as root can wipe your files too. That's really not what
this is all about.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http:
On Tue, 06 Nov 2012 16:55:25 -0500
Matthew Garrett wrote:
> I'm not sure why you think that Fedora PXE installs will automatically wipe
> disks - they'll do whatever Kickstart tells them to do. The only thing
> relevant to secure boot here is that you need a signed bootloader, just like
> when
It protects against certain classes of compromise. It doesn't prevent rogue
software damaging your system - anyone who gets root (and so could reconfigure
your boot order) could just rm -rf / anyway.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsub
* Matthew Garrett:
> I'm not sure why you think that Fedora PXE installs will
> automatically wipe disks - they'll do whatever Kickstart tells them
> to do.
Or what the referenced initrd contains (which is not signed, for
obvious reasons). The point is that "the bootloader is signed by
Fedora" d
I'm not sure why you think that Fedora PXE installs will automatically wipe
disks - they'll do whatever Kickstart tells them to do. The only thing relevant
to secure boot here is that you need a signed bootloader, just like when you
book off CD.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To u
* Chris Friesen:
> On 11/06/2012 01:56 AM, Florian Weimer wrote:
>
>> Personally, I think the only way out of this mess is to teach users
>> how to disable Secure Boot.
>
> If you're going to go that far, why not just get them to install a
> RedHat (or SuSE, or Ubuntu, or whoever) key and use that
On Tue, 6 Nov 2012, Chris Friesen wrote:
> > Personally, I think the only way out of this mess is to teach users
> > how to disable Secure Boot.
>
> If you're going to go that far, why not just get them to install a RedHat (or
> SuSE, or Ubuntu, or whoever) key and use that instead?
You always n
On 11/06/2012 01:56 AM, Florian Weimer wrote:
Personally, I think the only way out of this mess is to teach users
how to disable Secure Boot.
If you're going to go that far, why not just get them to install a
RedHat (or SuSE, or Ubuntu, or whoever) key and use that instead?
Secure boot does
On Tue, Nov 06, 2012 at 09:12:17AM +, Alan Cox wrote:
> - is it worth Red Hat doing - that's up to Red Hat's business managers
>
> - is it worth merging into the kernel - that's not
>
> The capability bit is small and clean the rest of it is beginning to look
> far too ugly for upstream right
On Tue, Nov 06, 2012 at 01:51:15PM +0100, Jiri Kosina wrote:
> On Wed, 31 Oct 2012, Matthew Garrett wrote:
> > shim generates a public and private key.
>
> It seems to me that this brings quite a huge delay into the boot process
> both for "regular" and resume cases (as shim has no way to know w
On Wed, 31 Oct 2012, Matthew Garrett wrote:
> > Reading stored memory image (potentially tampered before reboot) from disk
> > is basically DMA-ing arbitrary data over the whole RAM. I am currently not
> > able to imagine a scenario how this could be made "secure" (without
> > storing private k
On Tue, 6 Nov 2012 03:53:52 +
Matthew Garrett wrote:
> On Mon, Nov 05, 2012 at 07:36:32PM -0800, Eric W. Biederman wrote:
>
> > For automated installs you don't have to satisfy me. Feel free to
> > deliver a lousy solution to your users. Just don't use your arbitrary
> > design decisions
On Tue, 06 Nov 2012 03:12:19 +, Matthew Garrett said:
> On Mon, Nov 05, 2012 at 06:46:32PM -0800, Eric W. Biederman wrote:
> > You have it backwards. The conclusion here is that having a case where
> > a non-interactive install is possible is not a given.
>
> I deal with customers who perform
* Eric W. Biederman:
> If windows is not present on a system linux can not be used to boot a
> compromised version of windows without user knowledge because windows is
> not present.
Interesting idea. Unfortunately, it is very hard to detect reliably
that Windows is not present from the bootload
On Mon, Nov 05, 2012 at 09:19:46PM -0800, Eric W. Biederman wrote:
> Matthew Garrett writes:
>
> > On Mon, Nov 05, 2012 at 07:36:32PM -0800, Eric W. Biederman wrote:
> >
> >> For automated installs you don't have to satisfy me. Feel free to
> >> deliver a lousy solution to your users. Just don
Matthew Garrett writes:
> On Mon, Nov 05, 2012 at 07:36:32PM -0800, Eric W. Biederman wrote:
>
>> For automated installs you don't have to satisfy me. Feel free to
>> deliver a lousy solution to your users. Just don't use your arbitrary
>> design decisions to justify your kernel patches.
>
> M
On Mon, Nov 05, 2012 at 07:36:32PM -0800, Eric W. Biederman wrote:
> For automated installs you don't have to satisfy me. Feel free to
> deliver a lousy solution to your users. Just don't use your arbitrary
> design decisions to justify your kernel patches.
My kernel patches are justified by g
Matthew Garrett writes:
> On Mon, Nov 05, 2012 at 06:46:32PM -0800, Eric W. Biederman wrote:
>> Matthew Garrett writes:
>>
>> > On Mon, Nov 05, 2012 at 11:16:12AM -0800, Eric W. Biederman wrote:
>> >> Matthew Garrett writes:
>> >> > No, in the general case the system will do that once it fails
On Mon, Nov 05, 2012 at 06:46:32PM -0800, Eric W. Biederman wrote:
> Matthew Garrett writes:
>
> > On Mon, Nov 05, 2012 at 11:16:12AM -0800, Eric W. Biederman wrote:
> >> Matthew Garrett writes:
> >> > No, in the general case the system will do that once it fails to find a
> >> > bootable OS on
Matthew Garrett writes:
> On Mon, Nov 05, 2012 at 11:16:12AM -0800, Eric W. Biederman wrote:
>> Matthew Garrett writes:
>> > No, in the general case the system will do that once it fails to find a
>> > bootable OS on the drive.
>>
>> In the general case there will be a bootable OS on the drive
* James Bottomley:
> Right, but what I'm telling you is that by deciding to allow automatic
> first boot, you're causing the windows attack vector problem. You could
> easily do a present user test only on first boot which would eliminate
> it.
Apparently, the warning will look like this:
WAR
On Mon, Nov 05, 2012 at 11:16:12AM -0800, Eric W. Biederman wrote:
> Matthew Garrett writes:
> > No, in the general case the system will do that once it fails to find a
> > bootable OS on the drive.
>
> In the general case there will be a bootable OS on the drive.
That's in no way a given.
--
Matthew Garrett writes:
> On Sun, Nov 04, 2012 at 11:24:17PM -0800, Eric W. Biederman wrote:
>> "H. Peter Anvin" writes:
>> >
>> > That is a hugely different thing from needing a console.
>>
>> Not at all.
>>
>> In the general case user intereaction is required to tell the system to
>> boot of
On Mon, Nov 05, 2012 at 09:37:18AM -0600, Chris Friesen wrote:
> On 11/05/2012 09:31 AM, Jiri Kosina wrote:
>
> >I had a naive idea of just putting in-kernel verification of a complete
> >ELF binary passed to kernel by userspace, and if the signature matches,
> >jumping to it.
> >Would work for el
At Thu, 1 Nov 2012 13:18:49 +,
Alan Cox wrote:
>
> > I think it make sense because the private key is still protected by
> > signer. Any hacker who modified firmware is still need use private key
> > to generate signature, but hacker's private key is impossible to match
> > with the public key
On 11/05/2012 09:31 AM, Jiri Kosina wrote:
I had a naive idea of just putting in-kernel verification of a complete
ELF binary passed to kernel by userspace, and if the signature matches,
jumping to it.
Would work for elf-x86_64 nicely I guess, but we'd lose a lot of other
functionality currently
On Mon, 5 Nov 2012, Jiri Kosina wrote:
> Do I understand you correctly that by the 'glue' stuff you actually mean
> the division of the kexec image into segments?
>
> Of course, when we are dividing the image into segments and then passing
> those individually (even more so if some transformati
On Sun, 4 Nov 2012, Eric W. Biederman wrote:
> > Why is "when kernel has been securely booted, the in-kernel kexec
> > mechanism has to verify the signature of the supplied image before
> > kexecing it" not enough? (basically the same thing we are doing for signed
> > modules already).
>
> For
On Mon, Nov 05, 2012 at 01:44:36PM +, Alan Cox wrote:
> On Mon, 5 Nov 2012 12:38:58 +
> Matthew Garrett wrote:
> > No, in the general case the system will do that once it fails to find a
> > bootable OS on the drive.
>
> So your "secure" system can be wiped by a random Windows 8 install
On Mon, 5 Nov 2012 12:38:58 +
Matthew Garrett wrote:
> On Sun, Nov 04, 2012 at 11:24:17PM -0800, Eric W. Biederman wrote:
> > "H. Peter Anvin" writes:
> > >
> > > That is a hugely different thing from needing a console.
> >
> > Not at all.
> >
> > In the general case user intereaction is r
On Sun, Nov 04, 2012 at 11:24:17PM -0800, Eric W. Biederman wrote:
> "H. Peter Anvin" writes:
> >
> > That is a hugely different thing from needing a console.
>
> Not at all.
>
> In the general case user intereaction is required to tell the system to
> boot off of your choosen boot media instead
On Mon, Nov 05, 2012 at 09:20:17AM +0100, James Bottomley wrote:
> On Sun, 2012-11-04 at 13:52 +, Matthew Garrett wrote:
> > You don't get to punt on making the kernel secure by simply asserting
> > that some other system can be secure instead. The chain of trust needs
> > to go all the way b
On 11/05/2012 09:50 AM, Eric W. Biederman wrote:
>
> Facts are always a good thing to assume.
>
> The fact is the general case does not admit an install without user
> interaction.
>
In the general case, no. However, that is not a good reason to rule out
the cases where it *can* be done; espec
"H. Peter Anvin" writes:
> This is not a good thing to assume. A vendor could have an external
> button, for example.
Facts are always a good thing to assume.
The fact is the general case does not admit an install without user
interaction.
It makes a lot of sense to revisit the working assump
On Sun, 2012-11-04 at 13:52 +, Matthew Garrett wrote:
> On Sun, Nov 04, 2012 at 09:14:47AM +, James Bottomley wrote:
>
> > I've actually had more than enough experience with automated installs
> > over my career: they're either done by paying someone or using a
> > provisioning system. In
This is not a good thing to assume. A vendor could have an external button,
gor example.
ebied...@xmission.com wrote:
>"H. Peter Anvin" writes:
>
>> On 11/05/2012 07:14 AM, Eric W. Biederman wrote:
>>>
>>> In any case the notion that unattended install with no user
>interaction
>>> on any uef
"H. Peter Anvin" writes:
> On 11/05/2012 07:14 AM, Eric W. Biederman wrote:
>>
>> In any case the notion that unattended install with no user interaction
>> on any uefi machine in any state is complete and total rubbish. It
>> can't be done. You need power and you need boot media.
>>
>
> That
On 11/05/2012 07:14 AM, Eric W. Biederman wrote:
>
> In any case the notion that unattended install with no user interaction
> on any uefi machine in any state is complete and total rubbish. It
> can't be done. You need power and you need boot media.
>
That is a hugely different thing from nee
Jiri Kosina writes:
> On Fri, 2 Nov 2012, Vivek Goyal wrote:
>
>> > With secure boot enabled, then the kernel should refuse to let an
>> > unsigned kexec load new images, and kexec itself should refuse to
>> > load unsigned images.
>>
>> Yep, good in theory. Now that basically means reimplementi
Matthew Garrett writes:
> On Sun, Nov 04, 2012 at 09:14:47AM +, James Bottomley wrote:
>
>> I've actually had more than enough experience with automated installs
>> over my career: they're either done by paying someone or using a
>> provisioning system. In either case, they provision a stati
On Sun, Nov 04, 2012 at 09:14:47AM +, James Bottomley wrote:
> I've actually had more than enough experience with automated installs
> over my career: they're either done by paying someone or using a
> provisioning system. In either case, they provision a static image and
> boot environment d
On Sun 2012-11-04 04:28:02, Matthew Garrett wrote:
> On Sat, Nov 03, 2012 at 10:56:40PM +, James Bottomley wrote:
> > On Sat, 2012-11-03 at 13:46 +, Matthew Garrett wrote:
> > > I... what? Our signed bootloader will boot our signed kernel without any
> > > physically present end-user invol
On Sun, 2012-11-04 at 04:28 +, Matthew Garrett wrote:
> On Sat, Nov 03, 2012 at 10:56:40PM +, James Bottomley wrote:
> > On Sat, 2012-11-03 at 13:46 +, Matthew Garrett wrote:
> > > I... what? Our signed bootloader will boot our signed kernel without any
> > > physically present end-use
On Sat, Nov 03, 2012 at 10:56:40PM +, James Bottomley wrote:
> On Sat, 2012-11-03 at 13:46 +, Matthew Garrett wrote:
> > I... what? Our signed bootloader will boot our signed kernel without any
> > physically present end-user involvement. We therefore need to make it
> > as difficult as p
On Fri, 2 Nov 2012, Vivek Goyal wrote:
> > With secure boot enabled, then the kernel should refuse to let an
> > unsigned kexec load new images, and kexec itself should refuse to
> > load unsigned images.
>
> Yep, good in theory. Now that basically means reimplementing kexec-tools
> in kernel.
On Sat, 2012-11-03 at 13:46 +, Matthew Garrett wrote:
> On Sat, Nov 03, 2012 at 12:03:56PM +, James Bottomley wrote:
> > On Sat, 2012-11-03 at 00:22 +, Matthew Garrett wrote:
> > > Why would an attacker use one of those Linux systems? There's going to
> > > be plenty available that don
On Sat, Nov 03, 2012 at 12:37:44PM -0400, Eric Paris wrote:
> On Sat, Nov 3, 2012 at 12:31 PM, Alan Cox wrote:
> >> You're guaranteed to be able
> >> to do this on any Windows 8 certified hardware.
> >
> > Thats not my understanding of the situation.
>
> Windows 8 certification has this as a requ
On Sat, Nov 03, 2012 at 04:31:52PM +, Alan Cox wrote:
> > You're guaranteed to be able
> > to do this on any Windows 8 certified hardware.
>
> Thats not my understanding of the situation.
"17. Mandatory. On non-ARM systems, the platform MUST implement the
ability for a physically present us
On Sat, Nov 3, 2012 at 12:31 PM, Alan Cox wrote:
>> You're guaranteed to be able
>> to do this on any Windows 8 certified hardware.
>
> Thats not my understanding of the situation.
Windows 8 certification has this as a requirement for x86 hardware. I
belied the opposite is a requirement for arm
> You're guaranteed to be able
> to do this on any Windows 8 certified hardware.
Thats not my understanding of the situation.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel
On Sat, Nov 03, 2012 at 12:03:56PM +, James Bottomley wrote:
> On Sat, 2012-11-03 at 00:22 +, Matthew Garrett wrote:
> > Why would an attacker use one of those Linux systems? There's going to
> > be plenty available that don't have that restriction.
>
> It's called best practices. If som
On Sat, 2012-11-03 at 00:22 +, Matthew Garrett wrote:
> On Fri, Nov 02, 2012 at 11:38:23PM +, James Bottomley wrote:
> > On Fri, 2012-11-02 at 18:04 +, Matthew Garrett wrote:
> > > A user runs a binary that elevates itself to admin. Absent any flaws in
> > > Windows (cough), that shoul
On Fri, Nov 02, 2012 at 05:47:02PM -0700, Eric W. Biederman wrote:
> No reason to? How can I configure an off the shelf system originally
> sold with windows 8 installed to boot in UEFI secure boot mode using
> shim without trusting Microsoft's key?
Delete the installed keys, install your choice
> No reason to? How can I configure an off the shelf system originally
> sold with windows 8 installed to boot in UEFI secure boot mode using
> shim without trusting Microsoft's key?
Assuming its an x86 and a PC class platform and thus should allow you to
disable secure boot mode then you disable
On Sat, 3 Nov 2012 00:23:39 +
Matthew Garrett wrote:
> On Fri, Nov 02, 2012 at 11:46:07PM +, Alan Cox wrote:
> > On Fri, 02 Nov 2012 16:19:39 -0600
> > Chris Friesen wrote:
> > > On 11/02/2012 04:03 PM, Eric W. Biederman wrote:
> > > > Matthew Garrett writes:
> > > >> And if any of them
Matthew Garrett writes:
> On Fri, Nov 02, 2012 at 03:03:02PM -0700, Eric W. Biederman wrote:
>
>> I don't want my system p0wned in the first place and I don't want to run
>> windows. Why should I trust Microsoft's signing key?
>
> There's no reason to. Systems that don't trust Microsoft's signin
On Fri, Nov 02, 2012 at 11:46:07PM +, Alan Cox wrote:
> On Fri, 02 Nov 2012 16:19:39 -0600
> Chris Friesen wrote:
> > On 11/02/2012 04:03 PM, Eric W. Biederman wrote:
> > > Matthew Garrett writes:
> > >> And if any of them are used to attack Linux, we'd expect those versions
> > >> of Windows
On Fri, Nov 02, 2012 at 11:38:23PM +, James Bottomley wrote:
> On Fri, 2012-11-02 at 18:04 +, Matthew Garrett wrote:
> > A user runs a binary that elevates itself to admin. Absent any flaws in
> > Windows (cough), that should be all it can do in a Secure Boot world.
> > But if you can dro
On Fri, Nov 02, 2012 at 03:03:02PM -0700, Eric W. Biederman wrote:
> I don't want my system p0wned in the first place and I don't want to run
> windows. Why should I trust Microsoft's signing key?
There's no reason to. Systems that don't trust Microsoft's signing key
have no reason to be concer
On Fri, 02 Nov 2012 16:19:39 -0600
Chris Friesen wrote:
> On 11/02/2012 04:03 PM, Eric W. Biederman wrote:
> > Matthew Garrett writes:
> >
> >> On Fri, Nov 02, 2012 at 01:49:25AM -0700, Eric W. Biederman wrote:
> >>
> >>> When the goal is to secure Linux I don't see how any of this helps.
> >>>
On Fri, 2012-11-02 at 18:04 +, Matthew Garrett wrote:
> On Fri, Nov 02, 2012 at 05:57:38PM +, James Bottomley wrote:
> > On Fri, 2012-11-02 at 17:54 +, Matthew Garrett wrote:
> > > ? That's the message generated by the Windows access control mechanism
> > > when you run a binary that r
On 11/02/2012 04:03 PM, Eric W. Biederman wrote:
Matthew Garrett writes:
On Fri, Nov 02, 2012 at 01:49:25AM -0700, Eric W. Biederman wrote:
When the goal is to secure Linux I don't see how any of this helps.
Windows 8 compromises are already available so if we turn most of these
arguments ar
Matthew Garrett writes:
> On Fri, Nov 02, 2012 at 01:49:25AM -0700, Eric W. Biederman wrote:
>
>> When the goal is to secure Linux I don't see how any of this helps.
>> Windows 8 compromises are already available so if we turn most of these
>> arguments around I am certain clever attackers can go
I know I started it, but Windows really isn't necessary to see value,
even if it is what pushed the timing.
A user installs a package as root. Absent any flaws in the Linux
kernel (cough) that should be all it can do in a Secure Boot world.
But if you can drop a small trusted Linux system in ther
On Fri, Nov 02, 2012 at 05:22:41PM +0100, Jiri Kosina wrote:
> On Fri, 2 Nov 2012, Vivek Goyal wrote:
>
> > > > "crash" utility has module which allows reading kernel memory. So
> > > > leaking
> > > > this private key will be easier then you are thinking it to be.
> > >
> > > That's not upstrea
On Fri, Nov 02, 2012 at 05:57:38PM +, James Bottomley wrote:
> On Fri, 2012-11-02 at 17:54 +, Matthew Garrett wrote:
> > ? That's the message generated by the Windows access control mechanism
> > when you run a binary that requests elevated privileges.
>
> So that's a windows attack vecto
On Fri, 2012-11-02 at 17:54 +, Matthew Garrett wrote:
> On Fri, Nov 02, 2012 at 05:48:31PM +, James Bottomley wrote:
> > On Fri, 2012-11-02 at 16:54 +, Matthew Garrett wrote:
> > > On Fri, Nov 02, 2012 at 04:52:44PM +, James Bottomley wrote:
> > >
> > > > The first question is how
On Fri, Nov 02, 2012 at 05:48:31PM +, James Bottomley wrote:
> On Fri, 2012-11-02 at 16:54 +, Matthew Garrett wrote:
> > On Fri, Nov 02, 2012 at 04:52:44PM +, James Bottomley wrote:
> >
> > > The first question is how many compromises do you need. Without
> > > co-operation from windo
On Fri, 2012-11-02 at 16:54 +, Matthew Garrett wrote:
> On Fri, Nov 02, 2012 at 04:52:44PM +, James Bottomley wrote:
>
> > The first question is how many compromises do you need. Without
> > co-operation from windows, you don't get to install something in the
> > boot system, so if you're
On Thu, Nov 01, 2012 at 01:50:08PM -0400, Eric Paris wrote:
[..]
> I've talked with and
> worked with a public cloud operator who wants to prevent even a
> malicious root user from being able to run code in ring 0 inside their
> VM. The hope in that case was that in doing so they can indirectly
>
On Fri, Nov 02, 2012 at 10:54:50AM -0600, Chris Friesen wrote:
> On 11/02/2012 09:48 AM, Vivek Goyal wrote:
> >On Thu, Nov 01, 2012 at 03:02:25PM -0600, Chris Friesen wrote:
>
> >>With secure boot enabled, then the kernel should refuse to let an
> >>unsigned kexec load new images, and kexec itself
On 11/02/2012 09:48 AM, Vivek Goyal wrote:
On Thu, Nov 01, 2012 at 03:02:25PM -0600, Chris Friesen wrote:
With secure boot enabled, then the kernel should refuse to let an
unsigned kexec load new images, and kexec itself should refuse to
load unsigned images.
Yep, good in theory. Now that ba
On Fri, Nov 02, 2012 at 04:52:44PM +, James Bottomley wrote:
> The first question is how many compromises do you need. Without
> co-operation from windows, you don't get to install something in the
> boot system, so if you're looking for a single compromise vector, the
> only realistic attack
On Fri, 2012-11-02 at 17:33 +0100, Pavel Machek wrote:
> On Thu 2012-11-01 15:02:25, Chris Friesen wrote:
> > On 11/01/2012 02:27 PM, Pavel Machek wrote:
> >
> > >Could someone write down exact requirements for Linux kernel to be signed
> > >by Microsoft?
> > >Because thats apparently what you wa
On Fri, Nov 2, 2012 at 9:52 AM, Vivek Goyal wrote:
> On Fri, Nov 02, 2012 at 03:42:48PM +, Matthew Garrett wrote:
>> On Fri, Nov 02, 2012 at 11:30:48AM -0400, Vivek Goyal wrote:
>>
>> > "crash" utility has module which allows reading kernel memory. So leaking
>> > this private key will be easi
On Thu 2012-11-01 15:02:25, Chris Friesen wrote:
> On 11/01/2012 02:27 PM, Pavel Machek wrote:
>
> >Could someone write down exact requirements for Linux kernel to be signed by
> >Microsoft?
> >Because thats apparently what you want, and I don't think crippling
> >kexec/suspend is
> >enough.
>
On Fri, 2 Nov 2012, Vivek Goyal wrote:
> > > "crash" utility has module which allows reading kernel memory. So leaking
> > > this private key will be easier then you are thinking it to be.
> >
> > That's not upstream, right?
>
> Yes, checked with Dave, it is not upstream. Well, still it is a con
On Fri, Nov 02, 2012 at 03:42:48PM +, Matthew Garrett wrote:
> On Fri, Nov 02, 2012 at 11:30:48AM -0400, Vivek Goyal wrote:
>
> > "crash" utility has module which allows reading kernel memory. So leaking
> > this private key will be easier then you are thinking it to be.
>
> That's not upstre
On Thu, Nov 01, 2012 at 03:02:25PM -0600, Chris Friesen wrote:
> On 11/01/2012 02:27 PM, Pavel Machek wrote:
>
> >Could someone write down exact requirements for Linux kernel to be signed by
> >Microsoft?
> >Because thats apparently what you want, and I don't think crippling
> >kexec/suspend is
On Fri, Nov 02, 2012 at 11:30:48AM -0400, Vivek Goyal wrote:
> "crash" utility has module which allows reading kernel memory. So leaking
> this private key will be easier then you are thinking it to be.
That's not upstream, right?
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from
On Wed, Oct 31, 2012 at 03:02:01PM +, Matthew Garrett wrote:
> On Wed, Oct 31, 2012 at 03:50:00PM +0100, Jiri Kosina wrote:
>
> > Reading stored memory image (potentially tampered before reboot) from disk
> > is basically DMA-ing arbitrary data over the whole RAM. I am currently not
> > able
On Thu, Nov 01, 2012 at 10:29:17AM -0400, Eric Paris wrote:
> On Thu, Nov 1, 2012 at 5:59 AM, James Bottomley
> wrote:
>
> > But that doesn't really help me: untrusted root is an oxymoron.
>
> Imagine you run windows and you've never heard of Linux. You like
> that only windows kernels can boot
On Fri, Nov 02, 2012 at 01:49:25AM -0700, Eric W. Biederman wrote:
> When the goal is to secure Linux I don't see how any of this helps.
> Windows 8 compromises are already available so if we turn most of these
> arguments around I am certain clever attackers can go through windows to
> run compro
Matthew Garrett writes:
> On Thu, Nov 01, 2012 at 09:58:17PM +, Alan Cox wrote:
>> On Thu, 1 Nov 2012 21:34:52 +
>> Matthew Garrett wrote:
>> > I think you've misunderstood. Blacklist updates are append only.
>>
>> I think you've misunderstood - thats a technical detail that merely
>> a
On Thu, Nov 01, 2012 at 09:58:17PM +, Alan Cox wrote:
> On Thu, 1 Nov 2012 21:34:52 +
> Matthew Garrett wrote:
> > I think you've misunderstood. Blacklist updates are append only.
>
> I think you've misunderstood - thats a technical detail that merely
> alters the cost to the people who d
On Thu, 1 Nov 2012 21:34:52 +
Matthew Garrett wrote:
> On Thu, Nov 01, 2012 at 09:37:51PM +, Alan Cox wrote:
> > On Thu, 1 Nov 2012 21:28:43 +
> > Matthew Garrett wrote:
> > > Lawyers won't remove blacklist entries.
> >
> > Fear Uncertainty and Doubt
> >
> > Courts do, injunctions
On Thu, Nov 01, 2012 at 09:37:51PM +, Alan Cox wrote:
> On Thu, 1 Nov 2012 21:28:43 +
> Matthew Garrett wrote:
> > Lawyers won't remove blacklist entries.
>
> Fear Uncertainty and Doubt
>
> Courts do, injunctions do, the possibilty of getting caught with theirs
> hands in the till does.
On Thu, 1 Nov 2012 21:28:43 +
Matthew Garrett wrote:
> On Thu, Nov 01, 2012 at 09:31:27PM +, Alan Cox wrote:
> > > Linux vendors may care about Linux on Linux attacks. It's all fun and
> > > games until Oracle get Microsoft to revoke Red Hat's signature.
> >
> > Fear uncertainty and dou
On Thu, 1 Nov 2012 21:18:59 +
Matthew Garrett wrote:
> On Thu, Nov 01, 2012 at 09:14:00PM +, James Bottomley wrote:
>
> > I agree that's a possibility. However, I think the court of public
> > opinion would pillory the first Commercial Linux Distribution that went
> > to Microsoft for t
On Thu, Nov 01, 2012 at 09:31:27PM +, Alan Cox wrote:
> > Linux vendors may care about Linux on Linux attacks. It's all fun and
> > games until Oracle get Microsoft to revoke Red Hat's signature.
>
> Fear uncertainty and doubt (and if you think Oracle are going to do that
> I suspect your law
> Linux vendors may care about Linux on Linux attacks. It's all fun and
> games until Oracle get Microsoft to revoke Red Hat's signature.
Fear uncertainty and doubt (and if you think Oracle are going to do that
I suspect your lawyers should deal with it)
Alan.
--
To unsubscribe from this list: s
On Thu, Nov 01, 2012 at 09:14:00PM +, James Bottomley wrote:
> I agree that's a possibility. However, I think the court of public
> opinion would pillory the first Commercial Linux Distribution that went
> to Microsoft for the express purpose of revoking their competition's
> right to boot.
On Thu, 2012-11-01 at 21:06 +, Matthew Garrett wrote:
> On Thu, Nov 01, 2012 at 09:03:20PM +, James Bottomley wrote:
> > On Thu, 2012-11-01 at 13:50 -0400, Eric Paris wrote:
> > > What do we have to do to prevent Linux being used to attack Linux
> > > which may lead to secure boot being use
On Thu, Nov 01, 2012 at 09:03:20PM +, James Bottomley wrote:
> On Thu, 2012-11-01 at 13:50 -0400, Eric Paris wrote:
> > What do we have to do to prevent Linux being used to attack Linux
> > which may lead to secure boot being useless.
>
> That's not really remotely related, is it? Microsoft d
On Thu, 2012-11-01 at 13:50 -0400, Eric Paris wrote:
> On Thu, Nov 1, 2012 at 11:18 AM, James Bottomley
> wrote:
>
> > You're completely confusing two separate goals:
> >
> > 1. Is it possible to use secure boot to implement a security policy
> > on Linux
> > 2. What do we have
On 11/01/2012 02:27 PM, Pavel Machek wrote:
Could someone write down exact requirements for Linux kernel to be signed by
Microsoft?
Because thats apparently what you want, and I don't think crippling
kexec/suspend is
enough.
As I understand it, the kernel won't be signed by Microsoft.
Rathe
Hi!
> > But that doesn't really help me: untrusted root is an oxymoron.
>
> Imagine you run windows and you've never heard of Linux. You like
> that only windows kernels can boot on your box and not those mean
> nasty hacked up malware kernels. Now some attacker manages to take
> over your box
1 - 100 of 162 matches
Mail list logo
