Re: GRUB trusted boot framework

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

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