On Wed, 13 Nov 2013 18:32:19 -0500 Simo <[email protected]> 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... -- Jeff Layton <[email protected]> -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
