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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 5 Aug 2008 14:04:26 -0400
From:	"Press, Jonathan" <Jonathan.Press@...com>
To:	"Arjan van de Ven" <arjan@...radead.org>,
	"Eric Paris" <eparis@...hat.com>
Cc:	"Greg KH" <greg@...ah.com>, <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 linux interfaceforon access scanning

I'm not sure if this is off the direct idea of this thread, or if I am
possibly missing the whole point.

However, I want to point out that scanning on close is still an integral
part of AV protection, even if intercepting opens and execs
theoretically catches everything.

You can say that there are four parts to the malware life cycle --
getting on a machine, residing there, causing local damage, and
propagating elsewhere.  It is part of the philosophy of AV protection
that you do everything you can to prevent all of them.  That's why there
are scans on close, scheduled scans, and scans on open.  Most of our
users employ all three and do not rely on one or two.  If an infection
arrives on a machine and finds a home because it is assumed that it will
be caught when it is opened for use, then it is just one more compromise
away from doing damage and/or spreading.

Jon Press

-----Original Message-----
From: Arjan van de Ven [mailto:arjan@...radead.org] 
Sent: Tuesday, August 05, 2008 1:39 PM
To: Eric Paris
Cc: Press, Jonathan; Greg KH; 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 linux
interfaceforon access scanning

On Tue, 05 Aug 2008 13:19:56 -0400
Eric Paris <eparis@...hat.com> wrote:

> If you can outline the design of a better method that meets your needs
> I'd be glad to try to code it.  In your mind how do you see programs
> being able to exclude others while not being a security risk? 

ok so lets be specific.
You are trying to prevent an application from opening a "damaged" file,
or from someone starting a "damaged" file.
You are not trying to prevent anything once you have executed a damaged
file; once you execute one of these for this part it's game over (to
limit the damage other tools like selinux exist, but are outside the
scope of talpa).

So... as long as /sbin/init isn't compromised... intercepting exec and
open (in all variants) is all you need.

And this can be done from userland with the preload: the "workaround"
from the preload assumes you've already executed malicious code, which
is outside of your protection scope.

What am I missing?

-- 
If you want to reach me at my work email, use arjan@...ux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

--
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/