[systemd-devel] Antw: [EXT] Re: Creating executable device nodes in /dev?

Tue Dec 22 22:14:37 UTC 2020

On Wed, Dec 16, 2020 at 03:05:05PM +0200, Topi Miettinen wrote:
> On 16.12.2020 12.03, Ulrich Windl wrote:
> > > > > Jarkko Sakkinen <jarkko at kernel.org> schrieb am 15.12.2020 um 05:19 in
> > Nachricht
> > <20201215041903.GA21875 at kernel.org>:
> > > On Mon, Dec 14, 2020 at 08:25:50AM +0100, Ulrich Windl wrote:
> > > > > > > Topi Miettinen <toiwoton at gmail.com> schrieb am 11.12.2020 um 12:46 in
> > > > Nachricht
> > > > <27796c04-249e-6cf0-c3e1-0fd657a82f9c at gmail.com>:
> > > > > 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.

OK, this sounds relieving, thank you (late resp, I was vacation last
week).

> -Topi

/Jarkko