Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tomb doesn't ask for a password when forging a key #166

Closed
fsLeg opened this issue Nov 24, 2014 · 7 comments
Closed

Tomb doesn't ask for a password when forging a key #166

fsLeg opened this issue Nov 24, 2014 · 7 comments
Assignees
Milestone

Comments

@fsLeg
Copy link

fsLeg commented Nov 24, 2014

If it's now one, then it's the other... I've got another problem, and this time I'm completely clueless.

Well, this is what happens:

$ LC_ALL=C LANG=C ./tomb -D forge -k ~/tmp/test.tomb.key -f
tomb [D] Identified caller: fsleg (500:1000)
tomb [D] Tomb command: forge
tomb [D] Caller: uid[500], gid[1000], tty[/dev/pts/1].
tomb [D] Temporary directory: /tmp/zsh
tomb [D] Using sudo for root execution of './tomb -D forge -k /home/fsleg/tmp/test.tomb.key -f'.
tomb [D] Identified caller: fsleg (500:1000)
tomb [D] Updating HOME to match user's: /home/fsleg (was /root)
tomb [D] Tomb command: forge
tomb [D] Caller: uid[500], gid[1000], tty[/dev/pts/1].
tomb [D] Temporary directory: /tmp/zsh
tomb  .  Commanded to forge key /home/fsleg/tmp/test.tomb.key
tomb  .  Commanded to forge key /home/fsleg/tmp/test.tomb.key with cipher algorithm AES256
tomb  .  This operation takes time, keep using this computer on other tasks,
tomb  .  once done you will be asked to choose a password for your tomb.
tomb  .  To make it faster you can move the mouse around.
tomb  .  If you are on a server, you can use an Entropy Generation Daemon.
tomb [D] Data dump using dd from /dev/random
256+0 records in
256+0 records out
256 bytes (256 B) copied, 77.3713 s, 0.0 kB/s
tomb (*) Choose the  password of your key: /home/fsleg/tmp/test.tomb.key
tomb  .  (You can also change it later using 'tomb passwd'.)
tomb [D] exec_as_user 'fsleg': ./tomb askpass Type the new password to secure your key
tomb [E] You set empty password, which is not possible.

The password prompt never appears. Interesting fact: tomb askpass works as expected under both regular and superuser.

Here's trace taken with zsh -x: https://gist.github.com/fsLeg/ab1774f5b95a7a653d84

@jaromil
Copy link
Member

jaromil commented Nov 24, 2014

I got this reported yesterday by a slackware dev.

Needs a xhost +localhost to work with pinentry-gtk2

I plan to solve this by making pinentry-curses the hardcoded default, customizable from a new option --pinentry

@jaromil jaromil self-assigned this Nov 24, 2014
@jaromil jaromil added this to the 2.0 milestone Nov 24, 2014
@boyska
Copy link
Member

boyska commented Nov 24, 2014

I believe that pinenty-gtk2 is SERIOUSLY better than the curses version, and it should be the default, just like it is right now. It prevents focus to be stealed (both from a keylogger or even by accident) and passwords written in the wrong place. This really is an issue for me, and part of what makes tomb "secure by usability". Please let pinenty-gtk2 default. Adding an option won't be a problem, instead

@jaromil
Copy link
Member

jaromil commented Nov 24, 2014

I agree pinentry-gtk2 is better, please consider I'm an ardent supporter of pinentry and actively including in all my software and even other people's software. Please also note that right now pinentry-gtk2 is not the default. The default is pinentry, whatever that binary or symlink or alternative may lead to. Arguably here is Slackware's fault to configure that to something that does not work if run through sudo.

But the default must work and not leave users clueless without asking a password. For this to happen, pinentry-curses must be the defaut. Users can configure both Tomb or gpg-agent.conf to use pinentry-gtk2.

The problem arises for conscious OS developers and maintainers who want to configure a system-wide pinentry-gtk2 default. Hardcoding pinentry-curses may make it impossible to change such default without user's action and without defacing the curses version with the gtk2.

Therefore I'm now considering to parse also /etc/gpg-agent.conf which can be containing the same entry pinentry-program as the one found in $HOME, yet be overwritten by the latter.
OS distributors are encouraged to set that config file to use pinentry-gtk2 by default.

@boyska
Copy link
Member

boyska commented Nov 24, 2014

Is there a clear reason why pinentry-gtk2 is not working? If not, no solution is going to really fix it.

If someone has a system where pinentry-gtk2 is installed but not working, he/she should better fix THAT problem, or just install pinentry-curses, so that we can detect that pinentry-curses is our only solution. On many systems, you have a "pinentry" program that links to your favourite one; tomb should follow this hint, if it is available. I propose that looking for pinentry, then pinentry-gtk-2, then pinentry-curses is a good way to detect user preferences. Looking in other programs configuration files is not a good idea, instead.

So if you are a user of a system where pinentry-gtk-2 is broken and you don't know why, you can just symlink /usr/bin/pinentry to pinentry-curses. Or you can remove pinentry-gtk-2. Or you can make it work (with the xhost thing). Or you can manually say --pinentry to tomb. Security needs good defaults: picking bad ones "for *compatibility" is just going to give us problems.

@melon3r
Copy link
Member

melon3r commented Nov 24, 2014

pinentry is the kind of thing you will rarely change, so having to explicitly use --pinentry on every invocation could be annoying (unless you alias tomb="tomb --pinentry mypinentry").

I agree with @boyska that looking in other programs config is not good idea. I think we should go with plain pinentry, which should be defined by the system using tools such as update-alternatives (debian) or eselect (gentoo).

@jaromil
Copy link
Member

jaromil commented Nov 24, 2014

Thanks guys, but I've reached a decision already :^)

Good point parsing 3rd party confs should use validation.

Users should alias tomb=' tomb'anyway, to take advantage of zsh's exclusion from history...

@jaromil
Copy link
Member

jaromil commented Nov 26, 2014

This is solved by the latest pinentry refactoring.

I managed to make pinentry-gtk-2 default if present and DISPLAY is set!

Trick was to bypass the crappy wrapper by the distro, we call them directly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants