* Re: disablenetwork (v5): Simplify the disablenetwork sendmsg hook. [not found] ` <20100117170431.GA2949@heat> @ 2010-01-17 18:04 ` Michael S. Tsirkin 2010-01-17 18:25 ` Alan Cox 0 siblings, 1 reply; 3+ messages in thread From: Michael S. Tsirkin @ 2010-01-17 18:04 UTC (permalink / raw) To: Michael Stone Cc: Anthony Liguori, linux-kernel, netdev, linux-security-module On Sun, Jan 17, 2010 at 12:04:32PM -0500, Michael Stone wrote: > Michael Tsirkin wrote: >> On Fri, Jan 15, 2010 at 03:12:46AM -0500, Michael Stone wrote: >>> The idea is that calls like >>> >>> sendto(fd, buffer, len, 0, NULL, 0); >>> send(fd, buffer, len, 0) >>> write(fd, buffer, len) >>> >>> are all to be permitted but that calls like >>> >>> sendto(fd, buffer, len, 0, (struct sockadr *) &addr, sizeof(addr)); >>> >>> are to be rejected when the current task's network is disabled on the grounds >>> that the former calls must use previously connected sockets but that the latter >>> socket need not have been previously connected. >>> >>> Signed-off-by: Michael Stone <michael@laptop.org> >> >> Michael, if I understand correctly, with this patch one could use >> disablenetwork to pass an af_packet socket bound to a device to a >> task, and make sure that the task does not use it to inject packets into >> another device? > > Michael, > > Thanks for writing. If I understand you correctly, you're asking: > > May a network-disabled process use recvmsg() with SCM_RIGHTS control messages > to receive a file descriptor pointing to previously connected or bound > AF_PACKET socket and, having received such an fd, may the network-disabled > process use the socket normally? > > If I've understood correctly, then the answer is "yes, to the extent that you > can't do stupid things with sendmsg(), fnctl(), ioctl(), and friends." > > I intend to look more carefully at the ability to use those calls to do stupid > things in coming weeks. > > Does this help? > > Regards, > > Michael > > P.S. - Incidentally, what is the nature of your interest? We discussed using af_packet sockets for networking in qemu. qemu is a large project so it might not be a great idea to run it as root all the time: a better idea is to e.g. get fd from a priveledged server. However, we'd like to limit qemu even more, so that it can only use the fd for send/receive. > (And was your question intentionally or accidentally off-list?) Oops. Adding it back. -- MST ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: disablenetwork (v5): Simplify the disablenetwork sendmsg hook. 2010-01-17 18:04 ` disablenetwork (v5): Simplify the disablenetwork sendmsg hook Michael S. Tsirkin @ 2010-01-17 18:25 ` Alan Cox 0 siblings, 0 replies; 3+ messages in thread From: Alan Cox @ 2010-01-17 18:25 UTC (permalink / raw) To: Michael S. Tsirkin Cc: Michael Stone, Anthony Liguori, linux-kernel, netdev, linux-security-module > >>> are all to be permitted but that calls like > >>> > >>> sendto(fd, buffer, len, 0, (struct sockadr *) &addr, sizeof(addr)); > >>> > >>> are to be rejected when the current task's network is disabled on the grounds > >>> that the former calls must use previously connected sockets but that the latter > >>> socket need not have been previously connected. Not surprised to see this "simple" idea is unsurprisingly turning incredibly complex, full of policy and also holes. Can people now accept that the reason we have rather more complex models for security policy is because generally speaking these "oh so simple" little magic switches don't actually work or solve any real world problems. And just to point out further problems - there are numerous cases where I can control the remote destination of messages without using sendto or passing addresses in obvious manners. You'll need to parse all the ioctls and protocol specific calls as a starter. You'll also need a policy engine of some form to detect when I can use send stuff in one socket I have rights to in order to influence routing of another by talking to network stuff or emitting controlling messages of any form. (and even then there are tons of cases you can't fix that way as the early Java people found to their cost. Things like connecting to a web server via a socket that can only connect to port 80 and issuing proxy requests, or triggering a remote carefully placed cgi script to produce tunnels with total control. Alan ^ permalink raw reply [flat|nested] 3+ messages in thread
* disablenetwork (v5) patches @ 2010-01-15 8:10 Michael Stone 2010-01-15 8:12 ` disablenetwork (v5): Simplify the disablenetwork sendmsg hook Michael Stone 0 siblings, 1 reply; 3+ messages in thread From: Michael Stone @ 2010-01-15 8:10 UTC (permalink / raw) To: linux-kernel Cc: netdev, linux-security-module, Andi Kleen, David Lang, Oliver Hartkopp, Alan Cox, Herbert Xu, Valdis Kletnieks, Bryan Donlan, Evgeniy Polyakov, C. Scott Ananian, James Morris, Eric W. Biederman, Bernie Innocenti, Mark Seaborn, Randy Dunlap, Américo Wang, Tetsuo Handa, Samir Bellabes, Casey Schaufler, Serge E. Hallyn, Pavel Machek, Al Viro As promised, here are patches implementing and documenting a CAP_SETPCAP-gated "enable" bit along with a couple of other tweaks discussed earlier in the thread. For ease of development and review, the following four patches extend the disablenetwork (v4) patch series rather than replacing it. Enjoy, Michael ^ permalink raw reply [flat|nested] 3+ messages in thread
* disablenetwork (v5): Simplify the disablenetwork sendmsg hook. 2010-01-15 8:10 disablenetwork (v5) patches Michael Stone @ 2010-01-15 8:12 ` Michael Stone 0 siblings, 0 replies; 3+ messages in thread From: Michael Stone @ 2010-01-15 8:12 UTC (permalink / raw) To: linux-kernel Cc: netdev, linux-security-module, Andi Kleen, David Lang, Oliver Hartkopp, Alan Cox, Herbert Xu, Valdis Kletnieks, Bryan Donlan, Evgeniy Polyakov, C. Scott Ananian, James Morris, Eric W. Biederman, Bernie Innocenti, Mark Seaborn, Randy Dunlap, Américo Wang, Tetsuo Handa, Samir Bellabes, Casey Schaufler, Serge E. Hallyn, Pavel Machek, Al Viro The idea is that calls like sendto(fd, buffer, len, 0, NULL, 0); send(fd, buffer, len, 0) write(fd, buffer, len) are all to be permitted but that calls like sendto(fd, buffer, len, 0, (struct sockadr *) &addr, sizeof(addr)); are to be rejected when the current task's network is disabled on the grounds that the former calls must use previously connected sockets but that the latter socket need not have been previously connected. Signed-off-by: Michael Stone <michael@laptop.org> --- security/disablenetwork.c | 9 ++++----- 1 files changed, 4 insertions(+), 5 deletions(-) diff --git a/security/disablenetwork.c b/security/disablenetwork.c index f45ddfc..27b88d7 100644 --- a/security/disablenetwork.c +++ b/security/disablenetwork.c @@ -56,11 +56,10 @@ int disablenetwork_security_socket_connect(struct socket * sock, int disablenetwork_security_socket_sendmsg(struct socket * sock, struct msghdr * msg, int size) { - if (sock->sk->sk_family != PF_UNIX && - current->network && - (msg->msg_name != NULL || msg->msg_namelen != 0)) - return -EPERM; - return 0; + /* permit sockets which are PF_UNIX or connected; check others. */ + if (sock->sk->sk_family == PF_UNIX || msg->msg_name == NULL) + return 0; + return maybe_allow(); } int disablenetwork_security_ptrace_access_check(struct task_struct *child, -- 1.6.6.rc2 ^ permalink raw reply related [flat|nested] 3+ messages in thread
end of thread, other threads:[~2010-01-17 18:25 UTC | newest] Thread overview: 3+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <20100117161053.GG3420@redhat.com> [not found] ` <20100117170431.GA2949@heat> 2010-01-17 18:04 ` disablenetwork (v5): Simplify the disablenetwork sendmsg hook Michael S. Tsirkin 2010-01-17 18:25 ` Alan Cox 2010-01-15 8:10 disablenetwork (v5) patches Michael Stone 2010-01-15 8:12 ` disablenetwork (v5): Simplify the disablenetwork sendmsg hook Michael Stone
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).