Re: [PATCH v3] devtmpfs: mount with noexec and nosuid

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

> 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