RE: [malware-list] [RFC 0/5] [TALPA] Intro to a linuxinterfaceforon access scanning

[Press, Jonathan]

-----Original Message-----
From: Peter Dolding [mailto:oiaohm@xxxxxxxxx] 
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@xxxxxxxxxxxxxxx; linux-security-module@xxxxxxxxxxxxxxx
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@xxxxxx>
wrote:
> -----Original Message-----
> From: Rik van Riel [mailto:riel@xxxxxxxxxx]
> Sent: Tuesday, August 05, 2008 8:51 PM
> To: Press, Jonathan
> Cc: Greg KH; Arjan van de Ven; Eric Paris;
linux-kernel@xxxxxxxxxxxxxxx;
> malware-list@xxxxxxxxxxxxxxxx; linux-security-module@xxxxxxxxxxxxxxx
> 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@xxxxxx> 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.

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.


Jon

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/