All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frank van Maarseveen <frankvm@frankvm.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: frankvm@frankvm.com, akpm@osdl.org, aia21@cam.ac.uk,
	arjan@infradead.org, linux-kernel@vger.kernel.org
Subject: Re: FUSE merging?
Date: Fri, 1 Jul 2005 11:24:44 +0200	[thread overview]
Message-ID: <20050701092444.GA4317@janus> (raw)
In-Reply-To: <E1DoFTR-0002NH-00@dorka.pomaz.szeredi.hu>

On Fri, Jul 01, 2005 at 08:58:05AM +0200, Miklos Szeredi wrote:
> > > 
> > > - Frank points out that a user can send a sigstop to his own setuid(0)
> > >   task and he intimates that this could cause DoS problems with FUSE.  More
> > >   details needed please?
> > 
> > It's the other way around:
> > Apparently it is not a security problem to SIGSTOP or even SIGKILL a
> > setuid program. So why is it a security problem when such a program is
> > delayed by a supposedly malicious behaving FUSE mount?
> 
> Perfectly valid argument.  My question: is it not a security problem
> to allow signals to reach a suid program?

That's what I though too so I asked it first on the security mailing list.
Apparently this signal behavior is normal.

> There's a huge difference between slowing down, and stopping a
> process.  I wouldn't consider the first a true DoS. 

Stopping is a special case. But it is effectively the same as being
indefinately slowed down by, say, 10000+ malicious processes and from
that angle I don't see a fundamental difference w.r.t. security.

Killing the malicous processes should solve the problem. And killing
one FUSE process looks easier to me than killing 10000+ ones.

> Yes.  The extra problem with FUSE, is that they are not _able_ to be
> careful.

I think this is not true. Every pathname passed to a setuid program
by the user is basically "tainted". Standard I/O is tainted as well.

> They can't even check if a file is in fact on a FUSE mount

They shouldn't. The pathname is not to be trusted anyway.

I think FUSE has shown to be conservative enough w.r.t. security to be
merged. But it may be interesting to consider:

-	replace ptraceability test by a kill()ability test.
-	some sort of "intr" mount option for most signals on by default.
-	Forbid hiding data by mounting a FUSE filesystem on top of it (does
	FUSE check for this already?)
-	/proc isn't a problem: most root processes tend to avoid it because
	it is synthetic and thus uninteresting. Maybe we should extend
	the idea of "synthetic file-systems being uninteresting" to any
	process which cannot receive signals from the FUSE mount owner. When
	one cannot hide data by a FUSE mount and its synthetic anyway so not
	interesting then just show the original empty mount point.

-- 
Frank

  reply	other threads:[~2005-07-01  9:25 UTC|newest]

Thread overview: 85+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-30  9:19 FUSE merging? Miklos Szeredi
2005-06-30  9:27 ` Andrew Morton
2005-06-30  9:51   ` Miklos Szeredi
2005-06-30 10:00     ` Arjan van de Ven
2005-06-30 10:12       ` Miklos Szeredi
2005-06-30 10:20         ` Arjan van de Ven
2005-06-30 10:24           ` Miklos Szeredi
2005-06-30 19:39             ` Avuton Olrich
2005-07-01  6:23               ` Miklos Szeredi
2005-06-30 11:13           ` Anton Altaparmakov
2005-06-30 19:46             ` Andrew Morton
2005-06-30 20:00               ` Andrew Morton
2005-07-01  6:40                 ` Miklos Szeredi
2005-06-30 22:28               ` Frank van Maarseveen
2005-07-01  6:58                 ` Miklos Szeredi
2005-07-01  9:24                   ` Frank van Maarseveen [this message]
2005-07-01 10:27                     ` Miklos Szeredi
2005-07-01 12:00                       ` Frank van Maarseveen
2005-07-01 12:36                         ` Miklos Szeredi
2005-07-01 13:05                           ` Frank van Maarseveen
2005-07-01 13:21                             ` Miklos Szeredi
2005-07-01 15:20                               ` Frank van Maarseveen
2005-07-01 17:04                                 ` Miklos Szeredi
2005-07-01 18:04                                   ` Frank van Maarseveen
2005-07-01 19:35                                     ` Jeremy Maitin-Shepard
2005-07-02 14:49                                     ` Miklos Szeredi
2005-07-02 16:00                                       ` Frank van Maarseveen
2005-07-03  6:16                                         ` Miklos Szeredi
2005-07-03 11:25                                           ` Frank van Maarseveen
2005-07-03 13:24                                             ` Miklos Szeredi
2005-07-03 13:50                                               ` Frank van Maarseveen
2005-07-03 14:03                                                 ` Miklos Szeredi
2005-07-03 14:10                                               ` FUSE merging? (2) Frank van Maarseveen
2005-07-03 15:47                                                 ` Miklos Szeredi
2005-07-03 19:36                                                   ` Frank van Maarseveen
2005-07-04  8:56                                                     ` Miklos Szeredi
2005-07-04  9:59                                                       ` Frank van Maarseveen
2005-07-04 10:27                                                         ` Miklos Szeredi
2005-07-04 11:26                                                           ` Frank van Maarseveen
2005-07-01  6:36               ` FUSE merging? Miklos Szeredi
2005-07-01  6:50                 ` Andrew Morton
2005-07-01  7:07                   ` Miklos Szeredi
2005-07-01  7:14                     ` Andrew Morton
2005-07-01  7:27                       ` Miles Bader
2005-07-01  7:38                       ` Miklos Szeredi
2005-07-01  8:02                         ` Andrew Morton
2005-07-01 10:11                           ` Miklos Szeredi
2005-07-01 11:29                             ` Andrew Morton
2005-07-01 12:00                               ` Miklos Szeredi
2005-07-01 12:53                               ` Anton Altaparmakov
2005-07-01 13:07                                 ` Anton Altaparmakov
2005-07-01 13:51                                 ` Frank van Maarseveen
2005-07-01 13:29                               ` Eric Van Hensbergen
2005-07-01 16:45                               ` Matthias Urlichs
2005-07-01 12:08                             ` Frank van Maarseveen
2005-07-01 13:21                             ` Eric Van Hensbergen
2005-07-01 13:53                               ` Miklos Szeredi
2005-07-01 14:18                                 ` Eric Van Hensbergen
2005-07-01 14:31                                   ` Miklos Szeredi
2005-07-02 10:01                                     ` Eric W. Biederman
2005-07-02 14:58                                       ` Miklos Szeredi
2005-07-02 16:43                                       ` Eric Van Hensbergen
2005-07-02 17:33                                         ` Eric W. Biederman
2005-07-03 19:39                           ` Pavel Machek
2005-07-04  8:38                             ` Miklos Szeredi
     [not found]                               ` <20050704084900.GG15370@elf.ucw.cz>
2005-07-04  9:02                                 ` Miklos Szeredi
2005-07-04 10:46                                   ` Pekka Enberg
2005-07-01 12:37                   ` bert hubert
2005-07-01  7:46                 ` Frederik Deweerdt
2005-07-01  9:47                   ` Miklos Szeredi
2005-07-01  9:36                 ` Frank van Maarseveen
2005-07-01 10:45                   ` Miklos Szeredi
2005-07-01 11:34                     ` Frank van Maarseveen
2005-06-30 10:16       ` Miklos Szeredi
2005-06-30 16:30         ` Pavel Machek
  -- strict thread matches above, loose matches on Subject: below --
2005-09-02 22:02 Miklos Szeredi
2005-09-02 22:34 ` Andrew Morton
2005-09-03  0:34   ` Kasper Sandberg
2005-09-03  5:31   ` Miklos Szeredi
2005-09-03  6:40     ` Andrew Morton
2005-09-03  7:23       ` Miklos Szeredi
2005-09-03 13:29     ` Eric Van Hensbergen
2005-09-03 14:20       ` Miklos Szeredi
2005-09-03 15:01         ` Eric Van Hensbergen
2005-09-03 15:38           ` Miklos Szeredi

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=20050701092444.GA4317@janus \
    --to=frankvm@frankvm.com \
    --cc=aia21@cam.ac.uk \
    --cc=akpm@osdl.org \
    --cc=arjan@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.