Comment 12 for bug 307019

Revision history for this message
James Westby (james-w) wrote :

> Being the new maintainer of the stb, gst and friends,

Thanks for taking on this task.

> I must precise that if you want them to work properly with a new feature, that's a matter of one line fixes, most of
> the time. They are actually using "usermod -p" in the background. So if you find the stb are broken, well, fix your
> command line tools.

We can't fix "usermod -p" to go through pam, as pam requires the plaintext password so that the
modules can do as they like with it (which ecryptfs needs I believe). usermod -p takes the encrypted
password.

It does this as the separation between gst and stb means that you want to crypt the password in one
process and then pass it over, rather than sending the plaintext. This separation is needed for the
policykit stuff, and it is chosen to do it over DBus.

When changing your own password you don't need polkit, and so you can do it in process (as
gnome-about-me does), and so use pam with the plaintext password.

Now, Kees' proposal for the common case of changing your own password is to hand off to
gnome-about-me, gst could do this in-process for the same effect.

So, to fix this properly in gst for the other cases we need to do something different. Some
ideas

  * Rely on DBus security policies to stop snooping. I'm not sure how reliable this is.
  * DBus-ssl: negotiate an encrypted channel using DH key exchange or similar over DBus. I like the idea but it's rather over-engineered unfortunately :-)
  * gst requests that stb create a named pipe on the fs that it then writes the plaintext to. Kees would be able to say how secure that would be.
  * Drop DBus and move to a suid helper, still protected by polkit, and pass the plaintext using stdin or similar.

Having something like the above would clearly be a better fix, but is more work than the proposed
simple fix for the common case.

> It would be fairly easy to use another program, or to run, say, ecryptfs-rewrap-passphrase, just
> after changing the password.

The backend still would need the plaintext to run that wouldn't it?

Thanks,

James