Don't allow the desktop user to pass arguments to tails-upgrade-frontend
/etc/sudoers.d/zzz_upgrade, we allow the desktop user to run tails-upgrade-frontend as the tails-upgrade-frontend user, with any arguments. Some of the available options might be dangerous. I've looked at it quickly and didn't find anything scary, but still, we should lock this down, and apply something like:
--- a/config/chroot_local-includes/etc/sudoers.d/zzz_upgrade +++ b/config/chroot_local-includes/etc/sudoers.d/zzz_upgrade @@ -1,6 +1,6 @@ Cmnd_Alias INSTALL_IUK = /bin/chmod, /bin/cp, /bin/mkdir, /bin/mktemp, /bin/mount, /bin/rm, /bin/tar Cmnd_Alias IUK_GET_TARGET_FILE = /usr/bin/tails-iuk-get-target-file -Cmnd_Alias UPGRADE_FRONTEND = /usr/bin/tails-upgrade-frontend +Cmnd_Alias UPGRADE_FRONTEND = /usr/bin/tails-upgrade-frontend "" Defaults!IUK_GET_TARGET_FILE env_keep+="HARNESS_ACTIVE DISABLE_PROXY" Defaults!UPGRADE_FRONTEND env_keep+="DISABLE_PROXY SSL_NO_VERIFY"
Note that the manual test suite doc must be updated, to instruct testers to revert this change, as in this context they do need to pass arguments to t-p-s.
Don't allow the desktop user to pass arguments to tails-upgrade-frontend (Closes: #7410)
... and accordingly update the design document and manual test suite steps.
The tails-upgrade-frontend program is run as the tails-upgrade-frontend user,
that is basically equivalent to root. Some of the available
tails-upgrade-frontend options might be dangerous. I've looked at it quickly and
didn't find anything scary, but still, it's simply not worth taking the risk of
privilege escalation, persistent root kit implementation, and so on.
Strictly speaking, this change does not really belong to
bugfix/7345-upgrade-from-iso-from-1.0-to-1.1, and could have been implemented
separately. However, this branch introduces running as root a syslinux binary
taken from the installed IUK, so it raised the flag that made me want to lock
this down a bit more.
#2 Updated by intrigeri over 5 years ago
I'm not convinced. Users that dare add arguments are supposed to know what they're doing (not a mistake). I don't see the point if it bothers testers.
It's simply not worth taking the risk of privilege escalation,
persistent root kit implementation, and so on. It's way easier to lock
things down with the "least privilege" principle, than to make sure
that privileges beyond what's necessary are safe, and will ever be.