GRUB trusted boot framework

GRUB trusted boot framework

[Jan Alsenz]

[-- Attachment #1: Type: text/plain, Size: 1221 bytes --]

Hello!

Alright, lets try to end the pointless (in the sense, that I guess noone here,
including myself, will change their opinion anytime soon) TPM discussion and get
something done.

First I'd say we can agree, that we don't agree on whether/how to use a TPM.
I don't know about you, but I can perfectly live with that!

Next I think we can agree, that some sort of trusted boot chain can be useful.

Also there should be more than one implementation for this (or at least the
possibility to have them).

If we could agree on this, then I think we could find a way to extend the GRUB
module system to fully allow this.

From my point of view the minimal needed features for these systems are:
- easy exchange of the MBR binary to be installed
- easy exchange of the core.img loader binary
- hooks for any disk read (not sure if write is necessary)

(I didn't check if any of these is already implemented)

Last part to agree on would then be, that these infrastructure features should
be in the mainline code.
That way it would be easy to develop various trusted boot solutions (and
probably some other systems too), but keep all the controversial code out of
mainline.

Greets,

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: GRUB trusted boot framework

[phcoder]

> - hooks for any disk read (not sure if write is necessary)
This way how trusted grub does it is an ad-hoc solution which results in 
a MESS. They just try to hash and rehash everything without design. So 
if grub is instructed to load all modules in a directory and filesystem 
is reindexed then grub will load the same modules in a different order 
which results in a different hash. IMO we can't allow such thing to come 
to grub2 it's just against its basic design principles. Much better 
would be a layer similar to gzio:

grub_gnupg_open (const char *filename, int flags, struct grub_gnupg_info 
*info);
Which internally checks the certificate. This layer can also 
encrypt/decrypt from gnupg containers
Then all kernel and config loads would use this function instead of 
grub_gzio_open and grub_gnupg_open would check if its contents is 
gzipped. Flags can include:
GRUB_GNUPG_FLAGS_ALLOW_UNSIGNED
if signature can be checked later on (e.g. signed ELF)
Then the behavior is controlled by an environment variable
allow_unsigned=yes|no
If grub_gnupg_open is invoked without GRUB_GNUPG_FLAGS_ALLOW_UNSIGNED 
and allow_unsigned=no and signature is broken or not present it should 
prompt for password (if it isn't supplied yet) and write something like
File %s is unsigned. Are you sure you want to load it? Type "YES" if you do.
Regards
Vladimir 'phcoder' Serbinenko

Re: GRUB trusted boot framework

[Jan Alsenz]

[-- Attachment #1: Type: text/plain, Size: 1817 bytes --]

phcoder wrote:
>> - hooks for any disk read (not sure if write is necessary)
> This way how trusted grub does it is an ad-hoc solution which results in
> a MESS. They just try to hash and rehash everything without design. So
> if grub is instructed to load all modules in a directory and filesystem
> is reindexed then grub will load the same modules in a different order
> which results in a different hash. IMO we can't allow such thing to come
> to grub2 it's just against its basic design principles. Much better
> would be a layer similar to gzio:
> 
> grub_gnupg_open (const char *filename, int flags, struct grub_gnupg_info
> *info);
> Which internally checks the certificate. This layer can also
> encrypt/decrypt from gnupg containers
> Then all kernel and config loads would use this function instead of
> grub_gzio_open and grub_gnupg_open would check if its contents is
> gzipped. Flags can include:
> GRUB_GNUPG_FLAGS_ALLOW_UNSIGNED
> if signature can be checked later on (e.g. signed ELF)
> Then the behavior is controlled by an environment variable
> allow_unsigned=yes|no
> If grub_gnupg_open is invoked without GRUB_GNUPG_FLAGS_ALLOW_UNSIGNED
> and allow_unsigned=no and signature is broken or not present it should
> prompt for password (if it isn't supplied yet) and write something like
> File %s is unsigned. Are you sure you want to load it? Type "YES" if you
> do.

Ok, but your already talking of a specific solution here. My conclusion would
be: The hooks need to be able to determine the filename, that is currently read.

The reason why I want generic read hooks, is that I want it to inter operate
with everything else. So I should not need to figure out what files e.g. the
linux loader is going to read, or change it's code to do so.

Greets,

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: GRUB trusted boot framework

[phcoder]

> Ok, but your already talking of a specific solution here. My conclusion would
> be: The hooks need to be able to determine the filename, that is currently read.
> 
And then also where it comes from but some files may have different 
filenames. IMO the solution work independently of the order of files and 
where they come from. TPM checking is too limited for grub2 architecture.

> The reason why I want generic read hooks, is that I want it to inter operate
> with everything else. So I should not need to figure out what files e.g. the
> linux loader is going to read, or change it's code to do so.
You can do anything secure without collaboration from upper layers. 
Consider a huge loopback image from which you load only kernel. In you 
solution it will unnecessary check the whole image
> Greets,
> 
> Jan

Regards
Vladimir 'phcoder' Serbinenko

Re: GRUB trusted boot framework

[Jan Alsenz]

[-- Attachment #1: Type: text/plain, Size: 1114 bytes --]

phcoder wrote:
>> Ok, but your already talking of a specific solution here. My
>> conclusion would
>> be: The hooks need to be able to determine the filename, that is
>> currently read.
>>
> And then also where it comes from but some files may have different
> filenames. IMO the solution work independently of the order of files and
> where they come from. TPM checking is too limited for grub2 architecture.

I agree and I'm not talking TPM here.
Do you know if it is possible to determine where the files come from?

>> The reason why I want generic read hooks, is that I want it to inter
>> operate
>> with everything else. So I should not need to figure out what files
>> e.g. the
>> linux loader is going to read, or change it's code to do so.
> You can do anything secure without collaboration from upper layers.
> Consider a huge loopback image from which you load only kernel. In you
> solution it will unnecessary check the whole image

Hmm, to be precise we're interested in file reads. So if the loopback image is
implemented as disk driver, it should work.

Greets,

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: GRUB trusted boot framework

[phcoder]

> Do you know if it is possible to determine where the files come from?
Well it's possible looking at filename and root drive but it's not 
reliable (e.g. ata0 can be hd0 but also hd1, when we'll have network 
support it will be even less obvious. Actually it's something grub2's 
architecture is trying to hide) and in this context not relevant. If 
signature is correct does it matter where the file comes from? At most 
what is necessary for these functions is being able to read the files 
like <original filename>.sig but it's trivial when filename is given
> Hmm, to be precise we're interested in file reads. So if the loopback image is
> implemented as disk driver, it should work.
AFAIR it's a disk driver which reads from file. IMO disk read hooks will 
result in messy and bug-prone design which is incompatible with grub2's 
versatility. And only the files that end up in memory or control grub 
need to be checked.
> 
> Greets,
> 
> Jan
Regards
Vladimir 'phcoder' Serbinenko

Re: GRUB trusted boot framework

[Vesa Jääskeläinen]

Hi All,

Ok. Please keep the fighting of TPM out of this thread ;). Lets keep it
to the topic first... (I am already waiting for summary of that other
discussion at some point ;))

Jan Alsenz wrote:
> Next I think we can agree, that some sort of trusted boot chain can be useful.
> 
> Also there should be more than one implementation for this (or at least the
> possibility to have them).

I like the idea of modularity in here. However. It should work with
different schemes but same generic interfaces if that is what is planned.

> If we could agree on this, then I think we could find a way to extend the GRUB
> module system to fully allow this.
> 
> From my point of view the minimal needed features for these systems are:
> - easy exchange of the MBR binary to be installed
> - easy exchange of the core.img loader binary
> - hooks for any disk read (not sure if write is necessary)

Note: I will skip MBR+core.img validation for a reason here now.

I do like the idea what some protected systems use, they sign the binary
(in our case .mod file and kernels of loaded OSes). Now in that scenario
it is responsibility of the kernel module loader to first verify the
signature for correctness. This way the signature checking would be
somewhat transparent to the rest of the system.

I do not see a need to add any hooks to disk read. It should be
responsibility of the code needing signature checking to handle that.

And please try to share some code with password/authentication features :)

> Last part to agree on would then be, that these infrastructure features should
> be in the mainline code.
> That way it would be easy to develop various trusted boot solutions (and
> probably some other systems too), but keep all the controversial code out of
> mainline.

Yes.

Re: GRUB trusted boot framework

[Jan Alsenz]

[-- Attachment #1: Type: text/plain, Size: 1893 bytes --]

Vesa Jääskeläinen write:
> Hi All,
> 
> Ok. Please keep the fighting of TPM out of this thread ;). Lets keep it
> to the topic first... (I am already waiting for summary of that other
> discussion at some point ;))
> 
> Jan Alsenz wrote:
>> Next I think we can agree, that some sort of trusted boot chain can be useful.
>>
>> Also there should be more than one implementation for this (or at least the
>> possibility to have them).
> 
> I like the idea of modularity in here. However. It should work with
> different schemes but same generic interfaces if that is what is planned.

That was what I had in mind.

>> If we could agree on this, then I think we could find a way to extend the GRUB
>> module system to fully allow this.
>>
>> From my point of view the minimal needed features for these systems are:
>> - easy exchange of the MBR binary to be installed
>> - easy exchange of the core.img loader binary
>> - hooks for any disk read (not sure if write is necessary)
> 
> Note: I will skip MBR+core.img validation for a reason here now.
> 
> I do like the idea what some protected systems use, they sign the binary
> (in our case .mod file and kernels of loaded OSes). Now in that scenario
> it is responsibility of the kernel module loader to first verify the
> signature for correctness. This way the signature checking would be
> somewhat transparent to the rest of the system.
> 
> I do not see a need to add any hooks to disk read. It should be
> responsibility of the code needing signature checking to handle that.

Well, since to trusted operation should be transparent (and in my opinion should
not need code changes in something like the loaders - so if someone writes a new
loader, it should work by default), that's where the hooks come in.
Maybe the "disk read" was misleading, what I meant where "file reads".

Greets,

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: GRUB trusted boot framework

[Vesa Jääskeläinen]

Jan Alsenz wrote:
> Vesa Jääskeläinen write:
>> I do like the idea what some protected systems use, they sign the binary
>> (in our case .mod file and kernels of loaded OSes). Now in that scenario
>> it is responsibility of the kernel module loader to first verify the
>> signature for correctness. This way the signature checking would be
>> somewhat transparent to the rest of the system.
>>
>> I do not see a need to add any hooks to disk read. It should be
>> responsibility of the code needing signature checking to handle that.
> 
> Well, since to trusted operation should be transparent (and in my opinion should
> not need code changes in something like the loaders - so if someone writes a new
> loader, it should work by default), that's where the hooks come in.
> Maybe the "disk read" was misleading, what I meant where "file reads".

Hi,

Well.. you probably don't want to verify authenticity of the fonts or
bitmaps in graphical menu?

Anyway. I think the right place for verification hook in this case is
the module or OS kernel loader.

If you think otherwise. Then you have to provide a complete technical
design how it should work as I see no other good choice for it.

(actually there is one other place that could be used, but I let you
come up with the idea after you have given a bit more though on the
implementation side :))

Thanks,
Vesa Jääskeläinen

Re: GRUB trusted boot framework

[Jan Alsenz]

[-- Attachment #1: Type: text/plain, Size: 2320 bytes --]

Vesa Jääskeläinen wrote:
> Jan Alsenz wrote:
>> Vesa Jääskeläinen write:
>>> I do like the idea what some protected systems use, they sign the binary
>>> (in our case .mod file and kernels of loaded OSes). Now in that scenario
>>> it is responsibility of the kernel module loader to first verify the
>>> signature for correctness. This way the signature checking would be
>>> somewhat transparent to the rest of the system.
>>>
>>> I do not see a need to add any hooks to disk read. It should be
>>> responsibility of the code needing signature checking to handle that.
>> Well, since to trusted operation should be transparent (and in my opinion should
>> not need code changes in something like the loaders - so if someone writes a new
>> loader, it should work by default), that's where the hooks come in.
>> Maybe the "disk read" was misleading, what I meant where "file reads".
> 
> Hi,
> 
> Well.. you probably don't want to verify authenticity of the fonts or
> bitmaps in graphical menu?

Oh, I want!
If I remember correctly, exactly this broke the protection on some game console!


> Anyway. I think the right place for verification hook in this case is
> the module or OS kernel loader.
> 
> If you think otherwise. Then you have to provide a complete technical
> design how it should work as I see no other good choice for it.
> 
> (actually there is one other place that could be used, but I let you
> come up with the idea after you have given a bit more though on the
> implementation side :))

But how do I get it into every possible loader?

My current suggestion would be to put a hook possibility into kern/file.c and
extend the fs interface with a function to compare to files, to get rid of the
double hashing problem mentioned by phcoder.

I also checked the loopback code and it uses the standard grub_file_read, so for
these cases a read version without a hook would be needed.

By the way we're assuming here, that every file-system driver is free of
exploitable bugs!
To avoid this a real disk read hook would be needed, but of course that is
largely impractical. (There might be options with "sparce" hashing - meaning
only hashing the parts that are actually read, and including the map of read
areas into the final hash)

Greets,

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: GRUB trusted boot framework

[phcoder]

> Oh, I want!
> If I remember correctly, exactly this broke the protection on some game console!
Do you refer to Xbox crack based on King kong game? For once their goal 
is the evil one. For second the problem is a buffer overflow in 
rendering engine, not the not checking part. If you want to make a 
secure system it must be free of such bugs. Or you may as well hash the 
whole hd and be hacked through network code. Here is where advantages of 
open developement come in play
> 
> But how do I get it into every possible loader?
s/grub_gzio_open(filename, 1)/grub_gnupg_open(filename, GZIO_TRANSPARENT)
s/grub_file_open(filename)/grub_gnupg_open(filename, 0)

> I also checked the loopback code and it uses the standard grub_file_read, so for
> these cases a read version without a hook would be needed.

Then how is your proposition with two file read functions different from 
mine with two file read functions? What can be proposed is to merge 
somehow all opening functions into one with following protype
grub_file_open (const char *filename, int flags, struct grub_file_info 
*info)
Then on opening the function will do the default behavior with possible 
override possible through flags. It has an advantage of future 
expandability for possible new transparent transformations

> 
> By the way we're assuming here, that every file-system driver is free of
> exploitable bugs!
> To avoid this a real disk read hook would be needed, but of course that is
> largely impractical. (There might be options with "sparce" hashing - meaning
> only hashing the parts that are actually read, and including the map of read
> areas into the final hash)
And then after a minor write or fs self-maintenance it suddenly stops 
working. You may as well not boot at all. Perfectly secure booter in 2 
bytes of x86-assembly:
eb fe :   self: jmp self
> 
> Greets,
> 
> Jan
Regards
Vladimir 'phcoder' Serbinenko

Re: GRUB trusted boot framework

[Jan Alsenz]

[-- Attachment #1: Type: text/plain, Size: 3709 bytes --]

phcoder wrote:
>> Oh, I want!
>> If I remember correctly, exactly this broke the protection on some
>> game console!
> Do you refer to Xbox crack based on King kong game? For once their goal
> is the evil one. For second the problem is a buffer overflow in
> rendering engine, not the not checking part. If you want to make a
> secure system it must be free of such bugs. Or you may as well hash the
> whole hd and be hacked through network code. Here is where advantages of
> open developement come in play

It is totally irrelevant, if the purpose is good or evil, if it can break the
system.
And since it is awfully difficult to produce bug free code, the goal must be to
reduce the code that has to be bug free to the absolute (and openly known)
minimum: In this case I'd say the reasonable choice is the fs driver code.

>> But how do I get it into every possible loader?
> s/grub_gzio_open(filename, 1)/grub_gnupg_open(filename, GZIO_TRANSPARENT)
> s/grub_file_open(filename)/grub_gnupg_open(filename, 0)

With "every possible loader", I wanted to include unknown future loaders.

>> I also checked the loopback code and it uses the standard
>> grub_file_read, so for
>> these cases a read version without a hook would be needed.
> 
> Then how is your proposition with two file read functions different from
> mine with two file read functions? What can be proposed is to merge
> somehow all opening functions into one with following protype
> grub_file_open (const char *filename, int flags, struct grub_file_info
> *info)
> Then on opening the function will do the default behavior with possible
> override possible through flags. It has an advantage of future
> expandability for possible new transparent transformations

That would be a good idea.
The difference between your and my solution was, that mine it had secure as default.

I'm not yet sure about the flag solution though.
If we want to keep the solution general - which I would prefer - the flag is
only known to the transformation and the code who wants to avoid it.
To clarify:
I'm thinking about a general hook/transformation solution in kern/file.c .
Everyone can register a hook there, and now the goal of the flags is, to
selectively enable or disable hooks.

Problem is, that these hooks are not necessarily all known to all components.

My first thought for a solution was something like:
- Every hook gets an unique ID (distribution controlled e.g. via wiki)
- The flags are lists of these IDs
- A hook can by default be active or inactive
- (It may be useful to have some order within the hooks)

Apart from solving the problem, this solution would have a few other advantages:
- Existing filters, like gzio, could be ported to this generic framework
- IDs could be grouped into classes, e.g. to say "I don't want any security
hooks on this operation" for the loopback device

I'm not yet happy with the flag-list implementation, so if someone has a better
idea, I would be happy to hear it.

>> By the way we're assuming here, that every file-system driver is free of
>> exploitable bugs!
>> To avoid this a real disk read hook would be needed, but of course
>> that is
>> largely impractical. (There might be options with "sparce" hashing -
>> meaning
>> only hashing the parts that are actually read, and including the map
>> of read
>> areas into the final hash)
> And then after a minor write or fs self-maintenance it suddenly stops
> working. You may as well not boot at all. Perfectly secure booter in 2
> bytes of x86-assembly:
> eb fe :   self: jmp self

That's also part of what I meant with "largely impractical" ;)

Greets,

Jan



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: GRUB trusted boot framework

[phcoder]

Jan Alsenz wrote:
> phcoder wrote:
>>> Oh, I want!
>>> If I remember correctly, exactly this broke the protection on some
>>> game console!
>> Do you refer to Xbox crack based on King kong game? For once their goal
>> is the evil one. For second the problem is a buffer overflow in
>> rendering engine, not the not checking part. If you want to make a
>> secure system it must be free of such bugs. Or you may as well hash the
>> whole hd and be hacked through network code. Here is where advantages of
>> open developement come in play
> 
> It is totally irrelevant, if the purpose is good or evil, if it can break the
> system.
> And since it is awfully difficult to produce bug free code, the goal must be to
> reduce the code that has to be bug free to the absolute (and openly known)
> minimum: In this case I'd say the reasonable choice is the fs driver code.
> 
You can't really do this. You can safeguard from e.g. fonts drivers 
bugs. But what do you do with vulnerabilities with usb code. Some may 
connect an evil mouse to the computer
>>> But how do I get it into every possible loader?
>> s/grub_gzio_open(filename, 1)/grub_gnupg_open(filename, GZIO_TRANSPARENT)
>> s/grub_file_open(filename)/grub_gnupg_open(filename, 0)
> 
> With "every possible loader", I wanted to include unknown future loaders.
> 
New loaders will use the existing ones as a template. I did
> That would be a good idea.
> The difference between your and my solution was, that mine it had secure as default.
Mine too. It involves just using right code. If a developer wants to 
wrote unsecure code he can always, otherwise I don't see why he wouldn't 
use e.g. linux loader as a template
> - (It may be useful to have some order within the hooks)
It's even necessary. Otherwise you can't know if you have first to 
compress or to sign

Re: GRUB trusted boot framework

[Jan Alsenz]

[-- Attachment #1: Type: text/plain, Size: 3132 bytes --]

phcoder wrote:
> Jan Alsenz wrote:
>> phcoder wrote:
>>>> Oh, I want!
>>>> If I remember correctly, exactly this broke the protection on some
>>>> game console!
>>> Do you refer to Xbox crack based on King kong game? For once their goal
>>> is the evil one. For second the problem is a buffer overflow in
>>> rendering engine, not the not checking part. If you want to make a
>>> secure system it must be free of such bugs. Or you may as well hash the
>>> whole hd and be hacked through network code. Here is where advantages of
>>> open developement come in play
>>
>> It is totally irrelevant, if the purpose is good or evil, if it can
>> break the
>> system.
>> And since it is awfully difficult to produce bug free code, the goal
>> must be to
>> reduce the code that has to be bug free to the absolute (and openly
>> known)
>> minimum: In this case I'd say the reasonable choice is the fs driver
>> code.
>>
> You can't really do this. You can safeguard from e.g. fonts drivers
> bugs. But what do you do with vulnerabilities with usb code. Some may
> connect an evil mouse to the computer

Ok, your right, the definition should be: The fs drivers, and everything else,
that takes non disk input (this includes keyboard, command-line parser, mouse,
network, pci probe, etc.).
But I still think, that this is better, that everything above plus any
component, that reads a file!
If there is a way to prevent bugs in a part of our code, to hit our security
system, we should use it, because as we know - bugs DO occur.

There is alway the chance to be hit by new ideas and attack vectors, you can't
prevent that, but if we can, we should protect against the one we know.

>>>> But how do I get it into every possible loader?
>>> s/grub_gzio_open(filename, 1)/grub_gnupg_open(filename,
>>> GZIO_TRANSPARENT)
>>> s/grub_file_open(filename)/grub_gnupg_open(filename, 0)
>>
>> With "every possible loader", I wanted to include unknown future loaders.
>>
> New loaders will use the existing ones as a template. I did
>
>> That would be a good idea.
>> The difference between your and my solution was, that mine it had
>> secure as default.
> Mine too. It involves just using right code. If a developer wants to
> wrote unsecure code he can always, otherwise I don't see why he wouldn't

Yes, but it's a matter good design and convenience.
If it can, secure should always be default, without anyone having to think about it.
If security needs to be explicitly put in a and someone fails to do that, he can
blame you for not telling him to do that, but if you have secure defaults and
someone uses insecure, you can blame him for not following good
practices/reading the docs/etc.

This is especially useful if many people work on the code, like open source
projects, and not everyone might be aware of the security implication of his/her
actions.

> use e.g. linux loader as a template
>> - (It may be useful to have some order within the hooks)
> It's even necessary. Otherwise you can't know if you have first to
> compress or to sign

Agreed.

Greets,

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: GRUB trusted boot framework

[Robert Millan]

On Sun, Feb 22, 2009 at 02:27:25PM +0100, Jan Alsenz wrote:
> 
> If we could agree on this, then I think we could find a way to extend the GRUB
> module system to fully allow this.
> 
> From my point of view the minimal needed features for these systems are:
> - easy exchange of the MBR binary to be installed
> - easy exchange of the core.img loader binary
> - hooks for any disk read (not sure if write is necessary)
> 
> (I didn't check if any of these is already implemented)
> 
> Last part to agree on would then be, that these infrastructure features should
> be in the mainline code.

Hi,

The last stage is much simpler.  Just put /boot/ in a crypted filesystem (we
have a patch liing around which is pending to merge).

That only leaves MBR and core.img.  You can either check both from firmware
(does any BIOS allow this?) or do some funny gimmicks in MBR ;-)

> That way it would be easy to develop various trusted boot solutions (and
> probably some other systems too), but keep all the controversial code out of
> mainline.

I appreciate your interest in avoiding controversy.  If you want that, then
please don't refer to this as "trusted".  It is implied that all the code in
GRUB is already trusted by its user.  The difference here is that our system
would be hardened against physical attack, it doesn't change anything about
who is able to "trust" your computer and who isn't.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: GRUB hardened boot framework

[Jan Alsenz]

[-- Attachment #1: Type: text/plain, Size: 1852 bytes --]

Robert Millan wrote:
> On Sun, Feb 22, 2009 at 02:27:25PM +0100, Jan Alsenz wrote:
>> If we could agree on this, then I think we could find a way to extend the GRUB
>> module system to fully allow this.
>>
>> From my point of view the minimal needed features for these systems are:
>> - easy exchange of the MBR binary to be installed
>> - easy exchange of the core.img loader binary
>> - hooks for any disk read (not sure if write is necessary)
>>
>> (I didn't check if any of these is already implemented)
>>
>> Last part to agree on would then be, that these infrastructure features should
>> be in the mainline code.
> 
> Hi,
> 
> The last stage is much simpler.  Just put /boot/ in a crypted filesystem (we
> have a patch liing around which is pending to merge).

Yes, that would also be an idea.
Then the filesystem needs the authentication.

> That only leaves MBR and core.img.  You can either check both from firmware
> (does any BIOS allow this?) or do some funny gimmicks in MBR ;-)

There might be some boot virus protections, that could be abused. Or otherwise -
coreboot.

>> That way it would be easy to develop various trusted boot solutions (and
>> probably some other systems too), but keep all the controversial code out of
>> mainline.
> 
> I appreciate your interest in avoiding controversy.  If you want that, then
> please don't refer to this as "trusted".  It is implied that all the code in
> GRUB is already trusted by its user.  The difference here is that our system
> would be hardened against physical attack, it doesn't change anything about
> who is able to "trust" your computer and who isn't.

Alright, hardened then.
Personally I would still use "trusted", but it has been a bit overly (mis)used
in the recent past, which could lead to misunderstandings.

Greets,

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: GRUB hardened boot framework

[phcoder]

>> The last stage is much simpler.  Just put /boot/ in a crypted filesystem (we
>> have a patch liing around which is pending to merge).
> 
> Yes, that would also be an idea.
> Then the filesystem needs the authentication.
Encrypted filesystems don't prevent some attacks as inconsistent 
rollback. Suppose that some program is written like
if (!authenthicated)
    return error;
Let's say this is in sector X on disk. But then author added something 
before this function and this code is shifted to the sector X+1. However 
attacker has kept the previous sector X+1. Then he rewrites the sector 
X+1 with its previous version and bypasses the authentication. It's 
difficult attack but is still possible. Actually mac checksumming or 
signatures are better way to protect the system. Encrypting mainly 
protects from someone looking at data but isn't so good in 
detecting/protecting from modification. And normally you have no reason 
to hide you linux system partition. Additionally hashes are faster then 
encryptions.
> 
>> That only leaves MBR and core.img.  You can either check both from firmware
>> (does any BIOS allow this?) or do some funny gimmicks in MBR ;-)
> 
> There might be some boot virus protections, that could be abused. Or otherwise -
> coreboot.
Yes. My BIOS has boot virus protection but I haven't tested yet how it works

-- 

Regards
Vladimir 'phcoder' Serbinenko

Re: GRUB hardened boot framework

[Robert Millan]

On Fri, Feb 27, 2009 at 10:56:48PM +0100, Jan Alsenz wrote:
> > Hi,
> > 
> > The last stage is much simpler.  Just put /boot/ in a crypted filesystem (we
> > have a patch liing around which is pending to merge).
> 
> Yes, that would also be an idea.
> Then the filesystem needs the authentication.

I'm no crypto expert, but I was under the impression that when the data is
encrypted, measurement comes "for free": if someone tampered it, you'd be
unable to decrypt.  Is this correct?

> > I appreciate your interest in avoiding controversy.  If you want that, then
> > please don't refer to this as "trusted".  It is implied that all the code in
> > GRUB is already trusted by its user.  The difference here is that our system
> > would be hardened against physical attack, it doesn't change anything about
> > who is able to "trust" your computer and who isn't.
> 
> Alright, hardened then.

Thank you

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: GRUB hardened boot framework

[phcoder]

> 
> I'm no crypto expert, but I was under the impression that when the data is
> encrypted, measurement comes "for free": if someone tampered it, you'd be
> unable to decrypt.  Is this correct?
> 
It's not. Encryption is permutation
E_{key,sector} (P) -> C
Which permutes transforms plaintext P to ciphertext P. Without knowing 
the key an attacker still can reuse the values he has already seen (e.g. 
if he has an image of FS at previous date).
He can also replace the sector with anything. He can't predict to what 
it will be decrypted but not to what it originally was
Additionally most current modes subdivide sectors in 16-byte blocks. And 
how a block is encrypted depends on previous but not next blocks in 
sector. Then if attacker knows where the authentication is he can 
rewrite this place with anything. It will decrypt to garbage and with 
some quite high probability it won't crash and will let the attacker in.
With XTS block encryptions depends neither on previous nor on next block 
. So attacker doesn't even need the authenthication code to be at the 
end of the sector.
In various CBC modes if an attacker replaces sector A with sector B 
first block of sector B will decrypt to garbage but the rest will 
decrypt just fine. It can be used for e.g. launching printk to output 
the encryption keys.
In conclusion encryption doesn't check for modifications. Some 
encryption systems do it additionally through separate mechanism but 
encryption itself does no such thing

-- 

Regards
Vladimir 'phcoder' Serbinenko

Re: GRUB hardened boot framework

[Robert Millan]

On Fri, Feb 27, 2009 at 11:55:55PM +0100, phcoder wrote:
>>
>> I'm no crypto expert, but I was under the impression that when the data is
>> encrypted, measurement comes "for free": if someone tampered it, you'd be
>> unable to decrypt.  Is this correct?
>>
> It's not. Encryption is permutation
> E_{key,sector} (P) -> C
> Which permutes transforms plaintext P to ciphertext P. Without knowing  
> the key an attacker still can reuse the values he has already seen (e.g.  
> if he has an image of FS at previous date).
> He can also replace the sector with anything. He can't predict to what  
> it will be decrypted but not to what it originally was

I stand corrected;  But in that case, measurement can still be implemented
at the filesystem level?

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: GRUB hardened boot framework

[phcoder]

> 
> I stand corrected;  But in that case, measurement can still be implemented
> at the filesystem level?
> 
Yes it can be done. Most common way is to attach a mac to every sector 
(like a signature but uncheckable without the key). One could also 
implement mac on filesystems like btrfs. It doesn't solve all the 
problems however. It can't be used e.g. for checking authenticity of 
files received through network. IMO both approaches are important and we 
should provide the basic interface for both. Then people who are 
interested in implementing it can do it in a clean way which fits the 
general design.

-- 

Regards
Vladimir 'phcoder' Serbinenko

Re: GRUB hardened boot framework

[Jan Alsenz]

[-- Attachment #1: Type: text/plain, Size: 1870 bytes --]

phcoder wrote:
>>
>> I'm no crypto expert, but I was under the impression that when the
>> data is
>> encrypted, measurement comes "for free": if someone tampered it, you'd be
>> unable to decrypt.  Is this correct?
>>
> It's not. Encryption is permutation
> E_{key,sector} (P) -> C
> Which permutes transforms plaintext P to ciphertext P. Without knowing
> the key an attacker still can reuse the values he has already seen (e.g.
> if he has an image of FS at previous date).
> He can also replace the sector with anything. He can't predict to what
> it will be decrypted but not to what it originally was
> Additionally most current modes subdivide sectors in 16-byte blocks. And
> how a block is encrypted depends on previous but not next blocks in
> sector. Then if attacker knows where the authentication is he can
> rewrite this place with anything. It will decrypt to garbage and with
> some quite high probability it won't crash and will let the attacker in.
> With XTS block encryptions depends neither on previous nor on next block
> . So attacker doesn't even need the authenthication code to be at the
> end of the sector.
> In various CBC modes if an attacker replaces sector A with sector B
> first block of sector B will decrypt to garbage but the rest will
> decrypt just fine. It can be used for e.g. launching printk to output
> the encryption keys.
> In conclusion encryption doesn't check for modifications. Some
> encryption systems do it additionally through separate mechanism but
> encryption itself does no such thing

If the code that does the authentication is loaded from the encrypted partition,
without being checked, this is true, but we assume, that core.img is already
loaded (and checked), so the authentication code is not on the encrypted
partition, and can detect any tampering.

Greets,

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: GRUB hardened boot framework

[phcoder]

> If the code that does the authentication is loaded from the encrypted partition,
> without being checked, this is true, but we assume, that core.img is already
> loaded (and checked), so the authentication code is not on the encrypted
> partition, and can detect any tampering.
As far as I understood Robert Millan was suggesting that just encrypting 
  (but not verifying) your kernel is enough. I wanted to show wha it isn't

-- 

Regards
Vladimir 'phcoder' Serbinenko

Re: GRUB hardened boot framework

[Robert Millan]

On Sat, Feb 28, 2009 at 12:18:17AM +0100, phcoder wrote:
>> If the code that does the authentication is loaded from the encrypted partition,
>> without being checked, this is true, but we assume, that core.img is already
>> loaded (and checked), so the authentication code is not on the encrypted
>> partition, and can detect any tampering.
> As far as I understood Robert Millan was suggesting that just encrypting  
>  (but not verifying) your kernel is enough. I wanted to show wha it isn't

Fair enough.  My point is that we don't need overcomplicated mechanisms to
measure every module, config file or component separately.  After core.img
is verified/loaded, it's much simpler to handle the rest at this layer
below the filesystem, which doesn't require significant redesign of how
GRUB works.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: GRUB hardened boot framework

[Jan Alsenz]

[-- Attachment #1: Type: text/plain, Size: 1468 bytes --]

Robert Millan wrote:
> On Sat, Feb 28, 2009 at 12:18:17AM +0100, phcoder wrote:
>>> If the code that does the authentication is loaded from the encrypted partition,
>>> without being checked, this is true, but we assume, that core.img is already
>>> loaded (and checked), so the authentication code is not on the encrypted
>>> partition, and can detect any tampering.
>> As far as I understood Robert Millan was suggesting that just encrypting  
>>  (but not verifying) your kernel is enough. I wanted to show wha it isn't
> 
> Fair enough.  My point is that we don't need overcomplicated mechanisms to
> measure every module, config file or component separately.  After core.img
> is verified/loaded, it's much simpler to handle the rest at this layer
> below the filesystem, which doesn't require significant redesign of how
> GRUB works.

Well, the problem there will probably be, that no commonly used disk encryption
(e.g. dm-crypt) uses checksums (as far as I know), when reading from disk. So if
you want to be compatible, the check of the files needs to be done either by the
filesystem (which only very few can do), or by a separate layer.
Which brings us back to the initial idea.

In any case, for all the crypto stuff it would be a good idea, to have some
general GRUB crypto-library, that everyone could use. Probably like it is done
in the linux kernel.
This could then also be used for the password command.

Greets,

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]