krb5 library missing functions for collections

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

krb5 library missing functions for collections

Charles Hedrick
I have code to deal with a number of difficulties in implementing kerberos transparently to users.

Some of this code needs to know whether a KRB5CCNAME is a collection or a specific cache, and to be able to find the collection if it’s a cache.

I was surprised to find the methods to do these things aren’t present. Here’s what I’ve defined:

convert_to_collection(const char *ptr, uid_t uid)
  convert ccache name to the collection containing it
ccname_to_uid(const char *ptr, uid_t uid)
  find the uid that owns the cache
is_collection_type(const char *ccname)
  does the type support collections?
is_collection(const char *ccname)
  is it actually a collection (rather than a specific cache)
get_cc_type(const char *ccname)
  return the cache type

The first two have uid arguments because of KCM. Every other cache type allows you to determine unambiguously what user it’s associated with. For files you can use the file APIs to see who knows the file. Otherwise it’s encoded in the name. However the collection name for KCM is “KCM:”.  This is ambiguous. You need to know the current user to resolve it.

convert_to_collection actually returns KCM:uid so it’s unambiguous. This works as long as the code is always dealing with collection names. But it wouldn’t work in general, because KCM:uid is an actual collection name. (What I should have done is return something like KCM:#uid, so you can tell that it’s not a valid cache name.)

This oddity of KCM is really irritating. It means you have to do setruid every time you want to deal with a collection from a daemon, since otherwise the name is ambiguous.


________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: krb5 library missing functions for collections

Greg Hudson
On 7/22/19 11:16 AM, Charles Hedrick wrote:
> I was surprised to find the methods to do these things aren’t present. Here’s what I’ve defined:

Some of this is covered in
https://k5wiki.kerberos.org/wiki/Projects/Credential_cache_collection_improvements
(which unfortunately has not been worked on in quite a while), but not
all of it.

> The first two have uid arguments because of KCM. Every other cache type allows you to determine unambiguously what user it’s associated with.

By my reading, KEYRING also doesn't generally include the uid in the name.

> This oddity of KCM is really irritating. It means you have to do setruid every time you want to deal with a collection from a daemon, since otherwise the name is ambiguous.

The KCM daemon's namespace is machine-global, not uid-specific, and I
don't think doing setruid() would be visible to the daemon anyway (it
should see the euid of the client, not the ruid).
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: krb5 library missing functions for collections

Charles Hedrick
Please be aware that I’m using Redhat’s KCM implementation in sssd. It’s supposed to be compatible with Heimdal’s, but based on documentation it appears that it may not be.

The default value of KRB5CCNAME is simply KCM:  It had better be user-specific, or everybody shares a collection.

geneva:~/kerberos> klist -A
Ticket cache: KCM:1000:737
Default principal: [hidden email]<mailto:[hidden email]>

Valid starting       Expires              Service principal
07/22/2019 12:35:34  07/22/2019 20:33:37  krbtgt/[hidden email]<mailto:krbtgt/[hidden email]>
renew until 07/16/2020 09:53:19

geneva:~/kerberos> setenv KRB5CCNAME KCM:1000
geneva:~/kerberos> klist
klist: No credentials cache found

geneva:~/kerberos> setenv KRB5CCNAME KCM:
geneva:~/kerberos> klist
Ticket cache: KCM:1000:737
Default principal: [hidden email]<mailto:[hidden email]>

Valid starting       Expires              Service principal
07/22/2019 12:35:34  07/22/2019 20:33:37  krbtgt/[hidden email]<mailto:krbtgt/[hidden email]>
renew until 07/16/2020 09:53:19

I don’t know how it’s implemented, but it behaves as if KCM:1000 is a specific cache, and only KCM: can access the whole collection.

Note that root can’t read other user’s caches, so in a daemon I have to use setreuid to change to a user and then look at KCM:

I get the same results on my Mac if I use a Macports port of MIT Kerberos. With the builtin utilies I can’t make KCM work at all.


On Jul 22, 2019, at 1:00 PM, Greg Hudson <[hidden email]<mailto:[hidden email]>> wrote:

The KCM daemon's namespace is machine-global, not uid-specific, and I
don't think doing setruid() would be visible to the daemon anyway (it
should see the euid of the client, not the ruid).

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: krb5 library missing functions for collections

Charles Hedrick
In reply to this post by Greg Hudson
On Jul 22, 2019, at 1:00 PM, Greg Hudson <[hidden email]<mailto:[hidden email]>> wrote:

By my reading, KEYRING also doesn't generally include the uid in the name.

Again, I can only speak for what I see in Redhat and Ubuntu. The default for KRB5CCNAME is KEYRING:persistent:UID. Something (I think a combination of the library and the kernel) prevents users from accessing anything that doesn’t start with KEYRING:persistent:UID with their own UID. Root can access them all.

KEYRING:persistent:UID is a collection. All actual caches are KEYRING:persistent:UID:stuff, so there’s no ambiguity.

There are other formats for KEYRING for per-process, etc., but as far as I know they’re not used and would be pretty hard to use except for inside a specific application.

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: krb5 library missing functions for collections

Charles Hedrick
In reply to this post by Greg Hudson
Some more testing on MacOS. With the native Mac utilities, it uses credential type API:

It appears that if you set KRB5CCNAME to API or API:uid, it behaves the same way: If creates new unique names like API:027B19DC-01E6-4610-9300-7E3E1DFF706A.

Even if I set KRB5CCNAME to a specific cache, if I kinit a different user, it creates a new cache name. So it seems like API: followed by nothing or anything is the whole collection in contexts where a collection will work. But it still behaves like API: is user-specific, even though the name-space for actual caches is probably global.

Weird. If you use ported MIT utilities they behave like Redhat, and use KCM rather than API. KCM: is a collection of my caches just like API: is. But KCM:foo is now a specific cache.

So we have behavior that is specific not just to the OS, but which libraries are in use. Wonderful.

> On Jul 22, 2019, at 1:00 PM, Greg Hudson <[hidden email]> wrote:
>
> On 7/22/19 11:16 AM, Charles Hedrick wrote:
>> I was surprised to find the methods to do these things aren’t present. Here’s what I’ve defined:
>
> Some of this is covered in
> https://k5wiki.kerberos.org/wiki/Projects/Credential_cache_collection_improvements
> (which unfortunately has not been worked on in quite a while), but not
> all of it.
>
>> The first two have uid arguments because of KCM. Every other cache type allows you to determine unambiguously what user it’s associated with.
>
> By my reading, KEYRING also doesn't generally include the uid in the name.
>
>> This oddity of KCM is really irritating. It means you have to do setruid every time you want to deal with a collection from a daemon, since otherwise the name is ambiguous.
>
> The KCM daemon's namespace is machine-global, not uid-specific, and I
> don't think doing setruid() would be visible to the daemon anyway (it
> should see the euid of the client, not the ruid).


________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: krb5 library missing functions for collections

Greg Hudson
In reply to this post by Charles Hedrick
On 7/22/19 1:39 PM, Charles Hedrick wrote:
> Please be aware that I’m using Redhat’s KCM implementation in sssd. It’s
> supposed to be compatible with Heimdal’s, but based on documentation it
> appears that it may not be.
>
> The default value of KRB5CCNAME is simply KCM:  It had better be
> user-specific, or everybody shares a collection.

The Heimdal KCM implements a single global collection with access
control on individual caches, with the euid and egid of the client as
the access keys.  If a client doesn't have access to a cache, it isn't
visible in the collection as presented to that client.  Clients can only
create ccaches with names beginning with their "<euid>:" prefix.

In practice, users other than root will typically see disjoint
collections, where each cache name begins with the client's euid.  But
that's not a fundamental property of the daemon, and therefore not an
assumption of either the MIT krb5 or Heimdal client code.

One could conceivably build this namespace assumption into the client,
retrofitting it to treat "KCM:uid" as a collection by filtering out
caches whose names don't begin with the uid prefix.  Unfortunately that
wouldn't be 100% backward-compatible, as the Heimdal kcm daemon allows
clients to create individual caches named with only the euid (with no
":" afterwards).  Perhaps that's not important, though.

The sssd KCM may have different semantics from Heimdal's.  If it doesn't
let root see caches owned by other uids, then that would also have to be
changed to allow "KCM:uid" to work for root.

> I get the same results on my Mac if I use a Macports port of MIT Kerberos. With the builtin utilies I can’t make KCM work at all.

That's a little surprising to me.  My read of the OSX Heimdal code
suggests that it should allow "KCM:" as well as "API:".

> KEYRING:persistent:UID is a collection. All actual caches are KEYRING:persistent:UID:stuff, so there’s no ambiguity.
>
> There are other formats for KEYRING for per-process, etc., but as far as I know they’re not used and would be pretty hard to use except for inside a specific application.

The uid in "KEYRING:persistent" is optional (the process euid is used
implicitly), and the "session" and "user" forms (which do not have uids)
can be used across applications.

[Regarding OSX native utilities:]
> Even if I set KRB5CCNAME to a specific cache, if I kinit a different user, it creates a new cache name. So it seems like API: followed by nothing or anything is the whole collection in contexts where a collection will work.

The Heimdal kinit is a bit more aggressive than the MIT kinit in using a
collection when the ccache type supports it.  See
http://kerberos.996246.n3.nabble.com/KRB5CCNAME-new-semantics-under-Maverick-td40272.html
for some discussion of that.

> So we have behavior that is specific not just to the OS, but which libraries are in use. Wonderful.

Heimdal and MIT krb5 only promise to implement the same network
protocol, not to have identical behavior.  The OS X fork of Heimdal also
has significant behavior differences from upstream Heimdal.

Taking a step back: I'm guessing the use case here includes NFS.  The
architecture of Linux NFS and of Kerberos ccaches have unfortunately
never fit together in a very satisfactory way.  The NFS userspace daemon
wants to know what credentials are available to a user, knowing only its
uid, while credential cache types are typically designed to provide
flexibly named containers, not necessarily restricted to a single place
per user or even restricted to use by one user.

AFS, by contrast, has a mechanism (aklog) for userspace to tell the
kernel what credentials to use.  A single euid can have different
process groups (called PAGs) using different credentials.  This design
isn't perfect either, as the login and credential refresh systems need
enough hooks to know to re-run aklog (or unlog on credential destruction).
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: krb5 library missing functions for collections

Charles Hedrick
In my opinion NFS actually works fine for realistic cases, once a couple of bugs are fixed and some other tools are put in place.

In real cases, the user logins in with a principal username@DOMAIN. That is always placed in the default collection defined in /etc/krb5.conf. At least for us, they may at times get additional credentials. I guess they could also change to a different collection. But they’ll always have their primary credential in the default collection unless they do something really silly. Our renew daemon will make sure it’s renewed as long as they have an active process (and it’s killed within 5 min after they logout).

The NFS mechanism wants a credential username@DOMAIN. I think that’s perfectly sensible. And in any real cases the user will have such a credential when they’re logged in, whatever other credentials he may also have.

GSSAPI by default will look through the default collection (I think also some other places).

The problem is that the code in rpc.gssd works as followers:

* get the default credential from the collection
* fail unless it’s username@DOMAIN

If you replace the initial step by code telling it explicitly to get username@DOMAIN then it works just fine, assuming that the user actually has such a credential. Which they will. GSSAPI is perfectly capable of looking for a specific credential if you tell it to. It’s just that the code doesn’t do it that way. To avoid building my own copy of rpc.gssd, I use a loadable library to interpose code around GSSAPI that supplies the right argument.

The second case of interest is running cron jobs. In that case you will unfortunately have to trust root. It’s hard to imagine any way of running cron jobs that root couldn’t find a way to simulate. (well, actually there is. You could have a central cron server that ssh’s the command to the system. I think somebody does it that way. We might consider it.) So we allow users to register the fact that they trust root on a specific system. That fact is registered in LDAP. A pam module for cron does a kerberized call to a daemon on the KDC which verifies that root on that system is authorized, and returns a non-forwardable ticket for the user locked to that host’s IP(s). (It uses an MIT version of kimpersonate.) It is placed into a file in /tmp, which rpc.gssd checks if GSSAPI doesn’t find anything.

The third case of interest is sshd. Sshd for some reason insists on putting credentials in a /tmp file, even if the default ccname is set to a collection. rpc.gssd would find it there. But if the user knits with a different principal, it will overwrite the original. So we really want the login credentials to go into a collection. We have a pam module that normalizes the credential cache at login. If /etc/krb5.conf asks for KEYRING or KCM, and the cache is in /tmp, the pam module copies it to the right place and deletes the original.

I don’t have any issues with this. We did have lots of frustrations in the beginning. System staff would kinit to another principal to do administrative work and lose access to their files. Once we realized we needed the default ccname in /etc/krb5.conf to be a collection, and did these various fixes, things have worked fine.

Now if I could get the maintainers of rpc.gssd and sshd to take my fixes …

But really, to get transparent results you probably need our whole set of tools, since you’ll need the renew daemon, the stuff to generate credentials for cron, the pam modules, etc.


On Jul 22, 2019, at 3:22 PM, Greg Hudson <[hidden email]<mailto:[hidden email]>> wrote:

Taking a step back: I'm guessing the use case here includes NFS.  The
architecture of Linux NFS and of Kerberos ccaches have unfortunately
never fit together in a very satisfactory way.  The NFS userspace daemon
wants to know what credentials are available to a user, knowing only its
uid, while credential cache types are typically designed to provide
flexibly named containers, not necessarily restricted to a single place
per user or even restricted to use by one user.

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: krb5 library missing functions for collections

Simo Sorce-3
On Mon, 2019-07-22 at 20:10 +0000, Charles Hedrick wrote:

> The problem is that the code in rpc.gssd works as followers:
>
> * get the default credential from the collection
> * fail unless it’s username@DOMAIN
>
> If you replace the initial step by code telling it explicitly to get
> username@DOMAIN then it works just fine, assuming that the user
> actually has such a credential. Which they will. GSSAPI is perfectly
> capable of looking for a specific credential if you tell it to. It’s
> just that the code doesn’t do it that way. To avoid building my own
> copy of rpc.gssd, I use a loadable library to interpose code around
> GSSAPI that supplies the right argument.

rpc.gssd does this because it cannot know what the right credential
name is in all situations.

In very controlled environments it is indeed username + @REALM and the
realm is known, but in other cases it is not.
For example a personal laptop where the username is 'joe' and no
default realm is set and someone doing kinit [hidden email] then
walking into an NFS mount.

I guess the nfs-utils folks may accept a patch to rpc.gssd where an
option can be given to assume a specific form for the user's principal
name to look for, but that can't be the default as it would break
current uses.

HTH,
Simo.

--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc




________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: krb5 library missing functions for collections

Charles Hedrick
In reply to this post by Greg Hudson
This matches the observed behavior. What you describe is internally a single address space, but from a user's point of view KCM: points to a different address space per user. It means there’s no unambiguous syntax for a root daemon to refer to a specific user’s collection.

-------------------

MacOS seems to be an oddity.

With no default ccname set, the Mac version of “klist -l” shows

* [hidden email]       KCM:1003:4     Jul 23 17:18:08 2019
  [hidden email]       API:1003:4     Jul 23 17:18:08 2019
  [hidden email]   API:1003:3     Jul 23 17:13:29 2019

klist (no argument) shows KCM:1003:4, as you’d expect.

However if I set KRB5CCNAME to either API: or KCM: I get

  [hidden email]       API:1003:4     Jul 23 17:18:08 2019
  [hidden email]   API:1003:3     Jul 23 17:13:29 2019

There’s no longer a selected cache, so klist with no argument says no cache. Setting KRB5CCNAME to API:1003 or KCM:1003 doesn’t help. I can’t find any non-blank setting of KRB5CCNAME that works, nor does doing an expect kswitch help.

Of course using the Macports utilities, things work fine. /usr/bin/ssh seems not to find credentials where the Macports one can, consistently with when /usr/bin/klist can find them.

As far as I can see, on the Mac with native utilities, root can still only see one user’s credentials. It sees the one matching its ruid.

Just to add to the fun, if no KRB5CCNAME is set, the native kinit produces this result:

* [hidden email]   API:3C09F9F9-6C7D-4D41-95CB-F053F4102C7A   Jul 23 17:58:11 2019

No indication of uid in the name at all. At least setting KRB5CCNAME to the specific cache works.



> On Jul 22, 2019, at 3:22 PM, Greg Hudson <[hidden email]> wrote:
>
> On 7/22/19 1:39 PM, Charles Hedrick wrote:
>> Please be aware that I’m using Redhat’s KCM implementation in sssd. It’s
>> supposed to be compatible with Heimdal’s, but based on documentation it
>> appears that it may not be.
>>
>> The default value of KRB5CCNAME is simply KCM:  It had better be
>> user-specific, or everybody shares a collection.
>
> The Heimdal KCM implements a single global collection with access
> control on individual caches, with the euid and egid of the client as
> the access keys.  If a client doesn't have access to a cache, it isn't
> visible in the collection as presented to that client.  Clients can only
> create ccaches with names beginning with their "<euid>:" prefix.
>
> In practice, users other than root will typically see disjoint
> collections, where each cache name begins with the client's euid.  But
> that's not a fundamental property of the daemon, and therefore not an
> assumption of either the MIT krb5 or Heimdal client code.
>
> One could conceivably build this namespace assumption into the client,
> retrofitting it to treat "KCM:uid" as a collection by filtering out
> caches whose names don't begin with the uid prefix.  Unfortunately that
> wouldn't be 100% backward-compatible, as the Heimdal kcm daemon allows
> clients to create individual caches named with only the euid (with no
> ":" afterwards).  Perhaps that's not important, though.
>
> The sssd KCM may have different semantics from Heimdal's.  If it doesn't
> let root see caches owned by other uids, then that would also have to be
> changed to allow "KCM:uid" to work for root.
>
>> I get the same results on my Mac if I use a Macports port of MIT Kerberos. With the builtin utilies I can’t make KCM work at all.
>
> That's a little surprising to me.  My read of the OSX Heimdal code
> suggests that it should allow "KCM:" as well as "API:".
>
>> KEYRING:persistent:UID is a collection. All actual caches are KEYRING:persistent:UID:stuff, so there’s no ambiguity.
>>
>> There are other formats for KEYRING for per-process, etc., but as far as I know they’re not used and would be pretty hard to use except for inside a specific application.
>
> The uid in "KEYRING:persistent" is optional (the process euid is used
> implicitly), and the "session" and "user" forms (which do not have uids)
> can be used across applications.
>
> [Regarding OSX native utilities:]
>> Even if I set KRB5CCNAME to a specific cache, if I kinit a different user, it creates a new cache name. So it seems like API: followed by nothing or anything is the whole collection in contexts where a collection will work.
>
> The Heimdal kinit is a bit more aggressive than the MIT kinit in using a
> collection when the ccache type supports it.  See
> http://kerberos.996246.n3.nabble.com/KRB5CCNAME-new-semantics-under-Maverick-td40272.html
> for some discussion of that.
>
>> So we have behavior that is specific not just to the OS, but which libraries are in use. Wonderful.
>
> Heimdal and MIT krb5 only promise to implement the same network
> protocol, not to have identical behavior.  The OS X fork of Heimdal also
> has significant behavior differences from upstream Heimdal.
>
> Taking a step back: I'm guessing the use case here includes NFS.  The
> architecture of Linux NFS and of Kerberos ccaches have unfortunately
> never fit together in a very satisfactory way.  The NFS userspace daemon
> wants to know what credentials are available to a user, knowing only its
> uid, while credential cache types are typically designed to provide
> flexibly named containers, not necessarily restricted to a single place
> per user or even restricted to use by one user.
>
> AFS, by contrast, has a mechanism (aklog) for userspace to tell the
> kernel what credentials to use.  A single euid can have different
> process groups (called PAGs) using different credentials.  This design
> isn't perfect either, as the login and credential refresh systems need
> enough hooks to know to re-run aklog (or unlog on credential destruction).


________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: krb5 library missing functions for collections

Charles Hedrick
In reply to this post by Simo Sorce-3
Maybe there’s a path through the code that I didn’t find. But it ends up failing if the credential isn’t username@DOMAIN. There’s an explicit test. I don’t see why it couldn't specify that in the first place.

I think if you want a local user joe to access NFS as jdoe@REALM, you’d want to set up that mapping somewhere. I haven’t checked this in the code, but I’d expect it in a krb5.conf mapping, .k5identity, and/or idmap. I doubt you want NFS to use whatever random ticket may be in the default cache for the uid making the access. As far as I can tell it doesn’t actually do that now.

> On Jul 23, 2019, at 9:35 AM, Simo Sorce <[hidden email]> wrote:
>
> On Mon, 2019-07-22 at 20:10 +0000, Charles Hedrick wrote:
>> The problem is that the code in rpc.gssd works as followers:
>>
>> * get the default credential from the collection
>> * fail unless it’s username@DOMAIN
>>
>> If you replace the initial step by code telling it explicitly to get
>> username@DOMAIN then it works just fine, assuming that the user
>> actually has such a credential. Which they will. GSSAPI is perfectly
>> capable of looking for a specific credential if you tell it to. It’s
>> just that the code doesn’t do it that way. To avoid building my own
>> copy of rpc.gssd, I use a loadable library to interpose code around
>> GSSAPI that supplies the right argument.
>
> rpc.gssd does this because it cannot know what the right credential
> name is in all situations.
>
> In very controlled environments it is indeed username + @REALM and the
> realm is known, but in other cases it is not.
> For example a personal laptop where the username is 'joe' and no
> default realm is set and someone doing kinit [hidden email] then
> walking into an NFS mount.
>
> I guess the nfs-utils folks may accept a patch to rpc.gssd where an
> option can be given to assume a specific form for the user's principal
> name to look for, but that can't be the default as it would break
> current uses.
>
> HTH,
> Simo.
>
> --
> Simo Sorce
> RHEL Crypto Team
> Red Hat, Inc
>
>
>
>


________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: krb5 library missing functions for collections

Charles Hedrick
this is worse than it looks. Documentation says that GSSAPI will obey .k5identity. That’s the right solution for you situation of the laptop user with a different username.

The problem is that there’s no system-wide equivalent of .k5identity. My code causes problems, because in specifying a particular principle it bypasses .k5identity. But for the normal case we don’t want every user to have to specify a .k5identity. I suspect the right thing for me to do is rather than hack rpc.gssd, supply a cc_select plugin to make the obvious selection for service=nfs. But I claim this ought to be the default. I shouldn’t have to do C coding to make it happen.

> On Jul 23, 2019, at 10:09 AM, Charles Hedrick <[hidden email]> wrote:
>
> Maybe there’s a path through the code that I didn’t find. But it ends up failing if the credential isn’t username@DOMAIN. There’s an explicit test. I don’t see why it couldn't specify that in the first place.
>
> I think if you want a local user joe to access NFS as jdoe@REALM, you’d want to set up that mapping somewhere. I haven’t checked this in the code, but I’d expect it in a krb5.conf mapping, .k5identity, and/or idmap. I doubt you want NFS to use whatever random ticket may be in the default cache for the uid making the access. As far as I can tell it doesn’t actually do that now.
>
>> On Jul 23, 2019, at 9:35 AM, Simo Sorce <[hidden email]> wrote:
>>
>> On Mon, 2019-07-22 at 20:10 +0000, Charles Hedrick wrote:
>>> The problem is that the code in rpc.gssd works as followers:
>>>
>>> * get the default credential from the collection
>>> * fail unless it’s username@DOMAIN
>>>
>>> If you replace the initial step by code telling it explicitly to get
>>> username@DOMAIN then it works just fine, assuming that the user
>>> actually has such a credential. Which they will. GSSAPI is perfectly
>>> capable of looking for a specific credential if you tell it to. It’s
>>> just that the code doesn’t do it that way. To avoid building my own
>>> copy of rpc.gssd, I use a loadable library to interpose code around
>>> GSSAPI that supplies the right argument.
>>
>> rpc.gssd does this because it cannot know what the right credential
>> name is in all situations.
>>
>> In very controlled environments it is indeed username + @REALM and the
>> realm is known, but in other cases it is not.
>> For example a personal laptop where the username is 'joe' and no
>> default realm is set and someone doing kinit [hidden email] then
>> walking into an NFS mount.
>>
>> I guess the nfs-utils folks may accept a patch to rpc.gssd where an
>> option can be given to assume a specific form for the user's principal
>> name to look for, but that can't be the default as it would break
>> current uses.
>>
>> HTH,
>> Simo.
>>
>> --
>> Simo Sorce
>> RHEL Crypto Team
>> Red Hat, Inc
>>
>>
>>
>>
>


________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: krb5 library missing functions for collections

Simo Sorce-3
In reply to this post by Charles Hedrick
On Tue, 2019-07-23 at 14:09 +0000, Charles Hedrick wrote:

> Maybe there’s a path through the code that I didn’t find. But it ends
> up failing if the credential isn’t username@DOMAIN. There’s an
> explicit test. I don’t see why it couldn't specify that in the first
> place.
>
> I think if you want a local user joe to access NFS as jdoe@REALM,
> you’d want to set up that mapping somewhere. I haven’t checked this
> in the code, but I’d expect it in a krb5.conf mapping, .k5identity,
> and/or idmap. I doubt you want NFS to use whatever random ticket may
> be in the default cache for the uid making the access. As far as I
> can tell it doesn’t actually do that now.

Actually this is how NFS is supposed to work, it will pick the first
valid credential, but it is possible a later change broke it.

.k5identity is also an option but as a way to select a non-default
principal, if you have only one krbtgt regardless of what it is I
expect an NFS mount to try to use that credential.

Simo.

> > On Jul 23, 2019, at 9:35 AM, Simo Sorce <[hidden email]> wrote:
> >
> > On Mon, 2019-07-22 at 20:10 +0000, Charles Hedrick wrote:
> > > The problem is that the code in rpc.gssd works as followers:
> > >
> > > * get the default credential from the collection
> > > * fail unless it’s username@DOMAIN
> > >
> > > If you replace the initial step by code telling it explicitly to get
> > > username@DOMAIN then it works just fine, assuming that the user
> > > actually has such a credential. Which they will. GSSAPI is perfectly
> > > capable of looking for a specific credential if you tell it to. It’s
> > > just that the code doesn’t do it that way. To avoid building my own
> > > copy of rpc.gssd, I use a loadable library to interpose code around
> > > GSSAPI that supplies the right argument.
> >
> > rpc.gssd does this because it cannot know what the right credential
> > name is in all situations.
> >
> > In very controlled environments it is indeed username + @REALM and the
> > realm is known, but in other cases it is not.
> > For example a personal laptop where the username is 'joe' and no
> > default realm is set and someone doing kinit [hidden email] then
> > walking into an NFS mount.
> >
> > I guess the nfs-utils folks may accept a patch to rpc.gssd where an
> > option can be given to assume a specific form for the user's principal
> > name to look for, but that can't be the default as it would break
> > current uses.
> >
> > HTH,
> > Simo.
> >
> > --
> > Simo Sorce
> > RHEL Crypto Team
> > Red Hat, Inc
> >
> >
> >
> >
>
>

--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc




________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: krb5 library missing functions for collections

Charles Hedrick
In reply to this post by Charles Hedrick
ugh. rpc.gssd reads root’s .k5identity file. If I put my principal in /.k5identity, things work. So a plugin would probably work. But it looks like a bug that should be fixed.

> On Jul 23, 2019, at 10:09 AM, Charles Hedrick <[hidden email]> wrote:
>
> Maybe there’s a path through the code that I didn’t find. But it ends up failing if the credential isn’t username@DOMAIN. There’s an explicit test. I don’t see why it couldn't specify that in the first place.
>
> I think if you want a local user joe to access NFS as jdoe@REALM, you’d want to set up that mapping somewhere. I haven’t checked this in the code, but I’d expect it in a krb5.conf mapping, .k5identity, and/or idmap. I doubt you want NFS to use whatever random ticket may be in the default cache for the uid making the access. As far as I can tell it doesn’t actually do that now.
>
>> On Jul 23, 2019, at 9:35 AM, Simo Sorce <[hidden email]> wrote:
>>
>> On Mon, 2019-07-22 at 20:10 +0000, Charles Hedrick wrote:
>>> The problem is that the code in rpc.gssd works as followers:
>>>
>>> * get the default credential from the collection
>>> * fail unless it’s username@DOMAIN
>>>
>>> If you replace the initial step by code telling it explicitly to get
>>> username@DOMAIN then it works just fine, assuming that the user
>>> actually has such a credential. Which they will. GSSAPI is perfectly
>>> capable of looking for a specific credential if you tell it to. It’s
>>> just that the code doesn’t do it that way. To avoid building my own
>>> copy of rpc.gssd, I use a loadable library to interpose code around
>>> GSSAPI that supplies the right argument.
>>
>> rpc.gssd does this because it cannot know what the right credential
>> name is in all situations.
>>
>> In very controlled environments it is indeed username + @REALM and the
>> realm is known, but in other cases it is not.
>> For example a personal laptop where the username is 'joe' and no
>> default realm is set and someone doing kinit [hidden email] then
>> walking into an NFS mount.
>>
>> I guess the nfs-utils folks may accept a patch to rpc.gssd where an
>> option can be given to assume a specific form for the user's principal
>> name to look for, but that can't be the default as it would break
>> current uses.
>>
>> HTH,
>> Simo.
>>
>> --
>> Simo Sorce
>> RHEL Crypto Team
>> Red Hat, Inc
>>
>>
>>
>>
>


________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: krb5 library missing functions for collections

Charles Hedrick
In reply to this post by Greg Hudson
I’ve thought a bit more about this. i think the problem is that there’s no way to know what the user wants, and to really give him proper control requires significant kernel work.

Currently the Linux kernel establishes an NFS security context that is associated with the UID. Any process running with that UID uses that context.The context is long-lived, by default. The only sane choice is to use the main principal associated with the user. Using the principal that happens to be primary when the first access is done in simply broken.

I can think of two kinds of exception. Suppose I become root. I’d like to copy a program I just built to /usr. I need root to put in on user, but when I change UID, I lose access to my home directory. For this case perhaps it would be better if NFS used the current principal. Then I’d have a UID of root for local access and a principal of hedrick for NFS access. This would require a lot of kernel work, though. You’d need NFS security context based on the principal, and the kernel would have to look at KRB5CCNAME for every process doing an access, figure out the current principal, and use the right context.

But suppose we did that. Consider another case. I’m administrator of a number of services. Those services each require me to kinit as a specific principal. So now my current primary principal is hadoop or ldap-admin. If you use the current principal, I again lose access to my files.

I think a real solution involves a separate kernel attribute for the principal to use for NFS. Indeed it might need to be filesystem-specific, though in practical cases maybe not. (You’d also need to consider how to do idmap in that case.)

But none of these kernel changes exist. As long as the kernel does access based on UID, the only sane choice for rpc.gssd is the principal associated with my username. That means current behavior is broken. I now have a ccselect plugin to fix that. It has to be configured in /etc/krb5.conf. You can’t do it in ~/.k5identity. rpc.gssd ignores that, for good reason. If my home directory is on Kerberized NFS, I can’t access ~/.k5idenity until I’ve established a security context, so you can’t use ~/.k5identity to do that.

I’ve submitted a feature request to fix the default ccselect plugin so it reads /etc/k5identity if the user doesn’t have one or it doesn’t apply. Also, you’d need to recognize ${username}. That would let me specify a policy for NFS credentials, which could conceivably even differ for different file servers. I think that’s the best that can be done with the current kernel.


On Jul 22, 2019, at 3:22:19 PM, Greg Hudson <[hidden email]<mailto:[hidden email]>> wrote:

Taking a step back: I'm guessing the use case here includes NFS.  The
architecture of Linux NFS and of Kerberos ccaches have unfortunately
never fit together in a very satisfactory way.  The NFS userspace daemon
wants to know what credentials are available to a user, knowing only its
uid, while credential cache types are typically designed to provide
flexibly named containers, not necessarily restricted to a single place
per user or even restricted to use by one user.

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: krb5 library missing functions for collections

Charles Hedrick
Ok. I see Simo’s point about laptops. I say current behavior is broken because when the context needs to be renewed it uses whatever principal is currently primary. So from a users point of view their access can change or break randomly.

Given the current kernel support the only thing reasonable is probably the ability to set policy.

Incidentally on a single user laptop you can actually do that. Rpc.gssd used .k5identity in root. On a single user machine that’s actually potentially useful.

Sent from my iPhone

On Jul 26, 2019, at 9:09 AM, Charles Hedrick <[hidden email]<mailto:[hidden email]>> wrote:

I’ve thought a bit more about this. i think the problem is that there’s no way to know what the user wants, and to really give him proper control requires significant kernel work.

Currently the Linux kernel establishes an NFS security context that is associated with the UID. Any process running with that UID uses that context.The context is long-lived, by default. The only sane choice is to use the main principal associated with the user. Using the principal that happens to be primary when the first access is done in simply broken.

I can think of two kinds of exception. Suppose I become root. I’d like to copy a program I just built to /usr. I need root to put in on user, but when I change UID, I lose access to my home directory. For this case perhaps it would be better if NFS used the current principal. Then I’d have a UID of root for local access and a principal of hedrick for NFS access. This would require a lot of kernel work, though. You’d need NFS security context based on the principal, and the kernel would have to look at KRB5CCNAME for every process doing an access, figure out the current principal, and use the right context.

But suppose we did that. Consider another case. I’m administrator of a number of services. Those services each require me to kinit as a specific principal. So now my current primary principal is hadoop or ldap-admin. If you use the current principal, I again lose access to my files.

I think a real solution involves a separate kernel attribute for the principal to use for NFS. Indeed it might need to be filesystem-specific, though in practical cases maybe not. (You’d also need to consider how to do idmap in that case.)

But none of these kernel changes exist. As long as the kernel does access based on UID, the only sane choice for rpc.gssd is the principal associated with my username. That means current behavior is broken. I now have a ccselect plugin to fix that. It has to be configured in /etc/krb5.conf. You can’t do it in ~/.k5identity. rpc.gssd ignores that, for good reason. If my home directory is on Kerberized NFS, I can’t access ~/.k5idenity until I’ve established a security context, so you can’t use ~/.k5identity to do that.

I’ve submitted a feature request to fix the default ccselect plugin so it reads /etc/k5identity if the user doesn’t have one or it doesn’t apply. Also, you’d need to recognize ${username}. That would let me specify a policy for NFS credentials, which could conceivably even differ for different file servers. I think that’s the best that can be done with the current kernel.


On Jul 22, 2019, at 3:22:19 PM, Greg Hudson <[hidden email]<mailto:[hidden email]>> wrote:

Taking a step back: I'm guessing the use case here includes NFS.  The
architecture of Linux NFS and of Kerberos ccaches have unfortunately
never fit together in a very satisfactory way.  The NFS userspace daemon
wants to know what credentials are available to a user, knowing only its
uid, while credential cache types are typically designed to provide
flexibly named containers, not necessarily restricted to a single place
per user or even restricted to use by one user.

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: krb5 library missing functions for collections

Ken Hornstein
In reply to this post by Charles Hedrick
>I think a real solution involves a separate kernel attribute
>for the principal to use for NFS. Indeed it might need to be
>filesystem-specific, though in practical cases maybe not. (You’d also
>need to consider how to do idmap in that case.)

That already exists; the keyring functionality is used by AFS to
associate a particular set of Kerberos credentials with a user or
a login session (in my experience, the session keyring generally
give you the semantics that you want).

--Ken
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: krb5 library missing functions for collections

Greg Hudson
In reply to this post by Charles Hedrick
On 7/26/19 9:09 AM, Charles Hedrick wrote:
> I’ve submitted a feature request to fix the default ccselect plugin so
> it reads /etc/k5identity if the user doesn’t have one or it doesn’t
> apply. Also, you’d need to recognize ${username}. That would let me
> specify a policy for NFS credentials, which could conceivably even
> differ for different file servers. I think that’s the best that can be
> done with the current kernel.

A possible pure-userspace solution is to establish a local directory per
user in a well-known location, where users (or some agent operating as
the user's uid) can copy a ticket cache into in a well-known filename.
If rpc.gssd finds a cache there, it could use it in preference to
picking from the user's collection.  This doesn't give the kind of
per-process control you can get from AFS's pagsh, but it does give
control to users as opposed to a root-owned file like /etc/k5identity.
On machines using systemd, /run/user/uid could be leveraged for this
purpose, although that directory will only exist while the user is
logged in (so not for cron jobs).
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: krb5 library missing functions for collections

Charles Hedrick
I think you can actually do that now. But I’m not convinced it’s worth it. You can tell rpc.gssd to look in a specific directory. The default is /tmp then /run/user/%U. You’d probably want to reverse the order.

But these are used after GSSAPI, so in practice they probably wouldn’t get used.

But wait, there more. At least in our environment, GSSAPI will use gssproxy. I think you could configure it to look in some appropriate special cache. You can give it more than one, so you could tell it to use a cache in /run/user/%U if it exists, otherwise the default cache. But you’d still have the problem that it might pick the wrong thing from the default cache, so to get definite behavior, you’d need to use /run/user all the time. Then you have to make sure there’s something reasonable there by default. So you’d want a PAM module to make a copy of your login credentials there by default, since you don’t want to require every user to do a manual kinit. And of course your renewal code would need to renew that along with your primary credentials.

We have code to do all of this if you really wanted to, but it seems like excessive complexity. Ccselect is more straightforward.

I think the separate credential location only starts to make sense if you can select on a per-process basis which to use. And even then I think you’d normally point it to a credential in the default location. Basically the moment you can tell the kernel which credential to use, you can give it a specific credential, and the issue with collections goes away.

> On Jul 26, 2019, at 11:22 AM, Greg Hudson <[hidden email]> wrote:
>
> On 7/26/19 9:09 AM, Charles Hedrick wrote:
>> I’ve submitted a feature request to fix the default ccselect plugin so
>> it reads /etc/k5identity if the user doesn’t have one or it doesn’t
>> apply. Also, you’d need to recognize ${username}. That would let me
>> specify a policy for NFS credentials, which could conceivably even
>> differ for different file servers. I think that’s the best that can be
>> done with the current kernel.
>
> A possible pure-userspace solution is to establish a local directory per
> user in a well-known location, where users (or some agent operating as
> the user's uid) can copy a ticket cache into in a well-known filename.
> If rpc.gssd finds a cache there, it could use it in preference to
> picking from the user's collection.  This doesn't give the kind of
> per-process control you can get from AFS's pagsh, but it does give
> control to users as opposed to a root-owned file like /etc/k5identity.
> On machines using systemd, /run/user/uid could be leveraged for this
> purpose, although that directory will only exist while the user is
> logged in (so not for cron jobs).


________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: krb5 library missing functions for collections

Robbie Harwood
In reply to this post by Greg Hudson
Greg Hudson <[hidden email]> writes:

> On 7/22/19 1:39 PM, Charles Hedrick wrote:
>
>> Please be aware that I’m using Redhat’s KCM implementation in
>> sssd. It’s supposed to be compatible with Heimdal’s, but based on
>> documentation it appears that it may not be.
>>
>> The default value of KRB5CCNAME is simply KCM:  It had better be
>> user-specific, or everybody shares a collection.
>
> The Heimdal KCM implements a single global collection with access
> control on individual caches, with the euid and egid of the client as
> the access keys.  If a client doesn't have access to a cache, it isn't
> visible in the collection as presented to that client.  Clients can
> only create ccaches with names beginning with their "<euid>:" prefix.
>
> In practice, users other than root will typically see disjoint
> collections, where each cache name begins with the client's euid.  But
> that's not a fundamental property of the daemon, and therefore not an
> assumption of either the MIT krb5 or Heimdal client code.
>
> One could conceivably build this namespace assumption into the client,
> retrofitting it to treat "KCM:uid" as a collection by filtering out
> caches whose names don't begin with the uid prefix.  Unfortunately
> that wouldn't be 100% backward-compatible, as the Heimdal kcm daemon
> allows clients to create individual caches named with only the euid
> (with no ":" afterwards).  Perhaps that's not important, though.
>
> The sssd KCM may have different semantics from Heimdal's.  If it doesn't
> let root see caches owned by other uids, then that would also have to be
> changed to allow "KCM:uid" to work for root.
(CCing Jakub in case I miss anything here.)

To my reading, SSSD's KCM deliberately allows root to access all ccaches
but not list them.  See
https://github.com/SSSD/sssd/blob/master/src/responder/kcm/kcmsrv_ccache.h#L75-L80
and
https://github.com/SSSD/sssd/blob/master/src/responder/kcm/kcmsrv_ccache.h#L144-L156

Thanks,
--Robbie

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: krb5 library missing functions for collections

Jakub Hrozek
On Mon, Jul 29, 2019 at 02:35:40PM -0400, Robbie Harwood wrote:

> Greg Hudson <[hidden email]> writes:
>
> > On 7/22/19 1:39 PM, Charles Hedrick wrote:
> >
> >> Please be aware that I’m using Redhat’s KCM implementation in
> >> sssd. It’s supposed to be compatible with Heimdal’s, but based on
> >> documentation it appears that it may not be.
> >>
> >> The default value of KRB5CCNAME is simply KCM:  It had better be
> >> user-specific, or everybody shares a collection.
> >
> > The Heimdal KCM implements a single global collection with access
> > control on individual caches, with the euid and egid of the client as
> > the access keys.  If a client doesn't have access to a cache, it isn't
> > visible in the collection as presented to that client.  Clients can
> > only create ccaches with names beginning with their "<euid>:" prefix.
> >
> > In practice, users other than root will typically see disjoint
> > collections, where each cache name begins with the client's euid.  But
> > that's not a fundamental property of the daemon, and therefore not an
> > assumption of either the MIT krb5 or Heimdal client code.
> >
> > One could conceivably build this namespace assumption into the client,
> > retrofitting it to treat "KCM:uid" as a collection by filtering out
> > caches whose names don't begin with the uid prefix.  Unfortunately
> > that wouldn't be 100% backward-compatible, as the Heimdal kcm daemon
> > allows clients to create individual caches named with only the euid
> > (with no ":" afterwards).  Perhaps that's not important, though.
> >
> > The sssd KCM may have different semantics from Heimdal's.  If it doesn't
> > let root see caches owned by other uids, then that would also have to be
> > changed to allow "KCM:uid" to work for root.
>
> (CCing Jakub in case I miss anything here.)
>
> To my reading, SSSD's KCM deliberately allows root to access all ccaches
> but not list them.  See
> https://github.com/SSSD/sssd/blob/master/src/responder/kcm/kcmsrv_ccache.h#L75-L80
> and
> https://github.com/SSSD/sssd/blob/master/src/responder/kcm/kcmsrv_ccache.h#L144-L156

Hrm, maybe that comment is outdated. I thought, after discussing this
with Greg some time ago:
    https://github.com/krb5/krb5/pull/557#issuecomment-254834623
is that only KRB5CCNAME=KCM: is allowed and not KRB5CCNAME=KCM:uid and
the only way root can access other user's ccaches is to run klist -l and
filter by UID.

However, running:
    KRB5CCNAME=KCM: klist -l
as root does not allow me to list all users' ccaches as root..I haven't
tested if this would have worked with MIT's libkrb5 and Heimdal's KCM,
though..
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
12