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

Henry B (Hank) Hotz, CISSP hbhotz at oxy.edu
Thu Jun 29 22:27:56 CEST 2017


> On Jun 29, 2017, at 12:45 PM, Nico Williams <nico at cryptonector.com> 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 <nico at cryptonector.com> 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.  hbhotz at oxy.edu





More information about the Heimdal-discuss mailing list