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

[Michael Stone <michael@laptop.org>]

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-security-module" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html