> On May 25, 2013, 5:25 p.m., Àlex Fiestas wrote: > > I'm 100% against this patch, it is a no go. > > > > What we have to provide is a way for distributions to open the wallet in a > > SECURE way without asking the user for a password. Distros are free to use > > this patch but then they should rename kwallet because it won't be doing > > what it was design to do. > > Rex Dieter wrote: > By that logic, kwallet shouldn't support password-less operation *at > all*, yet it does. (In case its not obvious, I don't agree with your > assertions). That said, discussion of the security implications should best > be made onlist, not on reviewboard. > > Àlex Fiestas wrote: > There is a proper way of doing this which is opening the wallet (and > creating it if not created already) with a PAM module. Anything else is just > a hack. Feel free to start a discussion about this on list, but until then > this patch has my -1. > > BTW I looked into the PAM module, it is easy to do and I will do it for > 4.12 (was going to do it for 4.11 but it was already frozen). > > Àlex Fiestas wrote: > Oh and btw, NO, kwallet should NOT support pasword-less operations at > all, and if it does is because we lack PAM integration I guess. > > Thomas Lübking wrote: > You can either trick the GUI to enter an empty password or edit the > config by hand. > > --- > > Kwallet however does not do what it suggests (to me) anyway. > At least if that was anything different from what cryptsetup alongside > pam_mount would do (less annoyingly) - which may already be in use to protect > plaintext stored passwords (of other applications) > > I don't say a higher level of security and authorization is required to > protect joe users fartbook login, but atm. kwallet just suggests a level of > security that it does not nearly provide - with a pretty annoying lock on top > of the pretty weak door. > This would implicitly solve by dropping the pseudo-security and casually > have the system provide the required (or nearby not, in the "single user at > home" case) and actually present security (encrypted FS) > > Otherwise (if kwallet wants to be beyond that) there's quite some > workload (*far* beyond PAM) ahead (starting with clients having to authorize > themself... not really a trivial task - esp. not if you cannot use the > binaries hashkey because users won't like to reconfirm all clients after > every update) > > Àlex Fiestas wrote: > cryptsetup will crypt all the partition so I/O speed will get decreased a > lot. > > KWallet does only one thing, preventing access to clear text password for > cases like a stolen laptop, anything else is a false sense of security. > > For the "app access" there is a patch already on the way: > https://git.reviewboard.kde.org/r/110330/ and I voted to enable it by default. > > So, Imho KWallet still has a reason to exists and we should not break it > or make it easier to break specially since it can be properly fixed with a > PAM module that I already know how to do (so I will do for 4.12). > > Thomas Lübking wrote: > I guess you're aware of the concept of loop devices? ;-) > (Also recent mobile devices usually or at least often have HW AES > support, what oc. does still not justify encrypting your system libraries > etc.) > > You can u/mount a 32MB ecrypted image file on logout/in to store the > sensitive data on and in very doubt symlink them into the system (for tools > insisting on fixed data paths) - i do that for years, mostly because mstmp > still requires clear-text passwords, but i also moved the kwallet data there > and dropped the password the dirty way (sorry ;-) > > The only problem with that approach is that one has to read three or four > paragraphs on how to set this up (unless your distro does it) and there's no > elegant integration with powermanagement (pm-utils + pinentry-qt4, "yeah") - > and actually none with session locking at all (what i however hardly do > anyway on a mobile device) > > The shiny price is that i can store any stuff there. > > Àlex Fiestas wrote: > For keyring, soonish we are going to have something build in the kernel, > dunno how it will look or work. > > At least until we have another solution working, let's keep what we have > working, as I said I can make the PAM work in 4.12
pam-kwallet has landed, I suppose it's time to close this review? - Rex ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/110328/#review33135 ----------------------------------------------------------- On May 6, 2013, 5:25 p.m., Eike Hein wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/110328/ > ----------------------------------------------------------- > > (Updated May 6, 2013, 5:25 p.m.) > > > Review request for KDE Runtime and Harald Sitter. > > > Repository: kde-runtime > > > Description > ------- > > This patch adds a UI-less config option to kwalletd that makes it create the > initial local wallet silently with an empty password instead of prompting the > user to enter one. > > It's a change desired by downstream consumers Kubuntu and Netrunner, and > perhaps others, and recreates a modification they used to carry for KDE 3. > Their goal is to make KWallet mostly invisible to the user during routine > operations, but still have users benefit from encrypted password storage > behind the scenes. > > As such the config option is intended to be set by distributions. The new > behavior is disabled by default. > > In the interest of keeping the delta between upstream and downstream as small > as possible I'd say it makes sense to pick this up. > > > Diffs > ----- > > kwalletd/kwalletd.h e8e74c3 > kwalletd/kwalletd.cpp fa9fc11 > > Diff: https://git.reviewboard.kde.org/r/110328/diff/ > > > Testing > ------- > > Test package for Kubuntu by Harald Sitter, operation verified at runtime. > > > Thanks, > > Eike Hein > >
