Message-Id: <A5318C25-7864-453A-B09A-00232D9EAF2A@mac.com>
Date:	Wed, 19 Sep 2007 01:16:28 -0400
From:	Kyle Moffett <mrmacman_g4@....com>
To:	Satyam Sharma <satyam@...radead.org>
Cc:	Trond Myklebust <trond.myklebust@....uio.no>,
	"J. Bruce Fields" <bfields@...ldses.org>,
	Jan Engelhardt <jengelh@...putergmbh.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: NFS4 authentification / fsuid

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists