Re: When are security updates effective?

[paddy <paddy@panici.net>]

On Mon, Sep 04, 2006 at 09:15:45AM +0300, Mikko Rapeli wrote:
> On Sat, Sep 02, 2006 at 10:37:04AM +0200, Rolf Kutz wrote:
> > * Quoting Mikko Rapeli (mikko.rapeli@iki.fi):
> > > I think it is relevant: should the effectiveness actions in general 
> > > be based on the host where the update was applied through lsof, package 
> > > dependencies provided and digitally signed by Debian, some other information
> > > provided and digitally signed by the Debian security team in an
> > > advisory or something else?
> 
> Or package installation scripts provided by the package maintainer.
> 
> > The problem here is that when the software has
> > been exploited already, installing the security
> > update doesn't fix the problem anymore.
> 
> Exploited to what extend? Without stack protection, address space
> randomization, selinux etc, it's very difficult to know wether a
> processes address space has been violated. And non-privileged processes
> don't have write access to binary files on the system without additional
> local root holes.
> 
> My point is: lsof may not be trustworthy on per host basis when making
> security updates effective. The time between security bug publication and
> applying the updates varies too much. If a Linux distro can do better
> than Windows and not require full reboot after every update, I'd like to
> see a confirmation of the steps required to make the update effective
> from a source I trust anyway.

So you could have some system of compartments, where if there was a breach
in a compartment you could sanitise the compartment?  To take a more 
concrete example, suppose it's an ordinary user running a web browser in
their ordinary account, and a vulnerability is found in that browser, and
running instances must be assumed exploited.  Sounds like you're saying 
that lsof, even if the binary itself can be assumed sound, relies on data
from the compartment which could be compromised and so it's output for
the use you suggest cannot be completely trusted.  Seems to me that there
are plenty of other problems getting to a compartment you can sanitise
effectively, like the possibility of an exploit to persist via
filesystem and hooks like cron or .profile, no ? but I like the idea.

Regards,
Paddy
-- 
Perl 6 will give you the big knob. -- Larry Wall