Re: [PATCH v2 2/5] load_env support for whitelisting which variables are read from an env file, even if check_signatures=enforce

[Jonathan McCune]

On Sat, Sep 7, 2013 at 2:33 AM, Andrey Borzenkov <address@hidden> wrote:

В Fri, 6 Sep 2013 14:10:01 -0700
Jonathan McCune <address@hidden> пишет:

> Thanks for the feedback, inline:
>
> On Fri, Sep 6, 2013 at 12:48 PM, Andrey Borzenkov <address@hidden>wrote:
>
> > В Fri,  6 Sep 2013 09:18:50 -0700
> > Jon McCune <address@hidden> пишет:
> >
> > > This works by adding an open_envblk_file_untrusted() method that bypasses
> > > signature checking, but only if the invocation of load_env includes a
> > > whitelist of one or more environment variables that are to be read from
> > the
> > > file.
> >
> > What is the use case? load_env is called exactly once at the beginning
> > of configfile processing. At this point file still has valid signature
> > assuming grub-editenv (or some other tool) computed one. When do you
> > need to load environment more than once?
> >
>
> I agree that the default grub.cfg behaves such as you describe, but
> consider a configuration where the signing key is not available during
> every boot cycle.  E.g., it is password-protected by a password that I
> know, but that other users of the machine do not know.  Let's assume it's a
> server in a physically secure location so that, e.g., booting from a CD or
> USB drive is not a viable attack.  Let us also assume that the attacker may
> gain root privileges in the OS at some point after the bootloader
> configuration is completed and the signing key is secured.
>
> Now suppose I want to enable "savedefault" functionality, so that users can
> control which of several installed OSes, kernels, kernel configurations,
> ... to boot.  I don't care which configuration boots, or which one is the
> default, but I want to make sure the machine only boots known
> configurations.
>

So just use another environment block for untrusted variables, that's
all. I do not see why any change in sources is required.

What about variables that are set in a load.cfg (grub-mkimage -c FILE)?  Those can no longer be trusted after doing an untrusted load-env, even if it's the very first thing in grub.cfg.

 

Now if you could come up with solution that maintains compatibility
with existing grub.cfg, that would be valid reason. But right now
grub.cfg must be changed anyway at which point just save untrusted
variables separately from trusted.

I don't think my changes break compatibility with anybody's existing grub.cfg.  Can you be more specific?

Thanks,

-Jon