From: Greg KH <greg@kroah.com>
To: Eric Paris <eparis@redhat.com>
Cc: malware-list@lists.printk.net, linux-kernel@vger.kernel.org
Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to a linux interface for on access scanning
Date: Mon, 4 Aug 2008 15:32:49 -0700 [thread overview]
Message-ID: <20080804223249.GA10517@kroah.com> (raw)
In-Reply-To: <1217883616.27684.19.camel@localhost.localdomain>
On Mon, Aug 04, 2008 at 05:00:16PM -0400, Eric Paris wrote:
> Please contact me privately or (preferably the list) for questions,
> comments, discussions, flames, names, or anything. I'll do complete
> rewrites of the patches if someone tells me how they don't meet their
> needs or how they can be done better. I'm here to try to bridge the
> needs (and wants) of the anti-malware vendors with the technical
> realities of the kernel. So everyone feel free to throw in your two
> cents and I'll try to reconcile it all. These 5 patches are part 1.
> They give us a working able solution.
>
> >From my point of view patches forthcoming and mentioned below should
> help with performance for those who actually have userspace scanners but
> also could presents be implemented using this framework.
>
>
> Background
> ++++++++++
> There is a consensus in the security industry that protecting against
> malicious files (viruses, root kits, spyware, ad-ware, ...) by the way
> of so-called on-access scanning is usable and reasonable approach.
> Currently the Linux kernel does not offer a completely suitable
> interface to implement such security solutions. Present solutions
> involve overwriting function pointers in the LSM, in filesystem
> operations, in the sycall table, and other fragile hacks. The purpose
> of this project is to create a fast, clean interface for userspace
> programs to look for malware when files are accessed. This malware may
> be ultimately intended for this or some other Linux machine or may be
> malware intended to attack a host running a different operating system
> and is merely in transit across the Linux server. Since there are
> almost an infinite number of ways in which information can enter and
> exit a server it is not seen as reasonable to move these checks to all
> the applications at the boundary (MTA, NFS, CIFS, SSH, rsync, et al.) to
> look for such malware on at the border.
>
> For this Linux kernel interface speed is of particular interest for
> those who have it compiled into the kernel but have no userspace client.
> There must be no measurable performance hit to just compiling this into
> the kernel.
>
> Security vendors, Linux distributors and other interested parties have
> come together on the malware-list mailing list to discuss this problem
> and see if they can work together to propose a solution. During these
> talks couple of requirement sets were posted with the aim of fleshing
> out common needs as a prerequisite of creating an interface prototype.
These requirements were posted? Where? I don't recall seeing them.
> Collated requirements
> +++++++++++++++++++++
> 1. Intercept file opens (exec also) for vetting (block until
> decision is made) and allow some userspace black magic to make
> decisions.
> 2. Intercept file closes for scanning post access
> 3. Cache scan results so the same file is not scanned on each and every access
> 4. Ability to flush the cache and cause all files to be re-scanned when accessed
> 5. Define which filesystems are cacheable and which are not
> 6. Scan files directly not relying on path. Avoid races and problems with namespaces, chroot, containers, etc.
> 7. Report other relevant file, process and user information associated with each interception
> 8. Report file pathnames to userspace (relative to process root, current working directory)
> 9. Mark a processes as exempt from on access scanning
> 10. Exclude sub-trees from scanning based on filesystem (exclude procfs, sysfs, devfs)
> 11. Exclude sub-trees from scanning based on filesystem path
> 12. Include only certain sub-trees from scanning based on filesystem path
> 13. Register more than one userspace client in which case behavior is restrictive
I don't see anything in the list above that make this a requirement that
the code to do this be placed within the kernel.
What is wrong with doing it in glibc or some other system-wide library
(LD_PRELOAD hooks, etc.)?
> 1., 2. Basic interception
> -------------------------
> Core requirement is to intercept access to files and prevent it if
> malicious content is detected. This is done on open, not on read. It
> may be possible to do read time checking with minimal performance impact
> although not currently implemented. This means that the following race
> is possible
>
> Process1 Process2
> - open file RD
> - open file WR
> - write virus data (1)
> - read virus data
Wonderful, we are going to implement a solution that is known to not
work, with a trivial way around it?
Sorry, that's not going to fly.
> *note that any open after (1) will get properly vetted. At this time
> the likely hood of this being a problem vs the performance impact of
> scanning on read and the increased complexity of the code means this is
> left out. This should not be a problem for local executables as writes
> to files opened to be run typically return ETXTBSY.
Are you sure about this?
> One of the most important filters in the evaluation chain implements an
> interface through which an userspace process can register and receive
> vetting requests. Userspace process opens a misc character device to
> express its interest and then receives binary structures from that
> device describing basic interception information. After file contents
> have been scanned a vetting response is sent by writing a different
> binary structure back to the device and the intercepted process
> continues its execution. These are not done over network sockets and no
> endian conversions are done. The client and the kernel must have the
> same endian configuration.
How about the same 64/32bit requirement? Your implementation is
incorrect otherwise.
(hint, your current patch is also wrong in this area, you should fix
that up...)
And a binary structure? Ick, are you trying to make it hard for future
expansions and such?
And why not netlink/network socket? Why a character device? You are
already using securityfs, why not use a file node in there?
> 6. Direct access to file content
> --------------------------------
> When an userspace daemon receives a vetting request, it also receives a
> new RO file descriptor which provides direct access to the inode in
> question. This is to enable access to the file regardless of it
> accessibility from the scanner environment (consider process namespaces,
> chroot's, NFS). The userspace client is responsible for closing this
> file when it is finished scanning.
Is this secondary file handle properly checked for the security issues
involved with such a thing? What happens if the userspace client does
not close the file handle?
> 7. Other reporting
> ------------------
> Along with the fd being installed in the scanning process the process
> gets a binary structure of data including:
What's with the love of binary structures? :)
> + uint32_t version;
> + uint32_t type;
> + int32_t fd;
> + uint32_t operation;
> + uint32_t flags;
> + uint32_t mode;
> + uint32_t uid;
> + uint32_t gid;
> + uint32_t tgid;
> + uint32_t pid;
What happens when the world moves to 128bit or 64bit uids? (yes, I've
seen proposals for such a thing...)
Why would userspace care about these meta-file things, what does it want
with them?
> 8. Path name reporting
> ----------------------
> When a malicious content is detected in a file it is important to be
> able to report its location so the user or system administrator can take
> appropriate actions.
>
> This is implemented in a amazingly simple way which will hopefully avoid
> the controversy of some other solutions. Path name is only needed for
> reporting purposes and it is obtained by reading the symlink of the
> given file descriptor in /proc. Its as simple as userspace calling:
>
> snprintf(link, sizeof(link), "/proc/self/fd/%d", details.fd);
> ret = readlink(link, buf, sizeof(buf)-1);
Cute hack. What's to keep it from racing with the fd changing from the
original program?
> 9. Process exclusion
> --------------------
> Sometimes it is necessary to exclude certain processes from being
> intercepted. For example it might be a userspace root kit scanner which
> would not be able to find root kits if access to them was blocked by the
> on-access scanner.
>
> To facilitate that we have created a special file a process can open and
> register itself as excluded. A flag is then put into its kernel
> structure (task_struct) which makes it excluded from scanning.
>
> This implementation is very simple and provides greatest performance. In
> the proposed implementation access to the exclusion device is controlled
> though permissions on the device node which are not sufficient. An LSM
> call will need to be made for this type or access in a later patch.
Heh, so if you want to write a "virus" for Linux, just implement this
flag. What's to keep a "rogue" program from telling the kernel that all
programs on the system are to be excluded?
> 10. Filesystem exclusions
> -------------------------
> One pretty important optimization is not to scan things like /proc, /sys
> or similar. Basically all filesystems where user can not store
> arbitrary, potentially malicious, content could and should be excluded
> from scanning.
Why, does scanning these files take extra time? Just curious.
> 11. Path exclusions
> -------------------
> The need for exclusions can be demonstrated with an example of a MySQL
> server. It's data files are frequently modified which means they would
> need to be constantly rescanned which is very bad for performance. Also,
> it is most often not even possible to reasonably scan them. Therefore
> the best solution is not to scan its database store which can simply be
> implemented by excluding the store subdirectory.
>
> It is a relatively simple implementation which allows run-time
> configuration of a list of sub directories or files to exclude.
> Exclusion paths are relative to each process root. So for example if we
> want to exclude /var/lib/mysql/ and we have a mysql running in a chroot
> where from the outside that directory actually lives
> in /chroot/mysql/var/lib/mysql, /var/lib/mysql should actually be added
> to the exclusion list.
>
> This is also not included in the initial patch set but will be coming
> shortly after.
Again, what's to keep all files to be marked as excluded?
> Closing remarks
> ---------------
> Although some may argue some of the filters are not necessary or may
> better be implemented in userspace, we think it is better to have them
> in kernel primarily for performance reasons.
Why? What numbers do you have that say the kernel is faster in
implementing this? This is the first mention of such a requirement, we
need to see real data to back it up please.
> Secondly, it is all simple code not introducing much baggage or risk
> into the kernel itself.
I disagree, see above.
thanks,
greg k-h
next prev parent reply other threads:[~2008-08-04 22:35 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 ` Greg KH [this message]
2008-08-05 0:26 ` [malware-list] " 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
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=20080804223249.GA10517@kroah.com \
--to=greg@kroah.com \
--cc=eparis@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=malware-list@lists.printk.net \
/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).