All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: David Herrmann <dh.herrmann@gmail.com>, linux-kernel@vger.kernel.org
Cc: "Hugh Dickins" <hughd@google.com>,
	"Alexander Viro" <viro@zeniv.linux.org.uk>,
	"Matthew Wilcox" <matthew@wil.cx>,
	"Karol Lewandowski" <k.lewandowsk@samsung.com>,
	"Kay Sievers" <kay@vrfy.org>, "Daniel Mack" <zonque@gmail.com>,
	"Lennart Poettering" <lennart@poettering.net>,
	"Kristian Høgsberg" <krh@bitplanet.net>,
	john.stultz@linaro.org, "Greg Kroah-Hartman" <greg@kroah.com>,
	"Tejun Heo" <tj@kernel.org>,
	"Johannes Weiner" <hannes@cmpxchg.org>,
	dri-devel@lists.freedesktop.org, linux-fsdevel@vger.kernel.org,
	linux-mm@kvack.org, "Andrew Morton" <akpm@linux-foundation.org>,
	"Linus Torvalds" <torvalds@linux-foundation.org>,
	"Ryan Lortie" <desrt@desrt.ca>,
	"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
Subject: Re: [PATCH 0/6] File Sealing & memfd_create()
Date: Tue, 08 Apr 2014 15:00:28 +0200	[thread overview]
Message-ID: <5343F2EC.3050508@redhat.com> (raw)
In-Reply-To: <1395256011-2423-1-git-send-email-dh.herrmann@gmail.com>

On 03/19/2014 08:06 PM, David Herrmann wrote:

> Unlike existing techniques that provide similar protection, sealing allows
> file-sharing without any trust-relationship. This is enforced by rejecting seal
> modifications if you don't own an exclusive reference to the given file. So if
> you own a file-descriptor, you can be sure that no-one besides you can modify
> the seals on the given file. This allows mapping shared files from untrusted
> parties without the fear of the file getting truncated or modified by an
> attacker.

How do you keep these promises on network and FUSE file systems?  Surely 
there is still some trust involved for such descriptors?

What happens if you create a loop device on a sealed descriptor?

Why does memfd_create not create a file backed by a memory region in the 
current process?  Wouldn't this be a far more generic primitive? 
Creating aliases of memory regions would be interesting for many things 
(not just libffi bypassing SELinux-enforced NX restrictions :-).

-- 
Florian Weimer / Red Hat Product Security Team

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Florian Weimer <fweimer@redhat.com>
To: David Herrmann <dh.herrmann@gmail.com>, linux-kernel@vger.kernel.org
Cc: "Hugh Dickins" <hughd@google.com>,
	"Alexander Viro" <viro@zeniv.linux.org.uk>,
	"Matthew Wilcox" <matthew@wil.cx>,
	"Karol Lewandowski" <k.lewandowsk@samsung.com>,
	"Kay Sievers" <kay@vrfy.org>, "Daniel Mack" <zonque@gmail.com>,
	"Lennart Poettering" <lennart@poettering.net>,
	"Kristian Høgsberg" <krh@bitplanet.net>,
	john.stultz@linaro.org, "Greg Kroah-Hartman" <greg@kroah.com>,
	"Tejun Heo" <tj@kernel.org>,
	"Johannes Weiner" <hannes@cmpxchg.org>,
	dri-devel@lists.freedesktop.org, linux-fsdevel@vger.kernel.org,
	linux-mm@kvack.org, "Andrew Morton" <akpm@linux-foundation.org>,
	"Linus Torvalds" <torvalds@linux-foundation.org>,
	"Ryan Lortie" <desrt@desrt.ca>,
	"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
Subject: Re: [PATCH 0/6] File Sealing & memfd_create()
Date: Tue, 08 Apr 2014 15:00:28 +0200	[thread overview]
Message-ID: <5343F2EC.3050508@redhat.com> (raw)
In-Reply-To: <1395256011-2423-1-git-send-email-dh.herrmann@gmail.com>

On 03/19/2014 08:06 PM, David Herrmann wrote:

> Unlike existing techniques that provide similar protection, sealing allows
> file-sharing without any trust-relationship. This is enforced by rejecting seal
> modifications if you don't own an exclusive reference to the given file. So if
> you own a file-descriptor, you can be sure that no-one besides you can modify
> the seals on the given file. This allows mapping shared files from untrusted
> parties without the fear of the file getting truncated or modified by an
> attacker.

How do you keep these promises on network and FUSE file systems?  Surely 
there is still some trust involved for such descriptors?

What happens if you create a loop device on a sealed descriptor?

Why does memfd_create not create a file backed by a memory region in the 
current process?  Wouldn't this be a far more generic primitive? 
Creating aliases of memory regions would be interesting for many things 
(not just libffi bypassing SELinux-enforced NX restrictions :-).

-- 
Florian Weimer / Red Hat Product Security Team

  parent reply	other threads:[~2014-04-08 13:00 UTC|newest]

Thread overview: 123+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-19 19:06 [PATCH 0/6] File Sealing & memfd_create() David Herrmann
2014-03-19 19:06 ` David Herrmann
2014-03-19 19:06 ` David Herrmann
2014-03-19 19:06 ` David Herrmann
2014-03-19 19:06 ` [PATCH 1/6] fs: fix i_writecount on shmem and friends David Herrmann
2014-03-19 19:06   ` David Herrmann
2014-03-19 19:06   ` David Herrmann
2014-03-19 19:06   ` David Herrmann
2014-03-19 19:06 ` [PATCH 2/6] shm: add sealing API David Herrmann
2014-03-19 19:06   ` David Herrmann
2014-03-19 19:06   ` David Herrmann
2014-03-19 19:06   ` David Herrmann
2014-03-19 19:06 ` [PATCH 3/6] shm: add memfd_create() syscall David Herrmann
2014-03-19 19:06   ` David Herrmann
2014-03-19 19:06   ` David Herrmann
2014-03-19 19:06   ` David Herrmann
2014-03-20  8:47   ` Cyrill Gorcunov
2014-03-20  8:47     ` Cyrill Gorcunov
2014-03-20  9:01     ` Pavel Emelyanov
2014-03-20  9:01       ` Pavel Emelyanov
2014-03-20 11:29       ` David Herrmann
2014-03-20 11:29         ` David Herrmann
2014-03-20 11:29         ` David Herrmann
2014-03-20 11:29         ` David Herrmann
2014-03-20 11:50         ` Pavel Emelyanov
2014-03-20 11:50           ` Pavel Emelyanov
2014-03-20 19:22   ` John Stultz
2014-03-20 19:22     ` John Stultz
2014-04-02 13:38   ` Konstantin Khlebnikov
2014-04-02 13:38     ` Konstantin Khlebnikov
2014-04-02 14:18     ` David Herrmann
2014-04-02 14:18       ` David Herrmann
2014-04-02 14:52       ` Konstantin Khlebnikov
2014-04-02 14:52         ` Konstantin Khlebnikov
2014-04-02 14:52         ` Konstantin Khlebnikov
2014-04-10 19:07     ` Andy Lutomirski
2014-04-10 19:07       ` Andy Lutomirski
2014-03-19 19:06 ` [PATCH 4/6] selftests: add memfd_create() + sealing tests David Herrmann
2014-03-19 19:06   ` David Herrmann
2014-03-19 19:06 ` [PATCH man-pages 5/6] fcntl.2: document SHMEM_SET/GET_SEALS commands David Herrmann
2014-03-19 19:06   ` David Herrmann
2014-03-19 19:06   ` David Herrmann
2014-03-19 19:06   ` David Herrmann
2014-03-19 19:06 ` [PATCH man-pages 6/6] memfd_create.2: add memfd_create() man-page David Herrmann
2014-03-19 19:06   ` David Herrmann
2014-03-19 19:06   ` David Herrmann
2014-03-19 19:06   ` David Herrmann
2014-03-20  2:55 ` [PATCH 0/6] File Sealing & memfd_create() Greg Kroah-Hartman
2014-03-20  2:55   ` Greg Kroah-Hartman
2014-03-20  2:55   ` Greg Kroah-Hartman
2014-03-20  2:55   ` Greg Kroah-Hartman
2014-03-20  3:49 ` Linus Torvalds
2014-03-20  3:49   ` Linus Torvalds
2014-03-20  8:07   ` David Herrmann
2014-03-20  8:07     ` David Herrmann
2014-03-20  8:07     ` David Herrmann
2014-03-20  8:07     ` David Herrmann
2014-03-20 14:41     ` One Thousand Gnomes
2014-03-20 14:41       ` One Thousand Gnomes
2014-03-20 14:41       ` One Thousand Gnomes
2014-03-20 15:12       ` David Herrmann
2014-03-20 15:12         ` David Herrmann
2014-03-20 15:12         ` David Herrmann
2014-03-20 15:12         ` David Herrmann
2014-03-20 15:26         ` One Thousand Gnomes
2014-03-20 15:26           ` One Thousand Gnomes
2014-03-20 15:26           ` One Thousand Gnomes
2014-03-20 15:32 ` tytso
2014-03-20 15:32   ` tytso
2014-03-20 15:39   ` One Thousand Gnomes
2014-03-20 15:48   ` David Herrmann
2014-03-20 15:48     ` David Herrmann
2014-03-20 16:38     ` tytso
2014-03-20 16:38       ` tytso
2014-04-10 19:14       ` Andy Lutomirski
2014-04-10 19:14         ` Andy Lutomirski
2014-04-10 20:32         ` Theodore Ts'o
2014-04-10 20:32           ` Theodore Ts'o
2014-04-10 20:37           ` Andy Lutomirski
2014-04-10 20:37             ` Andy Lutomirski
2014-04-10 20:49             ` David Herrmann
2014-04-10 20:49               ` David Herrmann
2014-04-10 21:16               ` Andy Lutomirski
2014-04-10 21:16                 ` Andy Lutomirski
2014-04-10 22:57                 ` David Herrmann
2014-04-10 22:57                   ` David Herrmann
2014-04-10 22:57                   ` David Herrmann
2014-04-10 22:57                   ` David Herrmann
2014-04-10 23:05                   ` Andy Lutomirski
2014-04-10 23:05                     ` Andy Lutomirski
2014-04-10 23:16                     ` David Herrmann
2014-04-10 23:16                       ` David Herrmann
2014-04-10 23:32                       ` Andy Lutomirski
2014-04-10 23:32                         ` Andy Lutomirski
2014-04-20 15:03             ` Pavel Machek
2014-04-20 15:03               ` Pavel Machek
2014-06-17  9:48             ` Florian Weimer
2014-06-17  9:48               ` Florian Weimer
2014-06-17  9:48               ` Florian Weimer
2014-06-17  9:48               ` Florian Weimer
2014-06-17 16:21               ` Andy Lutomirski
2014-04-10 14:45   ` Colin Walters
2014-04-10 14:45     ` Colin Walters
2014-04-10 19:15     ` Andy Lutomirski
2014-04-10 19:15       ` Andy Lutomirski
2014-04-10 19:45       ` Colin Walters
2014-04-10 19:45         ` Colin Walters
2014-04-11  6:09         ` Alex Elsayed
2014-04-11  6:09           ` Alex Elsayed
2014-04-08 13:00 ` Florian Weimer [this message]
2014-04-08 13:00   ` Florian Weimer
2014-04-09 21:31   ` David Herrmann
2014-04-09 21:31     ` David Herrmann
2014-04-22  9:10     ` Florian Weimer
2014-04-22  9:10       ` Florian Weimer
2014-04-22 11:55       ` David Herrmann
2014-04-22 11:55         ` David Herrmann
2014-04-22 12:44         ` Florian Weimer
2014-04-22 12:44           ` Florian Weimer
2014-04-22 12:55           ` David Herrmann
2014-04-22 12:55             ` David Herrmann
2014-04-10 19:17   ` Andy Lutomirski
2014-04-10 19:17     ` Andy Lutomirski

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=5343F2EC.3050508@redhat.com \
    --to=fweimer@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=desrt@desrt.ca \
    --cc=dh.herrmann@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=greg@kroah.com \
    --cc=hannes@cmpxchg.org \
    --cc=hughd@google.com \
    --cc=john.stultz@linaro.org \
    --cc=k.lewandowsk@samsung.com \
    --cc=kay@vrfy.org \
    --cc=krh@bitplanet.net \
    --cc=lennart@poettering.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=matthew@wil.cx \
    --cc=mtk.manpages@gmail.com \
    --cc=tj@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=zonque@gmail.com \
    /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.