Re: [PATCH] implement menu_lock
I agree that with this design grub2 lock are somewhat cumbersome to implement some schemes. I would prefer a user+C-list design. In this case a following file be used by group username1:capability1,capability2,... username2:capability1,capability3,... ... E.g. root:all wheel:bootnonet ... This file can also be reversed and list users per capability instead of capabilities per user Then an authentication methods would be provided in form of modules each one using its one configuration to match users to authentication method (e.g. user-hash or user-fingerprint) To check the user level a special function would be provided int grub_user_is_allowed (const char *id) If user is already authenticated and is allowed to do whatever is specified by id it returns true, otherwise it proposes the user the list of available authentication methods and then calls the corresponding method. A drawback is that user has also to choose the method. Perhaps we can define methods as being non-blocking? E.g. use checkkey and so on. The code would be something like: static char * auth_user (void) { int do_sleep = 100; for (curauth=authmethods; curauth; curauth=curauth-next) { do_sleep = min (do_sleep, curauth-sleep_max); curauth-init (); } while (GRUB_TERM_ASCII_CHAR (grub_getkey ()) != GRUB_TERM_ESC) { for (curauth=authmethods; curauth; curauth=curauth-next) if (username = curauth-check ()) return username; if (do_sleep) grub_millisleep (do_sleep) } return 0; } In this case password module may be waiting for console input and fingerprint module would scan pci for input from fingerprint scanner When no clist file is loaded everyone is allowed to do everything then your menu would look like clist.txt: root:cmdline,barboot user2:bazboot passwords: root:grubrocks user2:grubisawesome grub.cfg: clist /clist.txt passwords /passwords.txt fingerprints /fingerprints.dat menuentry Anyone can boot this { multiboot /foo } menuentry Only users who unlocked the menu can boot this { if allowed bootbar ; then multiboot /bar fi } menuentry Only a few selected ones can boot this { if allowed bootbaz; then multiboot /baz fi } Yoshinori K. Okuji wrote: On Sunday 10 February 2008 21:59, Robert Millan wrote: I didn't see this; it was inspired in the lock command in GRUB Legacy. But since it only applies to menu, and doesn't lock anything else, I thought menu_lock would be a good choice. Since our default state is not to lock the menu, and that would match with non-existance of the variable, I think the meaning of the variable should be to lock the menu when set. If we make it mean the opposite, e.g. auth=1, what do we do when the variable is not set? You can observe I've been instructed by your advice not to implement ad-hoc features, so I tried to avoid some generic lock command that would handle multiple things depending on the context. With my proposed scheme, we provide the primitives and user can do just about anything. First of all, we need an authorization status at the global level anyway, because if you can enter into the command line interface, you can bypass everything. Once you accept defining an authorization status, you can write this: menuentry Anyone can boot this { multiboot /foo } menuentry Only users who unlocked the menu can boot this { if test $auth != no ; then multiboot /bar else echo You must enter a password before booting this entry. # Probably better to have a way to exit with an error here! fi } menuentry Only a few selected ones can boot this { echo -n Password: read password if test $password = grubisawesome ; then multiboot /baz else echo The password you entered was wrong. # error error fi } But my feeling is that it would be more powerful to implement a password checker as a command. Scripting allows you to perform many things, if GRUB provides many commands and control structures, but it looks very tiring to implement various features (e.g. various encryption schemes, challenge retries, the translation of prompts, and so on). Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] implement menu_lock
Implement menu_lock. This is a variable that locks the menu when set. It can be used by users to lock the menu, although there's no way to authenticate users for unlocking it, yet (but the procedure would be independant from this interface). -- Robert Millan GPLv2 I know my rights; I want my phone call! DRM What use is a phone call… if you are unable to speak? (as seen on /.) 2008-02-10 Robert Millan [EMAIL PROTECTED] * normal/misc.c (grub_normal_env_getint): New function. Generic method to obtain the integer value of an environment variable whose string represents an integer. * normal/menu.c (print_message): When `menu_lock' environment variable is set to 1, tell user that editor and command-line are locked instead of the hotkeys to access them. (run_menu): When `menu_lock' environment variable is set to 1, disallow access to editor or command-line. (grub_menu_run): When processing an entry, say that we're Processing it rather than Booting it, since user might setup entries to set or unset menu_lock without booting an OS. diff -x configure -x config.h.in -x CVS -x '*~' -x '*.mk' -urp ../grub2/normal/menu.c ./normal/menu.c --- ../grub2/normal/menu.c 2008-02-09 12:23:50.0 +0100 +++ ./normal/menu.c 2008-02-09 22:17:38.0 +0100 @@ -91,8 +91,15 @@ print_message (int nested, int edit) Use the %C and %C keys to select which entry is highlighted.\n, (grub_uint32_t) GRUB_TERM_DISP_UP, (grub_uint32_t) GRUB_TERM_DISP_DOWN); grub_printf (\ - Press enter to boot the selected OS, \'e\' to edit the\n\ + Press enter to boot the selected OS); + + if (grub_normal_env_getint (menu_lock) == 1) + grub_printf ( . Access to command\n\ + editor or command-line is currently locked.); + else + grub_printf ( , \'e\' to edit the\n\ commands before booting or \'c\' for a command-line.); + if (nested) grub_printf (\n\ ESC to return previous menu.); @@ -457,15 +464,21 @@ run_menu (grub_menu_t menu, int nested) break; case 'c': + if (grub_normal_env_getint (menu_lock) == 1) + break; + grub_cmdline_run (1); goto refresh; case 'e': - { + if (grub_normal_env_getint (menu_lock) == 1) + break; + + { grub_menu_entry_t e = get_entry (menu, first + offset); if (e) grub_menu_entry_run (e); - } + } goto refresh; default: @@ -511,7 +524,7 @@ grub_menu_run (grub_menu_t menu, int nes grub_cls (); grub_setcursor (1); - grub_printf ( Booting \'%s\'\n\n, e-title); + grub_printf ( Processing \'%s\'\n\n, e-title); run_menu_entry (e); diff -x configure -x config.h.in -x CVS -x '*~' -x '*.mk' -urp ../grub2/normal/misc.c ./normal/misc.c --- ../grub2/normal/misc.c 2007-10-15 12:59:38.0 +0200 +++ ./normal/misc.c 2008-02-09 21:32:39.0 +0100 @@ -73,3 +73,12 @@ grub_normal_print_device_info (const cha grub_printf (\n); return grub_errno; } + +int +grub_normal_env_getint (char *name) +{ + char *value = grub_env_get (name); + if (! value) +return -1; + return grub_strtoul (value, 0, 10); +} ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] implement menu_lock
On Sun, Feb 10, 2008 at 02:09:40PM +0100, Robert Millan wrote: diff -x configure -x config.h.in -x CVS -x '*~' -x '*.mk' -urp ../grub2/normal/misc.c ./normal/misc.c --- ../grub2/normal/misc.c2007-10-15 12:59:38.0 +0200 +++ ./normal/misc.c 2008-02-09 21:32:39.0 +0100 Ah, I forgot to update copyright year on this one (this mail is a reminder mostly for myself ;-)). -- Robert Millan GPLv2 I know my rights; I want my phone call! DRM What use is a phone call… if you are unable to speak? (as seen on /.) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] implement menu_lock
On Sunday 10 February 2008 14:09, Robert Millan wrote: Implement menu_lock. This is a variable that locks the menu when set. It can be used by users to lock the menu, although there's no way to authenticate users for unlocking it, yet (but the procedure would be independant from this interface). I think this should be named differently. menu_lock sounds like freezing a menu, but you also disable entering into the command line. In GRUB Legacy, I used a variable auth to define the state of authorization (you can have a look at stage2/stage2.c). Was it so bad? Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] implement menu_lock
On Sun, Feb 10, 2008 at 09:13:01PM +0100, Yoshinori K. Okuji wrote: On Sunday 10 February 2008 14:09, Robert Millan wrote: Implement menu_lock. This is a variable that locks the menu when set. It can be used by users to lock the menu, although there's no way to authenticate users for unlocking it, yet (but the procedure would be independant from this interface). I think this should be named differently. menu_lock sounds like freezing a menu, but you also disable entering into the command line. In GRUB Legacy, I used a variable auth to define the state of authorization (you can have a look at stage2/stage2.c). Was it so bad? I didn't see this; it was inspired in the lock command in GRUB Legacy. But since it only applies to menu, and doesn't lock anything else, I thought menu_lock would be a good choice. Since our default state is not to lock the menu, and that would match with non-existance of the variable, I think the meaning of the variable should be to lock the menu when set. If we make it mean the opposite, e.g. auth=1, what do we do when the variable is not set? You can observe I've been instructed by your advice not to implement ad-hoc features, so I tried to avoid some generic lock command that would handle multiple things depending on the context. With my proposed scheme, we provide the primitives and user can do just about anything. She can even implement different authorization levels. For example: set menu_lock=1 menuentry Unlock the menu { echo -n Password: read password if test $password=grubrocks ; then unset menu_lock fi } menuentry Anyone can boot this { multiboot /foo } menuentry Only users who unlocked the menu can boot this { if ! test $menu_lock=1 ; then multiboot /bar fi } menuentry Only a few selected ones can boot this { echo -n Password: read password if test $password=grubisawesome ; then multiboot /baz fi } -- Robert Millan GPLv2 I know my rights; I want my phone call! DRM What use is a phone call… if you are unable to speak? (as seen on /.) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] implement menu_lock
On Sun, Feb 10, 2008 at 09:59:48PM +0100, Robert Millan wrote: menuentry Only users who unlocked the menu can boot this { if ! test $menu_lock=1 ; then multiboot /bar fi } menuentry Only a few selected ones can boot this { echo -n Password: read password if test $password=grubisawesome ; then multiboot /baz fi } Uhm, actually the titles are confusing, since the third one only makes sense for users who can't unlock the menu (saving that, I think it still makes sense). -- Robert Millan GPLv2 I know my rights; I want my phone call! DRM What use is a phone call… if you are unable to speak? (as seen on /.) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel