linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Christoph Hellwig <hch@infradead.org>
Cc: Jan Engelhardt <jengelh@computergmbh.de>,
	Greg KH <greg@kroah.com>, Jon Masters <jonathan@jonmasters.org>,
	Valdis.Kletnieks@vt.edu, Christoph Hellwig <hch@infradead.org>,
	Al Viro <viro@ftp.linux.org.uk>,
	Casey Schaufler <casey@schaufler-ca.com>,
	"Tvrtko A. Ursulin" <tvrtko.ursulin@sophos.com>,
	linux-kernel@vger.kernel.org
Subject: Re: Out of tree module using LSM
Date: Thu, 29 Nov 2007 17:27:40 +0000	[thread overview]
Message-ID: <20071129172740.2515fa75@the-village.bc.nu> (raw)
In-Reply-To: <20071129165731.GA30719@infradead.org>

> Can we please stop this useless discussion?  Trying to check the content
> of files to see whether they might be malicious is inherently braindead,
> and no amounts of plugins in random places will fix this.

Actually it is quite effective especially for files whose content is
expected not to be executable material - there are some very distinct
mathematical signatures.

For the purposes of figuring out what is needed you can consider a random
simple user case such as a system which protects you against the works of
Eric S Raymond. Replace the mathematical analysis and heuristics with a
user space tool which spots the various ESR papers and design it for that
if it makes you happier.

SELinux seems to be able to do most of the lifting around the problem as
it can relabel a file into eric_t and constrain further access to it.

The big problem to me is that this essentially boils down to revoke() on
ordinary files, which as we know is _hard_.

The simple case is
	open
	write cathedral and bazaar in some order
	close
	<trap close -> process -> label eric_t>

	open (eric_t) - SELinux "no"


Anyone smart will then write it out of order and keep the file open, or
make sure someone else has it open. At that point close ceases to be a
point you can check the labelling. Open doesn't seem too helpful either
as the target may have the file open before it is modified into an ESR
work.

Even if you can spot the surrepticious assembly of an ESR work on your
computer you then have to implement revocation in order to take the file
away from those with it open.

Alan

  reply	other threads:[~2007-11-29 17:36 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-28 12:42 Out of tree module using LSM Tvrtko A. Ursulin
2007-11-28 14:41 ` Christoph Hellwig
2007-11-28 16:38   ` Casey Schaufler
2007-11-28 16:46     ` Christoph Hellwig
2007-11-28 17:39       ` Stephen Hemminger
2007-11-28 18:22         ` tvrtko.ursulin
2007-11-28 19:50           ` Alan Cox
2007-11-29 16:12             ` tvrtko.ursulin
2007-11-29  0:12           ` James Morris
2007-11-29 16:27             ` Jon Masters
2007-11-29 16:51               ` Greg KH
2007-11-29 16:51               ` Stephen Hemminger
2007-11-29 16:52               ` Jan Engelhardt
2007-11-29  0:51           ` Jan Engelhardt
2007-11-29  1:45             ` Casey Schaufler
2007-11-28 18:15       ` Valdis.Kletnieks
2007-11-28 18:30         ` Al Viro
2007-11-29  0:38           ` Greg KH
2007-11-29  0:53             ` Jan Engelhardt
2007-11-29  1:07               ` Greg KH
2007-11-29 16:36                 ` Jon Masters
2007-11-29 16:47                   ` Greg KH
2007-11-29 16:53                     ` Jan Engelhardt
2007-11-29 16:57                       ` Christoph Hellwig
2007-11-29 17:27                         ` Alan Cox [this message]
2007-11-29 22:58                           ` Andi Kleen
2007-12-08 10:50                             ` Pavel Machek
2007-11-29 17:03                       ` Greg KH
2007-11-29 17:35                         ` Ray Lee
2007-11-29 17:45                           ` Greg KH
2007-11-29 18:03                             ` Ray Lee
2007-11-29 18:19                               ` Justin Banks
2007-11-29 18:38                                 ` Jon Masters
2007-11-29 17:51                           ` Al Viro
2007-11-29 17:05                     ` Jon Masters
2007-11-29 17:14                       ` Greg KH
2007-11-29 16:26           ` tvrtko.ursulin
2007-11-29 17:36             ` Alan Cox
2007-11-29 18:40               ` Ray Lee
2007-11-29 18:56                 ` Jon Masters
2007-11-29 19:11                   ` Ray Lee
2007-11-29 19:45                     ` Jon Masters
2007-11-29 20:56                       ` Valdis.Kletnieks
2007-11-29 22:08                         ` Al Viro
2007-11-30  0:50                           ` James Morris
2007-11-29 23:31                         ` Jon Masters
2007-11-29 21:45                       ` Alan Cox
2007-11-29 22:12                         ` Justin Banks
2007-11-30  1:48                           ` Al Viro
2007-11-30 15:37                             ` Justin Banks
2007-11-29 23:34                         ` Jon Masters
2007-11-30  6:20                           ` Valdis.Kletnieks
2007-11-30 13:30                             ` Alan Cox
2007-11-29 21:09               ` Andi Kleen
2007-11-28 19:20 ` Andi Kleen
2007-11-28 19:52   ` Alan Cox
2007-11-28 20:05     ` Valdis.Kletnieks
2007-11-29 16:39   ` tvrtko.ursulin
2007-12-01  8:43     ` Pavel Machek
2007-12-02 19:44       ` Valdis.Kletnieks
2007-12-02 20:02         ` Arjan van de Ven
2007-12-02 20:06         ` Andi Kleen
2007-12-02 20:22         ` Pavel Machek
2007-12-02 21:09           ` Valdis.Kletnieks
2007-12-02 21:56             ` Pavel Machek
2007-12-02 23:15               ` Jan Engelhardt
2007-12-02 23:23                 ` Pavel Machek
2007-11-29  0:58 ` Greg KH
2007-11-30 20:52 Crispin Cowan
2007-11-30 21:36 ` James Morris
2007-11-30 23:52   ` Crispin Cowan
2007-12-01  0:05     ` James Morris
     [not found] <9uzZr-6iz-19@gated-at.bofh.it>
     [not found] ` <9uUrm-5w3-27@gated-at.bofh.it>
     [not found]   ` <9uVGz-7uQ-19@gated-at.bofh.it>
     [not found]     ` <9uWCC-xI-13@gated-at.bofh.it>
     [not found]       ` <9uWMp-Ix-13@gated-at.bofh.it>
     [not found]         ` <9uX5A-1rs-1@gated-at.bofh.it>
     [not found]           ` <9uXyK-24f-23@gated-at.bofh.it>
2007-12-03 22:45             ` Bodo Eggert

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=20071129172740.2515fa75@the-village.bc.nu \
    --to=alan@lxorguk.ukuu.org.uk \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=casey@schaufler-ca.com \
    --cc=greg@kroah.com \
    --cc=hch@infradead.org \
    --cc=jengelh@computergmbh.de \
    --cc=jonathan@jonmasters.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tvrtko.ursulin@sophos.com \
    --cc=viro@ftp.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).