[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC] Grub2 lock and password implementation

From: Julien Ranc
Subject: Re: [RFC] Grub2 lock and password implementation
Date: Tue, 27 May 2008 15:29:43 +0200

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
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/

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

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 <address@hidden>:
> 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
> address@hidden

Julien RANC

reply via email to

[Prev in Thread] Current Thread [Next in Thread]