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

[Michael Stone]

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