On Thu, 2007-12-06 at 10:33 -0500, Daniel J Walsh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > 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. > > Currently pam_keyinit is happening in system-auth as well as most of the > login pam modules. > > SELinux comes into play here, since we want to make sure the context on > the keyring is set correctly. "pam_selinux open" sets the kernel to > label the keyring with the users context, but in several places > pam_keyinit is being called before pam_selinux (system-auth) is the > culprit. > > This results in us having kernel keyrings labeled local_login_t or > sshd_t. Which is wrong. They should be labeled user_t or unconfined_t. > > 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. Make a lot of sense to me. > Now the next question is whether it should be called in su or sudo? > Since wouldn't this remove access to my keying material? Do you want sudo to really give you power over keying material? Usually sudo is used to run programs just with a higher privilege on the local machine, and never to obtain key material. I have the feeling that it is somehow wrong to give sudo that power. For su I am still uncertain, but given that su does not authenticate the final user but only the super user I again wonder if that should give any access to the kernel keyring. > 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 think it is safer to not give su and sudo access to keyrings by default, is there a credible scenario that would require that and that cannot be accomplisced in another way? Simo. -- | Simo S Sorce | | Sr.Soft.Eng. | | Red Hat, Inc | | New York, NY | -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
