diff mbox

net:ppp: replace too strict capability restriction on opening /dev/ppp

Message ID 44A9BDB8-754B-4402-BD09-6381229C07C5@tuna.tsinghua.edu.cn
State Changes Requested, archived
Delegated to: David Miller
Headers show

Commit Message

Shanker Wang June 18, 2016, 11:38 p.m. UTC
This patch removes the check for CAP_NET_ADMIN in the initial namespace
when opening /dev/open. Instead, CAP_NET_ADMIN is checked in the user
namespace the net namespace was created so that /dev/ppp cat get opened
in a unprivileged container.

Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
Cc: Richard Weinberger <richard.weinberger@gmail.com>
Cc: Guillaume Nault <g.nault@alphalink.fr>
Cc: Miao Wang <shankerwangmiao@gmail.com>
Signed-off-by: Miao Wang <shanker@tuna.tsinghua.edu.cn>
---
 drivers/net/ppp/ppp_generic.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Andi Kleen June 20, 2016, 5:02 a.m. UTC | #1
Shanker Wang <shanker@tuna.tsinghua.edu.cn> writes:

> This patch removes the check for CAP_NET_ADMIN in the initial namespace
> when opening /dev/open. Instead, CAP_NET_ADMIN is checked in the user
> namespace the net namespace was created so that /dev/ppp cat get opened
> in a unprivileged container.

Seems dangerous. From a quick look at the PPP ioctl there is no limit
how many PPP devices this can create. So a container having access to
this would be able to fill all kernel memory. Probably needs more
auditing and hardening first.

In general there seems to be a lot of attack surface for root
in PPP.

-Andi
Richard Weinberger June 20, 2016, 6:47 a.m. UTC | #2
Am 20.06.2016 um 07:02 schrieb Andi Kleen:
> Shanker Wang <shanker@tuna.tsinghua.edu.cn> writes:
> 
>> This patch removes the check for CAP_NET_ADMIN in the initial namespace
>> when opening /dev/open. Instead, CAP_NET_ADMIN is checked in the user
>> namespace the net namespace was created so that /dev/ppp cat get opened
>> in a unprivileged container.
> 
> Seems dangerous. From a quick look at the PPP ioctl there is no limit
> how many PPP devices this can create. So a container having access to
> this would be able to fill all kernel memory. Probably needs more
> auditing and hardening first.
> 
> In general there seems to be a lot of attack surface for root
> in PPP.

You are right.
Shanker Wang, I had also another at the open function, it is more complicated
than I thought. Please see how ppp_unattached_ioctl() is called.
Before we give containers access to it the use of nsproxy has to be removed.
Not sure how easy this will be, especially since you cannot break existing users.

Thanks,
//richard
diff mbox

Patch

diff --git a/drivers/net/ppp/ppp_generic.c b/drivers/net/ppp/ppp_generic.c
index f572b31..4b3b2b5 100644
--- a/drivers/net/ppp/ppp_generic.c
+++ b/drivers/net/ppp/ppp_generic.c
@@ -380,7 +380,7 @@  static int ppp_open(struct inode *inode, struct file *file)
 	/*
 	 * This could (should?) be enforced by the permissions on /dev/ppp.
 	 */
-	if (!capable(CAP_NET_ADMIN))
+	if (!ns_capable(current->nsproxy->net_ns->user_ns, CAP_NET_ADMIN))
 		return -EPERM;
 	return 0;
 }