lkml.org 
[lkml]   [2007]   [Sep]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: NFS4 authentification / fsuid
Date
On Sep 18, 2007, at 19:44:59, Satyam Sharma wrote:
> On Thu, 6 Sep 2007, Kyle Moffett wrote:
>> On Sep 06, 2007, at 19:35:14, Trond Myklebust wrote:
>>> On Thu, 2007-09-06 at 19:30 -0400, Kyle Moffett wrote:
>>>> On Sep 06, 2007, at 11:06:16, J. Bruce Fields wrote:
>>>>> The question of how to protect against someone with *physical*
>>>>> access certainly is more difficult, but surely that's a
>>>>> separate problem.
>>>>
>>>> Actually, that's a fairly simple problem (barring disassembling
>>>> the system and attaching a hardware debugger). You encrypt the
>>>> root filesystem and require a password to boot (See: LUKS).
>>>> Debian has built-in support for installing onto fs-on-LVM-on-
>>>> crypt-on-RAID, and it works quite well on all the laptops I use
>>>> regularly. It's not even much of a speed penalty; once you take
>>>> the overhead of hitting a 5400RPM laptop drive you can chew
>>>> thousands of cycles of CPU without anybody noticing (much).
>>>> Then all you have to do is burn a copy of your /boot with
>>>> bootloader onto some read-only media (like a finalized CDROM/
>>>> DVDROM) and you're set to go.
>>>
>>> Disconnect battery, and watch boot password go 'poof!'.
>>
>> Umm, I did say "encrypt the root filesystem", didn't I? Booting
>> my laptops
>
> The whole *point* here is to secure against physical access -- then
> how can you assume "barring disassembling the system"? If you're
> not considering attacks such as those, then how _are_ you solving
> the physical access problem in the first place? :-)

Security is about fractional reduction of risk, and anybody who tells
you otherwise is either ignorant or lying through their teeth. There
are *multiple* aspects of "physical access"; one of those is access
while the box is off and no data resident in volatile memory, which
is the easy case. Basically there you can just encrypt the non-
volatile storage. If the system is *on* and has unencrypted data in
memory (such as suspend-to-RAM for example) then you *HAVE* to ensure
that it can't be easily disassembled and a hardware debugger
attached; there is no way around that very fundamental limitation.

Basically if the key is resident and unencrypted as is necessary to
*USE* the system, then no amount of hardware is going to *prevent* a
dedicated attacker from getting at it unless you make it so
unportable that you don't have to worry about somebody carrying it
off in the first place. Typical mechanisms to increase the time and
effort to break into a device include wiring the entire enclosure
with extremely thin filament wires and detecting automatically wiping
the system upon any variation in a small flow of current through said
filament.

>> this way follows this procedure:
>> 1) Enter BIOS boot menu
>> 2) Insert /boot CDROM
>> 3) Select the "CDROM" entry
>> 4) Wait for kernel to start and run through initramfs
>> 5) Type password into the initramfs prompt so that it can DECRYPT
>> THE ROOT FILESYSTEM
>> 6) Continue to boot the system.
>>
>> Under this setup, tinkering with my BIOS does virtually nothing;
>> the only avenues of attack are strictly of the "Install a hardware
>> keylogger" variety.
>
> Doesn't flashing/replacing your BIOS firmware/chip count as
> tinkering? Then I don't really need a "hardware keylogger", do I ...

Ok, so you are saying your plan of attack on this system would be:
1) Steal the laptop such that I don't notice it has been stolen
2) Open it up
3) Replace the very-vendor-specific BIOS chip with a reflashed
one with sufficient storage to do all the things the old BIOS could
*AND* have enough storage for an entire replacement kernel binary
with a built-in keylogger, as well as some storage for the logged
password
4) Return the laptop, again such that I don't notice it has been
missing
5) Wait for me to boot and type my password
6) Somehow recover the laptop *yet* *again* to get the password
back off of it and decrypt the disk

Yes it "can be done", but so can dumping the firmware for an iPod out
through the built-in piezo clicker[1]. USE SOME COMMON SENSE HERE
PEOPLE!!! The only "unbreakable" computer is one always disconnected
and off under armed guard in a bank vault, and even then it's only as
secure as the bank in which it is stored (which get broken into on
occasion).

I am assuming that if the laptop has sufficiently important data on
it to warrant the above steps then I am also clueful enough to:
(A) Not carry the laptop around unsecured areas,
(B) Keep a close enough eye on it and be aware that it's gone by
the time they get to step 2, OR
(C) Pay somebody to build me a better physical chassis for my laptop

We are talking about *STANDARD* laptop systems with reasonably alert
users. If the user doesn't know how to properly protect the stuff on
the laptop then they probably don't know how to properly protect the
other copy in their heads, either. Besides, if some government
wanted the data on your laptop that bad they'd just pick you up in
the middle of the night and torture your password out of you.

On Sep 18, 2007, at 19:48:16, Satyam Sharma wrote:
> On Fri, 7 Sep 2007, Kyle Moffett wrote:
>> So you can't draw any relationships between "Protect the end-user"
>> with "Protect the device FROM the end-user", the former can be
>> done very reliably to whatever level of risk-reduction you need
>> and the latter can't practically be done at all.
>
> Well, you're the one who called solving the physical access problem
> "easy" here ... :-)

If your system equates end-user with attacker then you are *screwed*
regardless! If you give the end-user the tools that they need to use
the system, then they can just as easily hack into it, *END* *OF*
*STORY*. See The _only_ way to protect data on a piece of hardware
is with the _assistance_ of the end-user; they have to be alert and
aware of potential threats and act to protect from them.

Cheers,
Kyle Moffett

[1] http://hardware.slashdot.org/article.pl?sid=05/01/29/2017244
-
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: 2007-09-19 07:19    [W:3.013 / U:0.228 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site