Message-ID: <e7d8f83e0808130408q1a1a4d27occ265902a16cbc5@mail.gmail.com>
Date:	Wed, 13 Aug 2008 21:08:20 +1000
From:	"Peter Dolding" <oiaohm@...il.com>
To:	"Press, Jonathan" <Jonathan.Press@...com>
Cc:	"Pavel Machek" <pavel@...e.cz>, davecb@....com,
	"Arjan van de Ven" <arjan@...radead.org>,
	"Mihai Don??u" <mdontu@...defender.com>,
	"Adrian Bunk" <bunk@...nel.org>, tvrtko.ursulin@...hos.com,
	"Greg KH" <greg@...ah.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 Wed, Aug 13, 2008 at 8:46 PM, Press, Jonathan <Jonathan.Press@...com> wrote:
>> -----Original Message-----
>> From: Pavel Machek [mailto:pavel@...e.cz]
>> Sent: Wednesday, August 13, 2008 6:28 AM
>> To: Press, Jonathan
>> Cc: davecb@....com; Arjan van de Ven; Mihai Don??u; Adrian Bunk;
>> tvrtko.ursulin@...hos.com; Greg KH; 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
>>
>> > I think everyone understands one side of the threat model, that is
> Linux machines
>> being carriers of infections aimed at other platforms.  There are many
> ways that
>> such infections can be stored, and many ways in which they can be
> communicated
>> to the target machines.  There are so many that it would not be
> effective or efficient
>> for each such transfer application to be able to handle its own
> malware scanning,
>> which is the short statement of why centralized AV protection with
> notification
>> assistance from the kernel is appropriate.
>> >
>>
>> No.
>>
>> Proposed kernel solution did not work -- there still was write
>> vs. read race. You are right that it is not ok for each application to
>> do its own malware scanning, but libmalware.so that handles the
>> scanning seems very reasonable.
>>
>> And as applications _need_ to be modified for the write vs. read race
>> to be solved, libmalware.so looks like a way forward.
>>
> Pavel
>
> I am not sure what you are suggesting, and I may have missed the
> libmalware proposal (I don't see any mention of that specific idea in
> any other message).  However, just to be clear...  At no point did we
> suggest that the kernel would do any scanning.  What we have been
> interested in is a mechanism that can allow a scanning application to be
> notified by the kernel of specific i/o events, for those events to be
> blocked by the kernel until a user-space scan is done, and then the
> user-space scan sends back allow or deny, at which point the i/o event
> returns to the caller -- either success or error.  This is the only way
> that malware can be guaranteed of being detected when it is used (for
> local application purposes or for transmission to another platform) or
> created.
>
> Also, a solution that requires applications to be modified will not
> work, because there is no way that we would be able to get ALL
> applications on the machines to be modified in the required ways.  If
> ANY applications are not so modified, then you have an unacceptable
> malware hole.  The only solution that really works is one that
> guarantees that all applications are involved, which is why the kernel
> has to be involved in some way.  It's the only centralized authority
> that can stick its nose into all of the required activities.
>
> Whether the specific proposal currently on the table handles all the
> issues or not is to me a separate point.

Being in the correct place is key.   Wrong place more issues more holes.

Lets get this right this time please.  Windows is a mess.   You cannot
run many av products side by side.    Due to failures of signatures at
times to pickup every threat out there we have to move forward with a
system that works.  Supporting many scanners at once if needed.

LIM guys are going after the same kind of defect detection.

Lot of designs have been created over all the years but they have all
failed to address the basics.

Scanning without file caching leaves a hole and costs cpu time.  So
integration into the file system cache system is kinda key.

Designing hooks forcing users to use only 1 product.   Yes good for
market lock in but kicks lots people in teeth.

Getting patch mainline is basically going to hit walls if you don't
sit down and say lets fix the kernel secuirty correctly.   This is not
windows you have the power to alter the complete kernel if you can
provide valid justification for the change.

Valid justification is that someone like me looks at it and cannot
find a flaw in design and it provides needed functionality.  Issue you
keep on addressing only 1 this is the reason why the patches have
stayed out side mainline when other patches have got in.   In theory
the complete core of the Linux kernel could be replaced if Valid
justification could be made.

This is where Linux is different to Windows.   You are free to
redesign linux to be the hardest OS on earth for a virus to operate.
Where windows you have to work with provided model.   Lots here need
to drop the idea that anything in the Linux kernel is set in stone.
Only thing set in stone flawed designed get shot down.

Lets start with what would the features you would wish for as
Anti-virus designers if you could design a OS from scratch around your
Anti-virus so it was almost flawless.   From that list we have what we
need to work on to give you exactly what you want in time.   Even
better post that on a long term website as a wishlist for all OS's.
Basically give us direction.

Peter Dolding
--
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