Re: Heimdal 7.3: ext_keytab fails with "Operation requires `get-keys' privilege"
> On Jun 29, 2017, at 1:42 PM, Jeffrey Hutzelman wrote: > > > >>> 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. > > No, only people who build Heimdal are confronted with it at build time. > Most people will use packaged versions, not build their own. Is that why I’m the only one who ever complains about autotools/configure? Does that mean I should consider NetBSD/arm to be a hopeless cause? 8-/ Still think there is value to putting the appropriate notices in the release notes and announcements though. Personal email. hbh...@oxy.edu
Re: Heimdal 7.3: ext_keytab fails with "Operation requires `get-keys' privilege"
> > 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. No, only people who build Heimdal are confronted with it at build time. Most people will use packaged versions, not build their own.
Re: Heimdal 7.3: ext_keytab fails with "Operation requires `get-keys' privilege" (Corrected)
> On Jun 29, 2017, at 12:45 PM, Nico Williams 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 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. hbh...@oxy.edu
Re: Heimdal 7.3: ext_keytab fails with "Operation requires `get-keys' privilege"
> On Jun 29, 2017, at 12:45 PM, Nico Williams 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 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. hbh...@oxy.edu
Re: Heimdal 7.3: ext_keytab fails with "Operation requires `get-keys' privilege"
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 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 --
Re: Heimdal 7.3: ext_keytab fails with "Operation requires `get-keys' privilege"
> On Jun 28, 2017, at 8:11 AM, Nico Williams 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: >> >> 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. > > 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. hbh...@oxy.edu
