There is no KWallet PAM integration

[Malte S. Stretz]

Currently when logging in to KDE, most people have to type their password twice: Once for KDM and then for KWallet (see also bug 38821). A PAM integration like the one Gnome Keyring has would be great to avoid this.

Of course there are still plans to unify all keyring managers one day, but until then a quick hack like the one OpenSuse did for KDE3 would be great. And it seems like somebody called Pierre (pinaraf at pinaraf dot info) ported their package to KDE4 already, the patch is available here:
  http://lists.kde.org/?l=kde-devel&m=124341390013232

[Steffen (steffen-weber)]

Version: (using KDE KDE 3.3.1)
Installed from: Gentoo Packages
OS: Linux

It should be possible to use PAM with KWallet. This way I think a secure single-sign-on could be made possible by using the PAM module pam_ssh. You´d have to setup your /etc/pam.d/system-auth file to use pam_ssh as an alternative to pam_unix. Then you are able to login to your computer by entering the passphrase of your private key in ~/.ssh/.

The thing that make single-sign-on possible is that pam_ssh automatically launches the ssh-agent tool (belongs to OpenSSH) so that you´ll never have to enter your private key´s passphrase again when it is needed for example by KWallet.

I do not understand more about this topic than I´ve written down here, but I think it might satisfy the wish for a passwordless KWallet without of making it stupidly insecure.

[Yves Glodt (yglodt)]

*** This bug has been confirmed by popular vote. ***

[Praseodym+kdebugzilla (praseodym+kdebugzilla)]

Something similiar could also be done by storing the user's password in the wallet, and then have KDM silently login to the wallet (user clicks his user, and instead of account password types the wallet password) to get the linux password and log in with that.

[Jonny Heggheim (hegjon)]

Would be nice to integrate KDM and KWallet!

[Gilles Schintgen (shigi)]

Just in case this gets implemented (and I really hope so...), I'd like to point out that it should be implemented in such a way as to be compatible with pam_mount. Currently I'm using an encrypted home partition that is mounted automatically at login by pam_mount (using the login password). Using information from the user's home could be problematic when it's not yet mounted. So, please consider this point.
It would just be too cool to have single-sign-on for the system login, pam_mount and kwallet. Thanks for listening :-)

[Leo Savernik (d2d3d9)]

I'd like to have single-sign-on also working with the default login password. Please also keep in mind that not all people use kdm as their login manager (or no login manager at all! Runlevel 3, need I say more? ;-) ), so it should not depend on kdm or any graphical login procedure.

[Brazilian Joe (tiago-freire)]

what would have to happen then? will kwallet become a frontend/gui for the 'wallet' cli app, being useable without qt , kde or anything, and wallet would be a base system / libs for ppl to store their many passwords, possibly with bindings for other languages to use it, hopefully with Mozilla, Gnome, Freedesktop.org and possibly other ppl cooperation, so that we can have a solution which is not kde specific, but which encompasses the whole desktop? Maybe it should be talked with other parties which may be interested in the subject. Maybe I am overly optimistic, but I think this would be the best thing possible to happen: a unified wallet system with single sign-on useable by any desktop environment, so that I can use any desktop without having to retype the passwords in mozilla, konqueror, or foo.

[flickerfly (josiah-ritchie)]

I'm investigating this for the community over at LinuxBiometrics.com. We have talked a bit about how to most effectively integrate biometrics and so I'm investigating. We already have work building a PAM bridge and so Kwallet's attachment to PAM would significantly ease the efforts that would need to be made.

Just wanted to share that we see this as being a beneficial direction for our needs also. :-)

[R2s2-3 (r2s2-3)]

*** Bug 102465 has been marked as a duplicate of this bug. ***

[R2s2-3 (r2s2-3)]

Wouldn't be a kwallet pam module possible? It would start kwallet as soon as one logs in. This way it works also for other types of logins (NX, console, xdm,..) and doens't relay on ssh.

Of course an auto login to kwallet isn't much safer than a kwallet without password, but it adds an extra little bit of security (e.g. secure as long as you don't log in) at no cost for the user. So I think it should be possible.

[Gilles Schintgen (shigi)]

If I understand the following page correctly something similar already exists for Gnome:
http://www.flyn.org/projects/pam_keyring/index.html

[Bernie Innocenti (codewiz)]

In reply to comment #10 (Gilles Schintgen):

> If I understand the following page correctly something similar already exists for Gnome:
> http://www.flyn.org/projects/pam_keyring/index.html

This looks exactly what we need for KWallet.

[Leo Savernik (d2d3d9)]

> http://www.flyn.org/projects/pam_keyring/index.html

And it's abandoned, so we can take it over any time :-)

[R2s2-3 (r2s2-3)]

Gnome hat it and Mac OS x has it too: http://developer.apple.com/documentation/Security/Conceptual/keychainServConcepts/02concepts/chapter_2_section_1.html

So we need it, also! ;-)

The first step we need, is a seperation of the daemon and the gui. Like gnome does it (gnome keychain daemon/manager). Otherwise the pam module can't start the daemon because of the gui dependance. Should this be an own feature request?

[Staikos (staikos)]

On Sunday 18 September 2005 05:02, Roland Schulz wrote:
> Gnome hat it and Mac OS x has it too:
> http://developer.apple.com/documentation/Security/Conceptual/keychainServCo
>ncepts/02concepts/chapter_2_section_1.html
>
> So we need it, also! ;-)
>
> The first step we need, is a seperation of the daemon and the gui. Like
> gnome does it (gnome keychain daemon/manager). Otherwise the pam module
> can't start the daemon because of the gui dependance. Should this be an own
> feature request?

   Right now the whole thing is very dependent on Qt and actually DCOP. Once
KDE4 development really starts (ie: technology changes in kdelibs begin),
this can be considered.

[Brazilian Joe (tiago-freire)]

Personally, I think teh Best Way Possible® it to get in touch with Freedesktop.org and Gnome people too, and draft a standard way to do it, place under teh Freedesktop.org umbrella. You know, avoiding the NIHS (Not-Invented Here Syndrome), and doing something which can benefit all, instead of something KDE-centric. AFAIK tehre are already 'standards', at least in draft form, for things like DE-agnostic themes, clipboard, and so on. This could be one more thing.

[Staikos (staikos)]

On Sunday 18 September 2005 11:48, Tiago Freire wrote:
> ------- Personally, I think teh Best Way Possible® it to get in touch with
> Freedesktop.org and Gnome people too, and draft a standard way to do it,
> place under teh Freedesktop.org umbrella. You know, avoiding the NIHS
> (Not-Invented Here Syndrome), and doing something which can benefit all,
> instead of something KDE-centric.

  If there was interest on that side, why didn't they come to us and say they
wanted to co-operate too? KWallet is quite old and I've never seen or heard
of something similar on Linux or Gnome.

  That being said, the file format is open and there is a chance to extract
the daemon outside of KDE startup now that dbus is a likely candidate for
KDE4. I don't have any interest in redesigning and reimplementing all of
KWallet though. It works, and there are many other things that need to be
done in KDE4.

[Leo Savernik (d2d3d9)]

Am Montag, 19. September 2005 00:30 schrieb George Staikos:
>   If there was interest on that side, why didn't they come to us and say
> they wanted to co-operate too?  KWallet is quite old and I've never seen or
> heard of something similar on Linux or Gnome.

Right you are. It's about time that Gnome incorporates some precedent set by
KDE.

[Staikos (staikos)]

On Monday 19 September 2005 10:16, Leo Savernik wrote:
> Am Montag, 19. September 2005 00:30 schrieb George Staikos:
> >   If there was interest on that side, why didn't they come to us and say
> > they wanted to co-operate too?  KWallet is quite old and I've never seen
> > or heard of something similar on Linux or Gnome.
>
> Right you are. It's about time that Gnome incorporates some precedent set
> by KDE.

  That's not true either. They have and do (see freedesktop). I just don't
buy this argument that KWallet was done at the preclusion of Gnome. It
preceded any other similar project that I could find at the time.

[Brazilian Joe (tiago-freire)]

There are several standards, in draft form or otherwise, being developed or promoted for adoption on freedesktop.org. The 'Single' bit of 'Single Sign-On' only holds completely true if it works on every application. If you only use KDE apps, fine, but I find thinking like this a bit selfish (and I am not implying it is your thinking, just stating my belief). Ithink it is really worth pushing forward the 'Single' part of this idea, and have filed a project-request-bug at freedesktop.org.
https://bugs.freedesktop.org/show_bug.cgi?id=4513

[Mustavuohi (mustavuohi)]

Uh. It would be awesome to use pam_usb (http://www.pamusb.com) with KWallet, too.

[Staikos (staikos)]

*** Bug 114662 has been marked as a duplicate of this bug. ***

[mp (mpapet)]

Absolutely fantastic idea. I vote with 20 points!

[Somekool-f (somekool-f)]

it is really required to have this done using PAM ? I'm don't know. But the basic idea of having the kwallet automatically open upon login is strongly wished and I really wish to see this feature in the next release of KDE.

thanks

[Andrei Slavoiu (ansla80)]

Actualy I think it would be possible using Kwallet integration in KDM. So that the account password is stored inside the wallet, and at logon time you just enter the password for the wallet. What do you think?

[Sundance (sundance-greydragon)]

Hi Andrei,

This would be excellent, yes! Do you think it is possible technically?

Thanks!

[Gilles Schintgen (shigi)]

> Actualy I think it would be possible using Kwallet integration in
> KDM. So that the account password is stored inside the wallet, and at logon
> time you just enter the password for the wallet. What do you think?

No, the account password should always be the one stored in /etc/shadow.
Everything else would be incoherent. In my opinion, having the login password
depend on how you login (login, ssh, kdm) would be a terrible idea.

The password entered into kdm can already be reused by other PAM modules, such
as pam_mount. kwallet could "simply" integrate with PAM and obtain the
password in the same way.

The kwallet password would then be your login password. If the login password
is changed, decrypting of the wallet will fail and kwallet would inform the
user about it and ask for the old password in order to reencrypt the wallet
with the new password.

What do you think about this idea?

[Sundance (sundance-greydragon)]

With my apologies, Gilles, I think I disagree with your judgment on authentication sources: the whole point of pluggable authentication modules (P.A.M. :)) is precisely to let you authenticate yourself from different possible sources. I am not sure what invalidates KWallet as one such source, but I might be overlooking something, of course.

However, would it be possible to simply encrypt the KWallet password using the user's login password? This way, when the user logs in, he uses his regular login password; that password is also used to unlock his KWallet password, and KWallet is then loaded as usual.

Would PAM allow for such a behavior? This way, it would respect Gilles' misgivings about the previously suggested behavior, while still allowing for KWallet to be opened automatically at login time, and still allowing for different login and KWallet passwords.

What do you think?

[Gilles Schintgen (shigi)]

> With my apologies, Gilles [...]

I'm sorry if my response sounded a bit harsh, it really wasn't intended that
way.

> However, would it be possible to simply encrypt the KWallet password using
> the user's login password? This way, when the user logs in, he uses his
> regular login password; that password is also used to unlock his KWallet
> password, and KWallet is then loaded as usual.

There's a second reason I don't like this behaviour: I'm using an encrypted
home partition which is automatically decrypted by pam_mount using my login
password. Since the KWallet data is stored inside this partition I don't see
how this scheme could be implemented without breaking this kind of setup.
This same problem also arises for people using pam_mount to mount a remote
home directory. Unfortunately kdm can't rely on (or at least it shouldn't)
the availability of the KWallet data before the user is authenticated by PAM.
Except, of course, if the KWallet were to be stored outside the user's home
directory which, I think, would be a bad idea.

Kind regards,

Gilles

[mp (mpapet)]

> This way, when the user logs in, he uses
> his regular login password; that password is also used to unlock his
> KWallet password, and KWallet is then loaded as usual.

I'm not sure about this. This creates a what looks like a bad scenario where kwallet-stored passwords are available upon request once a user is logged in. Well, what if I'm a bad guy and somehow get access to your desktop? I think my first stop is kwallet. It's open right?

Personally, it doesn't bother me that kwallet asks for a password upon opening after I'm into my desktop.

Below the gui level, PAM and kwallet must remain separate. The kwallet gui needs to make it appear something like a single wallet though.

[Kde-org (kde-org)]

> Well, what if I'm a bad guy and somehow get access to your desktop?

Then I should have locked my desktop.

My second act, as a bad guy, is to change your desktop background to a picture of Tom Welling with his shirt off. Very few people around my office forget to lock their desktop anymore.

[Sundance (sundance-greydragon)]

Gilles,

Please note that in my last proposal, to my knowledge, KWallet could be opened only after everything else has been unlocked, i.e. after the login process has begun and the home partition has been mounted, in the same way that your home partition is only mounted after your authentication credentials have been validated. So your setup would not be prevented from working. If I'm not wrong in this and what I'm suggesting is indeed possible, would the proposal satisfy you?

Michael,

Would this be different from the usual way KWallet works? Once your KWallet is opened, some Bad Guy sneaking his way to your desk can access its passwords as well. The only difference would be that at login time -- when you're known to be at your desk -- the KWallet would be loaded as usual, simply without asking for its own password. But you raise a good point, and the unlocking of KWallet at login time should be an option. Perhaps it is worth pointing out that, as things currently stand, many users choose to use no password at all for their KWallet -- incidentally storing all its passwords in clear text -- so as to avoid the annoyance of unlocking it manually at login time. Our proposal ideas here would be a significant step up from that behavior in terms of security.

With kind regards,

-- S.

[Gilles Schintgen (shigi)]

> Please note that in my last proposal, to my knowledge, KWallet could be
> opened only after everything else has been unlocked, i.e. after the login
> process has begun and the home partition has been mounted

Now I see that I've misread your last proposal:
> However, would it be possible to simply encrypt the KWallet password using
> the user's login password? This way, when the user logs in, he uses his
> regular login password; that password is also used to unlock his KWallet
> password, and KWallet is then loaded as usual.

I thought it was the same proposal as before, except that now the two
passwords are the same. In other words I interpreted "he uses his regular
login password" as "he types the same password as always but it's first used
to open the wallet in order to retrieve the account password".

> would the proposal satisfy you?

Yes, it would be fine (for me). The only difference to my proposal is that
KWallet doesn't get the password through PAM, but directly from kdm. My
proposal would also work with console logins (but I'm not sure this would be
desirable) and with xdm and gdm.
Since I'm mostly using kdm, I'm not going to insist on this. (And I don't know
how difficult it would be to properly implement the PAM integration.)

In the long term I'd prefer a desktop-independent approach, as already pointed
out in comment #19.

Regards,

Gilles

[Malte S. Stretz (mss)]

Nominating as Paper Cut even though its a new feature: A patch exists and its a really annoying thing for new Kubuntu users to run into.

[goto (gotolaunchpad)]

Here is a temporary script hack to work around it without having to recompile anything. It uses GDM and PAM to unlock your Gnome keyring, and then uses gnome-keyring-manager as your ssh-agent. This does require using GDM as your login manager.

First, set up PAM to automatically unlock your gnome keyring on login, per http://live.gnome.org/GnomeKeyring/Pam. Make sure it works as advertised in Gnome.

Then, create a script to run gnome-keyring-manager in ssh-agent mode and set the SSH_AUTH_SOCK environment var to point to it (see attachment).

Finally, modify /etc/X11/Xsession.d/90x11-common_ssh-agent (or whatever file X uses to start your SSH agent) to run the script you just created instead of the normal ssh-agent.

[Malte S. Stretz (mss)]

That's a nice hack but doesn't really solve the problem with KWallet; hopefully soon it will be possible to use any password storage both in KDE and GNOME (see <http://www.freedesktop.org/wiki/Specifications/secret-storage-spec>), but until then the OpenSuse implementation for unlocking KWallet would be a big step forward.

[Jonathan Thomas (echidnaman)]

Hi there,
We are in the process of closing wishlist items that have already been reported at KDE. This is also a rather large-scale feature that really doesn't fit with the idea of a simple-to-fix paper cut. Don't worry, your issue still is being tracked at KDE's bug tracker at: http://bugs.kde.org/show_bug.cgi?id=928457 . It's just that Kubuntu currently does not have the manpower necessary to take this feature on ourselves. We will receive this functionality once KDE implements it in one of their releases.

Thanks for understanding, and have a nice day.

[b2ag (thomas-b2ag)]

http://bugs.kde.org/show_bug.cgi?id=928457
shows: Bug #928457 does not exist.

[Adam (adam.russell)]

He probably meant http://bugs.kde.org/show_bug.cgi?id=92845 .

[Malte S. Stretz (mss)]

From KDE bug 92845:

"there's a "pam_kwallet" in kde/playground/base and a pam_dbus_launch at http://code.confuego.org/index.php/p/pamdbuslaunch/ -- With those two modules, single sign on *works*."

So all we need now are packages for libpam-kwallet and libpam-dbus-launch :)

[Somekool-f (somekool-f)]

wow

[Lbeltrame (lbeltrame)]

Some general instructions can be found here (I wrote the post):

https://www.dennogumi.org/2014/04/unlocking-kwallet-with-pam/

[Kde-org (kde-org)]

unsubscribe

[Mathias Homann (lemmy04)]

@Luca, I have tried to build and install that module according to the instructions in your blog post... doesn't work. And no error messages either. Is there a way to switch it to verbose or such?

[imraro (imraro)]

Arch x86_64: pam_kwallet(systemd-user:session): pam_kwallet: open_session called without kwallet_key

[Lbeltrame (lbeltrame)]

I am not sure how to debug this, as I figured the steps with trial and error. Can you try installing socat?

[imraro (imraro)]

I'm not familiar with socat. Could you explain, how to use it in this case?

[Lbeltrame (lbeltrame)]

The Ubuntu package lists it as dependency. I forgot if I had it installed at the time of my tests.

[imraro (imraro)]

What do you mean by "Ubuntu package lists"?

[flickerfly (josiah-ritchie)]

unsubscribe

On Fri, Apr 25, 2014 at 11:53 AM, imraro <email address hidden> wrote:

> https://bugs.kde.org/show_bug.cgi?id=92845
>
> --- Comment #158 from imraro <email address hidden> ---
> What do you mean by "Ubuntu package lists"?
>
> --
> You are receiving this mail because:
> You voted for the bug.
>

[Lbeltrame (lbeltrame)]

The pam-kwallet package in Ubuntu has socat as dependency. Whether this helps or not I do not know as there is no documentation and this stuff is low level.

[imraro (imraro)]

Nothing has changed after installing socat.

[Orion-cora (orion-cora)]

(In reply to comment #151)
> unsubscribe

Remove yourself from the CC list.

[Orion-cora (orion-cora)]

(In reply to comment #159)
> unsubscribe
> > You are receiving this mail because:
> > You voted for the bug.

actually, remove your vote from the bug

[Lbeltrame (lbeltrame)]

Apparently to get this to work you need 3 commits that did not make into 4.13
and will likely be in 4.13.1.

More seriously, I would suggest people that need this to use Kubuntu, that
somehow got this to work. I can't even reproduce my work on another machine,
so I'm guessing that either the author or someone with deeper PAM knowledge
steps in, or it's just a waste of time.

[Lbeltrame (lbeltrame)]

FWIW, I updated the blog entry with more possible suggestions. But at least
for me I can't get it to work with KDM.

[imraro (imraro)]

I'm using lightdm and git-repos for pam_kwallet )

[imraro (imraro)]

(In reply to comment #163)
> (In reply to comment #159)
> > unsubscribe
> > > You are receiving this mail because:
> > > You voted for the bug.
>
> actually, remove your vote from the bug

Removing of a subscription and removing of a vote is not same, isn't it?

[8-herbert (8-herbert)]

(In reply to comment #160)
> The pam-kwallet package in Ubuntu has socat as dependency. Whether this
> helps or not I do not know as there is no documentation and this stuff is
> low level.

the socat is not strictly needed by pam_kwallet itself, but by the startkde script. But only when pam_kwallet is installed, too.

(In reply to comment #161)
> Nothing has changed after installing socat.

The following lines are needed in /usr/bin/startkde and are missing in openSUSE (ubuntu and fedora already have them):

if test -n "$PAM_KWALLET_LOGIN" ; then
  env | socat STDIN UNIX-CONNECT:$PAM_KWALLET_LOGIN
fi

[Lbeltrame (lbeltrame)]

Yes, my bad on that. I forget I run git master on my main box, which has already these commits in (but 4.13 hasn't them).

[8-herbert (8-herbert)]

Created attachment 86268
Adds pam_kwallet support to startkde

[Mathias Homann (lemmy04)]

I've set this up and it works, but only for local users. Does not work for network user accounts (i.e. NIS). Don't have a LDAP server here to test that.

[Lbeltrame (lbeltrame)]

On which distro did you set this up? Any changes from what I wrote? So that I can amend the guide as necessary.

[Mathias Homann (lemmy04)]

I'm using openSUSE 12.3 here, no changes from your blog post. when I login using a locally set up account, it works; logging in with a user account from NIS it doesn't.

[Mathias Homann (lemmy04)]

ok now i'm at the "huh?" stage of this; two identical machines, and I literally copied the config and libraries from one to the other, and on one computer it works for both local accounts and NIS, and on the other it doesn't work for any of them.

[Lbeltrame (lbeltrame)]

In data sabato 26 aprile 2014 07:59:01, hai scritto:

> computer it works for both local accounts and NIS, and on the other it
> doesn't work for any of them.

I've had the same issue when trying to generalize the guide. I guess we need a
PAM expert to debug this...

[Lukas Jirkovsky (l-jirkovsky)]

Oh come on guys, bugzilla is not a forum.

[Lbeltrame (lbeltrame)]

In data sabato 26 aprile 2014 08:40:39, hai scritto:

> Oh come on guys, bugzilla is not a forum.

Indeed, we have the KDE Community Forums. I've taken the liberty of creating
a post discussing the configuration, to keep this entry cleaner (although
anyone could have posted that, instead of just saying "bugzila is not a
forum"):

http://forum.kde.org/viewtopic.php?f=14&t=120843

Please direct further discussion on how to hook KWallet with PAM there.

[Leon Maurer (leon-n-maurer)]

Single sign-on no longer works for me when I upgraded to Kubuntu 15.04 and plasma 5.3. Does anyone know if this is because of a problem with Kubuntu or because the feature hasn't made it to KDE 5? (Or maybe the feature is still there but I need to enable it somehow?)

[Orion-cora (orion-cora)]

Looks like pam-kwallet needs to transition to kwallet5. But this needs to be tracked elsewhere.

[Leon Maurer (leon-n-maurer)]

As Orion suggested, I filed a new bug to request that this feature is revived in KDE 5. See Bug 349003.

(Am I the only person who misses this feature? This thread is awfully quiet considering the number of votes it got...)

[Ettore Atalan (atalanttore)]

(In reply to Leon Maurer from comment #180)
> As Orion suggested, I filed a new bug to request that this feature is
> revived in KDE 5. See Bug 349003.
Thanks.

> (Am I the only person who misses this feature? This thread is awfully quiet
> considering the number of votes it got...)
No, but most have given up on requesting this common feature.

[Murz (murznn)]

> (Am I the only person who misses this feature? This thread is awfully quiet considering the number of votes it got...)
I very want to vote, but didn't see Vote function in Bug #349003 but in this bug I can vote. Maybe you post the bug with wrong type?

[Chaser-andrey (chaser-andrey)]

I just use KWallet without password because I don't want to wait single-sing-on next year or two and I don't want to type my password again.

[Ettore Atalan (atalanttore)]

This request is from 2004. Expecting this feature in one or two years is quite optimistic.

[Leon Maurer (leon-n-maurer)]

This thread is dead. Checkout the new bugreport for KDE 5 (Bug 349003). It looks like the feature may be added back soon; there's already a patch.

[Bernie Innocenti (codewiz)]

(In reply to Leon Maurer from comment #185)
> This thread is dead. Checkout the new bugreport for KDE 5 (Bug 349003). It
> looks like the feature may be added back soon; there's already a patch.

Great news, but then why is this bug still open?
Can we just close it as WONTFIX / OBSOLETE?

[Leon Maurer (leon-n-maurer)]

That seems reasonable to me. We should probably put this thread out of its 10+ year misery.

[Malte S. Stretz (mss)]

http://martys.typepad.com/blog/2015/07/kwallet5-can-be-auto-unlocked-during-login-again.html