linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Mihai Donțu" <mihai.dontu@gmail.com>
To: Andi Kleen <andi@firstfloor.org>
Cc: Eric Paris <eparis@redhat.com>,
	linux-kernel@vger.kernel.org, malware-list@lists.printk.net,
	riel@redhat.com, greg@kroah.com, tytso@mit.edu,
	viro@zeniv.linux.org.uk, arjan@infradead.org,
	alan@lxorguk.ukuu.org.uk, peterz@infradead.org,
	hch@infradead.org
Subject: Re: TALPA - a threat model?  well sorta.
Date: Thu, 14 Aug 2008 03:18:00 +0300	[thread overview]
Message-ID: <200808140318.00740.mihai.dontu@gmail.com> (raw)
In-Reply-To: <20080813181714.GL1366@one.firstfloor.org>

On Wednesday 13 August 2008, Andi Kleen wrote:
> On Wed, Aug 13, 2008 at 12:36:15PM -0400, Eric Paris wrote:
>
> I miss a clear answer to the question: is this
> supposed to protect against malware injected as root or not?

I honestly don't think we should worry about root. Sure, if the AV scanner 
happens to catch something (as a consequence of it's implementation), then 
very well. But designing an antimalware solution which assumes the root is 
compromised will throw us into security talks for years and I don't think 
we'll live to hear the end of them.

We should focus on the regular users and fix (if needed) the current userland 
apps (ie. the ones that need root access to do their job). For anymore than 
that we'll need a super user that supervises root. And then another one.

> Assuming it wants to protect against root:
> > think we hear claim more grandious things.  But from what I've seen they
> > aren't the real deal.  Most of the security model descriptions that
> > people on list want actually are framed under the belief that these
> > products need to or attempt to completely block some class of attacks.
> > They don't.  If you think they do you need to fix your frame of
> > reference.  The only class of attacks this interface is supposed to
> > address is those that can be found by scanning files.  This is NOT an
> > LSM.
>
> But you need some LSM like protections to be able to protect the file
> scanner? Like the block device or kernel memory protection.
>
> > The real goal is to get files into to some userspace scanner and let
> > them do whatever they want.  Remember, this isn't a new LSM.  The goal
> > isn't to provide perfect security.  The goal isn't to stop already
> > running malicious programs.  The one and only goal is to scan files.  We
> > should not be considering timing attacks, we should not be considering
> > processes actively trying to get around the system for small periods of
> > time.  We should certainly not be considering root processes being able
> > to sneak things by.
>
> This means you need significant LSM components simply to protect
> the integrity of the file scanner against root. It's even
> unclear it's possible in the general case (e.g. X server doing
> arbitary DMA and no IOMMU -- how do you protect the file scanner?)
>
> > The idea is that a file exists on disk and we want
> > some userspace program to give a best effort at scanning it.  Yes, we
>
> Ok so you're implying it's ok to not protect against root?
>
> In the later case that means that you don't have to scan anything
> that only root can touch and you can trust file permissions,
> which makes a lot of things easier.
>
> I would suggest again to clarify this important point first. It has
> significant impact on the whole design.
>
> Personally I would think not protecting against root would be quite
> limiting (e.g. it would mean that e.g. if some worm trojans rpms
> people download then they wouldn't be caught because rpms are
> installed as root)

If GPG signatures don't work, then please fix the rpm design and if the user 
willingly installs a .rpm which is not signed (not from a known trusted host) 
and somehow doges the basic antimalware scanner, then too bad. We've done all 
we could.

> , but on the other hand if you protect against 
> root you need most of selinux/aa/other lsm functionality simply
> to guarantee the integrity of the scanner.  Also it has impact
> on some apps, e.g. X server running as root would be usually out due to
> the arbitary DMA issue. Also protect block devices could theoretically
> have significant impact on some sysadmin tasks.

I think we need to define the 'desktop user' and provide a decent protection 
mechanism for his common activities (edit documents, listen music, navigate 
the web, see movies, run scripts which change the IM status etc). For the 
rest, there are two possibilities:
    1. education (_extremely_ important);
    2. SELinux (or similar);

I don't think there will ever be an AV product using the marketing line: "it 
allows you to run your favorite rootkit and enjoy the pretty text it shows, 
with no worries".

In conclusion: everything AV related should stop at the user root. Popular 
distro-s already provide a way to do your daily office tasks without super 
user rights, which _is_ the correct thing to do.

-- 
Mihai Donțu

  parent reply	other threads:[~2008-08-14  0:18 UTC|newest]

Thread overview: 101+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-13 16:36 TALPA - a threat model? well sorta Eric Paris
2008-08-13 16:24 ` Alan Cox
2008-08-13 16:47   ` Eric Paris
2008-08-13 16:37     ` Alan Cox
2008-08-13 17:00       ` Eric Paris
2008-08-13 19:59         ` Alan Cox
2008-08-13 21:24           ` [malware-list] " Press, Jonathan
2008-08-13 21:13             ` Alan Cox
2008-08-13 21:35             ` Rik van Riel
2008-08-13 21:23               ` Alan Cox
2008-08-15  3:25                 ` Eric Paris
2008-08-15 20:16               ` Jan Harkes
2008-08-15 22:05                 ` Arjan van de Ven
2008-08-17 23:19                   ` Eric Paris
2008-08-17 23:26                     ` Arjan van de Ven
2008-08-17 21:11                       ` David Collier-Brown
2008-08-18 15:33                     ` Alan Cox
2008-08-18 16:43                       ` Rik van Riel
     [not found]                         ` <20080819071416.GA14731@elf.ucw.cz>
2008-08-19 16:10                           ` HSM (was Re: [malware-list] TALPA - a threat model? well sorta.) Rik van Riel
2008-08-19 19:20                             ` Pavel Machek
2008-08-19 20:33                               ` Rik van Riel
2008-08-20 17:03                                 ` Pavel Machek
2008-08-13 17:07   ` TALPA - a threat model? well sorta Christoph Hellwig
2008-08-14 13:00   ` Arnd Bergmann
2008-08-13 16:57 ` Greg KH
2008-08-13 17:39 ` Arjan van de Ven
2008-08-13 18:15   ` Theodore Tso
2008-08-13 18:21     ` Arjan van de Ven
2008-08-14  9:18       ` tvrtko.ursulin
2008-08-13 19:02     ` Eric Paris
2008-08-13 19:29       ` Theodore Tso
2008-08-13 21:15         ` [malware-list] " Press, Jonathan
2008-08-14  9:30         ` tvrtko.ursulin
2008-08-14 12:03           ` Press, Jonathan
2008-08-14 12:27             ` tvrtko.ursulin
2008-08-15 14:31               ` Pavel Machek
2008-08-14 13:24           ` Theodore Tso
2008-08-14 13:48             ` Eric Paris
2008-08-14 15:50               ` Theodore Tso
2008-08-14 17:29                 ` Eric Paris
2008-08-14 19:17                   ` Theodore Tso
2008-08-14 19:20                     ` Eric Paris
2008-08-14 19:34                     ` Christoph Hellwig
2008-08-14 19:41                       ` Theodore Tso
2008-08-14 20:20                         ` Christoph Hellwig
2008-08-14 21:21                           ` J. Bruce Fields
2008-08-14 23:34                             ` Theodore Tso
2008-08-19 21:43                               ` J. Bruce Fields
2008-08-15  1:44                         ` david
2008-08-15  2:04                           ` Theodore Tso
2008-08-15  3:41                             ` Arjan van de Ven
2008-08-15  5:05                               ` david
2008-08-15  5:12                                 ` Johannes Weiner
2008-08-15  5:28                                   ` david
2008-08-15  5:36                                 ` david
2008-08-15  4:48                             ` david
2008-08-15  8:51                             ` Alan Cox
2008-08-15 14:37                 ` Pavel Machek
2008-08-13 18:57   ` Eric Paris
2008-08-13 21:39     ` Arjan van de Ven
2008-08-14 14:12       ` Eric Paris
2008-08-14 15:57         ` Arjan van de Ven
2008-08-15 10:07         ` Helge Hafting
2008-08-15 10:37           ` Peter Zijlstra
2008-08-15 13:10             ` [malware-list] " Press, Jonathan
2008-08-15 13:18               ` douglas.leeder
2008-08-15 17:04                 ` Theodore Tso
2008-08-15 18:09                   ` Press, Jonathan
2008-08-18 10:09                     ` Helge Hafting
2008-08-18 10:14                       ` Peter Zijlstra
2008-08-18 10:24                         ` tvrtko.ursulin
2008-08-18 10:25                       ` douglas.leeder
2008-08-15 16:25               ` david
2008-08-15 16:30                 ` Press, Jonathan
2008-08-15 17:33                   ` david
2008-08-15 17:40                     ` Press, Jonathan
2008-08-15 17:47                       ` david
2008-08-15 18:06                         ` Valdis.Kletnieks
2008-08-15 20:05                           ` david
2008-08-15 20:17                           ` Theodore Tso
2008-08-15 18:17                         ` Press, Jonathan
2008-08-15 20:08                           ` david
2008-08-18 10:02               ` Helge Hafting
2008-08-15 10:44           ` tvrtko.ursulin
2008-08-14  9:46     ` [malware-list] " tvrtko.ursulin
2008-08-14 13:46       ` Arjan van de Ven
2008-08-15  1:37       ` david
2008-08-15  1:31   ` david
2008-08-15 16:06   ` Pavel Machek
2008-08-18 12:21     ` david
2008-08-18 13:30       ` Pavel Machek
2008-08-19  0:03         ` david
2008-08-13 18:17 ` Andi Kleen
2008-08-13 18:21   ` H. Peter Anvin
2008-08-13 18:24   ` Arjan van de Ven
2008-08-13 18:40   ` Eric Paris
2008-08-14  0:18   ` Mihai Donțu [this message]
2008-08-14 11:58     ` [malware-list] " Press, Jonathan
2008-08-14 12:34       ` Mihai Donțu
2008-08-14  0:14 ` 7v5w7go9ub0o
2008-08-14  2:25   ` 7v5w7go9ub0o

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=200808140318.00740.mihai.dontu@gmail.com \
    --to=mihai.dontu@gmail.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=andi@firstfloor.org \
    --cc=arjan@infradead.org \
    --cc=eparis@redhat.com \
    --cc=greg@kroah.com \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=malware-list@lists.printk.net \
    --cc=peterz@infradead.org \
    --cc=riel@redhat.com \
    --cc=tytso@mit.edu \
    --cc=viro@zeniv.linux.org.uk \
    /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).