Re: disablenetwork (v5): Simplify the disablenetwork sendmsg hook.

Re: disablenetwork (v5): Simplify the disablenetwork sendmsg hook.

[Michael S. Tsirkin]

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

Re: disablenetwork (v5): Simplify the disablenetwork sendmsg hook.

[Alan Cox]

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

disablenetwork (v5): Simplify the disablenetwork sendmsg hook.

[Michael Stone]

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