[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1289149866.2816.69.camel@localhost>
Date: Sun, 07 Nov 2010 17:11:06 +0000
From: Ben Hutchings <ben@...adent.org.uk>
To: Oliver Hartkopp <socketcan@...tkopp.net>
Cc: David Miller <davem@...emloft.net>, torvalds@...ux-foundation.org,
drosenberg@...curity.com, chas@....nrl.navy.mil,
kuznet@....inr.ac.ru, pekkas@...core.fi, jmorris@...ei.org,
yoshfuji@...ux-ipv6.org, kaber@...sh.net,
remi.denis-courmont@...ia.com, netdev@...r.kernel.org,
security@...nel.org
Subject: Re: [Security] [SECURITY] Fix leaking of kernel heap addresses via
/proc
On Sun, 2010-11-07 at 11:28 +0100, Oliver Hartkopp wrote:
[...]
> The layout break was ok in this case as the people using the CAN procfs stuff
> do this only when facing problems (with their applications) at runtime.
>
> A discussed approach that won't break the procfs layout was to set the values
> to "0" and only fill them with real content depending on CONFIG_DEBUG_INFO .
>
> Would that fit here?
>
> Or maybe a different config option CONFIG_DEBUG_KERNEL_ADDR would do the job,
> as i don't know which distros enable CONFIG_DEBUG_INFO by default ...
I believe most distributions now enable CONFIG_DEBUG_INFO (though the
debug information is then stripped and shipped in separate packages). I
also dislike this idea of an implicit trade-off between debugging and
security; such a trade-off may be necessary but then it should be
explicit.
Ben.
--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)
Powered by blists - more mailing lists