openssh bugs - Dec 2017 - [Bug 2815] New: please set KRB5CCNAME to collection

https://bugzilla.mindrot.org/show_bug.cgi?id=2815

            Bug ID: 2815
           Summary: please set KRB5CCNAME to collection
           Product: Portable OpenSSH
           Version: 7.4p1
          Hardware: amd64
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: Kerberos support
          Assignee: unassigned-bugs at mindrot.org
          Reporter: hedrick at rutgers.edu

Most current implementations for Kerberos use collections for
credentials, e.g. KEYRING or KCM. E.g. we have our default createntials
set to KEYRING:persistent:%{uid} in krb5.conf. When I login, that
should result in KRB5CCNAME being set to KEYRING:persistent:1003. When
I ssh and go through PAM, that's what I get. But if I have a current
Kerberos credential, sshd won't invoke PAM for authentication. It will
set up KRB5CCNAME itself. It will set it to ths specific cache, e.g.
KEYRING:persistent:1003:1003. 

Suppose I need to kinit as a different user, e.g. hedrick.admin. If
KRB5CCNAME is set to the collection, kinit will create a new cache for
hedrick.admin, leaving the original one undisturbed, and change the
primary cache to the new one. Then when I'm fnished I can go back to
hedrick using "kswitch -p hedrick". However if KRB5CCNAME is set to
KEYRING:persistent:1003:1003 rather than to KEYRING:persistent:1003,
kinit will replace the credentials, and I'll have to kinit again to go
back to hedrick. With one-time passwords I'd really rather be able to
use kswitch.

I'd appreciate it if you would set KRB5CCNAME to the value from
krb5.conf, and not to the specific credential cache.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2815

Jakub Jelen <jjelen at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jjelen at redhat.com

--- Comment #1 from Jakub Jelen <jjelen at redhat.com> ---
I believe we were trying to solve similar issue with the patch attached
to the bug #2775. In short, we came to the conclusion, we should not
set KRB5CCNAME at all if it is using the default location from
krb5.conf.

The original version we are using in Fedora is little bit more
complicated, but there is also lined red hat bugzilla, where you can
find some more discussion about this.

Feedback, comments, improvements would be very appreciated.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2815

--- Comment #2 from Charles Hedrick <hedrick at rutgers.edu> ---
That would solve the problem I'm reporting. It would also complicate my
life for other reasons, but I can deal with it.

What sssd seems to do if you login with PAM is create a random
subsidiary cache, make it primary, and set KRB5CCNAME to the
collection.

I agree that changing the primary has issues, but it's the lesser evil.
It's a defect in design of the Kerberos libraries. If you don't create
a new cache and make it primary, you can end up stomping on an existing
credential with a different principal, potentially breaking NFS (though
protecting against that also requires a patch to rpc.gssd that I've
just requested). The real problem is that the primary is global for the
user, and not per-session. That is in turn a result of the fact that
Linux doesn't have a very good way of defining sessions.

The reason not setting KRB5CCNAME would complicate my life is that I
have a daemon that renews principals. I have to know which principals
are still in use, to not renew and eventually clean up ones not in use.
Currently I do it by checking KRB5CCNAME for all processes. If you
don't set KRB5CCNAME it's going to be hard to know whether a process is
using Kerberos or not, though I have a design that will do an
approximation. I agree that in principle KRB5CCNAME doesn't need to be
set. The library defaults to what's in krb5.conf. However at the moment
everything actually does set it, so not doing so in sshd will require
special-case handling. It would be easier for me if you explicitly set
it to what's in krb5.conf. Basically I'd prefer your code to work the
same as sssd's, so we get the same behavior whether the user types a
password or comes is by virtue of a Kerberos ticket.

I guess we're a bit unusual, in that (1) our home directories are
kerberized, so we can't afford to lose the ticket, (2) some of my users
are pretty unsophisticated, so we don't want to explain tickets and
kinit, and (3) my staff are using 2FA. I've had to construct some
support code. I'm trying to get gssd, sssd, and sshd to adopt some
changes so that things will work by default. At the moment I have my
own pam module that changes KRB5CCNAME to the collection if it's a
specific cache, and I copy the new cache to a separate location where
gssd will see it, even if the primary cache ends up being something
else. (I've suggested a change to gssd that will make NFS work if
there's a ticket for the user's primary principal, even if it's not
currently primary. It just requires using gssapi in a slightly
different way.) The sssd maintainers have agreed to handle automatic
renewal in the long run.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2815

--- Comment #3 from Charles Hedrick <hedrick at rutgers.edu> ---
actually, a slight correction. I believe sssd does the same things as
kinit: if the default cache is a collection, it first checks to see
whether there is already a cache with the login principal. If so, it
puts a new credential there. If not, it creates a new cache and uses
that. In either case it sets the cache to be primary in the collection.

I'd like to see sshd act like sssd/PAM and kinit. That behavior isn't
perfect, but it's the lesser evil, and at least it's consistent.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2815

Orion Poplawski <orion at cora.nwra.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |orion at cora.nwra.com

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2815

Oliver Freyermuth <o.freyermuth at googlemail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |o.freyermuth at googlemail.com

-- 
You are receiving this mail because:
You are watching the assignee of the bug.