Re: NFS4 authentification / fsuid

Kyle Moffett
2007-09-07T05:49:39Z

On Sep 07, 2007, at 01:14:09, Trond Myklebust wrote:
> On Thu, 2007-09-06 at 20:56 -0400, Kyle Moffett wrote:
>> Umm, I did say "encrypt the root filesystem", didn't I? Booting
>> my laptops 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.
>>
>> [...] the only avenues of attack are strictly of the "Install a
>> hardware keylogger" variety.
>
> So an attacker will instead install a hardware keylogger, or swap
> out your boot cdrom with a compromised but almost identical boot
> cdrom instead, or mod your bios, ...
>
> A fully self-certifying system that can prevent any attack is
> _very_ hard to achieve. Just ask apple (iPhone) or any games
> console vendor...

A fully self-certifying system that can prevent any attack is
impossible to achieve. If I have the device and can devote as many
hours as I want to breaking into it, there is exactly ZERO way to
prevent that, aside from encrypting things and not giving out the key
(which sorta makes it useless but is precisely the point of real
crypto).

There is a HUGE difference between "I don't want the end-user to hack
into this" and "The end-user wants a certain degree of assurance that
his data can't be compromised. In the former case (IE: DRM) you are
NOT using cryptography because you are giving the user: (A) the data,
(B) the algorithm, and (C) the key, which means they can decrypt it
ANY TIME THEY WANT. In the latter case the attacker DOES NOT have
the key and virtually all of the attacks forms of "How do I get the
key?". The end-user is REQUIRED to provide an appropriate level of
physical security based on the nature of the data; If I'm that
worried about somebody substituting my /boot CD, then I'm going to
make DAMN sure that I keep it on my person at all times.

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.

Cheers,
Kyle Moffett