[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200808070349.55882.mdontu@bitdefender.com>
Date: Thu, 7 Aug 2008 03:49:55 +0300
From: Mihai Donțu <mdontu@...defender.com>
To: Adrian Bunk <bunk@...nel.org>
Cc: tvrtko.ursulin@...hos.com, Arjan van de Ven <arjan@...radead.org>,
Greg KH <greg@...ah.com>,
"Press, Jonathan" <Jonathan.Press@...com>,
linux-kernel@...r.kernel.org,
linux-security-module@...r.kernel.org,
malware-list@...ts.printk.net
Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to a linuxinterfaceforon access scanning
On Wednesday 06 August 2008, Adrian Bunk wrote:
> On Wed, Aug 06, 2008 at 12:07:57PM +0100, tvrtko.ursulin@...hos.com wrote:
> > Adrian Bunk <bunk@...nel.org> wrote on 06/08/2008 11:50:08:
> > > As an observer of this thread:
> > >
> > > - Some set of requirements suddenly appears out of the void on
> > > linux-kernel.
> >
> > Because previously it was said to go away and come back with a clear list
> > of requirements. And here you make it sound like a negative thing. See
> > what I am talking about?
>
> Both of my points belong together.
>
> > > - Noone is able and/or willing to exactly describe the problem(s) they
> > > are trying to solve.
> >
> > Hopefully we will get there. Very little time has passed since the
> > discussion has started, even less considering the time zone difference
> > for some.
> >
> > > With this status quo the discussion is going nowhere - Linux kernel
> > > development does not work this way.
> > >
> > > The aim is not to include this code, but to find the best technical
> > > solution for your problem(s) - no matter whether this will have
> > > anything in common with the list of requirements and the code posted or
> > > not.
> >
> > I completely agree with that. Here I was just pointing out that what Greg
> > wrote was untrue and exaggerated so not helping the discussion at all.
>
> Until now the main discussion participant from the AV side is
> Jonathan Press.
Well, if you insist, but I must state that this mail represents my own opinion
and not my employer's (that's because all the people I could consult with are
sleeping :) ).
> But the real discussion hasn't even started since the information
> required is not available.
>
> And as soon as the information for the real discussion is available all
> these initial discussions become irrelevant.
> - Noone is able and/or willing to exactly describe the problem(s) they
> are trying to solve.
Well, here is one attempt.
A good percentage of an AV product's job is to prevent exploitation of a
security hole in a product before the vendor (assuming the vendor admits it's
bug and not a misuse of the product's features).
Most distribution makers go through a lot of work before releasing an update,
which might take days. Add to this the fact that some users refuse to update
periodically (because one operating system out there shattered the belief in
this practice) and that some of them are willing to pay to not care. This is
reason enough for most AV vendors.
In the present, on the Linux Desktop, this is [still] hypothetical talk and
God help it will remain so. However, if there is one incredibly small chance
that one (new?) type of malware can spread to a large number of users, then
AV vendors will race for creating a solution because there will _definitely_
be people needing help with this (please notice that the IQ scale starts from
zero and not from 130 :) ).
I think this patch is trying to do what dazuko hasn't managed to do (yet): get
into mainline. :)
--
Mihai Donțu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists