gufw leaves ufw disabled if `/etc` or `/lib` is group writable
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Gufw |
Fix Released
|
Critical
|
costales |
Bug Description
Steps to reproduce this:
1. Make `/etc` group writable, and confirm this triggers a warning from the `ufw` command:
# ufw status
Status: inactive
# chmod g+w /etc
# ufw status
WARN: /etc is group writable!
Status: inactive
2. Run `watch -n.5 ufw status verbose` to monitor ufw.
3. Run gufw and enable a profile
Expected:
ufw status should report that ufw is enabled
Actual results:
ufw status briefly toggles to an enabled state, and then reverts back to being disabled.
I assume that what's happening is gufw runs a command to enable ufw, interprets the warnings as an error, raises an exception internally, and then runs some error handler that unconditionally disables ufw, but I haven't confirmed this in any way.
There's no hint in the user interface that the firewall isn't enabled (the switch stays in the enabled position), which makes this a security issue: a user could easily think that they've successfully set up gufw, and wouldn't realize that they're unprotected unless they bothered to independently test that their system's firewall is working as they've intended to configure it.
In case my reproduction steps don't work, I'm reporting this from LMDE (Debian Stretch), using ufw 0.35-4 and gufw 17.04.1-1.1.
Related branches
Changed in gui-ufw: | |
status: | New → In Progress |
importance: | Undecided → Critical |
assignee: | nobody → costales (costales) |
Changed in gui-ufw: | |
status: | In Progress → Fix Committed |
Changed in gui-ufw: | |
status: | Fix Committed → Fix Released |