Message-ID: <e7d8f83e0808060657v6723510fma8ca6defbdbb65aa@mail.gmail.com>
Date:	Wed, 6 Aug 2008 23:57:52 +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 11:11 PM, Press, Jonathan <Jonathan.Press@...com> wrote:
> -----Original Message-----
> From: Peter Dolding [mailto:oiaohm@...il.com]
> Sent: Wednesday, August 06, 2008 8:39 AM
> To: Press, Jonathan
> Cc: Rik van Riel; Greg KH; Arjan van de Ven; Eric Paris;
> 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.
>
>
> [JON PRESS]  First of all, my examples were just hypothetical examples
> designed to set a context.  If they don't work, then don't take them too
> literally.
>
> Second, I'll try to put another way.  The disease analogy for computer
> viruses, though perhaps overused, actually goes a surprisingly long way.
> The kernel guys are like medical researchers, and the AV guys (or at
> least speaking for myself) are in Public Health.  You guys are looking
> at the human body (the computer) and looking for its low-level
> vulnerabilities and ways to protect against them.  We are working in the
> context of imperfect human behavior that often causes people to get sick
> in spite of the current state of medical knowledge, and occasionally
> causes things to get out of control.  Neither point of view is incorrect
> -- but each attacks a very different aspect of the problem.

We are not just kernel.  http://hal.freedesktop.org/docs/PolicyKit/
Is a good read.

Long term Linux design is basically Nuke the root user and protect the
core os providing restricted access.

So anti system core damage integrates outside kernel space.   We are
designing to limit how damaging that imperfect behavior is.

> And this goes right to the heart of the statement "prevention beats
> cure".  That's true in the long run, but it's not true if you're already
> sick -- or your neighbor is, and prevention is still a few years away.
>
> Third, regarding stating what we need, we actually already had a
> discussion about this several months ago, where we described this.  That
> discussion was the basis for Eric's proposal.  To give it some
> perspective, here is how I understand the flow of events.  As Eric
> described in his original posting this week, in the past many products
> (AV, along with others that have needed access to similar events --
> representatives of which have been participating in this discussion)
> have done their own tricks to get at i/o events that they need to
> trigger some action.  Many do this by modifying the syscall table.  We
> were told that this was going to become an invalid operation in a coming
> release of Red Hat Linux, and Red Hat offered to have a discussion with
> us on what could be done to offer us another way into the same
> information.  This seemed like a very positive direction to go in, and
> there was a discussion about what this alternative ought to look like.
> On the basis of this discussion, Eric then went off and worked on the
> design that he has presented.

> There was probably an implicit assumption on everyone's part, including
> Red Hat's, that what ought to be done was to replace the existing
> syscall-based event trapping with some other interface that more or less
> does the same thing in a cleaner way -- NOT to have all of the AV and
> other product vendors go out and completely rethink their models.  And
> that's not because we inherently object to rethinking.  It's really an
> issue of what kind of time frame we have before a new OS goes out that
> completely breaks our products.  Rethinking the entire model and
> developing all new products along different paradigms is not a bad thing
> to do, but it takes a lot of time.  Frankly we're always doing that in
> some way.  However, there is a more pressing problem at hand, and that's
> what Eric's spec is meant to solve.
>
You got to remember syscall trapping can be done for good and evil.

You use it to monitor actions another use it to do harm like steal data.

We need syscall trapping for debugging.  ptrace and the like.

Something important you are forgetting and its critical.  Windows gets
hell loads of overhead from Anti-Virus products.   Our LSM's already
provide overhead.  Duplication is not a way forwards.

Credentials  IBM patch provides a way to override filesystem
permissions so monitor and scan can be done there.

Tracing improvements lined 2.6.27 could be used to monitor
applications a AV is suspect of.

Capabilities restrict syscalls by blocks.

Question exactly why needing to monitor at the syscall level.   Really
why.   There are ways to monitor and restrict accesses without
dropping to that level.

Most likely the issue is that your models are broken.   Under windows
most anti-viruses copy the methods you would use to root kit a OS to
get there data.   Not working with the existing secuirty model.
Learning to work side by side with the LSM and other systems already
provided anti-virus companies are going to have to learn to do.   No
more of this hooking into the OS to get what you want.

Critical note on Linux.   Rootkits out number viruses and malware 20
to 1.   This is way different to your windows numbers.   So any method
that is Rootkit style will fail in time because that hole will have to
be closed.

My main issue is TALPA, dazuko and so on of Anti-Virus Filesystem
monitoring are all going to break anyhow when
http://lwn.net/Articles/251224/ Credentials get added and common
filesystem caching gets added.

You want to change a permissions on a file/object before its opened.
So does the Credential user space daemon on file systems that cannot
store secuirty information.  We only really need 1 location in the
source base for this.  Expand Credentials slightly to allow anti
viruses to operate by by problem.   Even better when FS-Cache can sit
on top of Credentials correctly no need for anti virus software to
have independent caching of blocked and allowed files.  FS-Cache picks
a large amount of this up.

Basically TALPA, dazuko and so on of Anti-Virus Filesystem monitoring
don't fit in the future design of Linux.   All they will be is
duplication of a existing interface.  A interface that complete avoids
the stacking issue.

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