Re: thoughts on kernel security issues

[Norbert van Nobelen]

On Thursday 13 January 2005 19:59, you wrote:
> Linus Torvalds wrote:
> > On Thu, 13 Jan 2005, Alan Cox wrote:
> >>On Iau, 2005-01-13 at 16:38, Linus Torvalds wrote:
>
> [...]
>
> > Am I claiming that disallowing self-written ELF binaries gets rid of all
> > security holes? Obviously not. I'm claiming that there are things that
> > people can do that make it harder, and that _real_ security is not about
> > trusting one subsystem, but in making it hard enough in many independent
> > ways that it's just too effort-intensive to attack.
>
> I think you can make it non-guaranteeable.
>
> > It's the same thing with passwords. Clearly any password protected system
> > can be broken into: you just have to guess the password. It then becomes
> > a matter of how hard it is to "guess" - at some point you say a password
> > is secure not because it is a password, but because it's too _expensive_
> > to guess/break.
>
> You can't guarantee you can guess a password.  You could for example
> write a pam module that mandates a 3 second delay on failed
> authentication for a user (it does it for the console currently; use 3
> separate consoles and you can do the attack 3 times faster).  Now you
> have to guess the password with one try every 3 seconds.

Already done, actually standard practice. This does not mean actually that you 
can not guess a password, just that it will take longer (on average).
Luck and some knowledge about the system and people speeds up the process, so 
the standard procedure if you really want to get into a system with a 
password is to get information.


>
> aA1# 96 possible values per character, 8 characters.  7.2139x10^15
> combinations.  It takes 686253404.7 years to go through all those at one
> every 3 seconds.  You've got a good chance at half that.
>
> This isn't "hard," it's "infeasible."  I think the idea is to make it so
> an attacker doesn't have to put lavish amounts of work into creating an
> exploit that reliably re-exploits a hole over and over again; but to
> make it so he can't make an exploit that actually works, unless it works
> only by rediculously remote chance.
>
> > So all security issues are about balancing cost vs gain. I'm convinced
> > that the gain from openness is higher than the cost. Others will
> > disagree.
>
> Yes.  Nobody code audits your binaries.  You need source code to do
> source code auditing.  :)
>
> > 		Linus
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> > in the body of a message to majordomo@xxxxxxxxxxxxxxx
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/

-- 
<a href="http://www.edusupport.nl";>EduSupport: Linux Desktop for schools and 
small to medium business in The Netherlands and Belgium</a>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/