[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20091227010441.GA12077@heat>
Date: Sat, 26 Dec 2009 20:04:41 -0500
From: Michael Stone <michael@...top.org>
To: linux-kernel@...r.kernel.org
Cc: netdev@...r.kernel.org, linux-security-module@...r.kernel.org,
Andi Kleen <andi@...stfloor.org>, David Lang <david@...g.hm>,
Oliver Hartkopp <socketcan@...tkopp.net>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
Herbert Xu <herbert@...dor.apana.org.au>,
Valdis Kletnieks <Valdis.Kletnieks@...edu>,
Bryan Donlan <bdonlan@...il.com>,
Evgeniy Polyakov <zbr@...emap.net>,
"C. Scott Ananian" <cscott@...ott.net>,
James Morris <jmorris@...ei.org>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Bernie Innocenti <bernie@...ewiz.org>,
Mark Seaborn <mrs@...hic-beasts.com>,
Randy Dunlap <randy.dunlap@...cle.com>,
Américo Wang <xiyou.wangcong@...il.com>,
Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
Samir Bellabes <sam@...ack.fr>,
Casey Schaufler <casey@...aufler-ca.com>,
"Serge E. Hallyn" <serue@...ibm.com>, Pavel Machek <pavel@....cz>,
Michael Stone <michael@...top.org>
Subject: RFC: disablenetwork facility. (v4)
Here's version 4 of my disablenetwork facility and a recap of the significant
design choices so far:
1. Per Ulrich's request, we provide the initial userland interface through
prctl() rather than through *rlimit() (or through sys_disablenetwork()).
2. Per Alan's request, we use the existing security_*() hook callsites to
integrate the access control logic into the networking subsystem.
3. The access control state and logic are now conditionally compiled under
the CONFIG_SECURITY_DISABLENETWORK option. The interface calls return
-ENOSYS when this symbol is not defined.
4. In order to interoperate with as easily as possible with existing LSMs, we
store our state in a new (conditionally compiled) task_struct field named
current->network rather than in current->security. The access control
logic is called directly from the appropriate security_*() hook
implementations in security/security.c, as was done for IMA.
5. Per GeoffX's suggestion, the interface functions now take pointers to user
memory rather than passing the value of the flag field back and forth
directly. This permits prctl(PR_GET_NETWORK) to return an error code.
6. At the moment, we exempt all local networking which requires action by
both the sender and receiver and which has discretionary access control
comparable to regular Unix filesystem DAC.
In practice, this means that we leave all unix sockets, sysv IPC, and
kill()/killpg() alone.
We intercept ptrace() because it's effect on the receiver is "involuntary"
and we intercept socket_create(), socket_bind(), socket_connect(), and
socket_sendmsg() because they're not otherwise access-controlled.
sendmsg() on previously connected sockets is exempted.
7. The documentation, kconfig option, and access control logic are named
"disablenetwork" because that's the name of the functionality. The fact
that it's exposed through prctl is incidental to its purpose and semantics
and may become less exclusively true in the future, e.g., if we decide
that we want a /proc interface for reading the networking restrictions of
other processes.
Further suggestions?
Regards,
Michael
Michael Stone (3):
Security: Add disablenetwork interface. (v4)
Security: Implement disablenetwork semantics. (v4)
Security: Document disablenetwork. (v4)
Documentation/disablenetwork.txt | 84 ++++++++++++++++++++++++++++++++++++++
include/linux/disablenetwork.h | 22 ++++++++++
include/linux/prctl.h | 7 +++
include/linux/prctl_network.h | 7 +++
include/linux/sched.h | 4 ++
kernel/sys.c | 53 ++++++++++++++++++++++++
security/Kconfig | 11 +++++
security/Makefile | 1 +
security/disablenetwork.c | 73 +++++++++++++++++++++++++++++++++
security/security.c | 76 ++++++++++++++++++++++++++++++++--
10 files changed, 333 insertions(+), 5 deletions(-)
create mode 100644 Documentation/disablenetwork.txt
create mode 100644 include/linux/disablenetwork.h
create mode 100644 include/linux/prctl_network.h
create mode 100644 security/disablenetwork.c
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists