On 16.12.2020 12.03, Ulrich Windl wrote:
Jarkko Sakkinen <jarkko@xxxxxxxxxx> schrieb am 15.12.2020 um 05:19 in
Nachricht
<20201215041903.GA21875@xxxxxxxxxx>:
On Mon, Dec 14, 2020 at 08:25:50AM +0100, Ulrich Windl wrote:
Topi Miettinen <toiwoton@xxxxxxxxx> schrieb am 11.12.2020 um 12:46 in
Nachricht
<27796c04-249e-6cf0-c3e1-0fd657a82f9c@xxxxxxxxx>:
On 11.12.2020 12.46, Jarkko Sakkinen wrote:
On Wed, Dec 09, 2020 at 10:35:21AM +0200, Topi Miettinen wrote:
On 9.12.2020 2.15, Jarkko Sakkinen wrote:
On Wed, Dec 09, 2020 at 01:15:27AM +0200, Topi Miettinen wrote:
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).
UID 0 can just change mount options, though, unless SELinux or
similar
is
used. And SELinux can protect /dev just fine without noexec.
Well, mounting would need CAP_SYS_ADMIN in addition to UID 0. Also
SELinux
is not universal and the policies might not contain all users or
services.
‑Topi
What's the data that supports having noexec /dev anyway? With root
access I can then just use something else like /dev/shm mount.
Has there been out in the wild real world cases that noexec mount
of would have prevented?
For me this sounds a lot just something that "feels more secure"
without any measurable benefit. Can you prove me wrong?
I don't think security works that way. An attacker has various methods
to
choose from, some are more interesting than others. The case where
rw,exec
/dev would be interesting would imply that easier or more common
avenues
would be blocked, for example rw,exec /dev/shm, /tmp, /var/tmp, or
/run/user/$UID/ for user. Also fileless malware with pure ROP/JOP
approach
with no need for any file system access is getting more common. It
does
not
mean that it would not be prudent to block the relatively easy
approaches
too, including /dev.
What if we add a new mount option "chrexec", which allows exec
for character devices (S_IFCHR).
I think devices are a bad match for SGX because devices haven't been
executable and SGX is actually an operation for memory. So something
like memfd_create(, MFD_SGX) or mmap(,, PROT_READ|PROT_EXEC|PROT_SGX)
would be much more natural. Even better would be something that
conceptully also works for AMD version (either with the same flags or
MFD_SGX / MFD_whatever_the_AMD_version_is).
+1
SGX reserved memory from kernel's point of view is IO memory.
Mapping SGX to memfd would not be a great idea, as it does not map
into concept of anonymous file backed by regular memory.
A device file is very natural match actually. We have ioctl API for
uploading enclave pages during the build procedure to the enclave and
custom #PF handler. Conceptually it's a lot like video memory or such
special device specific memory area.
There's no AMD equivalent of this technology.
Hi!
Back to "noexec": AFAIR the execute bit does not make sense for device files,
and the purpose probably was to avoid execution of non-device files (e.g.
regular executables) from inside /dev (where they should not be). So in this
view "noexec" makes sense.
There were similar arguments for not allowing device files in user
directories.
PR#17940 (https://github.com/systemd/systemd/pull/17940) was merged, so
/dev will now on be mounted with "exec" by systemd.
I made issue #17942 (https://github.com/systemd/systemd/issues/17942) to
discuss related hardening options. I'm leaning towards
NoExecPaths=/ExecPaths= as it would enable nice hardening by
allow-listing of all executable content for system services with simple
directives like:
[Service]
NoExecPaths=/
ExecPaths=/usr/sbin/daemon /lib64/ld-linux-x86-64.so.2 /usr/lib
Then a service infected with malware would not be able to execute a
shell present in the system or downloaded later, if that was not
explicitly allowed. /dev would also not have "exec" flag by default, but
SGX could be allowed with "ExecPaths=/dev/sgx" when needed.
-Topi
