CAP_NET_ADMIN not being provided with the recommended plugs

Bug #1823988 reported by Clint Dovholuk
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Snappy
Invalid
Undecided
Unassigned

Bug Description

I am trying to use golang to make an application/snap that will create a TUN interface (vpn-like stuff). On execution the golang application pacakged as a snap returns "Operation not permitted" which appears to be because the CAP_NET_ADMIN capability is not getting applied.

I used the debug tools provided:
* sudo snap install snappy-debug
* sudo snap connect snappy-debug:log-observe
* sudo /snap/bin/snappy-debug.security scanlog

AppArmor reported:

    = AppArmor =
    Time: Apr 8 12:42:29
    Log: apparmor="ALLOWED" operation="capable" info="optional: no audit" error=-1 profile="snap.dovholuk.tunThing" pid=7224 comm="tunThing" capability=12 capname="net_admin"
    Capability: net_admin
    Suggestions:
    * adjust program to not require 'CAP_NET_ADMIN' (see 'man 7 capabilities')
    * add one of 'bluetooth-control, firewall-control, netlink-audit, netlink-connector, network-control' to 'plugs'
    * do nothing if using systemd utility (eg, timedatectl): https://forum.snapcraft.io/t/managing-time-date-and-timezone-in-ubuntu-core/408/44
    * do nothing (https://launchpad.net/bugs/1465724)

I started out by adding only network-control but that doesn't seem to be applying the CAP_NET_ADMIN capability so I then went on to include all the plugs in my snap to see if any of them would allow the application to create the tun.

I ran the snap with --stracce but I'm not sure if it's helpful:

    [pid 24136] openat(AT_FDCWD, "/dev/net/tun", O_RDWR|O_CLOEXEC) = 3
    [pid 24136] epoll_ctl(4, EPOLL_CTL_ADD, 3, {EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, {u32=1558634240, u64=140331025096448}}) = 0
    [pid 24136] fcntl(3, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE)
    [pid 24136] fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK|O_LARGEFILE) = 0
    [pid 24136] fcntl(3, F_GETFL) = 0x8802 (flags O_RDWR|O_NONBLOCK|O_LARGEFILE)
    [pid 24136] fcntl(3, F_SETFL, O_RDWR|O_LARGEFILE) = 0
    [pid 24136] ioctl(3, TUNSETIFF, 0xc0000ffb64) = -1 EPERM (Operation not permitted)

Apologies if this was misguided but I posted here first https://forum.snapcraft.io/t/cap-net-admin-not-being-provided-with-the-recommended-plugs/10834

The snap functions correctly when run as sudo but I'd like to not have to run it as sudo.

Revision history for this message
Zygmunt Krynicki (zyga) wrote :

Hello

Did you declare any connect any of the connected plugs to your application snap?

Changed in snappy:
status: New → Incomplete
Revision history for this message
Clint Dovholuk (dovholukspam) wrote :

Yes. At first I only provided network-control as I thought that made the most sense but after trying it out I then applied "all the plugs" (perhaps even too many)

    plugs:
      - home
      - network
      - network-bind
      - network-control
      - network-manager
      - network-observe
      - network-setup-control
      - network-setup-observe
      - network-status
      - bluetooth-control
      - firewall-control
      - netlink-audit
      - netlink-connector
      - fwupd

It's currently using strict confinement and I am 'snap remove' and 'snap install'-ing to do my testing. After snap install i also connect them all:

snap connect myTun:network
snap connect myTun:network-bind
snap connect myTun:network-control
snap connect myTun:network-manager
snap connect myTun:network-observe
snap connect myTun:network-setup-control
snap connect myTun:network-setup-observe
snap connect myTun:bluetooth-control
snap connect myTun:firewall-control
snap connect myTun:netlink-audit
snap connect myTun:netlink-connector
snap connect myTun:bluetooth-control

Revision history for this message
Clint Dovholuk (dovholukspam) wrote :

I also realize that I have built on ubuntu 18.04 - I am downloading the 16.04 LTS now to rule that out since the documentation states to use 16.04.

Revision history for this message
Clint Dovholuk (dovholukspam) wrote :

Confirmed on Ubuntu 16.04.

I have been running this as root to see any issues: /snap/bin/snappy-debug.security scanlog

The one issue logged was (Before running 'snap connect myTun:network-control')

    = AppArmor =
    Time: Apr 10 09:30:12
    Log: apparmor="DENIED" operation="open" profile="snap.dovholuk.myTun" name="/dev/net/tun" pid=12800 comm="aTun" requested_mask="wr" denied_mask="wr" fsuid=1000 ouid=0
    File: /dev/net/tun (write)
    Suggestion:
    * add 'network-control' to 'plugs'

After running 'snap connect myTun:network-control' - _NO_ logs pop out of the scanner and my application logs the failure:

    ioctl failed with 'operation not permitted'

Thanks for any help here...

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

Please note that snapd doesn't give your non-root user NET_ADMIN, it allows a user that already has it to keep it. As such, if the kernel is requiring your process to have NET_ADMIN and your user doesn't, then the kernel will deny the operation in this manner. When you launch your snap under sudo, the process starts with NET_ADMIN and since you connected network-control, the snapd security policy allows root to keep the capability, so the kernel allows the operation.

It sounds like once network-control is connected, everything is operating as expected.

Revision history for this message
Clint Dovholuk (dovholukspam) wrote :

Thanks again for the information; that makes sense. Since snap/snapd/snappy is managing this I had just presumed that it would be also be granting the capability when connecting the network-control plug.

Sounds like I need to look into how I can add capabilities to snaps so that non-root users can make a TUN. That or users of the snap will just have to be root. I've been searching for some doc on how to accomplish this but haven't had any luck so far but I'll keep looking.

Thanks again for your response

Changed in snappy:
status: Incomplete → Won't Fix
status: Won't Fix → Invalid
Revision history for this message
Clint Dovholuk (dovholukspam) wrote :

I'm ok with leaving this wontfix but I've been reading/researching. Is this document still valid? https://assets.ubuntu.com/v1/66fcd858-canonical-ubuntu-core-security-2018-11-13.pdf I ask because in that doc the words use certainly lead me to believe that snappy is "granting" these priviliges. (sadly there are not pages to reference so you'll need to 'find' the text)

under "Ubuntu Core interfaces" you will see:

  firewall-control: Can configure the firewall via netfilter and sysctl and grants the
  CAP_NET_ADMIN capability. Because this interface grants privileged access, this
  interface is not auto-connected on install and store policies may trigger a manual
  review for uploads of snaps specifying this interface.

  network-control: Can configure networking and network namespaces via sysctl,
  administrative commands (eg, ifconfig, route, ip, arp, etc) and grants the
  CAP_NET_ADMIN capability. Because this interface grants privileged access, this
  interface is not auto-connected on install and store policies may trigger a manual
  review.

Can you point me at how I might add this capability to my snap? The snaps themselves are just symlinks to /usr/bin/snap. I can't be excpected to run setcap on /usr/bin/snap right?

again - thank you for your time. it's much appreciated

Revision history for this message
Clint Dovholuk (dovholukspam) wrote :

I forgot to mention - if that doc is valid then maybe it needs to be updated to state that plug firewall-control and network-control do not _GRANT_ CAP_NET_ADMIN capability... And then - the guidance as to how to properly give the snap that capability should be referenced.

I will continue researching the doc out there to see if I can find "the right way" to add/actually grant the CAP_NET_ADMIN capability

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.