Heimdal 7.3: ext_keytab fails with "Operation requires `get-keys' privilege"

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

Heimdal 7.3: ext_keytab fails with "Operation requires `get-keys' privilege"

Andreas Haupt-2
Dear all,

Heimdal 7.3 seems to suffer from a bug in privilege checking. A prinicipal
having all rights on the database is unable to extract keytabs:

[kdc1] /root # cat /var/heimdal/kadmind.acl 
<myaccount>/admin@<MYREALM> all

[chip-vm8] /root # kadmin -p <myaccount>/admin -a kdc1
kadmin> ext -k /root/keytab <principal>
<myaccount>/admin@<MYREALM>'s Password: 
kadmin: ext <principal>: Operation requires `get-keys' privilege

Kadmind logs the error:

Jun 26 11:11:08 kdc1 kadmind[10116]: connection from IPv4:<ip>
Jun 26 11:11:10 kdc1 kadmind[10564]: <myaccount>/admin@<MYREALM>: GET principal@<MYREALM>
Jun 26 11:11:10 kdc1 kadmind[10564]: GET: Operation requires `get-keys' privilege

That does not change even when explicitly listing all rights:

[kdc1] /root # cat /var/heimdal/kadmind.acl 
<myaccount>/admin@<MYREALM> cpw list delete modify add get get-keys

It works using 'kadmin -l ext -k /root/keytab <principal>', though. Other
commands like get, cpw, etc. work correctly.

Is this a known issue? Any idea for a workaround?

Thanks,
Andreas
--
| Andreas Haupt            | E-Mail: [hidden email]
|  DESY Zeuthen            | WWW:    http://www-zeuthen.desy.de/~ahaupt
|  Platanenallee 6         | Phone:  +49/33762/7-7359
|  D-15738 Zeuthen         | Fax:    +49/33762/7-7216



smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Heimdal 7.3: ext_keytab fails with "Operation requires `get-keys' privilege"

Andreas Haupt-2
Sorry for replying to myself but I guess, I found the answer:

https://github.com/heimdal/heimdal/issues/96 contains the discussion.

When the kadmind.acl looks like this, the kadmin 'privileges' command won't
contain the 'get-keys' right, but ext_keytab will work anyway:

[kdc1] /root # cat /var/heimdal/kadmind.acl
<myaccount>/admin@<MYREALM> cpw,list,delete,modify,add,get,get-keys


So, this behaviour change is everything but nice, nevertheless it still
works ...

Cheers,
Andreas

On Mon, 2017-06-26 at 11:18 +0200, Andreas Haupt wrote:

> Dear all,
>
> Heimdal 7.3 seems to suffer from a bug in privilege checking. A prinicipal
> having all rights on the database is unable to extract keytabs:
>
> [kdc1] /root # cat /var/heimdal/kadmind.acl 
> <myaccount>/admin@<MYREALM> all
>
> [chip-vm8] /root # kadmin -p <myaccount>/admin -a kdc1
> kadmin> ext -k /root/keytab <principal>
> <myaccount>/admin@<MYREALM>'s Password: 
> kadmin: ext <principal>: Operation requires `get-keys' privilege
>
> Kadmind logs the error:
>
> Jun 26 11:11:08 kdc1 kadmind[10116]: connection from IPv4:<ip>
> Jun 26 11:11:10 kdc1 kadmind[10564]: <myaccount>/admin@<MYREALM>: GET
> principal@<MYREALM>
> Jun 26 11:11:10 kdc1 kadmind[10564]: GET: Operation requires `get-keys'
> privilege
>
> That does not change even when explicitly listing all rights:
>
> [kdc1] /root # cat /var/heimdal/kadmind.acl 
> <myaccount>/admin@<MYREALM> cpw list delete modify add get get-keys
>
> It works using 'kadmin -l ext -k /root/keytab <principal>', though. Other
> commands like get, cpw, etc. work correctly.
>
> Is this a known issue? Any idea for a workaround?
>
> Thanks,
> Andreas
--
| Andreas Haupt            | E-Mail: [hidden email]
|  DESY Zeuthen            | WWW:    http://www-zeuthen.desy.de/~ahaupt
|  Platanenallee 6         | Phone:  +49/33762/7-7359
|  D-15738 Zeuthen         | Fax:    +49/33762/7-7216



smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Heimdal 7.3: ext_keytab fails with "Operation requires `get-keys' privilege"

Henry B Hotz
I’m with Love’s comment. Sounds like we did something different for some reason?

Sounds like the current behavior is confusing, and therefore wrong, but I’ll have to make sure I understand it.

I don’t think being able to get passwords is a different privilege from getting keys. Getting keytabs is the same as getting keys, and it’s neither a rare nor unusual operation.

There is no security value to just making administration more arcane. If you’re worried about making a key extraction visible, then fix the logging, don’t make the admin interface confusing. That invites bugs and therefore INsecurity! Virtually all current security problems are due to bugs.

> On Jun 26, 2017, at 3:28 AM, Andreas Haupt <[hidden email]> wrote:
>
> Sorry for replying to myself but I guess, I found the answer:
>
> https://github.com/heimdal/heimdal/issues/96 contains the discussion.
>
> When the kadmind.acl looks like this, the kadmin 'privileges' command won't
> contain the 'get-keys' right, but ext_keytab will work anyway:
>
> [kdc1] /root # cat /var/heimdal/kadmind.acl
> <myaccount>/admin@<MYREALM> cpw,list,delete,modify,add,get,get-keys
>
>
> So, this behaviour change is everything but nice, nevertheless it still
> works ...
>
> Cheers,
> Andreas
>
> On Mon, 2017-06-26 at 11:18 +0200, Andreas Haupt wrote:
>> Dear all,
>>
>> Heimdal 7.3 seems to suffer from a bug in privilege checking. A prinicipal
>> having all rights on the database is unable to extract keytabs:
>>
>> [kdc1] /root # cat /var/heimdal/kadmind.acl
>> <myaccount>/admin@<MYREALM> all
>>
>> [chip-vm8] /root # kadmin -p <myaccount>/admin -a kdc1
>> kadmin> ext -k /root/keytab <principal>
>> <myaccount>/admin@<MYREALM>'s Password:
>> kadmin: ext <principal>: Operation requires `get-keys' privilege
>>
>> Kadmind logs the error:
>>
>> Jun 26 11:11:08 kdc1 kadmind[10116]: connection from IPv4:<ip>
>> Jun 26 11:11:10 kdc1 kadmind[10564]: <myaccount>/admin@<MYREALM>: GET
>> principal@<MYREALM>
>> Jun 26 11:11:10 kdc1 kadmind[10564]: GET: Operation requires `get-keys'
>> privilege
>>
>> That does not change even when explicitly listing all rights:
>>
>> [kdc1] /root # cat /var/heimdal/kadmind.acl
>> <myaccount>/admin@<MYREALM> cpw list delete modify add get get-keys
>>
>> It works using 'kadmin -l ext -k /root/keytab <principal>', though. Other
>> commands like get, cpw, etc. work correctly.
>>
>> Is this a known issue? Any idea for a workaround?
>>
>> Thanks,
>> Andreas
> --
> | Andreas Haupt            | E-Mail: [hidden email]
> |  DESY Zeuthen            | WWW:    http://www-zeuthen.desy.de/~ahaupt
> |  Platanenallee 6         | Phone:  +49/33762/7-7359
> |  D-15738 Zeuthen         | Fax:    +49/33762/7-7216
>
>

Personal email.  [hidden email]



Reply | Threaded
Open this post in threaded view
|

Re: Heimdal 7.3: ext_keytab fails with "Operation requires `get-keys' privilege"

Nico Williams
In reply to this post by Andreas Haupt-2
On Mon, Jun 26, 2017 at 11:18:28AM +0200, Andreas Haupt wrote:
> Heimdal 7.3 seems to suffer from a bug in privilege checking. A prinicipal
> having all rights on the database is unable to extract keytabs:

This is on purpose.

We decided that it was never a good idea for "all" to have meant
"extract keys", because in general that's not desirable.

Instead you should either use ext_keytab -r, or add the get-keys
privilege to whoever needs it.

> That does not change even when explicitly listing all rights:
>
> [kdc1] /root # cat /var/heimdal/kadmind.acl 
> <myaccount>/admin@<MYREALM> cpw list delete modify add get get-keys

That would be a bug.  I'll see if I can reproduce it.

Nico
--
Reply | Threaded
Open this post in threaded view
|

Re: Heimdal 7.3: ext_keytab fails with "Operation requires `get-keys' privilege"

Henry B Hotz

> On Jun 27, 2017, at 4:23 PM, Nico Williams <[hidden email]> wrote:
>
> We decided that it was never a good idea for "all" to have meant
> "extract keys", because in general that's not desirable.

How is extracting keys different from extracting a keytab (with the keys inside it)?

Personal email.  [hidden email]



Reply | Threaded
Open this post in threaded view
|

Re: Heimdal 7.3: ext_keytab fails with "Operation requires `get-keys' privilege"

Jeffrey Hutzelman
On Tue, 2017-06-27 at 16:42 -0700, Henry B (Hank) Hotz, CISSP wrote:
> >
> > On Jun 27, 2017, at 4:23 PM, Nico Williams <[hidden email]>
> > wrote:
> >
> > We decided that it was never a good idea for "all" to have meant
> > "extract keys", because in general that's not desirable.
> How is extracting keys different from extracting a keytab (with the
> keys inside it)?


ext_keytab is poorly-named. In MIT Kerberos, it doesn't actually
extract anything; it generates a new key with a new kvno and stores it
in both the keytab and the kdb. MIT kadmind, going back as far as krb4,
didn't even have an operation to fetch existing keys from the database;
that was considered an exceptionally dangerous ability and not really
necessary.

Heimdal initially took a different approach, which is still what
ext_keytab does by default, for backward compatibility and to avoid
unpleasantly-surprising results. With -r, it randomizes the key
instead, which is safer. Note that ext_keytab without -r will not work
if you don't have the get-keys privilege.

I have patches going back as far as Heimdal 0.6 which make get-keys a
separate privilege not included in 'all'. I didn't write the change
that eventually made it into Heimdal, but I certainly agree with it.


-- Jeff
Reply | Threaded
Open this post in threaded view
|

Re: Heimdal 7.3: ext_keytab fails with "Operation requires `get-keys' privilege"

Russ Allbery-2
Jeffrey Hutzelman <[hidden email]> writes:

> ext_keytab is poorly-named. In MIT Kerberos, it doesn't actually extract
> anything; it generates a new key with a new kvno and stores it in both
> the keytab and the kdb. MIT kadmind, going back as far as krb4, didn't
> even have an operation to fetch existing keys from the database; that
> was considered an exceptionally dangerous ability and not really
> necessary.

> Heimdal initially took a different approach, which is still what
> ext_keytab does by default, for backward compatibility and to avoid
> unpleasantly-surprising results. With -r, it randomizes the key instead,
> which is safer. Note that ext_keytab without -r will not work if you
> don't have the get-keys privilege.

> I have patches going back as far as Heimdal 0.6 which make get-keys a
> separate privilege not included in 'all'. I didn't write the change that
> eventually made it into Heimdal, but I certainly agree with it.

+1.  I was one of the people who asked for this.  Extracting the key
without changing it opens some nasty attack paths where an attacker can
silently get a copy of the key currently in use and use that to snoop on
traffic and forge sessions.

If the attacker has to invalidate the old key in order to download new
keys, the detection story is much better and the attacker is a bit more
limited in what they can immediately do.

--
Russ Allbery ([hidden email])              <http://www.eyrie.org/~eagle/>
Reply | Threaded
Open this post in threaded view
|

Re: Heimdal 7.3: ext_keytab fails with "Operation requires `get-keys' privilege"

Nico Williams
On Tue, Jun 27, 2017 at 05:44:25PM -0700, Russ Allbery wrote:

> Jeffrey Hutzelman <[hidden email]> writes:
> > ext_keytab is poorly-named. In MIT Kerberos, it doesn't actually extract
> > anything; it generates a new key with a new kvno and stores it in both
> > the keytab and the kdb. MIT kadmind, going back as far as krb4, didn't
> > even have an operation to fetch existing keys from the database; that
> > was considered an exceptionally dangerous ability and not really
> > necessary.
>
> > Heimdal initially took a different approach, which is still what
> > ext_keytab does by default, for backward compatibility and to avoid
> > unpleasantly-surprising results. With -r, it randomizes the key instead,
> > which is safer. Note that ext_keytab without -r will not work if you
> > don't have the get-keys privilege.
>
> > I have patches going back as far as Heimdal 0.6 which make get-keys a
> > separate privilege not included in 'all'. I didn't write the change that
> > eventually made it into Heimdal, but I certainly agree with it.
>
> +1.  I was one of the people who asked for this.  Extracting the key
> without changing it opens some nasty attack paths where an attacker can
> silently get a copy of the key currently in use and use that to snoop on
> traffic and forge sessions.
>
> If the attacker has to invalidate the old key in order to download new
> keys, the detection story is much better and the attacker is a bit more
> limited in what they can immediately do.

+1.

In many environments an admin can collate a copy of the KDB by just
visiting every host and hoovering up their keytabs.  But they won't get
expunged old keys that way.

We do need better key mgmt support though.  It'd nice to have automatic
rekeying and expunging of keys too old to be needed for decrypting
extant live tickets.

Some such software exists, such as Roland Dowdeswell's krb5_admin suite
(which does fantastic things, like using multi-party ECDH to atomically
agree on and install keys for clusters).  But it'd be nice if Heimdal
had better support like that builtin.

We've made some progress in that direction, and the get-keys privilege
is one step in that direction.

The get-keys privilege is not a lot of pain for sites given that
ext_keytab will tell you what's up and there's a way to put things the
way they were if you need to.

I might be up for enhancing ext_keytab's error message to also mention
the -r option.  But that's it.

We will not revisit the get-keys change, except, if anything, to someday
remove that and the original ext_keytab functionality!

Nico
--
Reply | Threaded
Open this post in threaded view
|

Re: Heimdal 7.3: ext_keytab fails with "Operation requires `get-keys' privilege"

Russ Allbery-2
Nico Williams <[hidden email]> writes:

> We do need better key mgmt support though.  It'd nice to have automatic
> rekeying and expunging of keys too old to be needed for decrypting
> extant live tickets.

Yes, please, or I will inflict my hideous shell script on you that does
this (using wallet).

--
Russ Allbery ([hidden email])              <http://www.eyrie.org/~eagle/>
Reply | Threaded
Open this post in threaded view
|

Re: Heimdal 7.3: ext_keytab fails with "Operation requires `get-keys' privilege"

Lars-Johan Liman-2
In reply to this post by Nico Williams
All (pun intended!),

On Mon, Jun 26, 2017 at 11:18:28AM +0200, Andreas Haupt wrote:
>> Heimdal 7.3 seems to suffer from a bug in privilege checking. A prinicipal
>> having all rights on the database is unable to extract keytabs:

[hidden email]:
> This is on purpose.

> We decided that it was never a good idea for "all" to have meant
> "extract keys", because in general that's not desirable.

I very seldom raise my voice on this mailing list, but here I must, on
sheer principal grounds.

Chosen names must have obvious meanings. To have a status called "all"
which isn't *ALL* is confusing at best. It will confuse the h-ll out of
sysadmins over the globe for years to come, wasting time and money for
no good purpose at all. I would have spent hours upon hours not
understanding what the problem was, had I run into this trap.

The "keep it simple" principle and the principle of least surprise are
two fundamental principles for successful system management.

Please fix this, either by changing the name "all" to "most" (or
preferrably to somthing better), or by changing the behaviour to be
*ALL*. Either is fine, but having "all" not mean *ALL* is not a good way
forward.

                                Best regards,
                                  /Lars-Johan Liman
#----------------------------------------------------------------------
# Lars-Johan Liman, M.Sc.               !  E-mail: [hidden email]
# Senior Systems Specialist             !  Tel: +46 8 - 562 860 12
# Netnod Internet Exchange, Stockholm   !  http://www.netnod.se/
#----------------------------------------------------------------------
Reply | Threaded
Open this post in threaded view
|

Re: Heimdal 7.3: ext_keytab fails with "Operation requires `get-keys' privilege"

Nico Williams
In reply to this post by Russ Allbery-2
On Tue, Jun 27, 2017 at 10:17:40PM -0700, Russ Allbery wrote:
> Nico Williams <[hidden email]> writes:
>
> > We do need better key mgmt support though.  It'd nice to have automatic
> > rekeying and expunging of keys too old to be needed for decrypting
> > extant live tickets.
>
> Yes, please, or I will inflict my hideous shell script on you that does
> this (using wallet).

Us maintainers mostly don't depend on Heimdal doing this, so there's
relatively little incentive for us to add it :(

If I had to the time for this I'd spend it on other things I want to do
in Heimdal.  Completely revamping the GSS mechglue is high on my list.
Reply | Threaded
Open this post in threaded view
|

Re: Heimdal 7.3: ext_keytab fails with "Operation requires `get-keys' privilege"

Nico Williams
In reply to this post by Lars-Johan Liman-2
On Wed, Jun 28, 2017 at 07:28:59AM +0200, Lars-Johan Liman wrote:

> All (pun intended!),
>
> On Mon, Jun 26, 2017 at 11:18:28AM +0200, Andreas Haupt wrote:
> >> Heimdal 7.3 seems to suffer from a bug in privilege checking. A prinicipal
> >> having all rights on the database is unable to extract keytabs:
>
> [hidden email]:
> > This is on purpose.
>
> > We decided that it was never a good idea for "all" to have meant
> > "extract keys", because in general that's not desirable.
>
> I very seldom raise my voice on this mailing list, but here I must, on
> sheer principal grounds.

I hope you feel welcomed.  Please speak up more often!

> Chosen names must have obvious meanings. To have a status called "all"
> which isn't *ALL* is confusing at best. It will confuse the h-ll out of
> sysadmins over the globe for years to come, wasting time and money for
> no good purpose at all. I would have spent hours upon hours not
> understanding what the problem was, had I run into this trap.
>
> The "keep it simple" principle and the principle of least surprise are
> two fundamental principles for successful system management.
>
> Please fix this, either by changing the name "all" to "most" (or
> preferrably to somthing better), or by changing the behaviour to be
> *ALL*. Either is fine, but having "all" not mean *ALL* is not a good way
> forward.

Renaming "all" to "most" would have been a backwards-incompatible change
too.  We chose a different backwards-incompatible change.

Changing the meaning of "all" was a backwards-incompatible change that
we WANTED to make because the previous situation was... not good!  By
making this change we're confronting sites with the underlying problem
that allowing extraction keys from the HDB is NOT a good thing, and
we're letting them choose how to move past this (they have two options).

Since there is a trivial way to get "all" + "get-keys", this change,
though backwards-incompatible, is of rather limited impact.  It is true
that switching to "ext_keytab -r", which is what we want sites to do, is
more difficult and requires careful consideration by them, but again,
you can get the old "all" by granting your admins "all" + "get-keys", so
you're not forced to use "ext_keytab -r".

In general, backwards-compatibility is a high priority.  But security is
a higher priority.  In general, we might remove interfaces and important
behaviors, but we won't break them.  If some interface in Heimdal is
insecure, and no backwards-compatible change can make it secure, then
we're just going to make a backwards-incompatible change.

All in all, we considered this carefully.  It's been discussed
extensively now, and we will make no further changes in this area other
than to improve the error message that users get.  I'm not being
flippant here, and I'm not ignoring your input.  We appreciate that this
change was surprising and caused some pain and we appreciate your input,
and if we reject your proposal in this case, please understand that it's
only after careful consideration.

Nico
--
Reply | Threaded
Open this post in threaded view
|

Re: Heimdal 7.3: ext_keytab fails with "Operation requires `get-keys' privilege"

Jeffrey Altman-2
In reply to this post by Russ Allbery-2
On 6/28/2017 1:17 AM, Russ Allbery wrote:
> Nico Williams <[hidden email]> writes:
>
>> We do need better key mgmt support though.  It'd nice to have automatic
>> rekeying and expunging of keys too old to be needed for decrypting
>> extant live tickets.
>
> Yes, please, or I will inflict my hideous shell script on you that does
> this (using wallet).

I would be interested in hearing from the participants of this list
whether or not it would be appropriate to ship some of the Secure
Endpoints open source kerberos tooling as part of Heimdal:

 http://oskt.secure-endpoints.com/

In particular, Roland's krb5_admin, krb5_keytab, and the C variant of KNC.

Jeffrey Altman





smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Heimdal 7.3: ext_keytab fails with "Operation requires `get-keys' privilege"

Fredrik Pettai-2
On 28 Jun 2017, at 17:48, Jeffrey Altman <[hidden email]> wrote:

>
> On 6/28/2017 1:17 AM, Russ Allbery wrote:
>> Nico Williams <[hidden email]> writes:
>>
>>> We do need better key mgmt support though.  It'd nice to have automatic
>>> rekeying and expunging of keys too old to be needed for decrypting
>>> extant live tickets.
>>
>> Yes, please, or I will inflict my hideous shell script on you that does
>> this (using wallet).
>
> I would be interested in hearing from the participants of this list
> whether or not it would be appropriate to ship some of the Secure
> Endpoints open source kerberos tooling as part of Heimdal:
>
> http://oskt.secure-endpoints.com/
>
> In particular, Roland's krb5_admin, krb5_keytab, and the C variant of KNC.

I’d like to see k5ping added to that list too :)  
(http://oskt.secure-endpoints.com/k5ping.html)

/P

Reply | Threaded
Open this post in threaded view
|

Re: Heimdal 7.3: ext_keytab fails with "Operation requires `get-keys' privilege"

Nico Williams
In reply to this post by Nico Williams
On Wed, Jun 28, 2017 at 12:08:31AM -0500, Nico Williams wrote:
> We do need better key mgmt support though.  It'd nice to have automatic
> rekeying and expunging of keys too old to be needed for decrypting
> extant live tickets.

Viktor points out that we do have server-side (in libkadm5, thus
kadmind) support for optional automatic expunging old keys in
kadm5_setkey_principal_3().  We have it for krb5_admin/krb5_keytab :)

We want to add client-side support as well.

We also need client-side support for automatic keytab entry expunge as
well.

Nico
--
Reply | Threaded
Open this post in threaded view
|

Re: Heimdal 7.3: ext_keytab fails with "Operation requires `get-keys' privilege"

Chaskiel Grundman-2
I have a toolset deployed at Carnegie Mellon that attempts to address some of these problems (automatic rekeying of services and purging of old keys from keytabs). 

The protocol is probably too cute and non-standard for people to want to use, and there isn't nearly enough documentation, but if there's interest, I might be able to work on changes to make it more useful.
Reply | Threaded
Open this post in threaded view
|

Re: Heimdal 7.3: ext_keytab fails with "Operation requires `get-keys' privilege"

Henry B Hotz
In reply to this post by Nico Williams

> On Jun 28, 2017, at 8:11 AM, Nico Williams <[hidden email]> wrote:
>
> On Wed, Jun 28, 2017 at 07:28:59AM +0200, Lars-Johan Liman wrote:
>> All (pun intended!),
>>
>> On Mon, Jun 26, 2017 at 11:18:28AM +0200, Andreas Haupt wrote:
>>>> Heimdal 7.3 seems to suffer from a bug in privilege checking. A prinicipal
>>>> having all rights on the database is unable to extract keytabs:
>>
>> [hidden email]:
>>> This is on purpose.
>>
>>> We decided that it was never a good idea for "all" to have meant
>>> "extract keys", because in general that's not desirable.
>>
>> I very seldom raise my voice on this mailing list, but here I must, on
>> sheer principal grounds.
>
> I hope you feel welcomed.  Please speak up more often!
>
>> Chosen names must have obvious meanings. To have a status called "all"
>> which isn't *ALL* is confusing at best. It will confuse the h-ll out of
>> sysadmins over the globe for years to come, wasting time and money for
>> no good purpose at all. I would have spent hours upon hours not
>> understanding what the problem was, had I run into this trap.
>>
>> The "keep it simple" principle and the principle of least surprise are
>> two fundamental principles for successful system management.
>>
>> Please fix this, either by changing the name "all" to "most" (or
>> preferrably to somthing better), or by changing the behaviour to be
>> *ALL*. Either is fine, but having "all" not mean *ALL* is not a good way
>> forward.

I absolutely agree with everything you said. I think it very to make unwise to make a backwards-incompatible change in order to turn the permissions description from plain english into a Heimdal-unique code.

I’ll repeat my recommendation that we do what Love suggested.

> Renaming "all" to "most" would have been a backwards-incompatible change
> too.  We chose a different backwards-incompatible change.
>
> Changing the meaning of "all" was a backwards-incompatible change that
> we WANTED to make because the previous situation was... not good!  By
> making this change we're confronting sites with the underlying problem
> that allowing extraction keys from the HDB is NOT a good thing, and
> we're letting them choose how to move past this (they have two options).
>
> Since there is a trivial way to get "all" + "get-keys", this change,
> though backwards-incompatible, is of rather limited impact.  

Disagree.  I think you are looking at the wrong impact when you make that judgement. Making “all” mean something other than “all” creates a *permanent* source of confusion.

> It is true
> that switching to "ext_keytab -r", which is what we want sites to do, is
> more difficult and requires careful consideration by them, but again,
> you can get the old "all" by granting your admins "all" + "get-keys", so
> you're not forced to use "ext_keytab -r”.

How about putting the recommended change (to ...-r) in the permissions error for ext_keytab?

> In general, backwards-compatibility is a high priority.  But security is
> a higher priority.  In general, we might remove interfaces and important
> behaviors, but we won't break them.  If some interface in Heimdal is
> insecure, and no backwards-compatible change can make it secure, then
> we're just going to make a backwards-incompatible change.
>
> All in all, we considered this carefully.  It's been discussed
> extensively now, and we will make no further changes in this area other
> than to improve the error message that users get.  I'm not being
> flippant here, and I'm not ignoring your input.  We appreciate that this
> change was surprising and caused some pain and we appreciate your input,
> and if we reject your proposal in this case, please understand that it's
> only after careful consideration.

The point is that you have made the pain, or at least the confusion, permanent by making the language mean something other than what it says. That does not seem well considered, and I think the amount of flack you’re getting reflects that.

If you’re really going to be that hard-nosed about it, then you had better put a hell of a lot of warning messages and explanations all over the place. Better yet, just do away with any ability to extract (current) keys altogether. Make the -r option the only thing possible unless you build with some configure option like --enable-insecure-key-extraction. Then you can phase it out over a couple of revisions, like we did with single-DES.

Honestly, is it really that big a deal to change “all” to e.g. “admin”? If you’re going to make a fundamental semantic change, you shouldn’t hide the fact. You should make it as obvious as you possibly can.

> Nico
> --

Personal email.  [hidden email]



Reply | Threaded
Open this post in threaded view
|

Re: Heimdal 7.3: ext_keytab fails with "Operation requires `get-keys' privilege"

Nico Williams
On Thu, Jun 29, 2017 at 11:41:41AM -0700, Henry B (Hank) Hotz, CISSP wrote:

> > On Jun 28, 2017, at 8:11 AM, Nico Williams <[hidden email]> wrote:
> > On Wed, Jun 28, 2017 at 07:28:59AM +0200, Lars-Johan Liman wrote:
> >> Please fix this, either by changing the name "all" to "most" (or
> >> preferrably to somthing better), or by changing the behaviour to be
> >> *ALL*. Either is fine, but having "all" not mean *ALL* is not a good way
> >> forward.
>
> I absolutely agree with everything you said. I think it very to make
> unwise to make a backwards-incompatible change in order to turn the
> permissions description from plain english into a Heimdal-unique code.

We want get-keys to go away.  When it does, "all" will mean "all".

> I’ll repeat my recommendation that we do what Love suggested.

Link?  Quote?

> > It is true
> > that switching to "ext_keytab -r", which is what we want sites to do, is
> > more difficult and requires careful consideration by them, but again,
> > you can get the old "all" by granting your admins "all" + "get-keys", so
> > you're not forced to use "ext_keytab -r”.
>
> How about putting the recommended change (to ...-r) in the permissions
> error for ext_keytab?

I've said I'm amenable to that.  I do want admins to understand what
that means though.  Doing that on a cluster could cause an outage.  So
such an error message improvement will need to be crafted carefully.

> The point is that you have made the pain, or at least the confusion,
> permanent by making the language mean something other than what it
> says. That does not seem well considered, and I think the amount of
> flack you’re getting reflects that.

It's one-time on upgrade per-site.

It was security vs backwards-compatibility.  Security won.

> If you’re really going to be that hard-nosed about it, then you had
> better put a hell of a lot of warning messages and explanations all
> over the place. Better yet, just do away with any ability to extract
> (current) keys altogether. Make the -r option the only thing possible
> unless you build with some configure option like
> --enable-insecure-key-extraction. Then you can phase it out over a
> couple of revisions, like we did with single-DES.

That wouldn't allow you to narrow key extraction permission slowly until
you no longer need it.

> Honestly, is it really that big a deal to change “all” to e.g.
> “admin”? If you’re going to make a fundamental semantic change, you
> shouldn’t hide the fact. You should make it as obvious as you possibly
> can.

That would not have had the desired effect of confronting sites with the
insecurity of extracting keys.  We can't force them to stop depending on
that in one fell swoop.

You're over-thinking this and making a mountain out of a molehill.  My
advice is to accept the change that took place -- we don't have a time
machine and we will not call this a bug -- and move on to something more
productive.

I'm thinking about what the UI should look like for automatic key
expunge, for example.  I'm thinking about how to integrate krb5_admin/
krb5_keytab into Heimdal, or some of their functionality into kadmin/
kadmind/libkadm5.  Thoughts on that?  Please use a new thread.

Nico
--
Reply | Threaded
Open this post in threaded view
|

Re: Heimdal 7.3: ext_keytab fails with "Operation requires `get-keys' privilege"

Henry B Hotz

> On Jun 29, 2017, at 12:45 PM, Nico Williams <[hidden email]> wrote:
>
> On Thu, Jun 29, 2017 at 11:41:41AM -0700, Henry B (Hank) Hotz, CISSP wrote:
>>> On Jun 28, 2017, at 8:11 AM, Nico Williams <[hidden email]> wrote:
>>> On Wed, Jun 28, 2017 at 07:28:59AM +0200, Lars-Johan Liman wrote:
>>>> Please fix this, either by changing the name "all" to "most" (or
>>>> preferrably to somthing better), or by changing the behaviour to be
>>>> *ALL*. Either is fine, but having "all" not mean *ALL* is not a good way
>>>> forward.
>>
>> I absolutely agree with everything you said. I think it very to make
>> unwise to make a backwards-incompatible change in order to turn the
>> permissions description from plain english into a Heimdal-unique code.
>
> We want get-keys to go away.  When it does, "all" will mean "all”.

If we’re really only arguing about a transient situation, then I can relax a bit.

>> I’ll repeat my recommendation that we do what Love suggested.
>
> Link?  Quote?

It’s from the year-ago discussion that someone (you?) provided a link for. I think it’s the only thing he’s said on the subject.

>>> It is true
>>> that switching to "ext_keytab -r", which is what we want sites to do, is
>>> more difficult and requires careful consideration by them, but again,
>>> you can get the old "all" by granting your admins "all" + "get-keys", so
>>> you're not forced to use "ext_keytab -r”.
>>
>> How about putting the recommended change (to ...-r) in the permissions
>> error for ext_keytab?
>
> I've said I'm amenable to that.  I do want admins to understand what
> that means though.  Doing that on a cluster could cause an outage.  So
> such an error message improvement will need to be crafted carefully.
>
>> The point is that you have made the pain, or at least the confusion,
>> permanent by making the language mean something other than what it
>> says. That does not seem well considered, and I think the amount of
>> flack you’re getting reflects that.
>
> It's one-time on upgrade per-site.
>
> It was security vs backwards-compatibility.  Security won.
>
>> If you’re really going to be that hard-nosed about it, then you had
>> better put a hell of a lot of warning messages and explanations all
>> over the place. Better yet, just do away with any ability to extract
>> (current) keys altogether. Make the -r option the only thing possible
>> unless you build with some configure option like
>> --enable-insecure-key-extraction. Then you can phase it out over a
>> couple of revisions, like we did with single-DES.
>
> That wouldn't allow you to narrow key extraction permission slowly until
> you no longer need it.
>
>> Honestly, is it really that big a deal to change “all” to e.g.
>> “admin”? If you’re going to make a fundamental semantic change, you
>> shouldn’t hide the fact. You should make it as obvious as you possibly
>> can.

What I had in mind was more like require that option do what you’re now doing. (Now that I’m convinced the Microsoft/MIT behavior is the right one.) Without it

> That would not have had the desired effect of confronting sites with the
> insecurity of extracting keys.  We can't force them to stop depending on
> that in one fell swoop.

If you create, then require, then eventually eliminate the option, you can announce that plan as part of the release notes/announcements. Everyone is confronted with it at build time, and everyone is told what to expect, and when you will do it.

> You're over-thinking this and making a mountain out of a molehill.  My
> advice is to accept the change that took place -- we don't have a time
> machine and we will not call this a bug -- and move on to something more
> productive.
>
> I'm thinking about what the UI should look like for automatic key
> expunge, for example.  I'm thinking about how to integrate krb5_admin/
> krb5_keytab into Heimdal, or some of their functionality into kadmin/
> kadmind/libkadm5.  Thoughts on that?  Please use a new thread.

Yes, it seems everyone agrees that better handling of service key rotation would be good.

> Nico
> --

Personal email.  [hidden email]



Reply | Threaded
Open this post in threaded view
|

Re: Heimdal 7.3: ext_keytab fails with "Operation requires `get-keys' privilege" (Corrected)

Henry B Hotz
In reply to this post by Nico Williams

> On Jun 29, 2017, at 12:45 PM, Nico Williams <[hidden email]> wrote:
>
> On Thu, Jun 29, 2017 at 11:41:41AM -0700, Henry B (Hank) Hotz, CISSP wrote:
>>> On Jun 28, 2017, at 8:11 AM, Nico Williams <[hidden email]> wrote:
>>> On Wed, Jun 28, 2017 at 07:28:59AM +0200, Lars-Johan Liman wrote:
>>>> Please fix this, either by changing the name "all" to "most" (or
>>>> preferrably to somthing better), or by changing the behaviour to be
>>>> *ALL*. Either is fine, but having "all" not mean *ALL* is not a good way
>>>> forward.
>>
>> I absolutely agree with everything you said. I think it very to make
>> unwise to make a backwards-incompatible change in order to turn the
>> permissions description from plain english into a Heimdal-unique code.
>
> We want get-keys to go away.  When it does, "all" will mean "all”.

If we’re really only arguing about a transient situation, then I can relax a bit.

>> I’ll repeat my recommendation that we do what Love suggested.
>
> Link?  Quote?

It’s from the year-ago discussion that someone (you?) provided a link for. I think it’s the only thing he’s said on the subject.

>>> It is true
>>> that switching to "ext_keytab -r", which is what we want sites to do, is
>>> more difficult and requires careful consideration by them, but again,
>>> you can get the old "all" by granting your admins "all" + "get-keys", so
>>> you're not forced to use "ext_keytab -r”.
>>
>> How about putting the recommended change (to ...-r) in the permissions
>> error for ext_keytab?
>
> I've said I'm amenable to that.  I do want admins to understand what
> that means though.  Doing that on a cluster could cause an outage.  So
> such an error message improvement will need to be crafted carefully.
>
>> The point is that you have made the pain, or at least the confusion,
>> permanent by making the language mean something other than what it
>> says. That does not seem well considered, and I think the amount of
>> flack you’re getting reflects that.
>
> It's one-time on upgrade per-site.
>
> It was security vs backwards-compatibility.  Security won.
>
>> If you’re really going to be that hard-nosed about it, then you had
>> better put a hell of a lot of warning messages and explanations all
>> over the place. Better yet, just do away with any ability to extract
>> (current) keys altogether. Make the -r option the only thing possible
>> unless you build with some configure option like
>> --enable-insecure-key-extraction. Then you can phase it out over a
>> couple of revisions, like we did with single-DES.
>
> That wouldn't allow you to narrow key extraction permission slowly until
> you no longer need it.
>
>> Honestly, is it really that big a deal to change “all” to e.g.
>> “admin”? If you’re going to make a fundamental semantic change, you
>> shouldn’t hide the fact. You should make it as obvious as you possibly
>> can.

What I had in mind was more like: require that option to do what you’re now doing. (I’m now convinced that the Microsoft/MIT behavior is the right one. It’s as close as Kerberos gets to PFS.)

> That would not have had the desired effect of confronting sites with the
> insecurity of extracting keys.  We can't force them to stop depending on
> that in one fell swoop.

If you create, then require, then eventually eliminate the option, you can announce that plan as part of the release notes/announcements. Everyone is confronted with it at build time, and everyone is told what to expect, and when you will do it.

> You're over-thinking this and making a mountain out of a molehill.  My
> advice is to accept the change that took place -- we don't have a time
> machine and we will not call this a bug -- and move on to something more
> productive.
>
> I'm thinking about what the UI should look like for automatic key
> expunge, for example.  I'm thinking about how to integrate krb5_admin/
> krb5_keytab into Heimdal, or some of their functionality into kadmin/
> kadmind/libkadm5.  Thoughts on that?  Please use a new thread.

Yes, it seems everyone agrees that better handling of service key rotation would be good. I’ll start such a thread in a bit if nobody else does.

> Nico
> --

Personal email.  [hidden email]



12