From mboxrd@z Thu Jan 1 00:00:00 1970 From: Topi Miettinen Date: Wed, 09 Dec 2020 08:58:02 +0000 Subject: Re: Creating executable device nodes in /dev? Message-Id: List-Id: References: <0f17eade-5e99-be29-fd09-2d0a1949ac7f@gmail.com> <9DF5C88B-5156-455A-BA3F-EB19CAA0411B@amacapital.net> <20201209001521.GA64007@kernel.org> <20201209004214.GA64820@kernel.org> In-Reply-To: <20201209004214.GA64820@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 9.12.2020 2.42, Jarkko Sakkinen wrote: > On Wed, Dec 09, 2020 at 02:15:28AM +0200, 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? > > Typo: "of" = "of /dev" > >> For me this sounds a lot just something that "feels more secure" >> without any measurable benefit. Can you prove me wrong? > > The debate is circled around something not well defined. Of course you > get theoretically more safe system when you decrease priviliges anywhere > in the system. Like you could start do grazy things with stuff that > unprivilged user has access, in order to prevent malware to elevate to > UID 0 in the first place. > > I think where this go intellectually wrong is that we are talking about > *default installation* of a distribution. That should have somewhat sane > common sense access control settings. For like a normal desktop user > noexec /dev will not do any possible favor. > > Then there is the case when you want to harden installation for an > application, let's' say some server. In that case you will anyway > fine-tune the security settings and go grazy enough with hardening. > When you tailor a server, it's a standard practice to enumerate and > adjust the mount points if needed. I think we agree that there's a need for either way to allow SGX (if default is hardened) or a hardening option (in the opposite case). For systemd I see two approaches: 1. Default noexec /dev, override with something like - ExecPaths=/dev - MountOptions=/dev:rw,exec,dev,nosuid - or even MountOptions=/dev/sgx:rw,exec,dev,nosuid - ProtectDev=no - AllowSGX=yes 2. Default exec /dev, override with - NoExecPaths=/dev - MountOptions=/dev:rw,noexec,dev,nosuid - ProtectDev=yes - DenySGX=yes I'd prefer 1. but of course 2. would be reasonable. > To summarize, I neither understand the intended target audience. We have something in common: me neither. What's the target audience for SGX? What's the use case? What are the users: browsers, system services? How would applications use SGX? Should udev rules for /dev/sgx make it available to any logged in users with uaccess tags? -Topi