Re: mlock(1)
From: Jon Masters (jonmasters_at_gmail.com)
Date: 09/29/04
- Previous message: Dave Airlie: "Re: 2.6.9-rc2-mm4 drm and XFree oopses"
- In reply to: Robert White: "RE: mlock(1)"
- Next in thread: Lee Revell: "RE: mlock(1)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 29 Sep 2004 13:34:45 +0100 To: Robert White <rwhite@casabyte.com>
On Tue, 28 Sep 2004 20:46:20 -0700, Robert White <rwhite@casabyte.com> wrote:
> (Sorry I am using outlook here at work by corporate mandate so my responses are
> tediously at the top... 8-)
Ouch. I thought even Outlook had the option to change posting form.
> I guess the first question to ask is who or what are you actually protecting the
> laptop against, what is their level of commitment, and what on the laptop are you
> trying to protect.
If I choose to use encryption on my laptop then I want to be sure it
has a foundation rather than relying on attacker ability - otherwise
there's always a risk those government agents Alan mentioned will come
to rely upon something like this some day believing it to be safe
(because they're more than capable enough to leave these things in
London taxis :P).
> 1) You have set your laptop not to boot from CD etc, and protected that option with a
> "bios settings password".
That's useless though because someone can trivially get around that -
it's why I don't use BIOS passwords by default.
> 2) You are making intelligent decisions about "how secure" your computer needs to be.
Sure. In my case I don't currently do anything as the risk assessment
goes something like ``it hardly ever leaves my sight and I'm happy to
kick the guy trying to nick it if necessary''.
> 4) The system doesn't have to be "perfect" (because none are) it just has to be
> "better" than the amount of effort the attacker is willing to expend.
I just don't like the idea of designing something that's known to be
flawed - someone would publish a set of instructions for getting
around it. Just like you don't need to know how to create complex bus
analyzers to do funky stuff with the xbox now that's all been
published and made publically available.
My sole point here really is that it's worth asking for a password
that the user actually has to type in themself. It's trivial to do and
most users are more than happy to do it - you can tie the password in
to some function of their user password if necessary and set this all
up for suspend when they first login to their desktop. I don't see the
difficulty here.
> 10) A smart guy with a good soldering iron and an eprom burner and a bunch of time
> will be able to defeat any of this because he can simply read the memory of the live
> system by adding in any piece of hardware that can do a bus-fetch. (e.g. PCI
> bus-mastering etc).
But it'll be harder for him to defeat a system in which I've given a
password to login to my desktop which has been hashed and used to
encrypt the saved system state. I think Microsoft use the user
password as part of their EFS implementation - but in any case there's
no need for overkill when users are happy to type in a password on
login.
> In a system that never does a "resume" the meta-boot-block key generation tidbit
> never reaches the disk.
I care only about the part of the discussion relating to the save/restore cycle.
> During a system suspend, the "last thing" that happens is that the applet block is
> saved to the swap system in a known place.
> It is instantly and admittedly obvious that a person could take apart the computer
> and harvest this block and all the other regions of memory
So it's completely useless to me at least - I'd rather continue to use
nothing :-).
> CPU ID fetch: static means.
Luckily I don't have one of these in my laptop, but I do have a serial
number - so you'd need a generic mechanism for getting whatever unique
ID is available.
> On the other hand, for anything short of a really smart guy with a soldering iron, we
> now "know", as part of our restore, that we are using our CPU, our clock chip, our
> bios configuration (so, if set, our setup and our boot passwords) and our root file
> system and boot arguments (so no lilo-time override or installer disk).
So it's great for verifying a restore, but it's not secure :-).
> So with "just" a configuration change, the user may "switch" to the template that
> demands a password from the keyboard (and then reboot). Now you have moved up "one
> notch" in the world, but you haven't had to change your kernel out or anything.
Yes ok. That would be ok perhaps but it still sounds like massive overkill.
> The fact of the matter is that this is "broken glass" security and detection.
So it's not worth using anything more than Alan's suggestion of a
warning message - this is massive overkill when a simple password
prompt is fine for those wishing to encrypt or otherwise just give a
warning. I don't even bother with this because my laptop has a
hardware sleep that doesn't need to save memory state to disk, and the
average attacker will take one look at my laptop and they won't
possibly understand how to use it ;-).
My worry is that when you create ellaborate security systems that are
fundamentally flawed, then you get people believing they are more
secure than they really are. Yes that's a people problem but it's also
a good reason not to try to push this kind of idea too hard. Feel free
to implement it of course - I might even use the passphrase
configuration.
Cheers,
Jon.
-
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/
- Previous message: Dave Airlie: "Re: 2.6.9-rc2-mm4 drm and XFree oopses"
- In reply to: Robert White: "RE: mlock(1)"
- Next in thread: Lee Revell: "RE: mlock(1)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
