Opened 9 years ago

Closed 8 years ago

#2824 closed defect (fixed)

Make Linux TBB not fail in a non-obvious manner when run as root

Reported by: rransom Owned by: erinn
Priority: Medium Milestone:
Component: Applications/Tor bundles/installation Version:
Severity: Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Currently, the Linux Tor Browser Bundle tarball contains files owned by a non-root user and its corresponding group. This causes TBB to fail to run when it is unpacked and run by root (Tor sees that its DataDirectory is not owned by the user that it is running as and refuses to run). Regardless of how absurdly bad an idea running TBB as root is, it shouldn't fail in such a non-obvious manner.

There are two not-mutually-exclusive ways to fix this:

  1. Set the owner and group of every file/directory in the Linux TBB tarball to root:wheel (UID and GID 0).
  2. Add an explicit check to start-tor-browser to detect that TBB is being run as root and refuse to run, with a meaningful error message.

Child Tickets

Change History (11)

comment:1 Changed 8 years ago by rransom

bsdcpio (shipped with libarchive) can produce tar archives and has a -R option that can set the user and group of every file in the resulting archive.

comment:2 Changed 8 years ago by rransom

To make TBB explicitly refuse to run as root, put the following command near the beginning of start-tor-browser.sh:

test "`id -u`" -eq 0 &&
echo "Tor Browser Bundle should not be run as root.  Exiting." >&2 &&
exit 2

comment:3 Changed 8 years ago by rransom

The Debian package tardy is another option for removing file UIDs and GIDs from the tarball.

comment:4 Changed 8 years ago by rransom

Status: newneeds_review

See fixes-2011-08-23-01-master ( https://git.torproject.org/user/rransom/torbrowser.git fixes-2011-08-23-01-master ) for fixes for this bug and some other not-yet-reported issues.

I chose tardy over the other options (GNU tar --owner and --group, bsdtar -R) for removing UIDs and GIDs from the tarball because they seemed less reliable.

comment:5 Changed 8 years ago by Sebastian

Not sure about the last patch, seems it would be yet one more way for TBB to fail to launch without any kind of user feedback when launched from a graphical file manager application?

comment:6 in reply to:  5 Changed 8 years ago by rransom

Replying to Sebastian:

Not sure about the last patch, seems it would be yet one more way for TBB to fail to launch without any kind of user feedback when launched from a graphical file manager application?

I think I've mostly fixed the 'no feedback when launched from a GUI file manager' issue now (on the same branch), along with a few others (including #2525).

Now that RelativeLink.sh can display messages to ordinary users, we will also need to figure out how to translate its strings.

comment:7 Changed 8 years ago by rransom

I've pushed some UI improvements suggested by velope to the same branch.

This set of changes should be applied to maint-2.2 by running git cherry-pick -x 57bd70de17606df28526ad9524f22f64849f66af..rransom/fixes-2011-08-23-01-master with maint-2.2 checked out. Do not leave out the -x.

comment:8 Changed 8 years ago by rransom

Some actual data on what shell-script-GUI programs complain can use:

  • The last time I set up a FreeBSD system, the xorg meta-port defaulted to bringing in xmessage. TBB would not be usable on a FreeBSD system with only xorg installed, but it is possible to make TBB run on FreeBSD without installing zenity or gxmessage.
  • My default installation of Debian Squeeze from the net-install disk came with both zenity and xmessage, but not gxmessage.
  • debian-live-6.0.1-i386-{gnome,lxde,xfce}-desktop.iso have zenity, but not xmessage or gxmessage. debian-live-6.0.1-i386-kde-desktop.iso has none of those three; I'm about to boot it and find out (a) what package kdialog lives in, if it still exists, and (b) how to use it.
  • Arch Linux is probably hopeless -- many window manager packages that I remember installing when I was an Arch user didn't pull in any xmessage-like program as a dependency, and the 'desktop environments' seem less popular among Arch users than minimalistic environments based on exotic WMs.
  • Gentoo is probably hopeless, too, although xmessage might be commonly installed on Gentoo systems with X.

Can anyone check to see what various default installations/configurations (with X and Gtk installed, of course) of the current versions of Fedora and CentOS include? Are there any other distributions we should care about?

comment:9 Changed 8 years ago by rransom

kdialog is in the Debian package kdebase-bin, and I've added support for it to complain.

comment:10 Changed 8 years ago by erinn

I've reviewed all of the changes and I like them. One remaining issue: as of Vidalia 0.2.13 (and now Vidalia 0.2.14), and the pending Torbutton 1.4.1, TBB will automatically choose a different port for Vidalia and Tor. Should we remove the checks for Vidalia and polipo, since polipo isn't even in any of the Linux TBBs? If so, do you want to update it? It's a pretty small section of the script so I could do it too, if there is agreement. (I can't see any reason at all to leave it though.)

comment:11 in reply to:  10 Changed 8 years ago by rransom

Resolution: fixed
Status: needs_reviewclosed

Replying to erinn:

I've reviewed all of the changes and I like them. One remaining issue: as of Vidalia 0.2.13 (and now Vidalia 0.2.14), and the pending Torbutton 1.4.1, TBB will automatically choose a different port for Vidalia and Tor. Should we remove the checks for Vidalia and polipo, since polipo isn't even in any of the Linux TBBs? If so, do you want to update it? It's a pretty small section of the script so I could do it too, if there is agreement. (I can't see any reason at all to leave it though.)

Erinn removed the check for running tor and vidalia processes; this bug is now fixed.

Note: See TracTickets for help on using tickets.