Re: RFC: disablenetwork facility. (v4)

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

Michael Stone <michael@laptop.org> writes:

> Serge,
>
> I think that Pavel's point, at its strongest and most general, could be
> rephrased as:
>
>   "Adding *any* interesting isolation facility to the kernel breaks backwards
>    compatibility for *some* program [in a way that violates security goals]."

*some* privileged program.

> The reason is the one that I identified in my previous note:
>
>   "The purpose of isolation facilities is to create membranes inside which
>    grievous security faults are converted into availability faults."
>
> The question then is simply:
>
>   "How do we want to deal with the compatibility-breaking changes created by
>    introducing new isolation facilities?"

You have a very peculiar taxonomy of the suggestions,
that fails to capture the concerns.

I strongly recommend working out a way to disable
setuid exec.  Ideally we would use capabilities to
achieve this.  

Serge can we have a capability that unprivelged processes
normally have an can drop without privelege?

I can see one of two possible reasons you are avoiding the
suggestion to disable setuid root.
- You have a use for setuid root executables in your contained
  environment.  If you do what is that use?
- Disabling suid root executables is an indirect path to your
  goal.

The problem with the disable_network semantics you want
is that they allow you to perform a denial of service attack
on privileged users.  An unprivileged DOS attack is unsuitable
for a general purpose feature in a general purpose kernel.

Your sysctl, your boot option, your Kconfig option all fail
to be viable options for the same reason.  Your facility is
only valid in an audited userspace.

Disabling setuid-exec especially to a subset of processes is
valid in an unaudited userspace as it does not allow propagating
the DOS to privileged processes.

Eric