linux-kernel - Re: [PATCH v3] 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] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 20 Nov 2012 16:17:57 -0800
From:	Kees Cook <keescook@...omium.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	linux-kernel@...r.kernel.org,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	ellyjones@...omium.org, Kay Sievers <kay@...y.org>,
	Roland Eggner <edvx1@...temanalysen.net>
Subject: Re: [PATCH v3] devtmpfs: mount with noexec and nosuid

On Tue, Nov 20, 2012 at 4:05 PM, Alan Cox <alan@...rguk.ukuu.org.uk> wrote:
>> +config DEVTMPFS_SAFE
>> +     bool "Use nosuid,noexec mount options on devtmpfs"
>> +     depends on DEVTMPFS
>> +     help
>> +       This instructs the kernel to include the MS_NOEXEC and
>> +       MS_NOSUID mount flags when mounting devtmpfs. This prevents
>> +       certain kinds of code-execution attacks on embedded platforms.
>
> This description appears to be wrong as well as the code being pointless.
> It doesn't prevent any meaningful code execution attacks and the config
> entry might give people the delusion its useful or a security feature.

I'm not trying to say it's a magic cure-all. This feature is just for
trying to build a system that follows security best-practices: nothing
should be writable and executable, and that includes mount points.
Since the devtmpfs is mounted by the kernel, that's the logical place
to fix it. All the other mounts are triggered by userspace and pass
flags, so that's where those get fixed.

> Please provide a valid and meaningful example.

I don't need a specific example to follow best practices. Any example
I try to invent will appear far-fetched, but those are exactly the
kind of things that happen. Chaining a series of far-fetched
vulnerabilities is a reality, and trying to defend against those
things via simple best practices can be effective.

If you want an invented example, how about a uid-0 service (let's say
listening on dbus) that takes arguments for some command (say "df")
and let's say it's really badly written, and filters all shell metas
except ";" so it'll run "df -- $arg" where $arg can't contain any $IFS
characters, but can lead with a semi-colon, meaning it can run a
single command but can't control arguments. Let's say there's nothing
else on the system that just running it will cause a problem, and so a
second flaw in some other service (or maybe the same one) can write
files to arbitrary locations, and the only writable and executable
location in the filesystem tree is /dev (e.g. all other locations are
either read-only or noexec). So an attacker writes a file to /dev/evil
and then uses the other flaw to run it.

-Kees

-- 
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/