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

[Christian Brauner <christian.brauner@ubuntu.com>]

On Fri, Dec 11, 2020 at 12:29:31PM +0100, Greg KH wrote:
> On Fri, Dec 11, 2020 at 12:46:35PM +0200, 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).
> 
> Oh please no.

Greg's right. That's very obviously a horrible hack so this is an
instant nak from my side.

Christian