lkml.org 
[lkml]   [2004]   [Sep]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: mlock(1)
    > On Sat, 2004-09-25 at 09:59, Bernd Eckenfels wrote:
    > > In article <20040924225900.GY3309@dualathlon.random> you wrote:
    > > > laptop (currently suspend dumps into the swap the cleartext key of any
    > > > cryptoloop device, making cryptoloop pretty much useless). And the good
    > > > thing is that it won't even need to ask for a password.
    > >
    > > Where would you store the key for the suspend image without asking?

    when I've said you will not be asked for a password, I meant during
    boot. my desktop machine will never annoy me asking me for a swap
    password. Of course on the laptop (but _only_ on the laptop, since I
    never use suspend on anything by the laptop) suspend/resume will have to
    ask for a password for suspend/resume to work safely (this secondary
    password choosen by the user, will encrypt the primary random swap
    password). This should be safe.

    On Sat, Sep 25, 2004 at 10:25:44AM +1000, Nigel Cunningham wrote:
    > Hi.
    >
    > You should really reply-to-all, not just to LKML. I've added the
    > original recipients back.
    >
    > I have to admit that I'm not sure. I haven't begun to try to write the
    > support yet, or even look at how the other implementations do
    > encryption. (Pointers welcome!) I assume there should be some option to
    > save it in a file and get it via the initrd, and/or perhaps require the
    > user to type in a passphrase at the lilo prompt.

    saving it to the disk is not safe. It really has to be choosen by the
    user. Maybe for suspend we could try to search for active cryptoloops
    or dm-crypt, and re-use the same password, to avoid asking the user.
    That would be ok. But resume definitely has to ask to the user.

    I doubt we can make it with lilo/grub, if we do that we should probably
    nuke it somehow from /proc/cmdline, allowing all users in the system to
    see the cleartext password doesn't sound secure enough. More likely the
    kernel should stop and ask the user to type something and then read the
    swap header and find a magic-check block and see if the password can
    decrypt the magic block.

    > >From what I have seen, random keys are sometimes chosen. I guess the
    > point there is not so much to protect access to the image as to obscure
    > it? If so, the existing compression support in suspend2 probably helps
    > satisfy this requirement.

    random keys are exactly fine, but only for the swap usage on a desktop
    machine (the one I mentioned above, where the user will not be asked for
    a password), but it's not ok for suspend/resume, suspend/resume needs
    a regular password asked to the user both at suspend time and at resume
    time.
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:06    [W:3.888 / U:0.184 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site