* Quoting Mikko Rapeli ([EMAIL PROTECTED]): > On Fri, Sep 01, 2006 at 06:56:17PM -0400, Michael Stone wrote: > > On Sat, Sep 02, 2006 at 12:28:17AM +0300, Mikko Rapeli wrote: > > >- can a process running vulnerable code be exploited to not show the > > > shared libraries and other non-shared libraries and files it had opened > > > for reading at some point? > > > > Of course it can. And that's irrelevant to the question at > > hand--installing a security update at that point isn't going to help. > > 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?
The problem here is that when the software has been exploited already, installing the security update doesn't fix the problem anymore. > When an admin takes the chance and trusts lsof, that's fine. If low > privilege process starts spamming the world he'll propably notice. But if > making these upgrades effective is ever automated, I wouldn't like to take > that chance. True, but in the example from above it's too late for that. - Rolf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]