Re: GRUB trusted boot framework

[Jan Alsenz <janalsenz@student.ethz.ch>]

[-- 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 --]