Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1391819 > unrolled thread

[Question] Should `CAP_NET_ADMIN` be needed when opening `/dev/ppp`?

Back to article view | Back to linux.kernel

Contents

  [Question] Should `CAP_NET_ADMIN` be needed when opening `/dev/ppp`? Wang Shanker <shankerwangmiao@gmail.com> - 2016-05-01 15:40 +0200
    Re: [Question] Should `CAP_NET_ADMIN` be needed when opening  `/dev/ppp`? Guillaume Nault <g.nault@alphalink.fr> - 2016-05-03 12:20 +0200
      Re: [Question] Should `CAP_NET_ADMIN` be needed when opening `/dev/ppp`? Richard Weinberger <richard.weinberger@gmail.com> - 2016-05-03 12:40 +0200
        Re: [Question] Should `CAP_NET_ADMIN` be needed when opening `/dev/ppp`? Hannes Frederic Sowa <hannes@stressinduktion.org> - 2016-05-03 13:30 +0200
          Re: [Question] Should `CAP_NET_ADMIN` be needed when opening `/dev/ppp`? 王邈 <shankerwangmiao@gmail.com> - 2016-05-03 15:10 +0200
          Re: [Question] Should `CAP_NET_ADMIN` be needed when opening  `/dev/ppp`? Guillaume Nault <g.nault@alphalink.fr> - 2016-05-03 18:00 +0200
            Re: [Question] Should `CAP_NET_ADMIN` be needed when opening  `/dev/ppp`? Hannes Frederic Sowa <hannes@stressinduktion.org> - 2016-05-03 18:10 +0200
        Re: [Question] Should `CAP_NET_ADMIN` be needed when opening  `/dev/ppp`? Guillaume Nault <g.nault@alphalink.fr> - 2016-05-03 15:50 +0200

#1391819 — [Question] Should `CAP_NET_ADMIN` be needed when opening `/dev/ppp`?

Hi, all.

                                                                               
I’ve recently met some problems when trying to create a pppoe network link 
inside a unprivileged container. There is a uid namespace which maps root 
inside to a normal user outside. There is also a separate net namespace in the 
container. I create a dev node inside the container and set right 
permission.    

However, `/dev/ppp` cannot get opened since the mapped normal user does not 
have `CAP_NET_ADMIN`. The related code is in `drivers/net/ppp/ppp_generic.c`: 
`int ppp_open()` 

```
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))
		return -EPERM;
	return 0;
}
```

I wonder why CAP_NET_ADMIN is needed here, rather than leaving it to the
permission of the device node. If there is no need, I suggest that the 
CAP_NET_ADMIN check be removed. 

[toc] | [next] | [standalone]

#1393295 — Re: [Question] Should `CAP_NET_ADMIN` be needed when opening `/dev/ppp`?

On Sun, May 01, 2016 at 09:38:57PM +0800, Wang Shanker wrote:
> 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))
> 		return -EPERM;
> 	return 0;
> }
> ```
> 
> I wonder why CAP_NET_ADMIN is needed here, rather than leaving it to the
> permission of the device node. If there is no need, I suggest that the
> CAP_NET_ADMIN check be removed.
> 
If this test was removed here, then it'd have to be added again in the
PPPIOCNEWUNIT ioctl, at the very least, because creating a netdevice
should require CAP_NET_ADMIN. Therefore that wouldn't help for your
case.
I don't know why the test was placed in ppp_open() in the first place,
but changing it now would have side effects on user space. So I'd
rather leave the code as is.

[toc] | [prev] | [next] | [standalone]

#1393314

On Tue, May 3, 2016 at 12:12 PM, Guillaume Nault <g.nault@alphalink.fr> wrote:
> On Sun, May 01, 2016 at 09:38:57PM +0800, Wang Shanker wrote:
>> 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))
>>               return -EPERM;
>>       return 0;
>> }
>> ```
>>
>> I wonder why CAP_NET_ADMIN is needed here, rather than leaving it to the
>> permission of the device node. If there is no need, I suggest that the
>> CAP_NET_ADMIN check be removed.
>>
> If this test was removed here, then it'd have to be added again in the
> PPPIOCNEWUNIT ioctl, at the very least, because creating a netdevice
> should require CAP_NET_ADMIN. Therefore that wouldn't help for your
> case.
> I don't know why the test was placed in ppp_open() in the first place,
> but changing it now would have side effects on user space. So I'd
> rather leave the code as is.

I think the question is whether we really require having CAP_NET_ADMIN
in the initial namespace and not just in the current one.
Is ppp not network namespace aware?

-- 
Thanks,
//richard

[toc] | [prev] | [next] | [standalone]

#1393341

On Tue, May 3, 2016, at 12:35, Richard Weinberger wrote:
> On Tue, May 3, 2016 at 12:12 PM, Guillaume Nault <g.nault@alphalink.fr>
> wrote:
> > On Sun, May 01, 2016 at 09:38:57PM +0800, Wang Shanker wrote:
> >> 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))
> >>               return -EPERM;
> >>       return 0;
> >> }
> >> ```
> >>
> >> I wonder why CAP_NET_ADMIN is needed here, rather than leaving it to the
> >> permission of the device node. If there is no need, I suggest that the
> >> CAP_NET_ADMIN check be removed.
> >>
> > If this test was removed here, then it'd have to be added again in the
> > PPPIOCNEWUNIT ioctl, at the very least, because creating a netdevice
> > should require CAP_NET_ADMIN. Therefore that wouldn't help for your
> > case.
> > I don't know why the test was placed in ppp_open() in the first place,
> > but changing it now would have side effects on user space. So I'd
> > rather leave the code as is.
> 
> I think the question is whether we really require having CAP_NET_ADMIN
> in the initial namespace and not just in the current one.
> Is ppp not network namespace aware?

I agree, ns_capable(net->user_ns, CAP_NET_ADMIN), would probably make
more sense.

Bye,
Hannes

[toc] | [prev] | [next] | [standalone]

#1393405

> 在 2016年5月3日，下午7:23，Hannes Frederic Sowa <hannes@stressinduktion.org> 写道：
> 
> On Tue, May 3, 2016, at 12:35, Richard Weinberger wrote:
>> On Tue, May 3, 2016 at 12:12 PM, Guillaume Nault <g.nault@alphalink.fr>
>> wrote:
>>> On Sun, May 01, 2016 at 09:38:57PM +0800, Wang Shanker wrote:
>>>> 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))
>>>>              return -EPERM;
>>>>      return 0;
>>>> }
>>>> ```
>>>> 
>>>> I wonder why CAP_NET_ADMIN is needed here, rather than leaving it to the
>>>> permission of the device node. If there is no need, I suggest that the
>>>> CAP_NET_ADMIN check be removed.
>>>> 
>>> If this test was removed here, then it'd have to be added again in the
>>> PPPIOCNEWUNIT ioctl, at the very least, because creating a netdevice
>>> should require CAP_NET_ADMIN. Therefore that wouldn't help for your
>>> case.
>>> I don't know why the test was placed in ppp_open() in the first place,
>>> but changing it now would have side effects on user space. So I'd
>>> rather leave the code as is.
>> 
>> I think the question is whether we really require having CAP_NET_ADMIN
>> in the initial namespace and not just in the current one.
>> Is ppp not network namespace aware?
> 
> I agree, ns_capable(net->user_ns, CAP_NET_ADMIN), would probably make
> more sense.
I agree with that.
> 
> Bye,
> Hannes

[toc] | [prev] | [next] | [standalone]

#1393563 — Re: [Question] Should `CAP_NET_ADMIN` be needed when opening `/dev/ppp`?

On Tue, May 03, 2016 at 01:23:34PM +0200, Hannes Frederic Sowa wrote:
> On Tue, May 3, 2016, at 12:35, Richard Weinberger wrote:
> > On Tue, May 3, 2016 at 12:12 PM, Guillaume Nault <g.nault@alphalink.fr>
> > wrote:
> > > On Sun, May 01, 2016 at 09:38:57PM +0800, Wang Shanker wrote:
> > >> 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))
> > >>               return -EPERM;
> > >>       return 0;
> > >> }
> > >> ```
> > >>
> > >> I wonder why CAP_NET_ADMIN is needed here, rather than leaving it to the
> > >> permission of the device node. If there is no need, I suggest that the
> > >> CAP_NET_ADMIN check be removed.
> > >>
> > > If this test was removed here, then it'd have to be added again in the
> > > PPPIOCNEWUNIT ioctl, at the very least, because creating a netdevice
> > > should require CAP_NET_ADMIN. Therefore that wouldn't help for your
> > > case.
> > > I don't know why the test was placed in ppp_open() in the first place,
> > > but changing it now would have side effects on user space. So I'd
> > > rather leave the code as is.
> > 
> > I think the question is whether we really require having CAP_NET_ADMIN
> > in the initial namespace and not just in the current one.
> > Is ppp not network namespace aware?
> 
> I agree, ns_capable(net->user_ns, CAP_NET_ADMIN), would probably make
> more sense.
>
I guess you assume net is set to current->nsproxy->net_ns here.
Why about ns_capable(current_user_ns(), CAP_NET_ADMIN)?

From my understanding of the code (I currently have no practical
experience with user namespaces), net->user_ns points to the userns in
which the current netns was created, while current_user_ns() refers to
the caller's userns. Shouldn't we check the later? Otherwise, any
process running in the netns would have the same capabilities regarding
PPP ioctls().

But I'm certainly missing important points. Interactions between netns
and userns are something I never investigated before, and using
net->user_ns seems to be way more common than using current_user_ns()
for checking capabilities in the networking stack.

[toc] | [prev] | [next] | [standalone]

#1393578 — Re: [Question] Should `CAP_NET_ADMIN` be needed when opening `/dev/ppp`?

On 03.05.2016 17:51, Guillaume Nault wrote:
> On Tue, May 03, 2016 at 01:23:34PM +0200, Hannes Frederic Sowa wrote:
>> On Tue, May 3, 2016, at 12:35, Richard Weinberger wrote:
>>> On Tue, May 3, 2016 at 12:12 PM, Guillaume Nault <g.nault@alphalink.fr>
>>> wrote:
>>>> On Sun, May 01, 2016 at 09:38:57PM +0800, Wang Shanker wrote:
>>>>> 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))
>>>>>               return -EPERM;
>>>>>       return 0;
>>>>> }
>>>>> ```
>>>>>
>>>>> I wonder why CAP_NET_ADMIN is needed here, rather than leaving it to the
>>>>> permission of the device node. If there is no need, I suggest that the
>>>>> CAP_NET_ADMIN check be removed.
>>>>>
>>>> If this test was removed here, then it'd have to be added again in the
>>>> PPPIOCNEWUNIT ioctl, at the very least, because creating a netdevice
>>>> should require CAP_NET_ADMIN. Therefore that wouldn't help for your
>>>> case.
>>>> I don't know why the test was placed in ppp_open() in the first place,
>>>> but changing it now would have side effects on user space. So I'd
>>>> rather leave the code as is.
>>>
>>> I think the question is whether we really require having CAP_NET_ADMIN
>>> in the initial namespace and not just in the current one.
>>> Is ppp not network namespace aware?
>>
>> I agree, ns_capable(net->user_ns, CAP_NET_ADMIN), would probably make
>> more sense.
>>
> I guess you assume net is set to current->nsproxy->net_ns here.
> Why about ns_capable(current_user_ns(), CAP_NET_ADMIN)?
> 
> From my understanding of the code (I currently have no practical
> experience with user namespaces), net->user_ns points to the userns in
> which the current netns was created, while current_user_ns() refers to
> the caller's userns. Shouldn't we check the later? Otherwise, any
> process running in the netns would have the same capabilities regarding
> PPP ioctls().

We want to test our (*current) capability in the user namespace the net
namespace was created. current is implied here.

If you create a new user_namespace ontop the same network stack you
shouldn't have those capabilities, otherwise you can elevate capabilities.

Bye,
Hannes

[toc] | [prev] | [next] | [standalone]

#1393428 — Re: [Question] Should `CAP_NET_ADMIN` be needed when opening `/dev/ppp`?

On Tue, May 03, 2016 at 12:35:12PM +0200, Richard Weinberger wrote:
> On Tue, May 3, 2016 at 12:12 PM, Guillaume Nault <g.nault@alphalink.fr> wrote:
> > On Sun, May 01, 2016 at 09:38:57PM +0800, Wang Shanker wrote:
> >> 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))
> >>               return -EPERM;
> >>       return 0;
> >> }
> >> ```
> >>
> >> I wonder why CAP_NET_ADMIN is needed here, rather than leaving it to the
> >> permission of the device node. If there is no need, I suggest that the
> >> CAP_NET_ADMIN check be removed.
> >>
> > If this test was removed here, then it'd have to be added again in the
> > PPPIOCNEWUNIT ioctl, at the very least, because creating a netdevice
> > should require CAP_NET_ADMIN. Therefore that wouldn't help for your
> > case.
> > I don't know why the test was placed in ppp_open() in the first place,
> > but changing it now would have side effects on user space. So I'd
> > rather leave the code as is.
> 
> I think the question is whether we really require having CAP_NET_ADMIN
> in the initial namespace and not just in the current one.
> Is ppp not network namespace aware?
> 
Indeed, I overlooked the namespace aspect of the problem. PPP is netns
aware, but ioctls performed on /dev/ppp file descriptors are all
serialised with ppp_mutex. A user could therefore affect other PPP
users by artificially creating contention on the ppp_mutex lock.

Other than that, I agree it'd make sense to test for user capabilies in
the current namespace rather than in the initial one.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web