Message-ID: <e7d8f83e0808060538m361eca9xa349fe08fdb20f12@mail.gmail.com>
Date:	Wed, 6 Aug 2008 22:38:33 +1000
From:	"Peter Dolding" <oiaohm@...il.com>
To:	"Press, Jonathan" <Jonathan.Press@...com>
Cc:	"Rik van Riel" <riel@...hat.com>, "Greg KH" <greg@...ah.com>,
	"Arjan van de Ven" <arjan@...radead.org>,
	"Eric Paris" <eparis@...hat.com>, linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org
Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to a linuxinterfaceforon access scanning

On Wed, Aug 6, 2008 at 10:10 PM, Press, Jonathan <Jonathan.Press@...com> wrote:
> -----Original Message-----
> From: Rik van Riel [mailto:riel@...hat.com]
> Sent: Tuesday, August 05, 2008 8:51 PM
> To: Press, Jonathan
> Cc: Greg KH; Arjan van de Ven; Eric Paris; linux-kernel@...r.kernel.org;
> malware-list@...ts.printk.net; linux-security-module@...r.kernel.org
> Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to a
> linuxinterfaceforon access scanning
>
> On Tue, 5 Aug 2008 14:38:23 -0400
> "Press, Jonathan" <Jonathan.Press@...com> wrote:
>
>> However, I will say that while preventing infections from arriving is
>> not foolproof, doing a scan-on-close with the option to delete or
>> quarantine an infected file goes a long way.
>
> How can you, as a security professional, argue for a security measure
> that you know is flawed, when there is a mailing list full of people
> willing to help figure out what a working security measure would look
> like?
>
> Yes, abandoning some of the old DOS anti-virus security model may cause
> work, but surely that will be worth it if it leads to a more secure
> system?
>
>
> [JON PRESS]  I hesitate to join back in the discussion, because so far I
> haven't been very successful.  I know that my level of technical depth
> is not at all the equal of just about everybody else in this
> conversation.  That's not my job and I don't claim to have the answers
> to all the questions that are being raised.
>
> However...  This question about arguing for a flawed security technique
> is a good one, and in a way it gets to the heart of the philosophy of
> security.  Scan-on-close is admittedly incomplete as an anti-virus tool.
> But I don't agree that that make it flawed.   It is part of a repertoire
> of techniques for preventing malware from residing on a machine.
>
> Let's take a simplistic and unrealistic example.  Let's suppose that you
> knew that there were 20 applications on your machine that had buffer
> overflow vulnerabilities that could be exploited, and you had a fix for
> 18 of them.  Would you decide not to apply the fixes, because that meant
> that there would still be 2 left -- and because theoretically there is a
> way to prevent all buffer overflows from being exploited and there is a
> mailing list full of people trying to figure out how to do it.
>
This buffer overflow risk and other equals are why LSM's exist.   It
put jails around applications so they cannot do any more than they are
meant to.   Its called risk reduction something that is most likely a
new idea to people coming from a windows background.   It also makes
exploiting a flawed applicaiton tricky.  Do something that application
should not normally do it will be blocked and trip the LSM alarm that
could be set to straight up terminate the offending application.   Yes
a true shot on sign of trouble system.  This is what you anti-virus
guys call behaviour monitoring same system some anti-virus software
uses to detect unknown viruses.

So 2 left should never happen since we have at least a part fix for
all of them.   This is how it has to work.   Failure is not a option
in our eyes.   If you have a percent missed that is a failure of there
is not something else to prevent damage.  We are not Windows users
with weak setup systems.   We don't want weak distributions out there.
 Nice if some anti-virus products started demanding a min standard LSM
to run side by side with them.

LSM's are already embedded core system exploitation prevention.

LSM currently don't extend deep enough into users to really tighten
completely down on the Users account.

So far I have not found a exact list of what is needed by AV or
Malware companies that say LSM stacking is needed.  That says stacked
LSM's are needed.

So I will bring a few things to the table.  Number one LSB is working
on a common packaging API using DBUS based off policy kit.   So
malware application installers run in users own account and to install
into the system have to go threw a scan able interface.   So far I
have not seen AV companies there working in improving the design.
Prevention beats cure.

This reduces a issue of malware to the Users own account without heavy
handed scanning.

So scanning becomes reduced to user editable files.

Linux firewall supports user mode modules so antivirus can scan
network traffic and use built in firewall to monitor for malware.

File scanning look no deeper than fusefs.
http://clamfs.sourceforge.net/.   Alter the automount system to wrap
this over the top of user mounted file systems and locations of user
editable and your are done.

Now credentials patch that has not got mainline yet also provides user
mode daemon support to override filesystem permissions.  Could also be
integrated into a Anti Virus Scanner.  credentials is not a LSM really
its centralisation of permission information so its no longer speed
all over the kernel.

There are sections in containers as well that could cover bits..

TPM segments appear in 2.6.27 as well that will also make a core
system breach harder.

Now please layout what you need Anti-Virus Companies.  Don't use
clueless desktop users as a reason.   Linux could already provide the
needed interfaces just not LSM.

Now please provide a detailed list of exactly what you need Anti-virus
companies.   Most likely everything you need already exists mainline
or in a development side line.  Extra coders to get some of those
features mainline would be good.



Peter Dolding


PS how to I get my email on the malware-list@...ts.printk.net  So it
does not bounce things to me.
--
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