[Bug 876626] Re: Unlocking the second crypto disk (/home) echos password on console

Tue Apr 24 14:00:37 UTC 2012

Hi Steve,

Since Plymouth is a 'long-running process' wrt the boot and since it is attaching to the console (a shared device), I really don't think it should be making any assumptions -- particularly before requesting a password: it should set a 'secure' terminal environment immediately before prompting. On my test system, over 1500 processes were created between plymouthd starting in the initramfs and my test plymouth client Upstart job running which gives huge scope for a process to tweak the
terminal settings after plymouth initially sets them.

We could make Upstart perform more intelligent bit-twiddling but there
are a _lot_ of options (atleast 47) and Upstart cannot really know which
bits it should be twiddling in all scenarios as -- for example --
/dev/console might be attached to a serial line.

Upstart cannot make assumptions about the state the console is left in
since either something running in the initramfs may have disturbed sane
defaults, or as mentioned, there may be no initramfs so a reset
generally makes perfect sense I think. The reset it is doing is similar
to "stty sane" (which also includes 'ECHO') which gives a 'normal'
console setup.

Details of when Scott changed the console handling in Upstart (both in
Upstream and Ubuntu) are:

------------------------------
revno: 1326
committer: Scott James Remnant <scott at netsplit.com>
branch nick: upstart
timestamp: Thu 2011-08-11 13:30:15 -0700
message:
  * init/main.c: Deal with failure to setup the system console by
  falling back to /dev/null, so we don't end up without default fds
  and castrate the process.
------------------------------

We need input from Scott as to the precise retionale for this change
since simply undoing it might cause equally bad problems in other parts
of the system. I wonder if he implemented it for bug 880049 and just
forgot to update that bug?

> I don't think the latter part is right, because plymouth is still running at
> the end of the job and still owns the console

I'm not sure any process owns the console. If we impose policy to state that plymouth does, which plymouth do we mean? The one that runs from the initramfs or the one started as an Upstart job? What about PID 1? What about 'console owner' Upstart jobs? I think the point here is that plymouthd doesn't have awareness of whether it is running in the initramfs or via an Upstart job and Upstart doesn't have an awareness of whether it was started directly or from an initramfs, neither does it
know about the existing plymouthd process if that was started from the initramfs.

> Also this job has no 'console' line, so the stty command
> would have to have its stdin attached to the console somehow... so it's
> really not worth trying to deploy a quick fix here.

The workaround I outlined wasn't necessarily intended to be included in
Ubuntu directly, but was more for users affected by this issue since
they could add those two commands relatively easily to restore expected
behaviour. I appreciate there is no 'console' stanza, but it doesn't
need one - the job runs the plymouth client that asks plymouthd to
request a password from the user, and plymouthd is connected to
/dev/console.

I've checked the latest Plymouth code and it seems there is an attractive compromise for Quantal: plymouth now locks the terminal before resetting it to its chosen defaults. This means that for Quantal (which would include the newer Plymouth) we could change Upstart to only reset the terminal attributes *if the tty in question is not already locked* (we could also add '--force-console-reset' and '--no-console-reset' options to Upstart too for flexibility). This co-operative method for
handling console access is in fact how systemd currently attempts to work with Plymouth on Fedora (although it appears the systemd implementation is broken).

Whatever approach we take, it might still possible for a job that specifies 'console output' or 'console owner' (including all SysV
services) to tweak the attributes underneath Plymouth so the safest approach I feel is for plymouth to also be modified to ensure it requests passwords in a more secure manner.

To summarise my thoughts:

- For Precise

    - Fix plymouthd to disable echoing at the point a password is prompted for.

    and/or:

    - Potentially revert the Upstart change
      (once we understand the rationale for change and full implications of reverting).

- For Quantal

    - Fix plymouthd to disable echoing at the point a password is
prompted for.

    - Pull in latest plymouth that locks the terminal attributes.

    - Stop Upstart resetting the terminal attributes if they are already
locked.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to plymouth in Ubuntu.
https://bugs.launchpad.net/bugs/876626

Title:
  Unlocking the second crypto disk (/home) echos password on console

Status in “plymouth” package in Ubuntu:
  Confirmed
Status in “upstart” package in Ubuntu:
  In Progress
Status in “plymouth” source package in Oneiric:
  Confirmed
Status in “upstart” source package in Oneiric:
  Confirmed
Status in “plymouth” source package in Precise:
  Confirmed
Status in “upstart” source package in Precise:
  In Progress

Bug description:
  Boot

  1.) Enter crypto phrase for /
  2.) ... init things...
  3.) Enter crypto phrase for /home

  On 3rd the password is echoed as such, only after pressing enter it prints the passwords again with stars.
  Enter passphrase: ABCDEF ENTER
  Enter passphrase: *******

  Workaround:  install the plymouth-theme-ubuntu-logo package if not
  already installed, and boot with the 'splash' option

  ---
  ApportVersion: 1.23-0ubuntu3
  Architecture: i386
  DistroRelease: Ubuntu 11.10
  Package: cryptsetup 2:1.1.3-4ubuntu2
  PackageArchitecture: i386
  ProcEnviron:
   SHELL=/bin/bash
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   LANGUAGE=en_US:en
  ProcVersionSignature: Ubuntu 3.0.0-12.20-generic 3.0.4
  Tags:  oneiric
  Uname: Linux 3.0.0-12-generic i686
  UpgradeStatus: Upgraded to oneiric on 2011-10-15 (5 days ago)
  UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare usrp
  crypttab:
   vg_xiaoyu-root_crypt UUID=8ef6fb8f-ada6-464c-8ba3-d3ceed02ccdd none luks
   vg_xiaoyu-home_crypt UUID=e0aa6c3d-21b1-4ae9-a0db-17b81f13a2cf none luks
   vg_xiaoyu-swap_crypt /dev/mapper/vg_xiaoyu-swap /dev/urandom cipher=aes-cbc-essiv:sha256,size=256,swap

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/876626/+subscriptions