IP_TRANSPARENT requires CAP_NET_ADMIN - why?

Hi,

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?

Thanks,
Maciej

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

Hi,

On Thu, 2011-09-01 at 14:25 -0700, Maciej Żenczykowski wrote:

quoted

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?

Well, the reason for choosing CAP_NET_ADMIN is that the original tproxy
functionality in Linux 2.2 required that cap, and we never questioned
it. Also, earlier the bits in the capability mask was a scarce resource
earlier. But see more info at the end of this email.

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.

I was a bit involved in a capability change earlier, in the syslog-ng
context. It is quite ugly, but doable.

For a new capability to work correctly the following changes must
trickle down to distributions:

  1) new kernel
  2) very recent glibc
  3) new libcap (both devel & runtime)
  4) patched applications (compiled against a new libcap)

If any of those is not yet patched, it won't work. Users tend to upgrade
the kernel and applications but rarely do so with the rest of the
userspace stack, e.g. libcap, which has caused some pain with syslog-ng.

The way that it was did for CAP_SYSLOG is that for a time CAP_SYSLOG
already worked, and the older cap CAP_SYS_ADMIN works too, but displays
an ugly oops-like kernel warning.

Certainly all of these can be worked around:

1) kernel

well, it's up to the user, but if the kernel is older than the one which
supports CAP_NET_TRANSPARENT, there's no issue.

2) glibc

The only way to detect if the kernel supports cap is to read the
capability bounding set, which uses a prctl() option that is defined by
a very new glibc (and kernel 2.6.25)

In syslog-ng, we had to define the value for PR_CAPBSET_READ in case it
wasn't defined.

3) libcap

The value for CAP_NET_TRANSPARENT is in the header file (e.g. devel
package), but that's not enough. We've seen distros, where the header
did contain the capability, but the runtime didn't know about the new
cap. I'm not sure why that happens, but it did on Fedora 15

https://bugzilla.balabit.com/show_bug.cgi?id=108#c24

The runtime needs to know about the new capability when transforming a
string representation to a bitset.

4) new apps

Well, the solution is not very easy to get right, and there's still some
problems with syslog-ng even after a couple of rounds. (see the end of
the quoted bugzilla ticket).

All this described to say that it is certainly doable, but requires
effort to get right and will definitely need to define a grace period
for which it is backward compatible. 

Somewhat less effort is needed if we reuse CAP_NET_RAW though, since
that is already in all kernels/libcap/glibc versions.

All that much said, I would vote for CAP_NET_RAW, and a grace period of
a couple of kernel releases, until the kernel displays a warning, like
it did with the CAP_SYSLOG case.

I'm a bit overwhelmed with stuff though, and would be happy if someone
else could prepare the necessary changes. But if someone does, I'd
recommend reading the CAP_SYSLOG related changes in kernel history to
avoid repeating the same mistakes.

-- 
Bazsi

From: Maciej Żenczykowski <redacted>

Up till now the IP{,V6}_TRANSPARENT socket options (which actually set
the same bit in the socket struct) have required CAP_NET_ADMIN
privileges to set or clear the option.

- we make clearing the bit not require any privileges.
- we deprecate using CAP_NET_ADMIN for this purpose.
- we introduce a new capability CAP_NET_TRANSPARENT,
  which is tailored to allow setting just this bit.
- we allow either one of CAP_NET_TRANSPARENT or CAP_NET_RAW
  to set this bit, because raw sockets already effectively
  allow you to emulate socket transparency, and make the
  transition easier for apps not desiring to use a brand
  new capability (because of header file or glibc support)
- we print a warning (but allow it) if you try to set
  the socket option with CAP_NET_ADMIN privs, but without
  either one of CAP_NET_TRANSPARENT or CAP_NET_RAW.

The reason for introducing a new capability is that while
transparent sockets are potentially dangerous (and can let you
spoof your source IP on traffic), they don't normally give you
the full 'freedom' of eavesdropping and/or spoofing that raw sockets
give you.

Signed-off-by: Maciej Żenczykowski <redacted>
CC: Balazs Scheidler <redacted>
---
 include/linux/capability.h |   13 +++++++++----
 net/ipv4/ip_sockglue.c     |   26 ++++++++++++++++++++++----
 net/ipv6/ipv6_sockglue.c   |   29 ++++++++++++++++++++++++-----
 3 files changed, 55 insertions(+), 13 deletions(-)

diff --git a/include/linux/capability.h b/include/linux/capability.h
index c421123..a115ed4 100644
--- a/include/linux/capability.h
+++ b/include/linux/capability.h

@@ -198,7 +198,7 @@ struct cpu_vfs_cap_data {
 /* Allow modification of routing tables */
 /* Allow setting arbitrary process / process group ownership on
    sockets */
-/* Allow binding to any address for transparent proxying */
+/* Allow binding to any address for transparent proxying (deprecated) */
 /* Allow setting TOS (type of service) */
 /* Allow setting promiscuous mode */
 /* Allow clearing driver statistics */

@@ -210,6 +210,7 @@ struct cpu_vfs_cap_data {
 
 /* Allow use of RAW sockets */
 /* Allow use of PACKET sockets */
+/* Allow binding to any address for transparent proxying */
 
 #define CAP_NET_RAW          13
 

@@ -332,7 +333,7 @@ struct cpu_vfs_cap_data {
 
 #define CAP_AUDIT_CONTROL    30
 
-#define CAP_SETFCAP	     31
+#define CAP_SETFCAP          31
 
 /* Override MAC access.
    The base kernel enforces no MAC policy.

@@ -357,10 +358,14 @@ struct cpu_vfs_cap_data {
 
 /* Allow triggering something that will wake the system */
 
-#define CAP_WAKE_ALARM            35
+#define CAP_WAKE_ALARM       35
+
+/* Allow binding to any address for transparent proxying */
+
+#define CAP_NET_TRANSPARENT  36
 
 
-#define CAP_LAST_CAP         CAP_WAKE_ALARM
+#define CAP_LAST_CAP         CAP_NET_TRANSPARENT
 
 #define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)
 

diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index 8905e92..44efa39 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c

@@ -961,12 +961,30 @@ mc_msf_out:
 		break;
 
 	case IP_TRANSPARENT:
-		if (!capable(CAP_NET_ADMIN)) {
-			err = -EPERM;
-			break;
-		}
 		if (optlen < 1)
 			goto e_inval;
+		/* Always allow clearing the transparent proxy socket option.
+		 * The pre-3.2 permission for setting this was CAP_NET_ADMIN,
+		 * and this is still supported - but deprecated.  As of Linux
+		 * 3.2 the proper permission is one of CAP_NET_TRANSPARENT
+		 * (preferred, a new capability) or CAP_NET_RAW.  The latter
+		 * is supported to make the transition easier (and because
+		 * raw sockets already effectively allow one to emulate
+		 * socket transparency).
+		 */
+		if (!!val && !capable(CAP_NET_TRANSPARENT)
+		          && !capable(CAP_NET_RAW)) {
+			if (!capable(CAP_NET_ADMIN)) {
+				err = -EPERM;
+				break;
+			}
+			printk_once(KERN_WARNING "%s (%d): "
+				 "deprecated: attempt to set socket option "
+				 "IP_TRANSPARENT with CAP_NET_ADMIN but "
+				 "without either one of CAP_NET_TRANSPARENT "
+				 "or CAP_NET_RAW.\n",
+				 current->comm, task_pid_nr(current));
+		}
 		inet->transparent = !!val;
 		break;
 

diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
index 147ede38..c840098 100644
--- a/net/ipv6/ipv6_sockglue.c
+++ b/net/ipv6/ipv6_sockglue.c

@@ -343,13 +343,32 @@ static int do_ipv6_setsockopt(struct sock *sk, int level, int optname,
 		break;
 
 	case IPV6_TRANSPARENT:
-		if (!capable(CAP_NET_ADMIN)) {
-			retv = -EPERM;
-			break;
-		}
 		if (optlen < sizeof(int))
 			goto e_inval;
-		/* we don't have a separate transparent bit for IPV6 we use the one in the IPv4 socket */
+		/* Always allow clearing the transparent proxy socket option.
+		 * The pre-3.2 permission for setting this was CAP_NET_ADMIN,
+		 * and this is still supported - but deprecated.  As of Linux
+		 * 3.2 the proper permission is one of CAP_NET_TRANSPARENT
+		 * (preferred, a new capability) or CAP_NET_RAW.  The latter
+		 * is supported to make the transition easier (and because
+		 * raw sockets already effectively allow one to emulate
+		 * socket transparency).
+		 */
+		if (valbool && !capable(CAP_NET_TRANSPARENT)
+		            && !capable(CAP_NET_RAW)) {
+			if (!capable(CAP_NET_ADMIN)) {
+				retv = -EPERM;
+				break;
+			}
+			printk_once(KERN_WARNING "%s (%d): "
+				 "deprecated: attempt to set socket option "
+				 "IPV6_TRANSPARENT with CAP_NET_ADMIN but "
+				 "without either one of CAP_NET_TRANSPARENT "
+				 "or CAP_NET_RAW.\n",
+				 current->comm, task_pid_nr(current));
+		}
+		/* we don't have a separate transparent bit for IPV6 we use the
+		 * one in the IPv4 socket */
 		inet_sk(sk)->transparent = valbool;
 		retv = 0;
 		break;

-- 
1.7.3.1

Comments?

On Fri, 2011-09-02 at 12:10 -0700, Maciej Żenczykowski wrote:

From: Maciej Żenczykowski <redacted>

Up till now the IP{,V6}_TRANSPARENT socket options (which actually set
the same bit in the socket struct) have required CAP_NET_ADMIN
privileges to set or clear the option.

- we make clearing the bit not require any privileges.
- we deprecate using CAP_NET_ADMIN for this purpose.
- we introduce a new capability CAP_NET_TRANSPARENT,
  which is tailored to allow setting just this bit.
- we allow either one of CAP_NET_TRANSPARENT or CAP_NET_RAW
  to set this bit, because raw sockets already effectively
  allow you to emulate socket transparency, and make the
  transition easier for apps not desiring to use a brand
  new capability (because of header file or glibc support)
- we print a warning (but allow it) if you try to set
  the socket option with CAP_NET_ADMIN privs, but without
  either one of CAP_NET_TRANSPARENT or CAP_NET_RAW.

The reason for introducing a new capability is that while
transparent sockets are potentially dangerous (and can let you
spoof your source IP on traffic), they don't normally give you
the full 'freedom' of eavesdropping and/or spoofing that raw sockets
give you.

Signed-off-by: Maciej Żenczykowski <redacted>
CC: Balazs Scheidler <redacted>

This is ok for me, as long as the security maintainers allow the
introduction of this new cap.

Thanks for doing this and sorry for the late reply.

Acked-by: Balazs Scheidler <redacted>

-- 
Bazsi

quoted

From: Maciej Żenczykowski <redacted>

Up till now the IP{,V6}_TRANSPARENT socket options (which actually set
the same bit in the socket struct) have required CAP_NET_ADMIN
privileges to set or clear the option.

- we make clearing the bit not require any privileges.
- we deprecate using CAP_NET_ADMIN for this purpose.
- we introduce a new capability CAP_NET_TRANSPARENT,
  which is tailored to allow setting just this bit.
- we allow either one of CAP_NET_TRANSPARENT or CAP_NET_RAW
  to set this bit, because raw sockets already effectively
  allow you to emulate socket transparency, and make the
  transition easier for apps not desiring to use a brand
  new capability (because of header file or glibc support)
- we print a warning (but allow it) if you try to set
  the socket option with CAP_NET_ADMIN privs, but without
  either one of CAP_NET_TRANSPARENT or CAP_NET_RAW.

The reason for introducing a new capability is that while
transparent sockets are potentially dangerous (and can let you
spoof your source IP on traffic), they don't normally give you
the full 'freedom' of eavesdropping and/or spoofing that raw sockets
give you.

Signed-off-by: Maciej Żenczykowski <redacted>
CC: Balazs Scheidler <redacted>

This is ok for me, as long as the security maintainers allow the
introduction of this new cap.

Thanks for doing this and sorry for the late reply.

Acked-by: Balazs Scheidler <redacted>

--
Bazsi

I'm not really sure who else to CC on this...

From: Balazs Scheidler <redacted>
Date: Tue, 13 Sep 2011 17:27:09 +0200

On Fri, 2011-09-02 at 12:10 -0700, Maciej Żenczykowski wrote:

quoted

From: Maciej Żenczykowski <redacted>

Up till now the IP{,V6}_TRANSPARENT socket options (which actually set
the same bit in the socket struct) have required CAP_NET_ADMIN
privileges to set or clear the option.

- we make clearing the bit not require any privileges.
- we deprecate using CAP_NET_ADMIN for this purpose.
- we introduce a new capability CAP_NET_TRANSPARENT,
  which is tailored to allow setting just this bit.
- we allow either one of CAP_NET_TRANSPARENT or CAP_NET_RAW
  to set this bit, because raw sockets already effectively
  allow you to emulate socket transparency, and make the
  transition easier for apps not desiring to use a brand
  new capability (because of header file or glibc support)
- we print a warning (but allow it) if you try to set
  the socket option with CAP_NET_ADMIN privs, but without
  either one of CAP_NET_TRANSPARENT or CAP_NET_RAW.

The reason for introducing a new capability is that while
transparent sockets are potentially dangerous (and can let you
spoof your source IP on traffic), they don't normally give you
the full 'freedom' of eavesdropping and/or spoofing that raw sockets
give you.

Signed-off-by: Maciej Żenczykowski <redacted>
CC: Balazs Scheidler <redacted>

This is ok for me, as long as the security maintainers allow the
introduction of this new cap.

Thanks for doing this and sorry for the late reply.

Acked-by: Balazs Scheidler <redacted>

I'm fine with this change too and I'll apply it as soon as at least
one security person ACK's the addition of the new capability bit.

From: Maciej Żenczykowski <redacted>

Up till now the IP{,V6}_TRANSPARENT socket options (which actually set
the same bit in the socket struct) have required CAP_NET_ADMIN
privileges to set or clear the option.

- we make clearing the bit not require any privileges.
- we deprecate using CAP_NET_ADMIN for this purpose.
- we introduce a new capability CAP_NET_TRANSPARENT,
  which is tailored to allow setting just this bit.
- we allow either one of CAP_NET_TRANSPARENT or CAP_NET_RAW
  to set this bit, because raw sockets already effectively
  allow you to emulate socket transparency, and make the
  transition easier for apps not desiring to use a brand
  new capability (because of header file or glibc support)
- we print a warning (but allow it) if you try to set
  the socket option with CAP_NET_ADMIN privs, but without
  either one of CAP_NET_TRANSPARENT or CAP_NET_RAW.

The reason for introducing a new capability is that while
transparent sockets are potentially dangerous (and can let you
spoof your source IP on traffic), they don't normally give you
the full 'freedom' of eavesdropping and/or spoofing that raw sockets
give you.

Signed-off-by: Maciej Żenczykowski <redacted>
Acked-by: Balazs Scheidler <redacted>
Acked-by: David Miller <redacted>
---
 include/linux/capability.h |   13 +++++++++----
 net/ipv4/ip_sockglue.c     |   26 ++++++++++++++++++++++----
 net/ipv6/ipv6_sockglue.c   |   29 ++++++++++++++++++++++++-----
 3 files changed, 55 insertions(+), 13 deletions(-)

diff --git a/include/linux/capability.h b/include/linux/capability.h
index c421123..a115ed4 100644
--- a/include/linux/capability.h
+++ b/include/linux/capability.h

@@ -198,7 +198,7 @@ struct cpu_vfs_cap_data {
 /* Allow modification of routing tables */
 /* Allow setting arbitrary process / process group ownership on
    sockets */
-/* Allow binding to any address for transparent proxying */
+/* Allow binding to any address for transparent proxying (deprecated) */
 /* Allow setting TOS (type of service) */
 /* Allow setting promiscuous mode */
 /* Allow clearing driver statistics */

@@ -210,6 +210,7 @@ struct cpu_vfs_cap_data {
 
 /* Allow use of RAW sockets */
 /* Allow use of PACKET sockets */
+/* Allow binding to any address for transparent proxying */
 
 #define CAP_NET_RAW          13
 

@@ -332,7 +333,7 @@ struct cpu_vfs_cap_data {
 
 #define CAP_AUDIT_CONTROL    30
 
-#define CAP_SETFCAP	     31
+#define CAP_SETFCAP          31
 
 /* Override MAC access.
    The base kernel enforces no MAC policy.

@@ -357,10 +358,14 @@ struct cpu_vfs_cap_data {
 
 /* Allow triggering something that will wake the system */
 
-#define CAP_WAKE_ALARM            35
+#define CAP_WAKE_ALARM       35
+
+/* Allow binding to any address for transparent proxying */
+
+#define CAP_NET_TRANSPARENT  36
 
 
-#define CAP_LAST_CAP         CAP_WAKE_ALARM
+#define CAP_LAST_CAP         CAP_NET_TRANSPARENT
 
 #define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)
 

diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index 8905e92..44efa39 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c

@@ -961,12 +961,30 @@ mc_msf_out:
 		break;
 
 	case IP_TRANSPARENT:
-		if (!capable(CAP_NET_ADMIN)) {
-			err = -EPERM;
-			break;
-		}
 		if (optlen < 1)
 			goto e_inval;
+		/* Always allow clearing the transparent proxy socket option.
+		 * The pre-3.2 permission for setting this was CAP_NET_ADMIN,
+		 * and this is still supported - but deprecated.  As of Linux
+		 * 3.2 the proper permission is one of CAP_NET_TRANSPARENT
+		 * (preferred, a new capability) or CAP_NET_RAW.  The latter
+		 * is supported to make the transition easier (and because
+		 * raw sockets already effectively allow one to emulate
+		 * socket transparency).
+		 */
+		if (!!val && !capable(CAP_NET_TRANSPARENT)
+		          && !capable(CAP_NET_RAW)) {
+			if (!capable(CAP_NET_ADMIN)) {
+				err = -EPERM;
+				break;
+			}
+			printk_once(KERN_WARNING "%s (%d): "
+				 "deprecated: attempt to set socket option "
+				 "IP_TRANSPARENT with CAP_NET_ADMIN but "
+				 "without either one of CAP_NET_TRANSPARENT "
+				 "or CAP_NET_RAW.\n",
+				 current->comm, task_pid_nr(current));
+		}
 		inet->transparent = !!val;
 		break;
 

diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
index 2fbda5f..b8315c8 100644
--- a/net/ipv6/ipv6_sockglue.c
+++ b/net/ipv6/ipv6_sockglue.c

@@ -343,13 +343,32 @@ static int do_ipv6_setsockopt(struct sock *sk, int level, int optname,
 		break;
 
 	case IPV6_TRANSPARENT:
-		if (!capable(CAP_NET_ADMIN)) {
-			retv = -EPERM;
-			break;
-		}
 		if (optlen < sizeof(int))
 			goto e_inval;
-		/* we don't have a separate transparent bit for IPV6 we use the one in the IPv4 socket */
+		/* Always allow clearing the transparent proxy socket option.
+		 * The pre-3.2 permission for setting this was CAP_NET_ADMIN,
+		 * and this is still supported - but deprecated.  As of Linux
+		 * 3.2 the proper permission is one of CAP_NET_TRANSPARENT
+		 * (preferred, a new capability) or CAP_NET_RAW.  The latter
+		 * is supported to make the transition easier (and because
+		 * raw sockets already effectively allow one to emulate
+		 * socket transparency).
+		 */
+		if (valbool && !capable(CAP_NET_TRANSPARENT)
+		            && !capable(CAP_NET_RAW)) {
+			if (!capable(CAP_NET_ADMIN)) {
+				retv = -EPERM;
+				break;
+			}
+			printk_once(KERN_WARNING "%s (%d): "
+				 "deprecated: attempt to set socket option "
+				 "IPV6_TRANSPARENT with CAP_NET_ADMIN but "
+				 "without either one of CAP_NET_TRANSPARENT "
+				 "or CAP_NET_RAW.\n",
+				 current->comm, task_pid_nr(current));
+		}
+		/* we don't have a separate transparent bit for IPV6 we use the
+		 * one in the IPv4 socket */
 		inet_sk(sk)->transparent = valbool;
 		retv = 0;
 		break;

-- 
1.7.3.1

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

Quoting Maciej Żenczykowski (zenczykowski@gmail.com):

From: Maciej Żenczykowski <redacted>

Up till now the IP{,V6}_TRANSPARENT socket options (which actually set
the same bit in the socket struct) have required CAP_NET_ADMIN
privileges to set or clear the option.

- we make clearing the bit not require any privileges.
- we deprecate using CAP_NET_ADMIN for this purpose.
- we introduce a new capability CAP_NET_TRANSPARENT,
  which is tailored to allow setting just this bit.
- we allow either one of CAP_NET_TRANSPARENT or CAP_NET_RAW
  to set this bit, because raw sockets already effectively
  allow you to emulate socket transparency, and make the
  transition easier for apps not desiring to use a brand
  new capability (because of header file or glibc support)
- we print a warning (but allow it) if you try to set
  the socket option with CAP_NET_ADMIN privs, but without
  either one of CAP_NET_TRANSPARENT or CAP_NET_RAW.

The reason for introducing a new capability is that while
transparent sockets are potentially dangerous (and can let you
spoof your source IP on traffic), they don't normally give you
the full 'freedom' of eavesdropping and/or spoofing that raw sockets
give you.

Signed-off-by: Maciej Żenczykowski <redacted>
Acked-by: Balazs Scheidler <redacted>
Acked-by: David Miller <redacted>

Looks good to me.  Please do make sure to also send the required
patch for libcap2.

Should the comments in capability.h reference each other to make
clear that it's not a mistake, either one offers the privilege?
I know it's clear from the comment in the code itself, but something
like

In any case,

Acked-by: Serge Hallyn <redacted>

thanks,
-serge

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

On 9/22/2011 4:29 PM, Maciej Żenczykowski wrote:

From: Maciej Żenczykowski <redacted>

Up till now the IP{,V6}_TRANSPARENT socket options (which actually set
the same bit in the socket struct) have required CAP_NET_ADMIN
privileges to set or clear the option.

- we make clearing the bit not require any privileges.
- we deprecate using CAP_NET_ADMIN for this purpose.
- we introduce a new capability CAP_NET_TRANSPARENT,
  which is tailored to allow setting just this bit.

Under what circumstances would a process that requires the
new capability not require CAP_NET_ADMIN? Is there a real
case where a process would be expected to require only this
new capability? Adding new capability values is somewhat
perilous and the granularity you are proposing, that of
controlling a single bit, would explode the list of
capabilities into the hundreds if it were applied throughout
the kernel.

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

Under what circumstances would a process that requires the
new capability not require CAP_NET_ADMIN? Is there a real
case where a process would be expected to require only this
new capability? Adding new capability values is somewhat
perilous and the granularity you are proposing, that of
controlling a single bit, would explode the list of
capabilities into the hundreds if it were applied throughout
the kernel.

CAP_NET_ADMIN is a huge hammer, it allows one to totally
reconfigure the networking subsystem.

In a containerized multi-user/job environment, you do not want
something like an instance of a load-balanced web server, proxy
or dns server being able to do that - policy/configuration decisions
should be left up to the administrator and/or machine management
daemon(s).  Each of these can make use of transparent sockets
(in various ways, mostly in coordination with large scale load balancing).

You also do not want one user running in one container being able
to sniff (CAP_NET_RAW) traffic from another user (hence CAP_NET_RAW
isn't an acceptable substitute).

One could conceivably use network namespaces for seperation, but
in this particular case they are _way_ too overkill (and also add too
much overhead).

This might be *just* a single bit in the socket, but this bit effectively
controls whether you can do certain types of privileged operations
on the socket in question - and it gets tested in various places throughout
the networking stack.

Hopefully, this answers your question.

- Maciej

On 9/23/2011 12:33 PM, Maciej Żenczykowski wrote:

quoted

Under what circumstances would a process that requires the
new capability not require CAP_NET_ADMIN? Is there a real
case where a process would be expected to require only this
new capability? Adding new capability values is somewhat
perilous and the granularity you are proposing, that of
controlling a single bit, would explode the list of
capabilities into the hundreds if it were applied throughout
the kernel.

CAP_NET_ADMIN is a huge hammer, it allows one to totally
reconfigure the networking subsystem.

In a containerized multi-user/job environment, you do not want
something like an instance of a load-balanced web server, proxy
or dns server being able to do that - policy/configuration decisions
should be left up to the administrator and/or machine management
daemon(s).  Each of these can make use of transparent sockets
(in various ways, mostly in coordination with large scale load balancing).

You also do not want one user running in one container being able
to sniff (CAP_NET_RAW) traffic from another user (hence CAP_NET_RAW
isn't an acceptable substitute).

One could conceivably use network namespaces for seperation, but
in this particular case they are _way_ too overkill (and also add too
much overhead).

This might be *just* a single bit in the socket, but this bit effectively
controls whether you can do certain types of privileged operations
on the socket in question - and it gets tested in various places throughout
the networking stack.

Hopefully, this answers your question.

It is an important argument, but no, it does not address my issue.
The problem is that you can make that same argument for breaking up
just about every capability. CAP_SYSADMIN could easily be broken into
a hundred separate capabilities and CAP_NET_ADMIN, as you point out,
into dozens. My point is that with the potential to create so many
capabilities, what makes this particular action so much more important
than the other things already covered by CAP_NET_ADMIN?

If we introduce dozens of new capabilities we will end up with
the exact same problem that has been so clearly demonstrated
by the SELinux reference policy. Excessive granularity will kill
and security facility. Capabilities are already more granular than
most people are comfortable with.

For a facility to warrant a new capability it must be completely
unreasonable to fit it into an existing capability, sufficiently
general in its use that the bit won't show up unused when networking
fashions change in a year or two, and it needs to protect something
that is obviously very important. You have a variant of a somewhat
obscure facility that will only be used in edge cases in support
of an unproven (if promising) technology that is targeted to a
disappearing use case.

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

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

From: Maciej Żenczykowski <redacted>

Up till now the IP{,V6}_TRANSPARENT socket options (which actually set
the same bit in the socket struct) have required CAP_NET_ADMIN
privileges to set or clear the option.

- we make clearing the bit not require any privileges.
- we deprecate using CAP_NET_ADMIN for this purpose.
- we allow CAP_NET_RAW to set this bit, because raw
  sockets already effectively allow you to emulate socket
  transparency.
- we print a warning (but allow it) if you try to set the socket
  option with CAP_NET_ADMIN privs, but without CAP_NET_RAW.

Signed-off-by: Maciej Żenczykowski <redacted>
---
 include/linux/capability.h |    3 ++-
 net/ipv4/ip_sockglue.c     |   20 ++++++++++++++++----
 net/ipv6/ipv6_sockglue.c   |   23 ++++++++++++++++++-----
 3 files changed, 36 insertions(+), 10 deletions(-)

diff --git a/include/linux/capability.h b/include/linux/capability.h
index c421123..ce34ae3 100644
--- a/include/linux/capability.h
+++ b/include/linux/capability.h

@@ -198,7 +198,7 @@ struct cpu_vfs_cap_data {
 /* Allow modification of routing tables */
 /* Allow setting arbitrary process / process group ownership on
    sockets */
-/* Allow binding to any address for transparent proxying */
+/* Allow binding to any address for transparent proxying (deprecated) */
 /* Allow setting TOS (type of service) */
 /* Allow setting promiscuous mode */
 /* Allow clearing driver statistics */

@@ -210,6 +210,7 @@ struct cpu_vfs_cap_data {
 
 /* Allow use of RAW sockets */
 /* Allow use of PACKET sockets */
+/* Allow binding to any address for transparent proxying */
 
 #define CAP_NET_RAW          13
 

diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index 8905e92..74f7d30 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c

@@ -961,12 +961,24 @@ mc_msf_out:
 		break;
 
 	case IP_TRANSPARENT:
-		if (!capable(CAP_NET_ADMIN)) {
-			err = -EPERM;
-			break;
-		}
 		if (optlen < 1)
 			goto e_inval;
+		/* Always allow clearing the transparent proxy socket option.
+		 * The pre-3.2 permission for setting this was CAP_NET_ADMIN,
+		 * and this is still supported - but deprecated.  As of Linux
+		 * 3.2 the proper permission is CAP_NET_RAW.
+		 */
+		if (!!val && !capable(CAP_NET_RAW)) {
+			if (!capable(CAP_NET_ADMIN)) {
+				err = -EPERM;
+				break;
+			}
+			printk_once(KERN_WARNING "%s (%d): "
+				 "deprecated: attempt to set socket option "
+				 "IP_TRANSPARENT with CAP_NET_ADMIN but "
+				 "without CAP_NET_RAW.\n",
+				 current->comm, task_pid_nr(current));
+		}
 		inet->transparent = !!val;
 		break;
 

diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
index 2fbda5f..7c4f5ce 100644
--- a/net/ipv6/ipv6_sockglue.c
+++ b/net/ipv6/ipv6_sockglue.c

@@ -343,13 +343,26 @@ static int do_ipv6_setsockopt(struct sock *sk, int level, int optname,
 		break;
 
 	case IPV6_TRANSPARENT:
-		if (!capable(CAP_NET_ADMIN)) {
-			retv = -EPERM;
-			break;
-		}
 		if (optlen < sizeof(int))
 			goto e_inval;
-		/* we don't have a separate transparent bit for IPV6 we use the one in the IPv4 socket */
+		/* Always allow clearing the transparent proxy socket option.
+		 * The pre-3.2 permission for setting this was CAP_NET_ADMIN,
+		 * and this is still supported - but deprecated.  As of Linux
+		 * 3.2 the proper permission is CAP_NET_RAW.
+		 */
+		if (valbool && !capable(CAP_NET_RAW)) {
+			if (!capable(CAP_NET_ADMIN)) {
+				retv = -EPERM;
+				break;
+			}
+			printk_once(KERN_WARNING "%s (%d): "
+				 "deprecated: attempt to set socket option "
+				 "IPV6_TRANSPARENT with CAP_NET_ADMIN but "
+				 "without CAP_NET_RAW.\n",
+				 current->comm, task_pid_nr(current));
+		}
+		/* we don't have a separate transparent bit for IPv6,
+		 * so we just use the one in the IPv4 socket */
 		inet_sk(sk)->transparent = valbool;
 		retv = 0;
 		break;

-- 
1.7.3.1

I still think we need a more precise permission for this, but possibly
not quite as specific as a separate capability just for transparent.
Maybe RAW should be split into RAW_READ (eavesdropping) and RAW_WRITE (spoof).

Either way, I'll leave that for another day.

-- 
Maciej A. Żenczykowski
Kernel Networking Developer @ Google

From: Maciej Żenczykowski <redacted>
Date: Mon, 17 Oct 2011 15:16:23 -0700

From: Maciej Żenczykowski <redacted>

Up till now the IP{,V6}_TRANSPARENT socket options (which actually set
the same bit in the socket struct) have required CAP_NET_ADMIN
privileges to set or clear the option.

- we make clearing the bit not require any privileges.
- we deprecate using CAP_NET_ADMIN for this purpose.
- we allow CAP_NET_RAW to set this bit, because raw
  sockets already effectively allow you to emulate socket
  transparency.
- we print a warning (but allow it) if you try to set the socket
  option with CAP_NET_ADMIN privs, but without CAP_NET_RAW.

Signed-off-by: Maciej Żenczykowski <redacted>

Warnings for something that has worked ever since the feature was
added, and in fact was the only way to make use of the feature, is
terrible.

You must support the status quo forever or else you risk breaking
existing setups.  So the warning is pointless, you'll never be
able to remove CAP_NET_ADMIN from these code paths, so there is
zero value in warning about it because we'll never change this.

I'm disliking these changes more and more.  I refuse to apply this
patch.

Are you okay with the patch without any warnings or deprecation markings?
Or are you against opening up CAP_NET_RAW to this in general?

On Wed, Oct 19, 2011 at 4:34 PM, David Miller [off-list ref] wrote:

From: Maciej Żenczykowski <redacted>
Date: Mon, 17 Oct 2011 15:16:23 -0700

quoted

From: Maciej Żenczykowski <redacted>

Up till now the IP{,V6}_TRANSPARENT socket options (which actually set
the same bit in the socket struct) have required CAP_NET_ADMIN
privileges to set or clear the option.

- we make clearing the bit not require any privileges.
- we deprecate using CAP_NET_ADMIN for this purpose.
- we allow CAP_NET_RAW to set this bit, because raw
  sockets already effectively allow you to emulate socket
  transparency.
- we print a warning (but allow it) if you try to set the socket
  option with CAP_NET_ADMIN privs, but without CAP_NET_RAW.

Signed-off-by: Maciej Żenczykowski <redacted>

Warnings for something that has worked ever since the feature was
added, and in fact was the only way to make use of the feature, is
terrible.

You must support the status quo forever or else you risk breaking
existing setups.  So the warning is pointless, you'll never be
able to remove CAP_NET_ADMIN from these code paths, so there is
zero value in warning about it because we'll never change this.

I'm disliking these changes more and more.  I refuse to apply this
patch.

-- 
Maciej A. Żenczykowski
Kernel Networking Developer @ Google
1600 Amphitheatre Parkway, Mountain View, CA 94043
tel: +1 (650) 253-0062

From: Maciej Żenczykowski <redacted>
Date: Wed, 19 Oct 2011 20:32:31 -0700

Are you okay with the patch without any warnings or deprecation markings?
Or are you against opening up CAP_NET_RAW to this in general?

I don't see any real benefit.

If it has been decided that you can't create a new capability for
tproxy, so that tasks can be segregated out of these more powerful
networking capability levels, I simply don't see the point.

A process with CAP_NET_RAW can spit whatever crap they want onto the
network, and receive all packets with impunity.

I can't see what this buys us at all, sorry.

I don't see any real benefit.

If it has been decided that you can't create a new capability for
tproxy, so that tasks can be segregated out of these more powerful
networking capability levels, I simply don't see the point.

It indeed seems that transparent may be a little too specific a capability.
Ultimately linux permissions are just not fine grained enough...
unless you start using LSMs

A process with CAP_NET_RAW can spit whatever crap they want onto the
network, and receive all packets with impunity.

Agreed.  But it can do so via raw sockets, it cannot do so via normal
udp/tcp/ip sockets.
That's why I'd like to relax the permissions check on being able to
switch a socket
into transparent mode.  A process with CAP_NET_RAW can already pretty
much emulate
that behaviour by using raw sockets - it just can't do that using the
higher level, often more
usable/useful socket/protocol apis.

I can't see what this buys us at all, sorry.

See above.

From: Maciej Żenczykowski <redacted>
Date: Wed, 19 Oct 2011 21:31:06 -0700

quoted

A process with CAP_NET_RAW can spit whatever crap they want onto the
network, and receive all packets with impunity.

Agreed.  But it can do so via raw sockets, it cannot do so via normal
udp/tcp/ip sockets.
That's why I'd like to relax the permissions check on being able to
switch a socket
into transparent mode.  A process with CAP_NET_RAW can already pretty
much emulate
that behaviour by using raw sockets - it just can't do that using the
higher level, often more
usable/useful socket/protocol apis.

quoted

I can't see what this buys us at all, sorry.

See above.

Ok, I'm convinced, send me that patch without the warning messages.

Thanks.

From: Maciej Żenczykowski <redacted>

Up till now the IP{,V6}_TRANSPARENT socket options (which actually set
the same bit in the socket struct) have required CAP_NET_ADMIN
privileges to set or clear the option.

- we make clearing the bit not require any privileges.
- we allow CAP_NET_ADMIN to set the bit (as before this change)
- we allow CAP_NET_RAW to set this bit, because raw
  sockets already pretty much effectively allow you
  to emulate socket transparency.

Signed-off-by: Maciej Żenczykowski <redacted>
---
 include/linux/capability.h |    3 ++-
 net/ipv4/ip_sockglue.c     |    2 +-
 net/ipv6/ipv6_sockglue.c   |    2 +-
 3 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/include/linux/capability.h b/include/linux/capability.h
index c421123..a63d13d 100644
--- a/include/linux/capability.h
+++ b/include/linux/capability.h

@@ -198,7 +198,7 @@ struct cpu_vfs_cap_data {
 /* Allow modification of routing tables */
 /* Allow setting arbitrary process / process group ownership on
    sockets */
-/* Allow binding to any address for transparent proxying */
+/* Allow binding to any address for transparent proxying (also via NET_RAW) */
 /* Allow setting TOS (type of service) */
 /* Allow setting promiscuous mode */
 /* Allow clearing driver statistics */

@@ -210,6 +210,7 @@ struct cpu_vfs_cap_data {
 
 /* Allow use of RAW sockets */
 /* Allow use of PACKET sockets */
+/* Allow binding to any address for transparent proxying (also via NET_ADMIN) */
 
 #define CAP_NET_RAW          13
 

diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index 8905e92..f0dc3ad 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c

@@ -961,7 +961,7 @@ mc_msf_out:
 		break;
 
 	case IP_TRANSPARENT:
-		if (!capable(CAP_NET_ADMIN)) {
+		if (!!val && !capable(CAP_NET_RAW) && !capable(CAP_NET_ADMIN)) {
 			err = -EPERM;
 			break;
 		}

diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
index 2fbda5f..c99e3ee 100644
--- a/net/ipv6/ipv6_sockglue.c
+++ b/net/ipv6/ipv6_sockglue.c

@@ -343,7 +343,7 @@ static int do_ipv6_setsockopt(struct sock *sk, int level, int optname,
 		break;
 
 	case IPV6_TRANSPARENT:
-		if (!capable(CAP_NET_ADMIN)) {
+		if (valbool && !capable(CAP_NET_ADMIN) && !capable(CAP_NET_RAW)) {
 			retv = -EPERM;
 			break;
 		}

-- 
1.7.3.1

From: Maciej Żenczykowski <redacted>
Date: Thu, 20 Oct 2011 15:10:14 -0700

From: Maciej Żenczykowski <redacted>

Up till now the IP{,V6}_TRANSPARENT socket options (which actually set
the same bit in the socket struct) have required CAP_NET_ADMIN
privileges to set or clear the option.

- we make clearing the bit not require any privileges.
- we allow CAP_NET_ADMIN to set the bit (as before this change)
- we allow CAP_NET_RAW to set this bit, because raw
  sockets already pretty much effectively allow you
  to emulate socket transparency.

Signed-off-by: Maciej Żenczykowski <redacted>

Applied, thanks.