On Thu, 2013-11-14 at 08:08 -0500, Jeff Layton wrote: > On Wed, 13 Nov 2013 18:32:19 -0500 > Simo <simo@xxxxxxxxx> wrote: > > > On Wed, 2013-11-13 at 15:50 -0700, Orion Poplawski wrote: > > > On 11/13/2013 03:47 PM, Orion Poplawski wrote: > > > > On 11/13/2013 03:34 PM, Simo wrote: > > > >> > > > >> Uhm doesn't this code store the user password in the clear in a key that > > > >> is explicitly made readable to any process of the user in the same > > > >> session ? > > > >> > > > >> Simo. > > > >> > > > > > > > > I tried to mimic exactly what the cifscreds program does, but I may have made > > > > a mistake. Or perhaps cifscreds is also doing a bad thing. The key > > > > permissions are set to: > > > > > > > > #define CIFS_KEY_PERMS (KEY_POS_VIEW|KEY_POS_WRITE|KEY_POS_SEARCH| \ > > > > KEY_USR_VIEW|KEY_USR_WRITE|KEY_USR_SEARCH) > > > > > > > > > > > > > > We're not setting KEY_*_READ, so one cannot read the contents of the key, IIUIC. > > > > My bad, my eyes saw VIEW but read READ. > > > > Simo. > > > > Yep, and furthermore... > > These keys are saved as a "logon" keytype (see kernel commit > 9f6ed2ca257). Those are basically just like the "user" keytype except > that there is no mechanism to report the payload to userland. So even > if the permissions we such that you could read them, there's no way for > the kernel to do so. > > About the only way to get the password out of the kernel would be to > poke around in /dev/mem or the equivalent. Unfortunately, there's not > much we can do about that... We could (reversibly) encrypt them with a key held in a TPM chip :-) Simo. -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
