Re: [PATCH] Security: Add prctl(PR_{GET,SET}_NETWORK) interface.

[Mark Seaborn <mrs@mythic-beasts.com>]

On Fri, Dec 18, 2009 at 3:00 AM, Michael Stone <michael@laptop.org> wrote:

> @Eric, Mark: regarding ptrace()-ing from network-disabled processes: I agree
> that this functionality is critical and I have altered the
> __ptrace_may_access() check to support it.
> The new rule I propose is equivalent to the rule I used in ptrace_set_network()
> and is similar to the rule that Eric proposed earlier this afternoon. I now
> propose:
>
>  "You may ptrace() any process that has all the network restrictions you do."
>
> This should take care of your use of strace without bending anything else into
> an unnatural shape.

I am in two minds about this.  On the one hand, it adds the
flexibility that I asked for.  On the other hand, it is a more
complicated rule to have fixed in the kernel.

It still seems wrong to me that the disable-networking flag should
affect ptrace() at all.

The reason is that the disable-networking flag is not useful on its
own.  Anyone who uses it will use it in combination with some other
authority-limiting mechanism.  They will already have a story for how
to prevent sandboxed processes with interfering with other processes
via ptrace(), kill(), writing to ~/.bashrc, etc.  There's no point in
disabling network access for a process if it has full access to your
home directory and can cause programs to be run with your full
authority as a user.

So if there is already a way to control access to ptrace(), we
shouldn't add another check to the kernel's access control rules.
They are complicated enough already.


On ad-hocness: I am very much in favour of providing unprivileged
mechanisms for switching off sources of ambient authority.  But it
does not seem very useful to provide an unprivileged mechanism to
switch off network access if there is no unprivileged mechanism for
switching off access to the filesystem namespace, which is usually a
more important source of authority.  Maybe we should solve both
problems?

Cheers,
Mark