netdev - Re: IP_TRANSPARENT requires CAP_NET_ADMIN

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHo-OozTNa8gtCuhSZm+aBqK-J0-eGMyr5rJBfTV6SmPZNhQVw@mail.gmail.com>
Date:	Thu, 1 Sep 2011 14:25:58 -0700
From:	Maciej Żenczykowski <zenczykowski@...il.com>
To:	Linux NetDev <netdev@...r.kernel.org>
Cc:	David Miller <davem@...emloft.net>,
	Balazs Scheidler <bazsi@...abit.hu>,
	Patrick McHardy <kaber@...sh.net>,
	KOVACS Krisztian <hidden@...abit.hu>,
	YOSHIFUJI Hideaki <yoshfuji@...ux-ipv6.org>
Subject: Re: IP_TRANSPARENT requires CAP_NET_ADMIN - why?

> I'm curious why transparent sockets [setsockopt(IP{,V6}_TRANSPARENT),
> ie. inet_sk(sk)->transparent bit] require CAP_NET_ADMIN privileges.
>
> Wouldn't CAP_NET_RAW be more appropriate?
>
> Looks to me like CAP_NET_RAW is all about raw sockets.
> Transparent sockets are dangerous because they effectively allow spoofing.
> But this seems to be the same sort of thing that CAP_NET_RAW protects
> against.
>
> Is there something I'm missing?
> Is there any reason why having CAP_NET_RAW privs shouldn't allow one
> to set the transparent bit on a socket?
>
> Would people be opposed to relaxing the check on setting sk->transparent
> to be either CAP_NET_ADMIN or CAP_NET_RAW?

Why am I even interested?  I have a couple of apps (dns servers, web
servers, load balancers, web crawlers) that
don't require any special permissions except the ability to use any ip
as the source ip for a listening tcp, outgoing tcp, and/or udp socket.
For example machines may receive arbitrary traffic over a tunnel (with
absolutely any ip as the destination ip within the tunneled payload)
and need to respond to it, hence they need to be able to respond with
any ip as the source ip.  This can be achieved with combinations of
routing tricks and/or ip non local bind and/or ip_transparent.

The way I see it there are a couple possibilities.

a) Leave as is: IP{,V6}_TRANSPARENT requires CAP_NET_ADMIN

   This seems like the least desirable solution, we end up requiring a
much more powerful privilege then necessary.

b) Backward compatible: Make it require one of CAP_NET_ADMIN or CAP_NET_RAW

   Better, but kind of ugly in there being two permissions that allow this.

c) Not-backward compatible: Make it require CAP_NET_RAW instead of CAP_NET_ADMIN

   Better, in that a less powerful privilege is required, but *does*
break non-root software which uses CAP_NET_ADMIN to get TRANSPARENT
sockets.
   Also the gain isn't that great, in that we are still using a
privilege which is a little too powerful.

d) Add a new capability: Make it require CAP_NET_ADMIN or CAP_NET_TRANSPARENT

  Again backward compatible - ugly.

e) Add a new capability: Make it require CAP_NET_ADMIN or CAP_NET_RAW
or CAP_NET_TRANSPARENT

  Again backward compatible - ugly.  The reason for allowing
CAP_NET_RAW is that it effectively already allows this to be done with
raw sockets in a less useful way.  ie. AFAICT CAP_NET_TRANSPARENT is a
subset of CAP_NET_RAW

f) Add a new capability: Make it require CAP_NET_TRANSPARENT instead
of CAP_NET_ADMIN

  Not backward compatible, introduces a new capability, however, long
term this is probably the cleanest.

My personal vote is for (f).  I figure the number of non-root-apps
that have CAP_NET_ADMIN in order to get IP{,V6}_TRANSPARENT support is
very low, and they should be easy to fix to request
CAP_NET_TRANSPARENT instead.

Any opinions?

Maciej
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html