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