Re: [systemd-devel] Antw: [EXT] Re: Creating executable device nodes in /dev?
On Wed, Dec 16, 2020 at 03:05:05PM +0200, Topi Miettinen wrote: > On 16.12.2020 12.03, Ulrich Windl wrote: > > > > > Jarkko Sakkinen schrieb am 15.12.2020 um 05:19 in > > Nachricht > > <20201215041903.ga21...@kernel.org>: > > > On Mon, Dec 14, 2020 at 08:25:50AM +0100, Ulrich Windl wrote: > > > > > > > Topi Miettinen schrieb am 11.12.2020 um > > > > > > > 12:46 in > > > > Nachricht > > > > <27796c04-249e-6cf0-c3e1-0fd657a82...@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
Re: [systemd-devel] Antw: [EXT] Re: Creating executable device nodes in /dev?
On 16.12.2020 12.03, Ulrich Windl wrote: Jarkko Sakkinen schrieb am 15.12.2020 um 05:19 in Nachricht <20201215041903.ga21...@kernel.org>: On Mon, Dec 14, 2020 at 08:25:50AM +0100, Ulrich Windl wrote: Topi Miettinen schrieb am 11.12.2020 um 12:46 in Nachricht <27796c04-249e-6cf0-c3e1-0fd657a82...@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. -Topi ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: [EXT] Re: Creating executable device nodes in /dev?
>>> Jarkko Sakkinen schrieb am 15.12.2020 um 05:19 in Nachricht <20201215041903.ga21...@kernel.org>: > On Mon, Dec 14, 2020 at 08:25:50AM +0100, Ulrich Windl wrote: >> >>> Topi Miettinen schrieb am 11.12.2020 um 12:46 in >> Nachricht >> <27796c04-249e-6cf0-c3e1-0fd657a82...@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. Regards, Ulrich > > /Jarkko ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: [EXT] Re: Creating executable device nodes in /dev?
On Tue, Dec 15, 2020 at 06:19:09AM +0200, Jarkko Sakkinen wrote: > On Mon, Dec 14, 2020 at 08:25:50AM +0100, Ulrich Windl wrote: > > >>> Topi Miettinen schrieb am 11.12.2020 um 12:46 in > > Nachricht > > <27796c04-249e-6cf0-c3e1-0fd657a82...@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. Anyway, I take a not on "PROT_SGX" as one of the ways sort this out in the future. That would at least fit what we have. Thanks for all the feedback. /Jarkko ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: [EXT] Re: Creating executable device nodes in /dev?
On Mon, Dec 14, 2020 at 08:25:50AM +0100, Ulrich Windl wrote: > >>> Topi Miettinen schrieb am 11.12.2020 um 12:46 in > Nachricht > <27796c04-249e-6cf0-c3e1-0fd657a82...@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. /Jarkko ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: [EXT] Re: Creating executable device nodes in /dev?
On Wed, Dec 09, 2020 at 08:58:52AM +0100, Ulrich Windl wrote: > >>> Jarkko Sakkinen schrieb am 09.12.2020 um 01:15 in > >>> Nachricht > <20201209001521.ga64...@kernel.org>: > > ... > > > > 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 think the better question is: Why not allow it? I.e.: Why do you want to > forbid it? > > Event though I wouldn't like it myself, I could even think of noexec /tmp. On an instance of an OS you should limit whatever is appropriate for your use case. The debate is about sane defaults. My argument is essentially that noexec /dev is not a sane default. For anyone to who this makes sense, does such thing anyway. For others, noexec /dev is only artificially useful. > Regards, > Ulrich /Jarkko ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
