No edit summary |
|||
| Line 10: | Line 10: | ||
I'm not sure it's an appropriate level of detail, but what I was referring to was gssd. Right now, it does something terrible: it trolls through /tmp looking for files that match krb5cc_UID* and then tests each one that it is capable of opening to see if it has live credentials. With the move to /run/user, gssd no longer will need to do this. It will instead be able to know with absolute certainty which credential cache it is supposed to be using. -- [[User:Sgallagh|Sgallagh]] 12:15, 19 March 2012 (UTC) | I'm not sure it's an appropriate level of detail, but what I was referring to was gssd. Right now, it does something terrible: it trolls through /tmp looking for files that match krb5cc_UID* and then tests each one that it is capable of opening to see if it has live credentials. With the move to /run/user, gssd no longer will need to do this. It will instead be able to know with absolute certainty which credential cache it is supposed to be using. -- [[User:Sgallagh|Sgallagh]] 12:15, 19 March 2012 (UTC) | ||
Not quite absolute certainty. Since different login sessions which have the same UID but different SELinux security contexts can't share credential caches, we have to allow for per-session credential caches. This means that rpc.gssd and cifs.upcall will still have to trawl, and now in a second location. -- [[User:Nalin|Nalin]] 18:34, 23 August 2012 (UTC) | |||
== Inflexible Policy == | == Inflexible Policy == | ||
Revision as of 18:34, 23 August 2012
Would it make sense to create a #define that sets the ccache format so that if this ever changes again all that would be required is a respin (assuming all packages use that define)?
selinux
No mention of selinux dependencies? --Ktdreyer 02:47, 24 February 2012 (UTC)
The /tmp directory is labelled tmp_t, and the user-specific directory under /run/user is labelled user_tmp_t. A quick check of the policy ("sesearch --allow -s gssd_t -t tmp_t", "sesearch --allow -s gssd_t -t user_tmp_t") suggests that rpc.gssd only loses "dir { write add_name remove_name }". Adding a new credential to a credential cache file (or a single file in a directory) is done by opening the file read-write, seeking to the end of the file, and writing the new credential. I don't think it'll be impacted. If someone can help me figure out what context cifs.upcall runs in, we can compare its privileges, too. -- Nalin 18:28, 23 August 2012 (UTC)
"...and simplify locating the caches for NFSv4." This seems not to be explained in the feature page.--Mitr 12:12, 19 March 2012 (UTC)
I'm not sure it's an appropriate level of detail, but what I was referring to was gssd. Right now, it does something terrible: it trolls through /tmp looking for files that match krb5cc_UID* and then tests each one that it is capable of opening to see if it has live credentials. With the move to /run/user, gssd no longer will need to do this. It will instead be able to know with absolute certainty which credential cache it is supposed to be using. -- Sgallagh 12:15, 19 March 2012 (UTC)
Not quite absolute certainty. Since different login sessions which have the same UID but different SELinux security contexts can't share credential caches, we have to allow for per-session credential caches. This means that rpc.gssd and cifs.upcall will still have to trawl, and now in a second location. -- Nalin 18:34, 23 August 2012 (UTC)
Inflexible Policy
"The most noticable effect will be that credential caches will not survive a reboot (this is a security enhancement, preventing a stolen system from being accessed for still-valid credentials)."
A major new features in Kerberos 5 is the support for renewable tickets along with a maximum renewable lifetime. These are controlled by the administrator of the KDC. By deleting the credentials cache on reboot you have killed a major feature of Kerberos 5 and have enforced your own judgement and policy choice as superior of the KDC admin of a site. I disagree with cache not surviving a reboot. --Dkelson 21:15, 10 April 2012 (UTC)
This change is for the default location. If you feel it is necessary for your environment to use a different, persistent location, that will still be available and configurable. That said, this arrangement still allows for renewable tickets throughout the renewable lifetime so long as the client machine is not rebooted (suspend and hibernate also not constituting a reboot). Sgallagh 22:48, 10 April 2012 (UTC)