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:	Wed, 21 Nov 2012 00:29:55 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Kees Cook <keescook@...omium.org>
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

> 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

If you want to talk about security practices then please do so rather
than using it as a magic label for cluelessness.

> I don't need a specific example to follow best practices. Any example

Yes you do. You should be able to accurately describe the attack vector,
the bounding constraints and the breach of those constraints.. so your
example will do fine.

> 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.

Which is fixed by using a mount syscall in userspace. Even better that
can be done and deployed on existing systems without a kernel change and
without having to move to a new kernel. From a good practice point of
view you are arguing for the wrong thing - poorer comaptibility, riskier
deployment, more code executed at higher privilege levels.

The *only* case I can see where the feature is useful is enforcing no
exec on /dev/ except for (potentially specific) device nodes. I can do
that today with AppArmour, Smack or SELinux but having a lighter way to
do it might be useful.

Alan

--
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/