On Sat, Sep 7, 2013 at 2:33 AM, Andrey Borzenkov <arvidj...@gmail.com>wrote:
> В Fri, 6 Sep 2013 14:10:01 -0700 > Jonathan McCune <jonmcc...@google.com> пишет: > > > Thanks for the feedback, inline: > > > > On Fri, Sep 6, 2013 at 12:48 PM, Andrey Borzenkov <arvidj...@gmail.com > >wrote: > > > > > В Fri, 6 Sep 2013 09:18:50 -0700 > > > Jon McCune <jonmcc...@google.com> пишет: > > > > > > > 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
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
