Re: thoughts on kernel security issues

[linux-os]

On Tue, 25 Jan 2005, John Richard Moser wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Dmitry Torokhov wrote:
> > On Tue, 25 Jan 2005 13:37:10 -0500, John Richard Moser
> > <nigelenki@xxxxxxxxxxx> wrote:
> >
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > >
> > > Linus Torvalds wrote:
> > >
> > > > On Tue, 25 Jan 2005, John Richard Moser wrote:
> > > >
> > > >
> > > > > It's kind of like locking your front door, or your back door.  If one is
> > > > > locked and the other other is still wide open, then you might as well
> > > > > not even have doors.  If you lock both, then you (finally) create a
> > > > > problem for an intruder.
> > > > >
> > > > > That is to say, patch A will apply and work without B; patch B will
> > > > > apply and work without patch A; but there's no real gain from using
> > > > > either without the other.
> > > >
> > > >
> > > > Sure there is. There's the gain that if you lock the front door but not
> > > > the back door, somebody who goes door-to-door, opportunistically knocking
> > > > on them and testing them, _will_ be discouraged by locking the front door.
> > >
> > > In the real world yes.  On the computer, the front and back doors are
> > > half-consumed by a short-path wormhole that places them right next to
> > > eachother, so not really.  :)
> >
> >
> > Then one might argue that doing any security patches is meaningless
> > because, as with bugs, there will always be some other hole not
> > covered by both A and B so why bother?
>
> I'm not talking about bugs, I'm talking about mitigation of unknown bugs.
>
> You have to remember that I think mostly in terms of proactive security.
> If there's a buffer overflow, temp file race condition, code injection
> or ret2libc in a userspace program, it can be stopped.  this narrows
> down what exploits an attacker can actually use.
>
> This puts pressure on the attacker; he has to find a bug, write an
> exploit, and find an opportunity to use it before a patch is written and
> applied to fix the exploit.  If say 80% of exploits are suddenly
> non-exploitable, then he's left with mostly very short windows that are
> far and few, and thus may be beyond his level of UNION(task->skill,
> task->luck) in many cases.
>
> Thus, by having fewer exploits available, fewer successful attacks
> should happen due to the laws of probability.  So the goal becomes to
> fix as many bugs as possible, but also to mitigate the ones we don't
> know about.  To truly mitigate any security flaw, we must make a
> non-circumventable protection.

So you intend to make so many changes to the kernel that a
previously thought-out exploit may no longer be workable?

A preemptive strike, so to speak? No thanks, to quote Frank
Lanza of L3 communications; "Better is the enemy of good enough."

> If you can circumvent protection A by simply using attack B* to disable
> protection A to do more interesting attack A*, then protection A is
> smoke and mirrors.  If you have protection B that stops B*, but can be
> circumvented by A*, then deploying A and B will reciprocate and prevent
> both A* and B*, creating a protection scheme that can't be circumvented.

It makes sense to add incremental improvements to security as
part of the normal maturation of a product. It does not make
sense to dump a new pile of snakes in the front yard because
that might keep the burglars away.

> In this context, it doesn't make sense to deploy a protection A or B
> without the companion protection, which is what I meant.  You're
> thinking of fixing specific bugs; this is good and very important (as
> effective proactive security BREAKS things that are buggy), but there is
> a better way to create a more secure environment.  Fixing the bugs
> increases the quality of the product, while adding protections makes
> them durable enough to withstand attacks targetting their own flaws.

Adding protections for which no known threat exists is a waste of
time, effort, and adds to the kernel size. If you connect a machine
to a network, it can always get hit with so many broadcast packets
that it has little available CPU time to do useful work. Do we
add a network throttle to avoid this? If so, then you will hurt
somebody's performance on a quiet network. Everything done in
the name of "security" has its cost. The cost is almost always
much more than advertised or anticipated.

> Try reading through (shameless plug)
> http://www.ubuntulinux.org/wiki/USNAnalysis and then try to understand
> where I'm coming from.

This isn't relevant at all. The Navy doesn't have any secure
systems connected to a network to which any hackers could connect.
The TDRS communications satellites provide secure channels
that are disassembled on-board. Some ATM-slot, after decryption
is fed to a LAN so the sailors can have an Internet connection
for their lap-tops. The data took the same paths, but it's
completely independent and can't get mixed up no matter how
hard a hacker tries.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips).
 Notice : All mail here is now cached for review by Dictator Bush.
                 98.36% of all statistics are fiction.
-
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/