[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <OF699E23DA.E36E712D-ON802573A2.00591FA8-802573A2.005A44A2@sophos.com>
Date: Thu, 29 Nov 2007 16:26:12 +0000
From: tvrtko.ursulin@...hos.com
To: Al Viro <viro@....linux.org.uk>
Cc: Casey Schaufler <casey@...aufler-ca.com>,
Christoph Hellwig <hch@...radead.org>,
linux-kernel@...r.kernel.org, Valdis.Kletnieks@...edu
Subject: Re: Out of tree module using LSM
Al Viro <viro@....linux.org.uk> wrote on 28/11/2007 18:30:40:
> On Wed, Nov 28, 2007 at 01:15:05PM -0500, Valdis.Kletnieks@...edu wrote:
> > (Note that the concept has interesting implications in the other
> direction as
> > well - rather than stopping you from reading a file that has
> malware, you could
> > in theory write an anti-export package that would let you write
> onto external
> > memory or outbound e-mail, but prevent the write if it was
> corporate-sensitive
> > data, or whatever.
>
> You _can_ _not_ do that. If shared mapping gets dirtied, you have no
way to
> intercept that. At all. Especially since the page stays mapped while
it is
> written out, so the next modification can come when hardware had already
> started outbound DMA and there's no way to abort it, no matter what your
> external scanner would do.
>
> Folks, really, that doesn't work. At all. You can intercept all system
> calls you want and it will not be enough to prevent the "bad" contents
> from hitting the disk.
On this level we are not talking about stopping bad stuff from hitting the
disk. There is a lot simpler scenario how that can happen and that is via
a dropper at which point it can be detected and reported when the file is
closed. But more importantly further access to it can be blocked until
appropriate actions are taken which also applies with your example, no? Is
it possible to open for execute and have dirty mappings (or open for
write) on a file at the same time?
> And if we are talking about the situation when files are written to in
> controlled way (i.e. we are not concerned with malware running on the
box
> in question and just want to stop it from passing through mailsewer,
etc.),
> then there's no damn need to play with LSM - just have e.g. coda with
its
> commit-on-close and run the scanner on commit. End of story. Mind you,
> in such setups one would be much better off just having the mail server
run
> the tests explicitly in the userland, along with the rest of anti-spam,
etc.
> filters.
That is true for that scenario.
--
Tvrtko August Ursulin
Senior Software Engineer, Sophos
"Views and opinions expressed in this email are strictly those of the
author.
The contents has not been reviewed or approved by Sophos."
Tel: 01235 559933
Web: www.sophos.com
Protecting business against viruses, spyware, spam and policy abuse
Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon,
OX14 3YP, United Kingdom.
Company Reg No 2096520. VAT Reg No GB 348 3873 20.
-
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/
Powered by blists - more mailing lists