linux-kernel - Re: [malware-list] [RFC 0/5] [TALPA] Intro to alinuxinterfaceforon 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:	Mon, 18 Aug 2008 00:10:15 +0200
From:	Pavel Machek <pavel@...e.cz>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Theodore Tso <tytso@....edu>, Rik van Riel <riel@...hat.com>,
	"Press, Jonathan" <Jonathan.Press@...com>, davecb@....com,
	Adrian Bunk <bunk@...nel.org>,
	Mihai Don??u <mdontu@...defender.com>,
	linux-kernel@...r.kernel.org, malware-list@...ts.printk.net,
	linux-security-module@...r.kernel.org,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to alinuxinterfaceforon access scanning

> > So if that is the threat model, then the only thing libmalware.so
> > doesn't solve is knfsd access, and it should be evaluated on that
> 
> And static binaries, and other kernel modular file I/O done on behalf of
> applications, and making a library work well which is *hard*, and
> labelling and scalability, and sharing a cache between users, and
> aggregating events across processes .. and a few other things.

Well, I believe libmalware.so works with threat model I described; of
course it will not protect statically linked sambad (unless you
statically link it with libmalware.so, which you should do). I'm not
actually advocating LD_PRELOAD. There are enough userspace nfsds
around, but yes, you can't use libmalware.so with knfsd. 

[You could do something like fuse filesystem linked with libmalware,
and make knfsd export that, and put applications you can't link with
libmalware to use that. But that's a _hack_.]

> There seem so far to be two independent requests
> 
> * Noticing a file has recently changed, possibly with information about
> changes and possibly being able to aggregate/time that for scalability.
> This has a need to be able to accurately reference which file. This is
> needed for good content indexing, and virus people want it for certain
> kinds of scanning (post write, background etc). Doing this solely as a
> final close notifier seems to be insufficient (as it may never
> close).

Agreed, we need this.

> * Being able to pause an open pending some action. Examples include HSM
> and dubiously some kinds of virus check. Problems here include the fact
> it can only meaningfully be done for first open (which is fine for HSM)
> and that the notion of an exclusive open, or of repeated clearly defined
> open/read-write/close/done sequences are actually quite foreign to Unix
> like systems.

Do HSMs really get implemented like that? I'd expect HSM to be
something like fuse or unionfs... and when it is confined to one
filesystem, you can use existing solutions.

I don't like blocking at open at all, and I don't think blocking at
open is enough for antivirus scanner.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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/