linux-kernel - Re: NFS4 authentification / fsuid

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <3BBEDBBC-FD71-4A6F-81B3-EC0978A37024@mac.com>
Date:	Fri, 7 Sep 2007 01:47:28 -0400
From:	Kyle Moffett <mrmacman_g4@....com>
To:	Trond Myklebust <trond.myklebust@....uio.no>
Cc:	"J. Bruce Fields" <bfields@...ldses.org>,
	Satyam Sharma <satyam@...radead.org>,
	Jan Engelhardt <jengelh@...putergmbh.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: NFS4 authentification / fsuid

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
-
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/