Re: [RFC][PATCH v3] Unprivileged: Disable raising of privileges

[ebiederm@xmission.com (Eric W. Biederman)]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

>> - unprivileged process took action to prevent gaining a capability.
>> - exec'd suid sendmail.
>> - sendmail took action as root because it could not become someone else.
>
> Which is a classic bug and replicated historically in cpu time, quota and
> other similar "remove rights and then .." attacks.

Exactly.  The problem that most limits the evolution of the unix
userspace API for ordinary processes.  I want a per process disable so
I can use advanced features of the API without being root (or a subset
of root).

>> I would like to trivially stop that entire class of exploit by making
>> execing a suid ( or equivalent ) executable impossible.
>
> Fine the LSM modules can already build such policies or you can add a new
> LSM for it - it doesn't need whacky one off extensions to prctl.

No it needs a proper system call. no_suid_for_me_and_my_children().
Spelled nosuid to keep from breaking peoples fingers.

> Of course you could also have an LSM which undoes restrictions on suid
> apps instead. Thats an equally valid model, just don't load both at once
> and don't assume you have the one true model.

Alan what are you talking about?  LSMs are not allowed to remove
restrictions.

You are quite right that my initial patch is a bit hacky, I am doing
my development in the open, proving that the concept can be sanely
implemented with very little code, and getting feedback from people
who know the area of code better than I do.  I know development in the
open and not having everything perfect and committed to before you
submit a patch is a strange concept on linux-kernel, but I am trying
it out.

My target audience here are application developers.  Not professional
system administrators, not distribution maintainers, and certainly
not professional security trolls.

I am about removing an impediment from the unix API for those
applications that don't need it so they can use features that would
otherwise be reserved to root and only root, because those features
can be used to addle suid applications.

I am sick and fed up with the conversations that go:
- I want to do X.
- X has been implemented.
- Sorry I can't use X as implemented because you have to be root to
  use X.

In this case X was the network namespace, which for non-root
users happens to act just like the proposed disable_network.

Putting something in an LSM versus anywhere else in the kernel still
pollutes the pool and we still have to maintain it forever.  So my
preference is for something small, trivial, that people can easily
audit.

I am not satisfied with my patch to disable suid yet, but it does
look simple and in the right ballpark.  It certainly needs better
integration with securebits and the like.

So Alan would you please give some constructive criticism about:
- Why this is a bad idea.
- How to implement this so it is available to application developers
  in general.

As I see and I may be wrong the LSM and the security modules that
exist today are useless unless you control the entire machine the
kernel runs on.  Which applications short of Oracle do not.

Personally I think I am on the sent of a good general feature that
makes sense, is useful in a lot of situations, is useful to a lot of
different people, and is useful in a lot of different ways.

Anything we merge into the mainstream kernel we have to maintain
forever, LSM or core feature.  I think this is a good backwards
compatible feature that removes impediments to forward compatibility.

Eric