[RFC] Grub2 lock and password implementation

[RFC] Grub2 lock and password implementation

[Julien Ranc]

Some months ago, I started working on this part, but it didn't go far,
and I abandonned it mainly because of a lack of time.
I'd like to take some time to work on it again, this time until it
(hopefully) gets accepted into Grub2.
I'll try in this mail to describe how I propose to implement these 2 features.
All comments, remarks will be highly appreciated.

What is needed / wanted ?

All functions of Grub legacy should be offered. The authentication
should be made extensible, in order to easily support various kind of
authentication: password-based, network-based, two-factor, or any
fancy authentication method one would think of.

In order to achieve this, I propose to implement the following infrastructure:

An "authentication" module. It would be in charge of:
 - (un)registering authentication methods,
 - managing user authentication state,
 - storing defined authentication data. This module would manage only
one authentication challenge at a time.
 - asking the authentication method for user credential to check
against authentication data when and as required.

Several "authentication method".
These modules would implement various authentication methods. An
authentication method would be in charge of storing authentication
data (whatever it is), asking user credentials, comparing user input
to authentication data and deciding whether the user succeeded or
failed. I am thinking of implementing, as a start:
 - Plain text password: insecure, but very easy to implement, and can
be useful for tests, and would ensure compatibility with Grub Legacy.
 - MD5 summed password. More secure, and required for compatibility
with Grub Legacy
 - probably also SHA-256: Even more secure since MD5 collisions exist.

An "authentication_data" structure,
It would store data relative to the authentication challenge (data
used by the authentication module, and opaque data used and controlled
by the authentication method). For example: plain text password, MD5
hash, a public RSA key read from a file specified in the grub
configuration file, etc)

Two new Grub 2 commands: lock and password. These commands, along with
parameters, and use cases are describes below.

The password command:

This command would register an authentication challenge in the
authentication module. The call to this command in transparent to the
user (nothing displayed on screen, no user interaction needed). The
command parameters would be:
password --type AUTH_METHOD_NAME [authentication method parameters]
The AUTH_METHOD_NAME parameter is used to call the authentication
method handler that registered with this name. It could be, for
example "plain" for plain texts, "md5", "sha256", etc.
Then, the authentication method would be called to set up an
"authentication_data" structure. It would be passed all the
[authentication method parameters] in order to fill the opaque data in
the structure.

The lock command:
This command would block the execution of the script until the user
correctly authenticate. If the user correctly authenticated
previously, and the password had not been changed (via a password
command) since, then the lock command would return without locking the
user again.
I imagine two uses of the lock command: Firstly alone, with no
additional parameter. This would use the latest defined authentication
data. Or with the same exact syntax as the password command. This
would lead to the following syntax:
lock [--type AUTH_METHOD_NAME [authentication method parameters]]


--
Julien RANC
julien.ranc@gmail.com

Re: [RFC] Grub2 lock and password implementation

[Michael Gorven]

[-- Attachment #1: Type: text/plain, Size: 560 bytes --]

On Friday 23 May 2008 15:50:53 Julien Ranc wrote:
> method handler that registered with this name. It could be, for
> example "plain" for plain texts, "md5", "sha256", etc.

I am currently implementing support for LUKS encrypted partitions in GRUB and 
have working SHA1, SHA256 and SHA512 modules. It would make sense to use 
those instead of reimplementing them. I can add an MD5 module fairly easily, 
and restore SHA224 and SHA384 functions if necessary.

Michael

-- 
http://michael.gorven.za.net
PGP Key ID 6612FE85
S/MIME Key ID D33AEB31

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [RFC] Grub2 lock and password implementation

[Vesa Jääskeläinen]

Julien Ranc wrote:
> What is needed / wanted ?

First of all, I do not ask that you code following. They are just to 
test out flexibility of your proposal.

So how would following scenarios work with your proposal?

a) smartcard + ext pin

There is smartcard reader on system with integrated keypad. Smartcard 
accessing software is developed as plugin.

b) smartcard + pc pin

There is smartcard reader on system without integrated keypad. User is 
requested about PIN code on screen and then validated on the card. 
Smartcard accessing software is developed as plugin. PIN code reading 
can be a plugin or generic implementation for password query.

c) RFID verification

There is RFID reader on system. User swipes dongle and gets a code. 
Optional password defined on grub config for user with some hash algo. 
If password would be asked, generic implementation would be used for 
asking it. Verification can be done by custom plugin if needed.

d) smartcard + biometric sensor

There is smartcard and biometric readers on system. User enters his 
smartcard on the reader and gives proper biometric identification to 
sensor. Verification can be done by custom plugin if needed.

e) multiple users

There are group of users that can be allowed to higher access. 
Authenticated with password or user & password pair.

f) network authentication

Authentication by LDAP server. User id and password will be asked. 
Network will be connected if no local authentication information 
available. If LDAP server cannot be contacted access is denied or only 
local sources available. Or alternative some other method like RADIUS or so.

Thanks,
Vesa Jääskeläinen

Re: [RFC] Grub2 lock and password implementation

[Julien Ranc]

Here's an attempt to answer briefly your questions. I hope it will
help you and others to have a better understanding of what I'm
proposing.  I'm looking for opinions on these examples : what is
acceptable, what could be better supported, what needs changing, and
so on.

1) smartcards

This is a point I'd like to implement, once password/lock feature will
be completed and USB support added. I was thinking of a module that
would handle ISO 7816 compliant cards. This module could defer some
work, if needed, to a card-specific driver, for example for PIN entry,
etc. (like openSC for example uses multiple drivers for different
cards)
This module would require to specify, in case of RSA use:
-	the card ID
-	a reference to the key to be used for authentication
-	a reference to the public key, stored on hard drive
This would lead to something like that:

lock –type iso7816 –driver cardmodel –cardname "my card" –key_id 49
–pubkey (hd0,0)/boot/key.pub

The pseudo code for authentication function being something like that:

Function authenticate_user
	While ( ! is_card_present( card_name ) ) {
		Ask_for_card( card_name )
	}
	challenge = generate_random_text()
	sig = card_sign_data( challenge, key_id )
	auth_result = check_signature( sig, public_key, challenge)
}

As for biometric sensors, I have no idea how it works, so I cannot
plot a way to support it at that time.

c) RFID verification

I think this is about the same as for smartcards, identify user with
the ID of his RFID dongle as read from RFID reader instead of
smartcard name, and check simple password instead of cryptographic
challenge.

lock -type rfid -driver rfid_reader -rfid_tag 123456 -MD5password XXXXXX

e) multiple users

The implementation I proposed does not cop very well with multiple
user/groups needs. However, it could be handled by a "multiuser"
module, which would in turn defer authentication work to other
specialized modules (like md5 for example). It assumes that ALL users
log in with the same method…. which is quite plausible I think.

The multiuser module would need, as arguments:
-	a file that contains authentication data for several users
-	who is allowed (list of users and/or groups)
-	what type of authentication to defer work to…
The file with auth data would contain user login, user group and user
auth data taht would be passed to the module which we defer work to.
For example:

#Start of file password.txt
#login group user_authentication_data
root admin –password md5hashofrootpassword
john bsd_user –password md5hashofjohnpassword
paul linux_user –password md5hashofpaulpassword
#End of file

The command would be

Lock –type multiuser –authtype md5 –datas (hd0,0)/password.txt
–allow_users john –allow_groups admin

This would allow root and john to log in, but not paul

The auth function would be like that:

Function authenticate_user {
    auth_method = load_method( authtype)
    login = prompt_user_login()
    auth_data = get_data_from_file( pwd_file, login )
    group = get_group_from_file( pwd_file, login )
    if (auth_data == null ) return FAIL
    if ! auth_method.authenticate( auth_data ) return FAIL
    if ( login not_in authorized_logins AND group not_in authorized_groups )
        return FAIL
    return OK
}

f) network authentication

This would I think be quite straightforward (though it requires not so
easy things such as network support, LDAP protocol, etc) : ask user
login and password, build a DN based of these info + some in the grub
config file:
DN : dc=company,dc=com,user=login,pass=password
And last, check the DN existence in LDAP




2008/5/23 Vesa Jääskeläinen <chaac@nic.fi>:
> Julien Ranc wrote:
>>
>> What is needed / wanted ?
>
> First of all, I do not ask that you code following. They are just to test
> out flexibility of your proposal.
>
> So how would following scenarios work with your proposal?
>
> a) smartcard + ext pin
>
> There is smartcard reader on system with integrated keypad. Smartcard
> accessing software is developed as plugin.
>
> b) smartcard + pc pin
>
> There is smartcard reader on system without integrated keypad. User is
> requested about PIN code on screen and then validated on the card. Smartcard
> accessing software is developed as plugin. PIN code reading can be a plugin
> or generic implementation for password query.
>
> c) RFID verification
>
> There is RFID reader on system. User swipes dongle and gets a code. Optional
> password defined on grub config for user with some hash algo. If password
> would be asked, generic implementation would be used for asking it.
> Verification can be done by custom plugin if needed.
>
> d) smartcard + biometric sensor
>
> There is smartcard and biometric readers on system. User enters his
> smartcard on the reader and gives proper biometric identification to sensor.
> Verification can be done by custom plugin if needed.
>
> e) multiple users
>
> There are group of users that can be allowed to higher access. Authenticated
> with password or user & password pair.
>
> f) network authentication
>
> Authentication by LDAP server. User id and password will be asked. Network
> will be connected if no local authentication information available. If LDAP
> server cannot be contacted access is denied or only local sources available.
> Or alternative some other method like RADIUS or so.
>
> Thanks,
> Vesa Jääskeläinen
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Julien RANC
julien.ranc@gmail.com

Re: [RFC] Grub2 lock and password implementation

[Tomáš Ebenlendr]

Dne 27 Květen 2008, 15:29, Julien Ranc napsal(a):

> e) multiple users
>
> The implementation I proposed does not cop very well with multiple
> user/groups needs. However, it could be handled by a "multiuser" module,
> which would in turn defer authentication work to other specialized modules
> (like md5 for example). It assumes that ALL users
> log in with the same method?. which is quite plausible I think.

I would like to say something on this. First of all I don't think that ALL
users want to log with the same method. Assume some school environment:
The administrator want access to the grubs command line and there are many
smart students so he has some hw method to authenticate (just for better
safety). Then there is the service of computer laboratory. They are
allowed to boot system on CD or usb-stick, because some students have
projects that need to boot something special (These students have some
permit by school, and they authenticate themself to the lab service people,
e.g, visually). The lab service logs in just using md5 (assume crypted
partitions, so the system from usb stick cannot read data on it). And also
there are ordinary students. They want to turn the machine on and use the
preconfigured booting method, without any password.

Yes it is marginal type of use. And in fact the single-user authetication
command, together with scripting can handle this environment.

Moreover multi-method configuration may be unsecure if configured in wrong
way. So I elaborated more on some methods how to use multiple methods
to authenticate.

The multi-method authentication can be done e.g. in following ways

1.) menu + single-method authentication
      This needs only allowing single-method authentication to ABORT.
      The return value (if authenticated/who authenticated) should be
      testable by grub scripting support.
      Moreover, we need no usernames here if the underlying authentication
      metods does not need them. Thus this case is as secure as underlying
      methods.

2.) authentication defined by username (scripting + single-method)
      Here user must give his user name. Script then decides the method
      by given username. - Here we want to have some test if user is
      in set defined by the method. - Note that some methods does not allow
      user testing to increase security (this may be the case of e.g. LDAP)

3.) username + password + trying all methods
      Assume we autheticate both by local passwd file and by LDAP.
      Both methods require username and password. This must be properly
      configured: if we try network first with plain passwords, we will
      send local passwords to the network server which is unsecure.

4.) Event system:
      Most difficult, may be we wan't implement this.
      Here grub displays some preconfigured menu or whatever and besides
      waiting for keyboard input it also waits for insertion of smartcards
      and takes actions accordingly.

So we need to allow the authentication to abort, then we are able to
use the cae 1 even without multi-user. In fact this method is sufficient
and I write here the other methods only for consideration.

For the case 2, we need to be able to ask for the username, assign it to
some variable and then call various grub commands including
the authentication command itself.

The example of a grub script in bash like language:

false
while (LAST_COMMAND_FAILED) do
  read USERNAME
  if login -user $USERNAME -method passwd -file (hd1,1)/passwd.txt -exists
    then
      login -user $USERNAME -method passwd -file (hd1,1)/passwd.txt
     else
      login -user $USERNAME -method LDAP -server 1.2.3.4 ...
   fi
done

Case 3 can be implemented in two ways:
a)
  loginmulti -method passwd -file (hd1,1)/passwd.txt -or -method LDAP ...
b)
  false
  while (LAST_COMMAND_FAILED) do
    USERNAME=""
    login -method passwd -file (hd1,1)/passwd.txt -savefailedcredentials
    login -user $USERNAME -pass $PASSWORD -method LDAP -server ...
    PASSWORD=""
  done

I think that case 4 is too heavy to implement in boot manager, but maybe
someone don't think so. It will be also interesting to look at libpam,
how it deals with multiple methods when logging into the system.

The loginmulti command for case 3 and maybe case 4 should be always
implementable provided that the modules export apropriate symbols.

Note that login command should always save at least username of positively
authenticated user to variable, so that scripting support may then take
apropriate actions (e.g. pass the username to booted system). It will be
also nice when autheticating e.g. by kerberos, to pass the kerberos ticket
to the system that we boot later, so the user needs not to authenticate
twice (for grub and for operating system).

-- 
                            Tomas Ebenlendr
                            http://drak.ucw.cz/~ebik