On 8.12.2020 20.07, Andy Lutomirski wrote:
On Thu, Nov 19, 2020 at 10:05 AM Topi Miettinen <toiwoton@xxxxxxxxx> wrote:
On 19.11.2020 18.32, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Nov 19, 2020 at 08:17:08AM -0800, Andy Lutomirski wrote:
Hi udev people-
The upcoming Linux SGX driver has a device node /dev/sgx. User code
opens it, does various setup things, mmaps it, and needs to be able to
create PROT_EXEC mappings. This gets quite awkward if /dev is mounted
noexec.
Can udev arrange to make a device node executable on distros that make
/dev noexec? This could be done by bind-mounting from an exec tmpfs.
Alternatively, the kernel could probably learn to ignore noexec on
/dev/sgx, but that seems a little bit evil.
I'd be inclined to simply drop noexec from /dev by default.
We don't do noexec on either /tmp or /dev/shm (because that causes immediate
problems with stuff like Java and cffi). And if you have those two at your
disposal anyway, having noexec on /dev doesn't seem important.
I'd propose to not enable exec globally, but if a service needs SGX, it
could use something like MountOptions=/dev:exec only in those cases
where it's needed. That way it's possible to disallow writable and
executable file systems for most services (which typically don't need
/tmp or /dev/shm either). Of course the opposite
(MountOptions=/dev:noexec) would be also possible, but I'd expect that
this would be needed to be used more often.
I imagine the opposite would be more sensible. It seems odd to me
that we would want any SGX-using service to require both special mount
options and regular ACL permissions.
How common are thes SGX-using services? Will every service start using
it without any special measures taken on it's behalf, or perhaps only a
special SGX control tool needs access? What about unprivileged user
applications, do they ever want to access SGX? Could something like
Widevine deep in a browser need to talk to SGX in a DRM scheme?
As a further argument, I just did this on a Fedora system:
$ find /dev -perm /ugo+x -a \! -type d -a \! -type l
No results. So making /dev noexec doesn't seem to have any benefit.
It's no surprise that there aren't any executables in /dev since
removing MAKEDEV ages ago. That's not the issue, which is that /dev is a
writable directory (for UID=0 but no capabilities are needed) and thus a
potential location for constructing unapproved executables if it is also
mounted exec (W^X).
-Topi
