ufw

UFW snap prevents internet access at boot

Bug #1854637 reported by Krish De Souza
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
ufw
Expired
Undecided
Unassigned

Bug Description

ufw stable snap 0.36

At launch, there appears to be some capability issues with the snap that means all traffic gets blocked.

In my system log I get the following errors with the snap at boot.
Dec 1 15:38:47 anon-desktop kernel: [ 127.568645] audit: type=1400 audit(1575214727.126:186): apparmor="DENIED" operation="capable" profile="snap.ufw.ufw" pid=4923 comm="cli" capability=2 capname="dac_read_search"
Dec 1 15:38:47 anon-desktop kernel: [ 127.568649] audit: type=1400 audit(1575214727.126:187): apparmor="DENIED" operation="capable" profile="snap.ufw.ufw" pid=4923 comm="cli" capability=1 capname="dac_override"
Dec 1 15:38:47 anon-desktop kernel: [ 127.569170] audit: type=1400 audit(1575214727.126:188): apparmor="DENIED" operation="capable" profile="snap.ufw.ufw" pid=4950 comm="iptables" capability=2 capname="dac_read_search"
Dec 1 15:38:47 anon-desktop kernel: [ 127.570067] audit: type=1400 audit(1575214727.130:189): apparmor="DENIED" operation="capable" profile="snap.ufw.ufw" pid=4951 comm="ufw" capability=2 capname="dac_read_search"
Dec 1 15:38:47 anon-desktop kernel: [ 127.570070] audit: type=1400 audit(1575214727.130:190): apparmor="DENIED" operation="capable" profile="snap.ufw.ufw" pid=4951 comm="ufw" capability=1 capname="dac_override"
Dec 1 15:38:47 anon-desktop kernel: [ 127.620748] audit: type=1400 audit(1575214727.178:191): apparmor="DENIED" operation="capable" profile="snap.ufw.ufw" pid=4952 comm="iptables" capability=2 capname="dac_read_search"
Dec 1 15:38:47 anon-desktop kernel: [ 127.620751] audit: type=1400 audit(1575214727.178:192): apparmor="DENIED" operation="capable" profile="snap.ufw.ufw" pid=4952 comm="iptables" capability=1 capname="dac_override"
Dec 1 15:38:47 anon-desktop kernel: [ 127.623597] audit: type=1400 audit(1575214727.182:193): apparmor="DENIED" operation="capable" profile="snap.ufw.ufw" pid=4953 comm="ufw-init" capability=2 capname="dac_read_search"

Dec 1 15:39:00 anon-desktop kernel: [ 139.842455] audit: type=1400 audit(1575214740.807:201): apparmor="DENIED" operation="capable" profile="snap.ufw.ufw" pid=5194 comm="iptables" capability=2 capname="dac_read_search"
Dec 1 15:39:00 anon-desktop kernel: [ 139.842461] audit: type=1400 audit(1575214740.807:202): apparmor="DENIED" operation="capable" profile="snap.ufw.ufw" pid=5194 comm="iptables" capability=1 capname="dac_override"
Dec 1 15:39:00 anon-desktop kernel: [ 139.902787] audit: type=1400 audit(1575214740.867:203): apparmor="DENIED" operation="capable" profile="snap.ufw.ufw" pid=5203 comm="iptables" capability=2 capname="dac_read_search"
Dec 1 15:39:00 anon-desktop kernel: [ 139.902789] audit: type=1400 audit(1575214740.867:204): apparmor="DENIED" operation="capable" profile="snap.ufw.ufw" pid=5203 comm="iptables" capability=1 capname="dac_override"
Dec 1 15:39:00 anon-desktop kernel: [ 140.018105] audit: type=1400 audit(1575214740.983:205): apparmor="DENIED" operation="capable" profile="snap.ufw.ufw" pid=5387 comm="ip6tables-resto" capability=2 capname="dac_read_search"
Dec 1 15:39:00 anon-desktop kernel: [ 140.018109] audit: type=1400 audit(1575214740.983:206): apparmor="DENIED" operation="capable" profile="snap.ufw.ufw" pid=5387 comm="ip6tables-resto" capability=1 capname="dac_override"
Dec 1 15:39:01 anon-desktop kernel: [ 140.094153] audit: type=1400 audit(1575214741.059:207): apparmor="DENIED" operation="capable" profile="snap.ufw.ufw" pid=5456 comm="iptables" capability=2 capname="dac_read_search"
Dec 1 15:39:01 anon-desktop kernel: [ 140.094158] audit: type=1400 audit(1575214741.059:208): apparmor="DENIED" operation="capable" profile="snap.ufw.ufw" pid=5456 comm="iptables" capability=1 capname="dac_override"

The only way I get internet is doing ufw disable, at which point i get traffic again. My guess is there are some issues with capabilities with the snap and apparmor.

My distribution is kubuntu 19.10.

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

Thanks for your bug report and for using ufw.

On Ubuntu 19.10, I cannot reproduce this:

$ sudo apt-get remove --purge ufw

$ sudo snap install ufw

$ sudo ufw status
Status: inactive

$ sudo ufw allow 22/tcp
Rules updated
Rules updated (v6)

$ sudo ufw enable
Command may disrupt existing ssh connections. Proceed with operation (y|n)? y
Firewall is active and enabled on system startup

$ sudo ufw status
Status: active

To Action From
-- ------ ----
22/tcp ALLOW Anywhere
22/tcp (v6) ALLOW Anywhere (v6)

$ journalctl |grep DENIED
$

Can you provide steps to reproduce?

Changed in ufw:
status: New → Incomplete
Revision history for this message
Krish De Souza (kd913) wrote :

This seems to happen only on reboot specifically.

If I disable or enable it manually everything works again.

When I boot in dmesg I get the following.

[ 119.971205] audit: type=1400 audit(1575489405.024:164): apparmor="DENIED" operation="capable" profile="snap.ufw.ufw" pid=4672 comm="cli" capability=2 capname="dac_read_search"
[ 119.971210] audit: type=1400 audit(1575489405.024:165): apparmor="DENIED" operation="capable" profile="snap.ufw.ufw" pid=4672 comm="cli" capability=1 capname="dac_override"
[ 119.971730] audit: type=1400 audit(1575489405.024:166): apparmor="DENIED" operation="capable" profile="snap.ufw.ufw" pid=4699 comm="iptables" capability=2 capname="dac_read_search"
[ 119.971734] audit: type=1400 audit(1575489405.024:167): apparmor="DENIED" operation="capable" profile="snap.ufw.ufw" pid=4699 comm="iptables" capability=1 capname="dac_override"
[ 119.972674] audit: type=1400 audit(1575489405.028:168): apparmor="DENIED" operation="capable" profile="snap.ufw.ufw" pid=4700 comm="ufw" capability=2 capname="dac_read_search"
[ 119.972677] audit: type=1400 audit(1575489405.028:169): apparmor="DENIED" operation="capable" profile="snap.ufw.ufw" pid=4700 comm="ufw" capability=1 capname="dac_override"
[ 120.024367] audit: type=1400 audit(1575489405.080:170): apparmor="DENIED" operation="capable" profile="snap.ufw.ufw" pid=4701 comm="iptables" capability=2 capname="dac_read_search"
[ 120.024370] audit: type=1400 audit(1575489405.080:171): apparmor="DENIED" operation="capable" profile="snap.ufw.ufw" pid=4701 comm="iptables" capability=1 capname="dac_override"

My guess is that there is something denied with the permissions for the ufw snap.

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

What is the output of 'snap version'?

Revision history for this message
Krish De Souza (kd913) wrote :

Snap: 2.42.5
Snapd: 2.42.5
Series: 16
Ubuntu: 19.10
Kernel: 5.3.0-24-generic

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

I am still unable to reproduce this:

$ sudo apt-get remove --purge ufw

$ sudo snap install ufw

$ sudo ufw status
Status: inactive

$ sudo ufw allow 22/tcp
Rules updated
Rules updated (v6)

$ sudo ufw enable
Command may disrupt existing ssh connections. Proceed with operation (y|n)? y
Firewall is active and enabled on system startup

$ sudo ufw status
Status: active

To Action From
-- ------ ----
22/tcp ALLOW Anywhere
22/tcp (v6) ALLOW Anywhere (v6)

$ sudo reboot
...

$ sudo ufw status
Status: active

To Action From
-- ------ ----
22/tcp ALLOW Anywhere
22/tcp (v6) ALLOW Anywhere (v6)

$ sudo journalctl|grep DEN
$

The capability denials may suggest that the permissions aren't right on the system. Can you:

$ sudo ls -lR /var/snap/ufw/current/ /var/snap/ufw/common/ /root/snap/ufw > /tmp/lp1854637

Then attach /tmp/lp1854637 to this bug?

Revision history for this message
Krish De Souza (kd913) wrote :

Hi, I have attached the permissions as requested. This bug is still affecting me it seems.

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

The permissions look ok. Can you please either attach or email the firewall configuration? Please run this command:

sudo tar -zcvf ufw-1854637.tar.gz /var/snap/ufw/ /root/snap/ufw /home/*/snap/ufw

(it is ok if it reports 'tar: /home/*/snap/ufw: Cannot stat: No such file or directory')

Please attach/email ufw-1854637.tar.gz.

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

Also, after a reboot but before you correct anything with ufw, can you perform:

$ sudo lsmod > /tmp/lp1854637.lsmod

and attach to the bug?

Revision history for this message
Krish De Souza (kd913) wrote :

I'll try and get the other attachment when it appears. The issue does seem to occur sporadically on fresh-boot and at random points that seem to coincide with kwallet key refresh.

Last week for example, I ran into the problem about 3-5 times.

Revision history for this message
Krish De Souza (kd913) wrote :

In addition to the previous bug, i have also noticed that sometimes the rules aren't set.

I have an explicit rule set to enable ssh.

I have to run ufw reload in order for the rule to actually be set on boot.

Revision history for this message
Krish De Souza (kd913) wrote :

Just to add, it seems that pretty regularly the ufw initial state seems to be a bit broken.

In my case i have openssh installed with an ssh key added.

When I try and ssh in from an external device, it doesn't work unless i run sudo ufw reload.

Revision history for this message
Krish De Souza (kd913) wrote :

Can I just confirm if you can reproduce this? If not, I will try and reproduce it in a VM over the weekend to see if I can replicate what is going wrong.

In your snap install are you having any of the messages I am seeing?

Running sudo sysctl | grep ufw

I am seeing the following:

kd913@anon-desktop:/snap/ufw/current$ systemctl | grep ufw
  run-snapd-ns-ufw.mnt.mount loaded active mounted /run/snapd/ns/ufw.mnt
  snap-ufw-296.mount loaded active mounted Mount unit for ufw, revision 296
  snap-ufw-337.mount loaded active mounted Mount unit for ufw, revision 337
● snap.ufw.srv.service loaded failed failed Service for snap application ufw.srv

Revision history for this message
Krish De Souza (kd913) wrote :

● snap.ufw.srv.service - Service for snap application ufw.srv
   Loaded: loaded (/etc/systemd/system/snap.ufw.srv.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Tue 2020-01-14 19:33:26 GMT; 5h 50min ago
 Main PID: 2107 (code=exited, status=1/FAILURE)

Jan 14 19:33:25 anon-desktop systemd[1]: Starting Service for snap application ufw.srv...
Jan 14 19:33:26 anon-desktop ufw.srv[2107]: iptables-restore: line 38 failed
Jan 14 19:33:26 anon-desktop ufw.srv[2107]: Problem running '/var/snap/ufw/296//etc/ufw/user.rules'
Jan 14 19:33:26 anon-desktop systemd[1]: snap.ufw.srv.service: Main process exited, code=exited, status=1/FAILURE
Jan 14 19:33:26 anon-desktop systemd[1]: snap.ufw.srv.service: Failed with result 'exit-code'.
Jan 14 19:33:26 anon-desktop systemd[1]: Failed to start Service for snap application ufw.srv.

Running journalctl -u snap.ufw.srv.service

Jan 13 21:31:23 anon-desktop systemd[1]: Starting Service for snap application ufw.srv...
Jan 13 21:31:24 anon-desktop ufw.srv[2067]: iptables-restore: line 38 failed
Jan 13 21:31:24 anon-desktop ufw.srv[2067]: Problem running '/var/snap/ufw/296//etc/ufw/user.rules'
Jan 13 21:31:24 anon-desktop systemd[1]: snap.ufw.srv.service: Main process exited, code=exited, status=1/FAILURE
Jan 13 21:31:24 anon-desktop systemd[1]: snap.ufw.srv.service: Failed with result 'exit-code'.
Jan 13 21:31:24 anon-desktop systemd[1]: Failed to start Service for snap application ufw.srv.

I think like 38 '/var/snap/ufw/296//etc/ufw/user.rules' may be something...

Revision history for this message
Krish De Souza (kd913) wrote :

To add here is my history of journalctl and the point in which things seem to become a little screwed.

Revision history for this message
Krish De Souza (kd913) wrote :

So I reinstalled the snap, and now that service file of /etc/systemd/system/snap.ufw.srv.service doesn't exist.

Was this some remnant left from a previous snap version?

Revision history for this message
Krish De Souza (kd913) wrote :

I rebooted and the service file is now in place and failing with the above problem.

-- Reboot --
Jan 15 01:42:40 anon-desktop systemd[1]: Starting Service for snap application ufw.srv...
Jan 15 01:42:41 anon-desktop systemd[1]: snap.ufw.srv.service: Succeeded.
Jan 15 01:42:41 anon-desktop systemd[1]: Started Service for snap application ufw.srv.
-- Reboot --
Jan 15 01:53:50 anon-desktop systemd[1]: Starting Service for snap application ufw.srv...
Jan 15 01:53:51 anon-desktop ufw.srv[2065]: iptables-restore: line 38 failed
Jan 15 01:53:51 anon-desktop ufw.srv[2065]: Problem running '/var/snap/ufw/296//etc/ufw/user.rules'
Jan 15 01:53:51 anon-desktop systemd[1]: snap.ufw.srv.service: Main process exited, code=exited, status=1/FAILURE
Jan 15 01:53:51 anon-desktop systemd[1]: snap.ufw.srv.service: Failed with result 'exit-code'.
Jan 15 01:53:51 anon-desktop systemd[1]: Failed to start Service for snap application ufw.srv.

Revision history for this message
Krish De Souza (kd913) wrote :

Hello,

Is there anyone still working on this problem? I seem to still regularly hit this issue and the only solution so far has been to move to the non-snap version of ufw.

Kind regards,
Krish

Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for ufw because there has been no activity for 60 days.]

Changed in ufw:
status: Incomplete → Expired
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

Sorry for the delay in response. I've tried to reproduce this many times over the last months, added monitoring scripts, etc and have asked around if others have seen it and neither I nor they can reproduce it. I'm not sure how feasible it is, but if you are able to reproduce with with a fresh install and simple steps to reproduce, that would help a lot. I've marked the bug back to Incomplete but I understand if you don't have the time to provide the requested info.

Changed in ufw:
status: Expired → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for ufw because there has been no activity for 60 days.]

Changed in ufw:
status: Incomplete → Expired
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.