From kde-frameworks-devel Sun Feb 26 05:37:04 2017 From: Martin Klapetek Date: Sun, 26 Feb 2017 05:37:04 +0000 To: kde-frameworks-devel Subject: Re: Review Request 125641: Allow PAM unlocking of a running wallet Message-Id: <20170226053704.3284.56699 () mimi ! kde ! org> X-MARC-Message: https://marc.info/?l=kde-frameworks-devel&m=148808743012209 --===============5018532194242668119== MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > On Feb. 25, 2017, 11:55 p.m., Albert Astals Cid wrote: > > Martin, Valentin, should I commit this? I honestly don't know what the state of this and/or the component(s) that needed it is. It was mainly meant for Plasma Mobile, no idea about that project either. I guess it should still work, so perhaps it's ok to commit. - Martin ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125641/#review102608 ----------------------------------------------------------- On Oct. 16, 2015, 6:52 p.m., Martin Klapetek wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/125641/ > ----------------------------------------------------------- > > (Updated Oct. 16, 2015, 6:52 p.m.) > > > Review request for KDE Frameworks and Valentin Rusu. > > > Repository: kwallet > > > Description > ------- > > A use-case: kwallet gets locked with lockscreen, eg. on Plasma Mobile, unlocking the screen would also unlock kwallet through PAM. > > Another use-case: automatic login that shows lockscreen after booting, unlocking that session would also unlock kwallet through PAM. > > This requires a small change in kwallet-pam. > > Now to the patch itself. When a user authenticates via lockscreen, PAM can start the kwalletd process and pass the auth hash token to it. In case the kwalletd process is already running, this patch would check if the wallet is opened and if not, it would pass the PAM hash token over dbus to the running kwallet instance which would unlock the running wallet. If it is unlocked, nothing would happen. > > I originally didn't want to pass it over dbus, but in the end it doesn't matter because as soon as the session is unlocked (at this point the hash is sent), the wallet would be unlocked and a possible attacker would have access to its data anyway. But I'm open to suggestions on improvements. > > > Diffs > ----- > > src/runtime/kwalletd/main.cpp fbab58d > > Diff: https://git.reviewboard.kde.org/r/125641/diff/ > > > Testing > ------- > > I've created a special PAM profile which has > > auth optional pam_kwallet5.so lockscreen kwalletd=/opt/kde5/bin/kwalletd5 > > ran kcheckpass -c myprofile and kwallet5 got started and unlocked. Then I locked the wallet using kwalletmanager5, ran kcheckpass -c myprofile again and the running kwallet5 instance got unlocked. > > > Thanks, > > Martin Klapetek > > --===============5018532194242668119== MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit

This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125641/

On February 25th, 2017, 11:55 p.m. CET, Albert Astals Cid wrote:
Martin, Valentin, should I commit this?

I honestly don't know what the state of this and/or the component(s) that needed it is. It was mainly meant for Plasma Mobile, no idea about that project either.

I guess it should still work, so perhaps it's ok to commit.

- Martin

On October 16th, 2015, 6:52 p.m. CEST, Martin Klapetek wrote:

Review request for KDE Frameworks and Valentin Rusu.

By Martin Klapetek.

Updated Oct. 16, 2015, 6:52 p.m.

Repository: kwallet

Description

A use-case: kwallet gets locked with lockscreen, eg. on Plasma Mobile, unlocking the screen would also unlock kwallet through PAM.

Another use-case: automatic login that shows lockscreen after booting, unlocking that session would also unlock kwallet through PAM.

This requires a small change in kwallet-pam.

Now to the patch itself. When a user authenticates via lockscreen, PAM can start the kwalletd process and pass the auth hash token to it. In case the kwalletd process is already running, this patch would check if the wallet is opened and if not, it would pass the PAM hash token over dbus to the running kwallet instance which would unlock the running wallet. If it is unlocked, nothing would happen.

I originally didn't want to pass it over dbus, but in the end it doesn't matter because as soon as the session is unlocked (at this point the hash is sent), the wallet would be unlocked and a possible attacker would have access to its data anyway. But I'm open to suggestions on improvements.

Testing

I've created a special PAM profile which has

auth optional pam_kwallet5.so lockscreen kwalletd=/opt/kde5/bin/kwalletd5

ran kcheckpass -c myprofile and kwallet5 got started and unlocked. Then I locked the wallet using kwalletmanager5, ran kcheckpass -c myprofile again and the running kwallet5 instance got unlocked.

Diffs

src/runtime/kwalletd/main.cpp (fbab58d)

--===============5018532194242668119==--