From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jarkko Sakkinen Date: Tue, 15 Dec 2020 04:19:03 +0000 Subject: Re: Antw: [EXT] Re: [systemd-devel] Creating executable device nodes in /dev? Message-Id: <20201215041903.GA21875@kernel.org> List-Id: References: <0f17eade-5e99-be29-fd09-2d0a1949ac7f@gmail.com> <9DF5C88B-5156-455A-BA3F-EB19CAA0411B@amacapital.net> <20201209001521.GA64007@kernel.org> <20201211104635.GD12091@kernel.org> <27796c04-249e-6cf0-c3e1-0fd657a82f9c@gmail.com> <5FD7137E020000A10003D81B@gwsmtp.uni-regensburg.de> In-Reply-To: <5FD7137E020000A10003D81B@gwsmtp.uni-regensburg.de> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: Ulrich Windl Cc: toiwoton@gmail.com, luto@amacapital.net, Ben Hutchings , jethro@fortanix.com, bruce.schlobohm@intel.com, kai.svahn@intel.com, luto@kernel.org, haitao.huang@linux.intel.com, jarkko.sakkinen@linux.intel.com, "systemd-devel@lists.freedesktop.org" , casey@schaufler-ca.com, sds@tycho.nsa.gov, linux-hotplug@vger.kernel.org, linux-sgx@vger.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-0fd657a82f9c@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