All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robert Millan <rmh@aybabtu.com>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: [PATCH] read --echo=[yes|no|wildcard]
Date: Sun, 10 Feb 2008 18:00:26 +0100	[thread overview]
Message-ID: <20080210170026.GA12941@thorin> (raw)
In-Reply-To: <47AF293F.8070804@isaac.cedarswampstudios.org>

On Sun, Feb 10, 2008 at 11:41:35AM -0500, Isaac Dupree wrote:
> Robert Millan wrote:
> >On Sun, Feb 10, 2008 at 08:56:18AM -0500, Isaac Dupree wrote:
> >>Robert Millan wrote:
> >>>Adds a parameter to define echoing behaviour in read.  Then one can use
> >>>--echo=no or --echo=wildcard to make it suitable for reading passwords.
> >>I wonder how suitable it is for passwords -- is the memory always erased 
> >>before jumping to e.g. Linux? (and is it important to hide it from the 
> >>prying eyes of the root system? Probably...)
> >
> >Why?  This suggests that the Linux image you just booted is not trusted, 
> >which
> >I find a bit strange.
> 
> well, suppose it runs for a few months, doesn't happen to overwrite that 
> memory, and then someone hacks in and gets root access (unpatched 
> security flaws can happen) and then reads the raw memory.  Then the 
> local boot **and the password itself** might be unknowingly compromised 
> (rather than just probably a hash of the password). (plus you might be 
> booting Windows ^_^, or anything really.)  It's generally good practice, 
> I think... that GnuPG tries to do, for example? (I could be remembering 
> wrong)

I think that it'd be better to just erase all our environment in
grub_machine_fini() or a similar routine, than to give read specific knowledge
that its data needs this kind of special protection.  Besides, it wouldn't be
that simple since the data is controlled by the user via grub.cfg, not directly
by GRUB.

Anyway, untill we support hashing this doesn't provide any additional security,
since you can get the same from grub.cfg ;-)

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



  reply	other threads:[~2008-02-10 17:02 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-10 13:16 [PATCH] read --echo=[yes|no|wildcard] Robert Millan
2008-02-10 13:56 ` Isaac Dupree
2008-02-10 15:22   ` Robert Millan
2008-02-10 16:41     ` Isaac Dupree
2008-02-10 17:00       ` Robert Millan [this message]
2008-02-10 18:00         ` Isaac Dupree
2008-02-10 19:39           ` Robert Millan
2008-02-10 20:00             ` Isaac Dupree
2008-02-10 20:47               ` [PATCH] erase variable data on user unset Robert Millan
2008-02-10 21:00                 ` Robert Millan
2008-02-10 21:31                 ` Isaac Dupree
2008-02-10 21:38                   ` Isaac Dupree
2008-02-10 21:53                     ` Robert Millan
2008-02-10 20:16 ` [PATCH] read --echo=[yes|no|wildcard] Yoshinori K. Okuji
2008-02-10 20:49   ` Robert Millan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080210170026.GA12941@thorin \
    --to=rmh@aybabtu.com \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.