FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 07-08-2012, 05:26 PM
Philipp Kern
 
Default EFI in Debian

Paul,

am Sun, Jul 08, 2012 at 10:00:05AM -0600 hast du folgendes geschrieben:
> On Sun, Jul 8, 2012 at 7:15 AM, Wookey wrote:
> > Will Android machines make secure boot turn-offable or another key
> > installable, or will thay follow the Microsoft lead and lock
> > everything down too?
> Are there any Android devices that aren't *already* bootloader locked
> or require jailbreaking to get root? I don't think Microsoft is
> creating a trend here, locked down ARM devices are already the norm
> AFAICT.

there's a difference between requiring jailbreaking to get root and being able
to flash a random different software image. The Samsung Galaxy S is perfectly
able to get flashed, but with the default image you don't get root. I'm sort
of ok with that because I couldn't care less about the default image.

Kind regards
Philipp Kern
 
Old 07-08-2012, 11:30 PM
Ted Ts'o
 
Default EFI in Debian

On Sun, Jul 08, 2012 at 10:00:05AM -0600, Paul Wise wrote:
> On Sun, Jul 8, 2012 at 7:15 AM, Wookey wrote:
> > Will Android machines make secure boot turn-offable or another key
> > installable, or will thay follow the Microsoft lead and lock
> > everything down too?
>
> Are there any Android devices that aren't *already* bootloader locked
> or require jailbreaking to get root? I don't think Microsoft is
> creating a trend here, locked down ARM devices are already the norm
> AFAICT.

The Galaxy Nexus (and Nexus devices in general) can be unlocked by
simply running the "fastboot oem unlock" command which is distributed
as part of the Android SDK. The unlock process will erase all of the
user data for security reasons (so that if someone steals your phone,
they can't use the unlock process to break security and grab all of
your data, including silly things like the authentication cookies
which would allow an attacker access to your google eaccount).

HTC and ASUS have also been selling their newer android with an
unlocked bootloader. Most Samsung devices are shipped with unlocking
tools, so it came as a bit a surprise when the Verizon Samsung Galaxy
S3 came with a locked bootloader. Some have blamed Verizon, but
there's no proof of that as far as I know.

So in answer to your question, there are plenty of Android devices
which are trivially unlockable. (And once a Nexus phone is unlocked,
it's you can get a root shell trivially; no jail-breaking necessary.
Of course this is true for an attacker/thief who has managed to steal
your phone, but if you want to unlock the phone, it's easily doable on
many Android devices.)

- Ted

P.S. Personally, I recommend that people buy SIM unlocked, and easily
boot-unlocked Android phones; and if you get Google Experience Nexus
that isn't subsidized by Carriers, its firmware updates don't have to
get approved by carriers. It also means you don't get any
carrier-mandated or handset-manfacturer-mandated bloatware.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120708233048.GA24807@thunk.org">http://lists.debian.org/20120708233048.GA24807@thunk.org
 
Old 07-08-2012, 11:52 PM
Ted Ts'o
 
Default EFI in Debian

On Fri, Jul 06, 2012 at 05:32:44AM +0100, Ben Hutchings wrote:
>
> 2. Upstream kernel support: when booted in Secure Boot mode, Linux would
> only load signed kernel modules and disable the various debug interfaces
> that allow code injection. I'm aware that David Howells, Matthew
> Garrett and others are working on this.

Matthew Garret believes that this is a requirement; however, there is
no documented paper trail indicating that this is actually necessary.
There are those who believe that Microsoft wouldn't dare revoke a
Linux key because of the antitrust issues that would arise.

This would especially true if the bootloader displayed a spash screen
with a huge penguin on it, and the user was obliged to hit a key
acknowledging the spash screen before the boot was allowed to
continue. James is working on a signed bootloader which would do
this.

It's not even obvious that the spash screen is needed, BTW. Canonical
is not using a splash screen and is not signing the kernel or kernel
modules. It will be *very* interesting if Microsoft dares to revoke
Canonical's certificate, or refuse to issue a certificate. I'm sure
there are developers in Europe who would be delighted to call this to
the attention of the European Anti-Trust regulators --- you know, the
ones who have already fined Microsoft to the tune of 860 million Euros
($1.1 billion USD).

So personally, I would hope that at least some distributions will
patch out the splash screen, and apply for a certificate. If we have
multiple distributions using different signing policies and slightly
different approaches (which is the beauty of free/open source boot
loaders; everyone can tweak things slightly), we can see how Microsoft
will react.

It should be entertaining....

- Ted


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120708235244.GB24807@thunk.org">http://lists.debian.org/20120708235244.GB24807@thunk.org
 
Old 07-09-2012, 03:48 PM
Matthew Garrett
 
Default EFI in Debian

In article <20120708235244.GB24807@thunk.org> Ted Ts'o wrote:
> Matthew Garret believes that this is a requirement; however, there is
> no documented paper trail indicating that this is actually necessary.
> There are those who believe that Microsoft wouldn't dare revoke a
> Linux key because of the antitrust issues that would arise.

Hey, it's hardly my fault that nobody else bothered turning up to the
well-advertised events where this got discussed...

> This would especially true if the bootloader displayed a spash screen
> with a huge penguin on it, and the user was obliged to hit a key
> acknowledging the spash screen before the boot was allowed to
> continue. James is working on a signed bootloader which would do
> this.

Well, sure, we could associate "Large picture of a penguin on your boot
screen" with "your machine has been hacked", but I'm not convinced that's
a great strategy.

--
Matthew Garrett | mjg59@srcf.ucam.org


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: E1SoGCU-0007mE-0i@chiark.greenend.org.uk">http://lists.debian.org/E1SoGCU-0007mE-0i@chiark.greenend.org.uk
 
Old 07-09-2012, 04:26 PM
Ted Ts'o
 
Default EFI in Debian

On Mon, Jul 09, 2012 at 04:48:38PM +0100, Matthew Garrett wrote:
> In article <20120708235244.GB24807@thunk.org> Ted Ts'o wrote:
> > Matthew Garret believes that this is a requirement; however, there is
> > no documented paper trail indicating that this is actually necessary.
> > There are those who believe that Microsoft wouldn't dare revoke a
> > Linux key because of the antitrust issues that would arise.
>
> Hey, it's hardly my fault that nobody else bothered turning up to the
> well-advertised events where this got discussed...

If it's documented on paper, it didn't happen. :-)

Discussions in smoke-filled rooms, even if they are well-advertised,
don't really impress me.... (This isn't your fault, but Microsoft's.)

- Ted


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120709162649.GA7405@thunk.org">http://lists.debian.org/20120709162649.GA7405@thunk.org
 
Old 07-09-2012, 04:31 PM
Matthew Garrett
 
Default EFI in Debian

On Mon, Jul 09, 2012 at 12:26:49PM -0400, Ted Ts'o wrote:
> On Mon, Jul 09, 2012 at 04:48:38PM +0100, Matthew Garrett wrote:
> > Hey, it's hardly my fault that nobody else bothered turning up to the
> > well-advertised events where this got discussed...
>
> If it's documented on paper, it didn't happen. :-)
>
> Discussions in smoke-filled rooms, even if they are well-advertised,
> don't really impress me.... (This isn't your fault, but Microsoft's.)

I look forward to the LF's discussion of this being made public, then.

--
Matthew Garrett | mjg59@srcf.ucam.org


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120709163145.GA2679@srcf.ucam.org">http://lists.debian.org/20120709163145.GA2679@srcf.ucam.org
 
Old 07-10-2012, 10:08 AM
"Thomas Preud'homme"
 
Default EFI in Debian

Le lundi 2 juillet 2012 18:42:13, Steve McIntyre a écrit :
> Hey folks,
>
> As you might have seen from recent discussions about the Fedora and
> Ubuntu strategies for how to deal with EFI and Secure Boot, there are
> potentially major issues in the area. In Debian we don't (yet) have a
> plan, so it's high time that we had some discussion. I've set up a BoF
> at DebConf for this:
>
> https://penta.debconf.org/penta/schedule/dc12/event/925.en.html
>
> That's Monday 9th July, 15:00 local time (21:00 UTC).

Sorry for my naive questions but I want to be sure I understand the goal
behind secure boot correctly. I'm not talking about Microsoft here but as
stated by Bdale yesterday there is many people who see a value in secure boot
to protect their system. Please correct any mistake I do in my reasonning and
if I'm plain wrong just ignore my email or send me a notice on IRC or private
email. Suggestions for the implementation are after the questions.

What I'd really like to understand is why is protecting the boot so important
for these people? Secure boot is designed to prevent booting code anywhere in
the boot sequence which is infected by a malware. But if such an infection
happens, it means a flaws in the system was used during the last run. It should
normally not be possible to modify any of the code in the boot sequence
without appropriate privilege.

When the flaws was exploited, then the attacker had sufficient access to change
e.g. EFI and could thus have done whatever nasty things he wanted on the
system. And as long as the system is not rebooted, nothing can prevent it to
do so.

From this, I came to the conclusion that secure boot only provides additional
security when the administrator discover the flaws, either via a
CVE/DSA/whatever announce, or because he realized the system is having a
strange behavior (ex: something suspicious in the logs). Then, he will try to
patch the flaw by upgrading its kernel and want to be sure at reboot that the
malware didn't manage to infect the patched kernel in the mean time. In other
words, the administrator want to be sure at reboot that the problem is solved
(at least for this flaw, there could be other flaws of course but they need to
be found).

If I understood all this correctly and that my conclusions are correct then I
believe there could be an interest the secure boot functionality. Don't get me
wrong, I'm really concerned about all the side effect of this technology with
regards to locked down systems. There is an important need to both be able to
disable secure boot and to be able to change and add main/CA keys. But there
is nothing we can do technically about this.

==== Implementation ====

So the first question is wether we play secure boot or not. I believe that by
playing it we don't remove anything to the users. No matter we play it or not,
they will not be free to install whatever software they want as long as secure
boot is activated (and this become a "forever" on ARM systems with windows
certified logo). But by providing a signed image of Debian we provide at least
a bit more security for people with secure boot enabled.

Second question is with what key to sign Debian image and our bootloader.
Should we use Microsoft key or use our own key and ask the users who wants to
benefit from secure boot to install the Debian key. I personnally don't like
the idea of using the key of Microsoft as we give them a switch to prevent
Debian systems from being booted. On the other hand, I don't know if it will
be easy to install new CA keys.

At last, there is the question of what to sign. If we want secure boot to be
really useful then we should sign all the way from the bootloader to the
kernel modules.

Thoughts about this?

Best regards.
 
Old 07-10-2012, 11:08 AM
Russell Coker
 
Default EFI in Debian

On Tue, 10 Jul 2012, "Thomas Preud'homme" <robotux@celest.fr> wrote:
> When the flaws was exploited, then the attacker had sufficient access to
> change e.g. EFI and could thus have done whatever nasty things he wanted
> on the system. And as long as the system is not rebooted, nothing can
> prevent it to do so.

http://etbe.coker.com.au/2011/12/28/secure-boot-protecting-against-root/

I've written a blog post about some of the issues related to secure boot at
the above URL. Some of the problems include the fact that workstations have a
lot of uptime nowadays (so a machine that has a trojan in RAM is likely to
stay that way for a while) and that an attack which is performed once can be
performed on every boot.

http://www.coker.com.au/selinux/play.html

Also in that post I address the apparently common misconception that "secure
boot" makes it impossible for a remote "root" user to damage the system. As
an aside I have a Wheezy based SE Linux Play Machine online right now, it
demonstrates "root" as an account that can't damage the system - but that
"root" account also can't be used for system administration...

> From this, I came to the conclusion that secure boot only provides
> additional security when the administrator discover the flaws, either via
> a
> CVE/DSA/whatever announce, or because he realized the system is having a
> strange behavior (ex: something suspicious in the logs). Then, he will try
> to patch the flaw by upgrading its kernel and want to be sure at reboot
> that the malware didn't manage to infect the patched kernel in the mean
> time. In other words, the administrator want to be sure at reboot that the
> problem is solved (at least for this flaw, there could be other flaws of
> course but they need to be found).

The problem with that is the wide variety of ways that the system is
configured. We would need some way to verify, inspect, or revert every change
to a security sensitive config file to restore a compromised system. Signing
every config file isn't viable as you can't sign it locally (and taking every
changed config file from a disconnected system is a PITA). Inspection isn't
good as even competent sysadmins will have a hard time recognising every
potential mistake in a config file.

Reverting changes (IE wiping /etc on upgrade) is unpleasant, but maybe we
could have a patch management system to treat all changes to /etc as patches.
This might be viable.

> At last, there is the question of what to sign. If we want secure boot to
> be really useful then we should sign all the way from the bootloader to
> the kernel modules.

No. The easiest way of doing that properly would be to have a filesystem that
includes signing and not allow high integrity processes (either processes with
a high integrity label according to Biba or a system domain in SE Linux) to
read files that weren't signed.

The harder way of doing that would be to have the system dynamic loader, every
interpreter (the shell, Perl, etc), and every important process that reads a
config file (IE most daemons) check signatures on all files.

There's really not much benefit in having a signed kernel and modules if you
can have a trojan loaded from /root/.bashrc !

--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201207102108.57283.russell@coker.com.au">http://lists.debian.org/201207102108.57283.russell@coker.com.au
 
Old 07-10-2012, 12:20 PM
"Thomas Preud'homme"
 
Default EFI in Debian

Le mardi 10 juillet 2012 13:08:57, Russell Coker a écrit :
> On Tue, 10 Jul 2012, "Thomas Preud'homme" <robotux@celest.fr> wrote:
> > When the flaws was exploited, then the attacker had sufficient access to
> > change e.g. EFI and could thus have done whatever nasty things he wanted
> > on the system. And as long as the system is not rebooted, nothing can
> > prevent it to do so.
>
> http://etbe.coker.com.au/2011/12/28/secure-boot-protecting-against-root/
>
> I've written a blog post about some of the issues related to secure boot at
> the above URL. Some of the problems include the fact that workstations
> have a lot of uptime nowadays (so a machine that has a trojan in RAM is
> likely to stay that way for a while) and that an attack which is performed
> once can be performed on every boot.
>
> http://www.coker.com.au/selinux/play.html

Ah yeah, I read that blog post. I like your blog by the way. Anyway, I had the
exact same impression. That's why I came to the conclusion it's only useful
after fixing a flaw in order to be sure the problem is fixed on next reboot. But
for machine which never reboot it's indeed useless.

>
> Also in that post I address the apparently common misconception that
> "secure boot" makes it impossible for a remote "root" user to damage the
> system. As an aside I have a Wheezy based SE Linux Play Machine online
> right now, it demonstrates "root" as an account that can't damage the
> system - but that "root" account also can't be used for system
> administration...

Of course, if you are root you can do whatever you want. That's the definition
of root.

>
> The problem with that is the wide variety of ways that the system is
> configured. We would need some way to verify, inspect, or revert every
> change to a security sensitive config file to restore a compromised
> system. Signing every config file isn't viable as you can't sign it
> locally (and taking every changed config file from a disconnected system
> is a PITA). Inspection isn't good as even competent sysadmins will have a
> hard time recognising every potential mistake in a config file.
>
> Reverting changes (IE wiping /etc on upgrade) is unpleasant, but maybe we
> could have a patch management system to treat all changes to /etc as
> patches. This might be viable.

Mmmmh, indeed I didn't think about all these important files. But then, if not
everything is signed it reduce the number of ways an exploit can survive
accross fix+reboot to files. Yes, it's still a large surface. Actually if you go
down that road you'd need to sign everything you use. No matter that the
kernel, bootloader and firmware are intact if your webserver is infected and
giving access to important files of your system for example. The problem is
that it becomes very hard to implement for a rather small benefit (IMHO).

>
> > At last, there is the question of what to sign. If we want secure boot to
> > be really useful then we should sign all the way from the bootloader to
> > the kernel modules.
>
> No. The easiest way of doing that properly would be to have a filesystem
> that includes signing and not allow high integrity processes (either
> processes with a high integrity label according to Biba or a system domain
> in SE Linux) to read files that weren't signed.
>
> The harder way of doing that would be to have the system dynamic loader,
> every interpreter (the shell, Perl, etc), and every important process that
> reads a config file (IE most daemons) check signatures on all files.
>
> There's really not much benefit in having a signed kernel and modules if
> you can have a trojan loaded from /root/.bashrc !

Yes, true. That's what in the end everything you care about should be signed.
But I don't think it's doable. So either we don't do secure boot at all
(benefit is it requires no additional work), or we do secure boot on part of
the system which guarantee that when this part of the system is upgraded to fix
a flaws, it will only be booted if it was not compromised before the fix. Sort
of it provides a way of knowing cryptographically if part of the system was
infected or not.

Best regards.
 
Old 07-17-2012, 04:20 PM
Mark Brown
 
Default EFI in Debian

On Sun, Jul 08, 2012 at 07:30:48PM -0400, Ted Ts'o wrote:

> So in answer to your question, there are plenty of Android devices
> which are trivially unlockable. (And once a Nexus phone is unlocked,
> it's you can get a root shell trivially; no jail-breaking necessary.
> Of course this is true for an attacker/thief who has managed to steal
> your phone, but if you want to unlock the phone, it's easily doable on
> many Android devices.)

Note that the unlock process wipes the data on the phone which does
provide some security here.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120717162018.GA8198@sirena.org.uk">http://lists.debian.org/20120717162018.GA8198@sirena.org.uk
 

Thread Tools




All times are GMT. The time now is 10:29 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org