It should probably be pointed out that the keyring we're talking about here is the kernel's keyring, which you can manipulate using 'keyctl' from the 'keyutils' package, and not the GNOME keyring. That said, On Thu, Dec 06, 2007 at 10:33:27AM -0500, Daniel J Walsh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > I don't fully understand how you intend to use keying, but I have talked > to Nalin about this, since he is about to allow or does allow the > storing of the kerberos tgt in a kernel keyring. The krb5 package grew this ability either in F7 or an update; set KRB5CCNAME=KEYRING:blahblahblah in your environment and 'kinit' and 'kdestroy' to your heart's content. Raw Hide's pam_krb5 adds a 'ccname_template' option which can be used to tell it to create a keyring-based ccache for your session instead of the usual file-based one. It still defaults to files, though. For now, at least. [snip] > So I would suggest that we remove pam_keyinit from system_auth and only > use it in login pam modules which call it after pam_selinux open. Agreed completely. It's surprising when the new credentials your screensaver got by using a PAM module get stored in a brand-new keyring which is not tied to the rest of your desktop session. > Now the next question is whether it should be called in su or sudo? > Since wouldn't this remove access to my keying material? That's an interesting problem. In the process of authenticating for sudo or su, we _might_ get new credentials which would be stored in the keyring. It's easier for me to think about if I think of those creds as being a Kerberos TGT, but since the keyring can store any kind of data, I don't think we can assume it's only going to crop up when you're using Kerberos. Anyway, we probably don't want to store them in the same keyring as the parent process, because that be a pretty bad leak, so for the sake of that case we should always be creating a new keyring in su and sudo. But if we don't get new creds, it's going to be more useful to just re-use any creds we already have, in case they're being used to store credentials which let us access networked filesystems. Assuming that behavior wouldn't be super-broken (if it is, someone jump in, please!), how could we make that happen? That is, how can we create a new session only when we have things to store in it? > su and sudo do not call pam_selinux open, so it will not setup a > labeling for pam_keyinit, and the keys will get created as user_sudo_t > or user_su_t for example. At this point what access is expected by the > user for these keyrings? Would you expect the keyrings to be labeled > kernel_t, or should we remove the pam_keyinit from su and sudo, leaving > access to the login keyrings. I'd kind of expect those keyrings to be labeled as usual. Is there value to having different labels on them, aside from being able to restrict what other types of processes can access them in an SELinux sense? While we're sorting all of that out, we should probably make sure the right thing's going on wrt pam_namespace and pam_loginuid. Sorry, more questions than answers. Nalin -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
