gufw-developers team mailing list archive

[JPW <midi.johnny@xxxxxxxxx>]

*** This bug is a security vulnerability ***

Private security bug reported:

I noticed this issue using the Raspberry Pi Ubuntu Mate Image:

$ sha1sum ubuntu-mate-15.10.3-desktop-armhf-raspberry-pi-2.img
2c7e349e5adb37dd0a98adb8d2bd8edcdf79c38a  ubuntu-mate-15.10.3-desktop-armhf-raspberry-pi-2.img

I haven't tried this on other images/architecture - but it seems to me
that the Firewall Applet GUI in Mate is not correctly verifying whether
the Firewall is *really* enabled; and this will likely apply to any
architecture/image.

The Raspberry Pi image above (I guess incorrectly?) happens to install
the '/lib' directory with non-root ownership, and additionally has
group-write permissions: I am *not* reporting that issue here: I'm
reporting the downstream problem with the Firewall UI given this fact.

The upshot is: if you use the GUI Firewall Applet to enable the
Firewall: the Firewall reports back that it is enabled; but then running
a commandline check:

    sudo ufw status

Shows that it is not: and reports back the issue with the /lib
ownership/permissions:

    WARN: uid is 0 but '/lib' is owned by 1000
    WARN: /lib is group writeable!
    Status: inactive

Closing the Firewall Applet and re-opening it confirms this.
But to a normal Desktop user: the Firewall Applet has reported back that all is well; it gives the end-user a false impression that their Firewall is enabled, but it is not: it should check (or display the errors that the commandline version 'ufw' does?)

I fixed this on my system; by issuing the following and retrying - the
Firewall Applet then correctly enables the Firewall.

        sudo chown root:root /lib
	sudo chmod g-w /lib

(And I checked in both cases that the 'ufw status' is telling the truth;
by attempting to 'break-in' to the Firewall from another machine)

I am attaching a few screenshots and textfiles showing this issue.

** Affects: gui-ufw
     Importance: Undecided
         Status: New


** Tags: false-enabled-message lib ufw

** Attachment added: "screenshots (and text files)"
   https://bugs.launchpad.net/bugs/1581944/+attachment/4663241/+files/firewall-applet-false-enabled-message.tar.gz

-- 
You received this bug notification because you are a member of Gufw
Developers, which is subscribed to Gufw.
https://bugs.launchpad.net/bugs/1581944

Title:
  "Firewall enabled" message: but not. (/lib has wrong ownership)

Status in Gufw:
  New

Bug description:
  I noticed this issue using the Raspberry Pi Ubuntu Mate Image:

  $ sha1sum ubuntu-mate-15.10.3-desktop-armhf-raspberry-pi-2.img
  2c7e349e5adb37dd0a98adb8d2bd8edcdf79c38a  ubuntu-mate-15.10.3-desktop-armhf-raspberry-pi-2.img

  I haven't tried this on other images/architecture - but it seems to me
  that the Firewall Applet GUI in Mate is not correctly verifying
  whether the Firewall is *really* enabled; and this will likely apply
  to any architecture/image.

  The Raspberry Pi image above (I guess incorrectly?) happens to install
  the '/lib' directory with non-root ownership, and additionally has
  group-write permissions: I am *not* reporting that issue here: I'm
  reporting the downstream problem with the Firewall UI given this fact.

  The upshot is: if you use the GUI Firewall Applet to enable the
  Firewall: the Firewall reports back that it is enabled; but then
  running a commandline check:

      sudo ufw status

  Shows that it is not: and reports back the issue with the /lib
  ownership/permissions:

      WARN: uid is 0 but '/lib' is owned by 1000
      WARN: /lib is group writeable!
      Status: inactive

  Closing the Firewall Applet and re-opening it confirms this.
  But to a normal Desktop user: the Firewall Applet has reported back that all is well; it gives the end-user a false impression that their Firewall is enabled, but it is not: it should check (or display the errors that the commandline version 'ufw' does?)

  I fixed this on my system; by issuing the following and retrying - the
  Firewall Applet then correctly enables the Firewall.

          sudo chown root:root /lib
  	sudo chmod g-w /lib

  (And I checked in both cases that the 'ufw status' is telling the
  truth; by attempting to 'break-in' to the Firewall from another
  machine)

  I am attaching a few screenshots and textfiles showing this issue.

To manage notifications about this bug go to:
https://bugs.launchpad.net/gui-ufw/+bug/1581944/+subscriptions