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

[Lars-Johan Liman]

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:

n...@cryptonector.com:
> 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: li...@netnod.se
# Senior Systems Specialist !  Tel: +46 8 - 562 860 12
# Netnod Internet Exchange, Stockholm   !  http://www.netnod.se/
#--

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

[Russ Allbery]

Nico Williams  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 (ea...@eyrie.org)  

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  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
-- 

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

[Russ Allbery]

Jeffrey Hutzelman  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 (ea...@eyrie.org)  

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 
> > 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

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

[Henry B (Hank) Hotz, CISSP]

> On Jun 27, 2017, at 4:23 PM, Nico Williams  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.  hbh...@oxy.edu

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

[Nico Williams]

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 
> /admin@ cpw list delete modify add get get-keys

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

Nico
-- 

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

[Henry B (Hank) Hotz, CISSP]

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  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
> /admin@ 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 
>> /admin@ all
>> 
>> [chip-vm8] /root # kadmin -p /admin -a kdc1
>> kadmin> ext -k /root/keytab 
>> /admin@'s Password: 
>> kadmin: ext : Operation requires `get-keys' privilege
>> 
>> Kadmind logs the error:
>> 
>> Jun 26 11:11:08 kdc1 kadmind[10116]: connection from IPv4:
>> Jun 26 11:11:10 kdc1 kadmind[10564]: /admin@: GET
>> principal@
>> 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 
>> /admin@ cpw list delete modify add get get-keys
>> 
>> It works using 'kadmin -l ext -k /root/keytab ', 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: andreas.ha...@desy.de
> |  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.  hbh...@oxy.edu