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]
Date:	Wed, 19 Sep 2007 09:49:43 -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 19, 2007, at 08:16:30, Satyam Sharma wrote:
> [all sorts of crap about spies in washington needing stronger  
> protection than your average consumer]

Well no duh.  I think most of the 4-year-olds I know could have told  
you that.  What sense does it make to give a spy all sorts of fancy  
electronic listening and monitoring equipment and then rely on the  
physical security of your average Dell?  You _can_ make a laptop  
sufficiently secure that its data is encrypted and it cannot be  
physically compromised to install a hardware keylogger without  
virtually destroying the enclosure, but that's completely unnecessary  
for 99.99999% of the users on the planet.

We would be much better off if all the companies getting their data  
stolen out from under them on company laptops would just use basic  
drive encryption and implement basic physical-security training.   
*THAT* is where protecting the laptop is easy; all the bullcrap about  
foreign intelligence is just drawing focus off of how easy it is to  
achieve *adequate* physical protection where it matters.

 From a practical standpoint, an identity thief trying to determine  
which company to attack will just steal a few laptops from a company  
which doesn't encrypt them instead of going through all the very  
risky steps of trying to break into the laptops of one that does.

Of course, this also relies on being able to teach the stupid lusers  
with the laptops not to give their boot password to the "service tech  
on the phone"


>> If your system equates end-user with attacker
>
> "If"? Was there ever any doubt?
>
> Heh, did you even read the thread you just replied to?

Yes I did and I wanted to make it *really* clear that with average  
hardware you can properly protect against virtually all of the  
*common* attack vectors.  The pretty standard problems of "somebody  
stole the company laptop with a bunch of credit-card info on it" or  
"my personal financial data was on the laptop I left in the airport",  
are pretty easy to make safe.  Furthermore, that is *EXACTLY* the  
initial example I gave (my laptop with my personal data on it).


On the other hand, I made this point in my original email, so if this  
is what you were arguing about you've been preaching to the choir.

> We're talking of consoles / hardware sold by commercial companies  
> to  users here, where they want explicitly want to prevent the  
> users from  being able to hack it. So yes, end user == attacker.
>
>> then you are *screwed* regardless!
>
> Ah, finally you make my point again for me :-)


To quote myself again:
> 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.


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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ