From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LgJOh-00028h-Sd for mharc-grub-devel@gnu.org; Sun, 08 Mar 2009 09:50:31 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LgJOf-00027p-Aw for grub-devel@gnu.org; Sun, 08 Mar 2009 09:50:29 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LgJOd-00026B-Om for grub-devel@gnu.org; Sun, 08 Mar 2009 09:50:27 -0400 Received: from [199.232.76.173] (port=51560 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LgJOd-00025u-Gs for grub-devel@gnu.org; Sun, 08 Mar 2009 09:50:27 -0400 Received: from fg-out-1718.google.com ([72.14.220.155]:2063) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LgJOc-0006jY-On for grub-devel@gnu.org; Sun, 08 Mar 2009 09:50:27 -0400 Received: by fg-out-1718.google.com with SMTP id l27so716539fgb.30 for ; Sun, 08 Mar 2009 06:50:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=b7ZJ6aYj9UubnBgyW0FzCkqHmvaJjiAkrGr0bD1zqYo=; b=wD10+G8fDNIW2piz4rTlE5fEcL4LZjTaHq1DkrtTczGl6P9KmtnqGKXCGyWWBfXpzz ByzBtT8Tvb7uar46Pro2tChljW4m6zMuZVO64yMCPfKvoF5eEITIdi4hmzboPwHm9VYK z9b3g+Ubblwbv3Fv0rrJzJoRm4CPrOxIc4GY4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=Xb3AytpPA4L13Cpl6aLVzl45i/SPjlr3VbnSXNTGmx1KhSmjhfLaKSqBj753CUH/LZ VJVT7POGq/erwgFpzAxzYVyWVp+FegzVD88E1xwSq5BeW4gmItml7RnYT2Xwjm7hgC1i cjrkFPcs84ohBu9gBIia04+ViTLgCjqWkKfAI= Received: by 10.86.53.8 with SMTP id b8mr3241580fga.10.1236520224811; Sun, 08 Mar 2009 06:50:24 -0700 (PDT) Received: from ?192.168.1.25? (232-156.62-81.cust.bluewin.ch [81.62.156.232]) by mx.google.com with ESMTPS id d6sm2220848fga.12.2009.03.08.06.50.24 (version=SSLv3 cipher=RC4-MD5); Sun, 08 Mar 2009 06:50:24 -0700 (PDT) Message-ID: <49B3CD1A.7030805@gmail.com> Date: Sun, 08 Mar 2009 14:50:18 +0100 From: phcoder User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: The development of GRUB 2 References: <20080210130940.GA3879@thorin> <200802102113.01523.okuji@enbug.org> <20080210205948.GC4916@thorin> <200802120841.24890.okuji@enbug.org> In-Reply-To: <200802120841.24890.okuji@enbug.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: [PATCH] implement menu_lock X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2009 13:50:29 -0000 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 :,,... :,,... ... 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