linux-kernel - Re: [PATCH] devtmpfs: mount with noexec and nosuid

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 20 Nov 2012 00:55:40 +0100
From:	Roland Eggner <edvx1@...temanalysen.net>
To:	Kees Cook <keescook@...omium.org>
Cc:	Kay Sievers <kay@...y.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-kernel@...r.kernel.org, ellyjones@...omium.org
Subject: Re: [PATCH] devtmpfs: mount with noexec and nosuid

On 2012-11-19 Monday at 10:14 -0800 Kees Cook wrote:
> On Fri, Nov 16, 2012 at 4:39 PM, Kay Sievers <kay@...y.org> wrote:
> > On Sat, Nov 17, 2012 at 1:27 AM, Greg Kroah-Hartman
> > <gregkh@...uxfoundation.org> wrote:
> >> On Fri, Nov 16, 2012 at 04:20:16PM -0800, Kees Cook wrote:
> >>> Since devtmpfs is writable, make the default noexec nosuid as well. This
> >>> protects from the case of a privileged process having an arbitrary file
> >>> write flaw and an argumentless arbitrary execution (i.e. it would lack
> >>> the ability to run "mount -o remount,exec,suid /dev"), with a system
> >>> that already has nosuid,noexec on all other writable mounts.
> >>>
> >>> Cc: ellyjones@...omium.org
> >>> Signed-off-by: Kees Cook <keescook@...omium.org>
> >>> ---
> >>>  drivers/base/devtmpfs.c |    6 ++++--
> >>>  1 file changed, 4 insertions(+), 2 deletions(-)
> >>
> >> Have you tested this to verify that it doesn't break anything?
> >>
> >> Kay, could this cause any problems that you could think of?
> >
> > It breaks all sorts of old, possibly outdated, stuff, that does things
> > like mapping /dev/mem executable. It for sure used to break X drivers,
> > that fiddle with the BIOS of cards.
> 
> Ah, yeah, you're totally right. Attempting an mmap with PROT_EXEC on
> /dev/mem would be denied.

Sidenote:  non-executable devtmpfs + nouveau + KMS + xorg works for me:

uname -mrs
..........
Linux 3.2.33-grsecurity.roland.0 x86_64

grep devtmpfs /etc/{fs,m}tab /proc/{$$/mountinfo,mounts}
........................................................
/etc/fstab:devtmpfs     /dev    devtmpfs        rw,noexec,nosuid,size=8m,nr_inodes=16k,mode=0755        0       0
/etc/mtab:devtmpfs /dev devtmpfs rw,noexec,nosuid,size=8m,nr_inodes=16k,mode=0755 0 0
/proc/10358/mountinfo:18 15 0:5 / /dev rw,nosuid,noexec - devtmpfs devtmpfs rw,size=8192k,nr_inodes=16384,mode=755
/proc/mounts:devtmpfs /dev devtmpfs rw,nosuid,noexec,size=8192k,nr_inodes=16384,mode=755 0 0

lspci -d 10de:0a3c -k -nn
.........................
01:00.0 VGA compatible controller [0300]: nVidia Corporation GT216 [Quadro FX 880M] [10de:0a3c] (rev a2)
        Subsystem: Dell Device [1028:040c]
        Kernel driver in use: nouveau

ps -p $( pgrep -d, xinit ) -F
.............................
UID        PID  PPID  C    SZ   RSS PSR STIME TTY          TIME CMD
roland    9514  9478  0 16583   844   2 Nov02 tty6     00:00:00 xinit /etc/X11/xinit/xinitrc -- /usr/bin/X :0 -auth /home/roland/.serverauth.9478
qemu     11486 11463  0 12723   848   0 Nov02 tty30    00:00:00 xinit /etc/X11/xinit/xinitrc -- /usr/bin/X :1 -auth /home/qemu/.serverauth.11463
opera    12273 12240  0  8973   848   3 Nov02 tty18    00:00:00 xinit /etc/X11/xinit/xinitrc -- /usr/bin/X :2 -auth /home/opera/.serverauth.12240


> Is this something we could put behind a CONFIG?

IMHO would be great :)

-- 
Roland

Content of type "application/pgp-signature" skipped