Received-SPF: pass (google.com: best guess record for domain of selinux-refpolicy-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
From:   Nicolas Iooss <nicolas.iooss@m4x.org>
Date:   Sun, 10 Nov 2019 19:32:43 +0100
Message-ID: <CAJfZ7=kwLVohyjoeTBx7Kmf=31qnubR1gTrJUbcZF+EB1Gbciw@mail.gmail.com>
Subject: Intent to add support for cryfs
To:     refpolicy <selinux-refpolicy@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: selinux-refpolicy-owner@vger.kernel.org
Precedence: bulk

Hello,
I am using CryFS (https://www.cryfs.org/) in order to encrypt some
files in a shared directory. Before writing a policy for this software
and upstreaming it to refpolicy, I am wondering how this should be
handled.

CryFS is a software that can be run by non-root users that have access
to /dev/fuse. Its command is directly used to mount a directory
("/usr/bin/cryfs basedir mountpoint"), like command "mount".
Unmounting a mountpoint is done with "fusermount -u mountpoint",
/usr/bin/fusermount being a setuid-root program labeled mount_exec_t.
Currently, sysadm_t cannot use CryFS because it is not allowed to open
and use /dev/fuse (ie. fuse_device_t). Moreover labeling CryFS as
mount_exec_t makes mount_t require more accesses (reading a
configuration file from the base directory, reading
/proc/sys/crypto/fips_enabled, using pipes, etc.).

Therefore I am thinking of creating a new policy module for cryfs,
which could be shared with other similar software like EncFS
(https://vgough.github.io/encfs/). Does this sound like something
acceptable? Did I miss an existing module that can be extended in
order to support CryFS?

Thanks,
Nicolas