From: tvrtko.ursulin@sophos.com
To: Theodore Tso <tytso@MIT.EDU>
Cc: Arjan van de Ven <arjan@infradead.org>,
"Press, Jonathan" <Jonathan.Press@ca.com>,
linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org,
malware-list@lists.printk.net, Rik van Riel <riel@redhat.com>
Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to a linuxinterfaceforon access scanning
Date: Wed, 6 Aug 2008 16:54:19 +0100 [thread overview]
Message-ID: <20080806155513.25BA137659D@pmx1.sophos.com> (raw)
In-Reply-To: <20080806152236.GE14109@mit.edu>
Theodore Tso <tytso@MIT.EDU> wrote on 06/08/2008 16:22:36:
> On Wed, Aug 06, 2008 at 03:16:02PM +0100, tvrtko.ursulin@sophos.com
wrote:
> >
> > You can't do something like inotify("/") (made up API) but you have to
set
> > up a watch for every directory you wan't to watch. That seems like a
waste
> > of resources.
> >
> > Then you get back a file name, if you wan't to report it or attempt*
to
> > scan it you have to build a pathname yourself, which means you have to
> > maintain the whole tree of names in memory. Even bigger waste.
>
> Yes, it would be nice if inotify gave you back a full pathname and
> where a single watch would return all changes anywhere in the
> filesystem tree. I'd recommend that folks try to create such a patch.
I will have a brief look to familiarise myself with inotify
implementation. So maybe, but even if that solves only one
sub-requirement.
> > When I say attempt to scan it above I mean that we are back into the
> > pathanme teritorry. It is not guaranteed we will be able to open and
scan
> > using that pathname. I don't know what inotify reports with chroots
and
> > private namespaces, but it can certainly fail with NFS and
root_squash. So
> > it is less effective as well as being resource intensive.
>
> Linux's namespace support does break a lot of traditional paradigm.
> I'll note the TALPA "requirements" are broken themselves since they
> refer to pathnames.
Core functionality does not depend on pathnames. I thought that was
sufficiently clear from the design description. But read below...
> Furthermore, I assume you'll always want to do the scanning in
> userspace; the virus signature files for Windows are ***huge***. And
You assume correctly so the rest of the paragraph was not needed. :)
> if you are going to be scanning for Windows virii on the argument that
> you want to stop malware on fileservers, I don't think you want to put
> all of that code into the kernel. (I'll note that all that code
> complexity leads to bugs, which will in kernel code cause system
> crashes. One company's Linux AV code --- I won't say which --- almost
> lead to a rather big and public customer abandoning an Linux
> deployment because said proprietary, badly/disastrously written,
> kernel code was leaking a small amount of memory on every file open,
> and no one could figure out why their file server was crashing every
> five days or so. I was called in to rescue said customer before they
> cancelled the contract in disgust, and I traced it back to a
> proprietary AV kernel module. What fun...)
Once upon a time I worked for a different company and we used embedded
linux to drive some custom hardware, rather complex things. On some
customer sites, every week or so the OS would hang. Some free, public and
open kernel GPL code was leaking kernel memory on each USB transaction and
depending on the use it would use up all memory sooner or later. We lost
the customer, but didn't abandon Linux. Instead we helped fix the leak and
if you don't believe me it should be ChangeLogs under my name, something
like five or six years ago.
So what do ours anecdotes prove? Only lack of testing I would say.
Also, that companies from your example bad code would probably be better
if a proper interface did exist and they didn't have to hack around.
> So if we are going to have to deal with namespaces, I suspect the best
> we can do for any interface (whether it is inotify based or not) is to
> have it return pathnames that are valid in the namespace that the
> program calling said interface happens to be running in. If necessary
> the AV program can be given access to a highly privileged namespace
> where all mounts are visible. And if you want to restrict namespaces
> from being created at all, that's a security policy decision that
> should be made via the LSM hooks.
I agree wih the first part and that is how it works.
Pathnames are used for reporting purposes and for possible filesystem
hiearchy exclusions. For reporting it is obviously not critical from
security point of view and the design document showed how we get them.
There is no new code added to do it and it happens from userspace. Such
pathnames are relative to the userspace daemon since they are obtained via
/proc/self/fd/ and readlink. Exclusions use relative paths and that is
also explained in the document.
Therefore access to all namespaces should not be needed except in a way of
getting a file descriptor from another process, possibly from another
namespace, do to the scan.
> As far as blocking opens are concerned, my suggestion there would be
> changes would probably be much more likely accepted if they solved
> more problems than just what the AV folks need. For example, think
> about hierarchical storage management, and DMAPI. DMAPI is a total
> disaster because it doesn't know about namespaces and so is completely
> pathname based (which doesn't work well when you have namespaces).
> But a solution which is general enough that it can also be used to
> support HSM would probably be a good thing.
I agree and think we are completely open to this. However the story
reverses in a way that we now don't know what are the requirements for
those so couldn't possibly address them initially.
> Also, it may very well be that instead of one, purpose-specific
> interface such as what you suggested in TALPA, it might be much better
> if it was a series of different interfaces; and in some cases, some of
> the changes might be extensions and improvments to existing
> facilities, such inotify.
Could be, but I think we won't know for sure until everything is fleshed
out.
Tvrtko
Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon,
OX14 3YP, United Kingdom.
Company Reg No 2096520. VAT Reg No GB 348 3873 20.
next prev parent reply other threads:[~2008-08-06 15:56 UTC|newest]
Thread overview: 220+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-04 21:00 [RFC 0/5] [TALPA] Intro to a linux interface for on access scanning Eric Paris
2008-08-04 22:32 ` [malware-list] " Greg KH
2008-08-05 0:26 ` Christoph Hellwig
2008-08-05 0:47 ` Eric Paris
2008-08-05 0:54 ` Christoph Hellwig
2008-08-05 5:49 ` Kyle Moffett
2008-08-05 12:32 ` Alan Cox
2008-08-05 11:31 ` Alan Cox
2008-08-05 14:06 ` Peter Zijlstra
2008-08-05 14:09 ` Alan Cox
2008-08-05 17:58 ` Nick Piggin
2008-08-06 2:41 ` Andi Kleen
2008-08-06 18:04 ` Rik van Riel
2008-08-05 0:32 ` Eric Paris
2008-08-05 0:35 ` Eric Paris
2008-08-05 0:51 ` Greg KH
2008-08-05 11:23 ` Alan Cox
2008-08-05 17:03 ` Greg KH
2008-08-05 18:56 ` Eric Paris
2008-08-05 20:30 ` Greg KH
2008-08-06 18:49 ` Eric Paris
2008-08-06 21:02 ` Theodore Tso
2008-08-06 21:28 ` Eric Paris
2008-08-06 21:52 ` Theodore Tso
2008-08-07 14:16 ` Eric Paris
2008-08-07 21:55 ` David Wagner
2008-08-08 2:06 ` Rene Herman
2008-08-08 2:15 ` Eric Paris
2008-08-08 2:55 ` Rene Herman
2008-08-08 11:58 ` Press, Jonathan
2008-08-08 12:34 ` Rene Herman
2008-08-08 13:11 ` Press, Jonathan
2008-08-08 13:43 ` Rene Herman
2008-08-05 11:25 ` Alan Cox
2008-08-05 17:01 ` Greg KH
2008-08-05 20:36 ` Alan Cox
2008-08-05 19:46 ` Eric Paris
2008-08-05 20:15 ` Greg KH
2008-08-06 9:37 ` tvrtko.ursulin
2008-08-06 15:25 ` Greg KH
2008-08-06 15:41 ` Eric Paris
2008-08-06 16:03 ` tvrtko.ursulin
2008-08-06 9:28 ` tvrtko.ursulin
2008-08-05 14:41 ` [malware-list] [RFC 0/5] [TALPA] Intro to a linux interface foron " Press, Jonathan
2008-08-05 14:56 ` Eric Paris
2008-08-05 16:37 ` [malware-list] [RFC 0/5] [TALPA] Intro to a linux interfaceforon " Press, Jonathan
2008-08-05 17:19 ` Eric Paris
2008-08-05 17:38 ` Arjan van de Ven
2008-08-05 17:29 ` Alan Cox
2008-08-05 18:02 ` Arjan van de Ven
2008-08-05 20:12 ` Alan Cox
2008-08-05 20:41 ` Arjan van de Ven
2008-08-05 18:04 ` Press, Jonathan
2008-08-05 18:11 ` Greg KH
2008-08-05 18:38 ` [malware-list] [RFC 0/5] [TALPA] Intro to a linuxinterfaceforon " Press, Jonathan
2008-08-05 18:54 ` Theodore Tso
2008-08-05 20:37 ` [malware-list] [RFC 0/5] [TALPA] Intro to alinuxinterfaceforon " Press, Jonathan
2008-08-05 21:14 ` Greg KH
2008-08-05 21:23 ` [malware-list] [RFC 0/5] [TALPA] Intro to alinuxinterfaceforonaccess scanning Press, Jonathan
2008-08-05 21:42 ` Arjan van de Ven
2008-08-05 21:44 ` Greg KH
[not found] ` <2629CC4E1D22A64593B02C43E855530303E21D47@USILMS12.ca.com>
2008-08-05 22:26 ` [malware-list] [RFC 0/5] [TALPA] Intro toalinuxinterfaceforonaccess scanning Greg KH
2008-08-05 23:37 ` Al Viro
2008-08-05 23:48 ` Eric Paris
2008-08-05 23:57 ` Theodore Tso
2008-08-06 0:11 ` Greg KH
2008-08-06 0:25 ` Eric Paris
2008-08-06 0:46 ` Rik van Riel
2008-08-06 1:44 ` Theodore Tso
2008-08-08 10:48 ` [malware-list] Threat model for Unix Computers Jörg Ostertag
2008-08-08 22:26 ` Peter Dolding
2008-08-09 1:21 ` david
2008-08-09 1:44 ` Ulrich Drepper
2008-08-05 23:55 ` [malware-list] [RFC 0/5] [TALPA] Intro toalinuxinterfaceforonaccess scanning Theodore Tso
2008-08-06 10:25 ` Pavel Machek
2008-08-05 21:45 ` [malware-list] [RFC 0/5] [TALPA] Intro to alinuxinterfaceforonaccess scanning Al Viro
2008-08-05 20:18 ` [malware-list] [RFC 0/5] [TALPA] Intro to a linuxinterfaceforon access scanning Greg KH
2008-08-05 20:28 ` [malware-list] [RFC 0/5] [TALPA] Intro to alinuxinterfaceforon " Press, Jonathan
2008-08-05 20:51 ` Eric Paris
2008-08-05 21:08 ` Arjan van de Ven
2008-08-06 0:51 ` [malware-list] [RFC 0/5] [TALPA] Intro to a linuxinterfaceforon " Rik van Riel
2008-08-06 12:10 ` Press, Jonathan
2008-08-06 12:38 ` Peter Dolding
2008-08-06 13:11 ` Press, Jonathan
2008-08-06 13:49 ` Arjan van de Ven
2008-08-06 13:55 ` Eric Paris
2008-08-06 14:11 ` Peter Dolding
2008-08-06 14:20 ` Serge E. Hallyn
2008-08-06 13:57 ` Peter Dolding
2008-08-06 11:31 ` [malware-list] [RFC 0/5] [TALPA] Intro to a linux interfaceforon " David Collier-Brown
2008-08-06 23:20 ` Peter Dolding
2008-08-06 13:44 ` [malware-list] [RFC 0/5] [TALPA] Intro to a linuxinterfaceforon " Arjan van de Ven
2008-08-06 14:16 ` tvrtko.ursulin
2008-08-06 14:23 ` Arjan van de Ven
2008-08-06 15:22 ` Theodore Tso
2008-08-06 15:54 ` tvrtko.ursulin [this message]
2008-08-07 9:28 ` Pavel Machek
2008-08-07 14:21 ` Peter Dolding
2008-08-07 14:31 ` Eric Paris
2008-08-08 0:05 ` Peter Dolding
2008-08-08 5:17 ` James Morris
2008-08-06 15:08 ` Theodore Tso
2008-08-06 15:33 ` [malware-list] [RFC 0/5] [TALPA] Intro to alinuxinterfaceforon " Press, Jonathan
2008-08-06 15:46 ` Rik van Riel
2008-08-06 16:12 ` tvrtko.ursulin
2008-08-06 16:25 ` Rik van Riel
2008-08-06 18:06 ` Eric Paris
2008-08-05 20:17 ` [malware-list] [RFC 0/5] [TALPA] Intro to a linux interfaceforon " Alan Cox
2008-08-06 9:24 ` tvrtko.ursulin
2008-08-06 15:24 ` Greg KH
2008-08-05 18:27 ` Arjan van de Ven
2008-08-05 18:34 ` Press, Jonathan
2008-08-05 18:38 ` Greg KH
2008-08-05 20:15 ` [malware-list] [RFC 0/5] [TALPA] Intro to a linuxinterfaceforon " Press, Jonathan
2008-08-05 20:26 ` Greg KH
2008-08-06 10:05 ` tvrtko.ursulin
2008-08-06 10:50 ` Adrian Bunk
2008-08-06 11:07 ` tvrtko.ursulin
2008-08-06 11:26 ` Adrian Bunk
2008-08-07 0:49 ` Mihai Donțu
2008-08-07 4:39 ` Arjan van de Ven
2008-08-11 13:45 ` Mihai Donțu
2008-08-11 13:56 ` Arjan van de Ven
2008-08-11 16:11 ` David Collier-Brown
2008-08-11 21:18 ` Press, Jonathan
2008-08-11 22:09 ` David Wagner
2008-08-12 7:32 ` Alan Cox
2008-08-13 10:28 ` Pavel Machek
2008-08-13 10:46 ` Press, Jonathan
2008-08-13 11:08 ` Peter Dolding
2008-08-13 12:56 ` Pavel Machek
2008-08-13 13:52 ` tvrtko.ursulin
2008-08-14 12:54 ` Pavel Machek
2008-08-14 18:37 ` [malware-list] [RFC 0/5] [TALPA] Intro to alinuxinterfaceforon " Press, Jonathan
2008-08-14 22:39 ` Pavel Machek
2008-08-15 0:00 ` Rik van Riel
2008-08-15 0:43 ` Theodore Tso
2008-08-15 1:02 ` Rik van Riel
2008-08-15 3:00 ` Eric Paris
2008-08-15 5:22 ` david
2008-08-15 5:33 ` david
2008-08-15 5:38 ` david
2008-08-17 22:14 ` Pavel Machek
2008-08-17 22:12 ` Pavel Machek
2008-08-17 22:47 ` david
2008-08-17 22:58 ` Pavel Machek
2008-08-17 23:24 ` david
2008-08-18 0:00 ` Casey Schaufler
2008-08-18 0:17 ` david
2008-08-18 0:31 ` Peter Dolding
2008-08-18 0:39 ` david
2008-08-18 0:42 ` Casey Schaufler
2008-08-18 0:07 ` Rik van Riel
2008-08-19 10:41 ` Pavel Machek
2008-08-15 8:35 ` Alan Cox
2008-08-15 11:35 ` Theodore Tso
2008-08-15 12:57 ` [malware-list] [RFC 0/5] [TALPA] Intro to alinuxinterfaceforonaccess scanning Press, Jonathan
2008-08-15 13:16 ` Theodore Tso
2008-08-15 13:22 ` douglas.leeder
2008-08-15 13:28 ` douglas.leeder
2008-08-15 13:55 ` Theodore Tso
2008-08-15 14:19 ` douglas.leeder
2008-08-15 15:42 ` Valdis.Kletnieks
2008-08-17 22:10 ` [malware-list] [RFC 0/5] [TALPA] Intro to alinuxinterfaceforon access scanning Pavel Machek
2008-08-13 13:58 ` [malware-list] [RFC 0/5] [TALPA] Intro to a linuxinterfaceforon " Arjan van de Ven
2008-08-13 13:54 ` Arjan van de Ven
2008-08-13 14:16 ` tvrtko.ursulin
2008-08-13 14:28 ` Arjan van de Ven
2008-08-13 15:19 ` tvrtko.ursulin
2008-08-14 12:56 ` Pavel Machek
2008-08-14 20:06 ` Alan Cox
2008-08-14 22:35 ` Pavel Machek
2008-08-11 21:53 ` David Wagner
2008-08-11 21:45 ` Alan Cox
2008-08-14 10:48 ` David Collier-Brown
2008-08-06 15:00 ` Theodore Tso
2008-08-06 15:17 ` Greg KH
2008-08-06 15:22 ` Eric Paris
2008-08-05 20:38 ` Arjan van de Ven
2008-08-05 20:54 ` Eric Paris
2008-08-05 21:05 ` Al Viro
2008-08-05 18:38 ` [malware-list] [RFC 0/5] [TALPA] Intro to a linux interfaceforon " Arjan van de Ven
2008-08-05 18:39 ` Eric Paris
2008-08-06 0:30 ` Rik van Riel
2008-08-06 1:55 ` Eric Paris
2008-08-06 11:40 ` Sidebar to [malware-list] [RFC 0/5] [TALPA] Intro to a linux interface for on " David Collier-Brown
2008-08-06 0:22 ` [malware-list] [RFC 0/5] [TALPA] Intro to a linux interfaceforon " Rik van Riel
2008-08-06 0:53 ` jmorris
2008-08-06 2:46 ` [malware-list] [RFC 0/5] [TALPA] Intro to a linux interface foron " Andi Kleen
2008-08-06 8:39 ` [malware-list] [RFC 0/5] [TALPA] Intro to a linux interface for on " tvrtko.ursulin
2008-08-05 11:21 ` Helge Hafting
2008-08-05 17:04 ` Greg KH
2008-08-05 2:49 ` Casey Schaufler
2008-08-05 3:01 ` Cliffe
2008-08-05 3:44 ` Casey Schaufler
2008-08-05 3:45 ` Cliffe
2008-08-05 20:56 ` Paul Moore
2008-08-06 3:00 ` Casey Schaufler
2008-08-06 14:18 ` Paul Moore
2008-08-07 0:49 ` Casey Schaufler
2008-08-05 3:46 ` Greg KH
2008-08-05 3:58 ` Cliffe
2008-08-05 12:05 ` Peter Dolding
2008-08-05 12:22 ` Alan Cox
2008-08-05 18:08 ` Nick Piggin
2008-08-06 9:44 ` [malware-list] " tvrtko.ursulin
2008-08-06 11:10 ` Nick Piggin
2008-08-06 11:29 ` tvrtko.ursulin
2008-08-06 16:57 ` Nick Piggin
2008-08-05 22:55 ` J. Bruce Fields
2008-08-06 10:09 ` [malware-list] " tvrtko.ursulin
2008-08-06 22:24 ` David Wagner
2008-08-07 0:04 ` James Morris
2008-08-07 10:30 ` Alan Cox
2008-08-07 11:19 ` tvrtko.ursulin
2008-08-06 2:35 ` Andi Kleen
2008-08-06 3:43 ` Eric Paris
2008-08-06 3:52 ` Andi Kleen
2008-08-06 22:04 ` David Wagner
2008-08-18 14:06 ` John Moser
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080806155513.25BA137659D@pmx1.sophos.com \
--to=tvrtko.ursulin@sophos.com \
--cc=Jonathan.Press@ca.com \
--cc=arjan@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=malware-list@lists.printk.net \
--cc=riel@redhat.com \
--cc=tytso@MIT.EDU \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).