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
Hi
On Tue, Apr 8, 2014 at 3:00 PM, Florian Weimer <[email protected]> wrote:
> How do you keep these promises on network and FUSE file systems?
I don't. This is shmem only.
Thanks
David
On 04/08/2014 06:00 AM, Florian Weimer wrote:
> 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 :-).
If you write a patch to prevent selinux from enforcing NX, I will ack
that patch with all my might. I don't know how far it would get me, but
I think that selinux has no business going anywhere near execmem.
Adding a clone mode to mremap might be a better bet. But memfd solves
that problem, too, albeit messily.
--Andy
On 04/09/2014 11:31 PM, David Herrmann wrote:
> On Tue, Apr 8, 2014 at 3:00 PM, Florian Weimer <[email protected]> wrote:
>> How do you keep these promises on network and FUSE file systems?
>
> I don't. This is shmem only.
Ah. What do you recommend for recipient to recognize such descriptors?
Would they just try to seal them and reject them if this fails?
--
Florian Weimer / Red Hat Product Security Team
Hi
On Tue, Apr 22, 2014 at 11:10 AM, Florian Weimer <[email protected]> wrote:
> Ah. What do you recommend for recipient to recognize such descriptors?
> Would they just try to seal them and reject them if this fails?
This highly depends on your use-case. Please see the initial email in
this thread. It describes 2 example use-cases. In both cases, the
recipients read the current set of seals and verify that a given set
of seals is set.
Thanks
David
On 04/22/2014 01:55 PM, David Herrmann wrote:
> Hi
>
> On Tue, Apr 22, 2014 at 11:10 AM, Florian Weimer <[email protected]> wrote:
>> Ah. What do you recommend for recipient to recognize such descriptors?
>> Would they just try to seal them and reject them if this fails?
>
> This highly depends on your use-case. Please see the initial email in
> this thread. It describes 2 example use-cases. In both cases, the
> recipients read the current set of seals and verify that a given set
> of seals is set.
I didn't find that very convincing. But in v2, seals are monotonic, so
checking them should be reliable enough.
What happens when you create a loop device on a write-sealed descriptor?
--
Florian Weimer / Red Hat Product Security Team
Hi
On Tue, Apr 22, 2014 at 2:44 PM, Florian Weimer <[email protected]> wrote:
> I didn't find that very convincing. But in v2, seals are monotonic, so
> checking them should be reliable enough.
Ok.
> What happens when you create a loop device on a write-sealed descriptor?
Any write-back to the loop-device will fail with EPERM as soon as the
fd gets write-sealed. See __do_lo_send_write() in
drivers/block/loop.c. It's up to the loop-device to forward the error
via bio_endio() to the caller for proper error-handling.
Thanks
David