Menu locks / password authentication

Menu locks / password authentication

[Robert Millan]

It's funny, we're all discussing about performing security measurements in
GRUB and nobody mentioned that our user interface lacks even the most basic
lock mechanism :-)

Perhaps this would be a good time to retake the discussion on implementing
an equivalent to "lock" and "password" commands.  I think I even sent a patch
a while ago!

Vesa, do you still think we should design an extensible framework for
authentication before we do anything else?  I think it'd be interesting if
we could implement the lock/password paradigm, even if later it would be
replaced, since our users commonly need this, and it's blocking the
transition from GRUB Legacy.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: Menu locks / password authentication

[Vesa Jääskeläinen]

Robert Millan wrote:
> It's funny, we're all discussing about performing security measurements in
> GRUB and nobody mentioned that our user interface lacks even the most basic
> lock mechanism :-)
> 
> Perhaps this would be a good time to retake the discussion on implementing
> an equivalent to "lock" and "password" commands.  I think I even sent a patch
> a while ago!
> 
> Vesa, do you still think we should design an extensible framework for
> authentication before we do anything else?  I think it'd be interesting if
> we could implement the lock/password paradigm, even if later it would be
> replaced, since our users commonly need this, and it's blocking the
> transition from GRUB Legacy.

I think that most important thing at this time is to match needed
functionality with GRUB legacy. So just make it clean and perhaps think
a bit about how it can be easily extended :).

I think there was some hash algorithms posted previously that could be
used for this.

Re: Menu locks / password authentication

[Robert Millan]

On Tue, Mar 03, 2009 at 05:32:40PM +0200, Vesa Jääskeläinen wrote:
> Robert Millan wrote:
> > It's funny, we're all discussing about performing security measurements in
> > GRUB and nobody mentioned that our user interface lacks even the most basic
> > lock mechanism :-)
> > 
> > Perhaps this would be a good time to retake the discussion on implementing
> > an equivalent to "lock" and "password" commands.  I think I even sent a patch
> > a while ago!
> > 
> > Vesa, do you still think we should design an extensible framework for
> > authentication before we do anything else?  I think it'd be interesting if
> > we could implement the lock/password paradigm, even if later it would be
> > replaced, since our users commonly need this, and it's blocking the
> > transition from GRUB Legacy.
> 
> I think that most important thing at this time is to match needed
> functionality with GRUB legacy. So just make it clean and perhaps think
> a bit about how it can be easily extended :).
> 
> I think there was some hash algorithms posted previously that could be
> used for this.

Hashing is nice, but basic password support can work without hash.  If you
give grub.cfg the proper perms, that is.

Anyway, for those interested:

  http://www.mail-archive.com/grub-devel@gnu.org/msg05350.html

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: Menu locks / password authentication

[Michał Radomski]

On Fri, Feb 27, 2009 at 09:53:27PM +0100, Robert Millan wrote:
> 
> It's funny, we're all discussing about performing security measurements in
> GRUB and nobody mentioned that our user interface lacks even the most basic
> lock mechanism :-)
> 
Actualy... I'm working on password command... 

At this moment I have plain password checking and 
almost finished MD5 support.

-- 
- -  (_ _) Regards                                       -----,  (_ _)  - -
-     ','  |  Michał Radomski <ezzo (at) poczta (dot) pl>     |   ','     -
- -  vv-   `---                                                    -vv  - -

Re: Menu locks / password authentication

[phcoder]

Michał Radomski wrote:
> On Fri, Feb 27, 2009 at 09:53:27PM +0100, Robert Millan wrote:
>> It's funny, we're all discussing about performing security measurements in
>> GRUB and nobody mentioned that our user interface lacks even the most basic
>> lock mechanism :-)
>>
> Actualy... I'm working on password command... 
> 
> At this moment I have plain password checking and 
> almost finished MD5 support.
> 
What is your design? Is it expandable? Flexible?

-- 

Regards
Vladimir 'phcoder' Serbinenko

Re: Menu locks / password authentication

[Michał Radomski]

On Mon, Mar 09, 2009 at 08:16:16AM +0100, phcoder wrote:
> Michał Radomski wrote:
>> On Fri, Feb 27, 2009 at 09:53:27PM +0100, Robert Millan wrote:
>>> It's funny, we're all discussing about performing security measurements in
>>> GRUB and nobody mentioned that our user interface lacks even the most basic
>>> lock mechanism :-)
>>>
>> Actualy... I'm working on password command... 
>>
>> At this moment I have plain password checking and almost finished MD5 
>> support.
>>
> What is your design? Is it expandable? Flexible?
>
Flexible Yes, expandable I think yes. 

Password checking is implemented as grub module, which blocks grub
execution until user supply a valid password. Take a look at 2 sample
configs: 

# this config will wait for valid password 
# after that it will show grub menu 
set timeout=5
password --plain qwerty 

menuentry "Linux" {
set root=(hd0,1)
linux /vmlinuz26 root=/dev/sda1 ro
initrd /kernel26.img
}
 
# this config will show menu, but if user would like to boot os,
# it will ask for a password.  
set timeout=5

menuentry "Linux" {
password --md5 md5_hash  
set root=(hd0,1)
linux /vmlinuz26 root=/dev/sda1 ro
initrd /kernel26.img
}


md5 algoritm is implemented as a library(grub2/lib), So it can by easy
used in other source files. 

I've also think about more complex solution (password file)
And I think that it is possible to add, without many changes. 


-- 
- -  (_ _) Regards                                       -----,  (_ _)  - -
-     ','  |  Michał Radomski <ezzo (at) poczta (dot) pl>     |   ','     -
- -  vv-   `---                                                    -vv  - -

Re: Menu locks / password authentication

[phcoder]

Michał Radomski wrote:
> On Mon, Mar 09, 2009 at 08:16:16AM +0100, phcoder wrote:
>> Michał Radomski wrote:
>>> On Fri, Feb 27, 2009 at 09:53:27PM +0100, Robert Millan wrote:
>>>> It's funny, we're all discussing about performing security measurements in
>>>> GRUB and nobody mentioned that our user interface lacks even the most basic
>>>> lock mechanism :-)
>>>>
>>> Actualy... I'm working on password command... 
>>>
>>> At this moment I have plain password checking and almost finished MD5 
>>> support.
>>>
>> What is your design? Is it expandable? Flexible?
>>
> Flexible Yes, expandable I think yes. 
> 
> Password checking is implemented as grub module, which blocks grub
> execution until user supply a valid password. Take a look at 2 sample
> configs: 
> 
> # this config will wait for valid password 
> # after that it will show grub menu 
> set timeout=5
> password --plain qwerty 
> 
> menuentry "Linux" {
> set root=(hd0,1)
> linux /vmlinuz26 root=/dev/sda1 ro
> initrd /kernel26.img
> }
>  
> # this config will show menu, but if user would like to boot os,
> # it will ask for a password.  
> set timeout=5
> 
> menuentry "Linux" {
> password --md5 md5_hash  
> set root=(hd0,1)
> linux /vmlinuz26 root=/dev/sda1 ro
> initrd /kernel26.img
> }
> 
> 
> md5 algoritm is implemented as a library(grub2/lib), So it can by easy
> used in other source files. 
> 
> I've also think about more complex solution (password file)
> And I think that it is possible to add, without many changes. 
> 
> 

What prevents an attacker from simply pressing 'e' or 'c' in menu? I 
personally would prefer the architecture with users as I described. Also 
I would recommend using other hashes that md5 (e.g. whirlpool or sha-2) 
because it's been depreceated
And blocking is a bad idea because if a legitimate user accidently 
chooses wrong entry he can't press ESC to go back.
Do you already have a copyright assignment?

-- 

Regards
Vladimir 'phcoder' Serbinenko

Re: Menu locks / password authentication

[Michał Radomski]

On Mon, Mar 09, 2009 at 11:57:40AM +0100, phcoder wrote:
> I would recommend using other hashes that md5 (e.g. whirlpool or sha-2)  
> because it's been depreceated
I chose md5 because it is in grub2 wiki (see command list)
It is not a problem to add sha-2 or whirlpool.  

> Do you already have a copyright assignment?
You mean license? GPL3 

md5 code is based on grub-legacy. Some code is mine, some is from old grub. 
I hope that this is not a problem... 

-- 
- -  (_ _) Regards                                       -----,  (_ _)  - -
-     ','  |  Michał Radomski <ezzo (at) poczta (dot) pl>     |   ','     -
- -  vv-   `---                                                    -vv  - -

Re: Menu locks / password authentication

[phcoder]

Michał Radomski wrote:
> On Mon, Mar 09, 2009 at 11:57:40AM +0100, phcoder wrote:
>> I would recommend using other hashes that md5 (e.g. whirlpool or sha-2)  
>> because it's been depreceated
> I chose md5 because it is in grub2 wiki (see command list)
> It is not a problem to add sha-2 or whirlpool.  

grub1 has been depreceated and command list has been provided as a 
feature comparison.

> 
>> Do you already have a copyright assignment?
> You mean license? GPL3 
> 
No if you want to code for grub2 you have to sign the copyright 
assignment. look at "contributing changes"
> md5 code is based on grub-legacy. Some code is mine, some is from old grub. 
> I hope that this is not a problem... 
> 

I think that your design really has to be discussed
-- 

Regards
Vladimir 'phcoder' Serbinenko