{{toc}}

Rationale

Current state

In current Tails,

• a root password is set in config/chroot_local-hooks/01-password, but it’s public and the same on all live systems;
• full sudo access is granted to the amnesia user.

Problems

If the user password is empty, any malware that infects user code can get root access. Else, any malware that can guess that password (which is particularly easy if it’s written specifically for amnesia, which is a reasonable thing to have within the threat model) while running as the amnesia user can get root access.

One could, however, argue that protecting the root user isn’t very important given how bad a compromise of the amnesia user (which is the most likely user account to be attacked) is: it has access to the real IP address through /sbin/ifconfig, and everything Tor does (through its control port) so it could send all that information to the attacker, and we’re screwed.

Sure, ifconfig will only report a local address if we’re using NAT, and a service like whatismyip.org wouldn’t work due to the transparent proxying which forwards all traffic to Tor.

A root account compromise would screw us in that case.

Obviously disabling the root account (i.e. trashing its password hash in the shadow file) does nothing against a local root exploit.

Needed functionality

In order to find a security/privacy/usability compromise, let’s discuss what kind of root access is needed.

Package installation

In a Debian Live system, it’s really easy to install new packages after startup (sudo apt-get install <package> or through the graphical package manager). This is a really nice and desirable feature, making some kind of root access quite worthwhile.

OTOH, there might be an obscure Debian package whose installation would reset our iptables rules. A malware could install such a package, retrieve the real user IP, and send it to an attacker.

• A targeted piece of malware could do this with out the need of installing said software

Our plans

We agreed upon using the upcoming TailsGreeter boot menu to allow the user to type a sudo/root password in a text input box. If none is entered, there’s no root access at all. If a password is entered, it is set for the default user + sudo enabled.

Implementation:

1. there should be no root nor user password by default;
2. the TailsGreeter should trigger a script that would run in an environnement containing a $TAILS_USER_PASSWORD variable OR the TailsGreeter should setup that env variable an the script is always run?
3. the script would set the user password, if any was given;
4. if the environnement TailsGreeter run the script in does’t terminate with it, TailsGreeter should then unset the env variable.

The steps that are not part of the TailsGreeter (1st and 3rd) are implemented in the branch feature/better_root_access_control.

done in Tails 0.11

Archives

The following solutions are kept only for historical reasons and understanding the decision that was made.

Disabled root access by default, boot menu option to enable it

If enabled to user would be prompted to set a password during early init or initramfs.

• If persistence is available it is possible to save the root line from /etc/shadow and have it automatically restored instead of showing the password setting prompt which makes this option less intrusive.
  • Since the idea of this possibility is to reduce the number of obstackes for the user during boot it wouldn’t make much sense to encrypt it as the user then would have to enter the passphrase during boot instead. However, if the user has some other encrypted persistent storage (like $HOME) it could be saved there and restored after the passphrase for that container has been entered.

Mandatory password setting

The user is prompted for a password during init or initramfs. If an empty password is entered, the root account is disabled.

• If persistence is available the password can be saved and restored as in the above solution.

Random password at boot

Maybe we could generate on boot a random password and display it on screen. But that is really to bothersome in practice.

No root access, more restrictive sudo configuration

We could be more restrictive of which commands are allowed to run as root.

• Enabling some commands might have dangerous consequences which are hard to anticipate.
• Some users might need less restrictions to work around bugs/problems they have — in other words, it might be hard for us to know which commands the users expect to have available.

Root console available for 2 minutes after boot

This leaves the user 2 minutes to set a root password. Unless this is done before this delay has expired, the root console is disabled, and no root access is possible anymore (as the root account has a disabled password by default).

This is the solution chosen by Liberte Linux. They:

• patch inittab in src/etc/conf.d/local.start to run a root shell and have it not respawned
• set TMOUT=120 in src/root/.profile (this is a bash feature that makes interactive terminals exit unless there is input during this time after the first prompt)

Beware! live-config patches inittab at boot time. Let’s re-patch it in a later live-config script (hint: config/chroot local-includes/lib/live/config/.

Also, we don’t ship the /root/.profile that ends up in Tails images but we can patch it using chroot_local-patches after a package has put it in place.

We also need to:

• stop setting a known root password
• set the (probably live-config) option that disables sudo for the default user
• write documentation (about the change / how to use it the new way)

GrSecurity/PaX/SELinux etc.

See Mandatory Access Control.