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

Michael Stone
2009-12-18T02:59:11Z

Mark, Andi, Eric, and Randy,

First, thanks for all the comments, questions, and suggestions. They're very
much appreciated.

@Randy: In the revised patches that follow, I moved the documentation to

Documentation/prctl/network.txt

as you requested.

@Américo: In the revised patches that follow, I moved prctl_{get,set}_network()
into sys/kernel.c as you suggested.

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

------------------------

@Andi, Mark

Next, let's talk about the "ad-hoc"-ness of the current patches. There seem to
be three issues:

1. What is "network access"?

2. How should "network access" be access-controlled?

3. Should we add a per-process boolean flag enabling and disabling some
kinds of network access?

Here are my thoughts:

1. "Network access" refers to the ability of a security principal to send
messages to or to receive messages from a different principal. For our
purposes, principals may be thought of as processes.

2. Messages are sent and received over "channels". Common channels include
open file descriptors, memory segments, message queues, file systems,
process signalling trees, and ptrace attachments.

3. The creation of new channels between principals is a security-sensitive
operation.

4. The decision about whether or not to authorize opening a new channel
between security principals should be based on five inputs:

a) the general system policy, if any, of the sysadmin
b) the personal policies, if any, of the human operator(s)
c) the authors' policies, if any, in security principal(s)
d) the channel being requested
e) security labels like pids, uids, and acls labeling the principals

5. Linux today has pretty good support for controlling the creation of
channels involving the filesystem and involving shared daemons. It has
mediocre support for access control involving sysv-ipc mechanisms. It has
terrible support for access control involving non-local principals like
"the collection of people and programs receiving packets sent to
destination 18.0.0.1:80 from source 192.168.0.3:34661".

6. We can make it easier and safer to write and to run software by improving
the access control mechanisms available for deciding whether or not to
open new channels.

7. The best way to improve said access control mechanisms today is to add a
facility that permits any process to drop the (heretofor not formally
recognized) privilege that causes the kernel to open new *insufficiently
access controlled* network channels.

8. Anything that has to pass a regular Unix uid/gid/world discretionary
access check *and* which the partner principal(s) have the opportunity to
turn down is sufficiently access controlled. Everything else is not.

(For example, filesystem Unix sockets are sufficiently controlled but
ptrace is not because the process being traced has no opportunity to say
"don't open this channel".)

9. My patch implements the simplest and most usable improvement available in
this area.

Critiques?

Alternately, you've both expressed some interest in a more general facility for
restricting network access. Do either of you have specific ideas on what you'd
like to see?

Michael