From mboxrd@z Thu Jan 1 00:00:00 1970 From: Topi Miettinen Date: Fri, 11 Dec 2020 11:46:03 +0000 Subject: Re: Creating executable device nodes in /dev? Message-Id: <27796c04-249e-6cf0-c3e1-0fd657a82f9c@gmail.com> 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> In-Reply-To: <20201211104635.GD12091@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Jarkko Sakkinen Cc: Andy Lutomirski , Andy Lutomirski , =?UTF-8?Q?Zbigniew_J=c4=99drzejewski-Szmek?= , linux-hotplug@vger.kernel.org, systemd Mailing List , Jarkko Sakkinen , Jethro Beekman , Casey Schaufler , linux-sgx@vger.kernel.org, "Svahn, Kai" , "Schlobohm, Bruce" , Stephen Smalley , Haitao Huang , Ben Hutchings 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). -Topi