linux-kernel - Re: [malware-list] [RFC 0/5] [TALPA] Intro to a linuxinterfaceforon 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]

Message-ID: <20080805133832.220d71c7@infradead.org>
Date:	Tue, 5 Aug 2008 13:38:32 -0700
From:	Arjan van de Ven <arjan@...radead.org>
To:	"Press, Jonathan" <Jonathan.Press@...com>
Cc:	"Greg KH" <greg@...ah.com>, "Eric Paris" <eparis@...hat.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 linuxinterfaceforon
 access scanning

On Tue, 5 Aug 2008 16:15:32 -0400
"Press, Jonathan" <Jonathan.Press@...com> wrote:

> 
> > Also, it seems to me that for my purposes, close is discrete enough.
> It
> > tells me that there is now something out there that should be looked
> at.
> 
> So, if you hook glibc to catch all calls to close, is that sufficient?
> 
> [JON PRESS]  Let's see...I'm going to use inotify for some events,
> glibc for others, and this API for the rest.  Would you really want
> to write an application like that?

so you have to do 2 cases:

1) inotify to notice files changing
 (no need to hook glibc for that, and no need to hook close() since you
 already get a notify for the change)

This is to catch the *creation* of "bad" content (say a browser saving a
download or somesuch)

By nature this is asynchronous for both performance and "what could you
do if" reasons.
(but so would the close() scan be, and again please explain how you
deal with write-to-mmap-after-close)

2) A synchronous check on open() or exec()

This is to prevent *use* of "bad" content, either by an application
opening a bad file, or by executing a "bad" program. 

For neither do you need to hook the kernel; ld preload works great for
this. 

This does assume that at some point you have a transition from "ok"
program to the first time you run a "bad" one (via exec or open); and
that you catch it at that point.

I don't yet buy the argument "but what if the virus corrupted your ld
preload", because if it can do that your own virus scanner is also
corrupted.

Can you explain what gap is left after you do these two things?

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