Re: RFC: disablenetwork facility. (v4)

[Michael Stone]

Eric Biederman writes:
> Serge,
>
> Michael Stone <michael@xxxxxxxxxx> writes:
> > 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.

Your amendment is a good one; it makes the statement better reflect your and
Pavel's concern. Thanks.

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

Do you agree with my assessment that this is fundamentally a
backwards-compatibility problem with security consequences?

> I strongly recommend working out a way to disable
> setuid exec.  Ideally we would use capabilities to
> achieve this.  
>
> ...
>
> I can see one of two possible reasons you are avoiding the
> suggestion to disable setuid root...

Heard and understood. I'll start thinking about how to do it (and about what
the consequences might be). However, those aren't my reasons for wariness.

My reasons have to do with history, preparation, and logic: 

  1. I first began playing with disablenetwork about two years ago and I missed
     both the need to restrict ptrace and the fact that the interaction with
     privileged executables would be a problem for other people.

  2. With disablenetwork, I was already building on clear (if slightly
     incomplete) design by djb. We have none of that prep work here.

  3. We have definite reasons, laid out by my argument above about the general
     compatibility cost of isolation facilities, to suspect that disablesuid
     in any form will break at least one other interesting use case. I don't
     know what that use case is yet but I'm fairly sure that it exists.

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

Then where did rlimits come from? rlimits *can* DoS privileged processes and
people are pretty much okay with the idea. People who are concerned can raise
the rlimits in their privileged processes and get on with life.

Second, as you point out, I am willing to audit and to modify my setuid
executables *in exchange* for having a kernel that changes in useful ways.
Obviously, not everyone is willing to pay this upkeep.

At any rate, I hope all this helps make my position clearer. I'll think more
about your suggestions.

Regards,

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