Skip Menu |
 

From: Fabiano Tarlao <ftarlao@gmail.com>
Date: Mon, 13 Nov 2017 11:02:13 +0100
Subject: ksu command doesn't use service ticket in cache file but always re-requests to TGS
To: krb5-bugs@mit.edu
ksu command doesn't use service ticket in the cache file but always re-requests to TGS (or fails when there is no TGT in cache)

The documentation states it should not re-request the service ticket (for end-server) but use the already cached quote:
Show quoted text

Otherwise, ksu looks for an appropriate Kerberos ticket in the source cache. The ticket can either be for the end-server or a ticket granting ticket (TGT) for the target principal’s realm. If the ticket for the end-server is already in the cache, it’s decrypted and verified. If it’s not in the cache but the TGT is, the TGT is used to obtain the ticket for the end-server. The end-server ticket is then verified.

Details about the problem (my experiments and my enviroment) in this (long) serverfault question:

I already asked to but got no solution in the Krb5 mailing lists and no response on serverfault.
Regards
Fabiano
Download (untitled) / with headers
text/plain 1.1KiB
Thanks for the bug report, and apologies for not having time to look
into this last week.

It looks like ksu's behavior changed in release 1.13 as a result of
this pull request:

https://github.com/krb5/krb5/pull/170

although it may have been partially broken since referrals support
was introduced in release 1.6. Pull request 170 was motivated by a
bug caused by the referrals changes. At that time, we didn't realize
that the fix we arrived at (simplifying the ksu code) created a
mismatch with the documented behavior.

I can see several possible remedies here:

1. Change the documentation to match the code (talk only about using
a cached TGT).

2. Restore the documented behavior, but only make it work if the
canonicalized local hostname matches the host principal in the ccache
service ticket and the system keytab.

3. Restore the documented behavior, and make it work for any host
principal in the system keytab.

The serverfault post contains a lot of detail about the test case,
but doesn't explain why the documented behavior is important in this
use case. Is there a reason why it's not sufficient for ksu to look
for a TGT in the ccache and make a TGS request to verify it?
From: Fabiano Tarlao <ftarlao@gmail.com>
Date: Tue, 14 Nov 2017 00:31:15 +0100
Subject: Re: [krbdev.mit.edu #8619] ksu command doesn't use service ticket in cache file but always re-requests to TGS
To: rt-comment@krbdev.mit.edu, rt@krbdev.mit.edu
RT-Send-Cc:
Download (untitled) / with headers
text/plain 2.5KiB
Hi,
thank you for looking into this issue.
From my point of view there are two main reasons to restore the documented ksu behaviour:
1) to not perform useless requests to TGS/DC, to spare resources; performing the TGS requests also raises the ksu execution latency..
2) from a security standpoint, to reduce the potential "attack surface"; this point is far more important to us, let me elaborate a bit:

A potential attacker may, in a limited time window, have the opportunity to stole the cached krb tickets. One TGT permits the attacker to impersonate the user for all resources/services in the domain; a service ticket (not forwardable) limits the attacker to impersonate the user only on the current host/service.

Taking this into account.. in order to use ksu.. we would like to populate the Krb cachefile only with the end-server service ticket (the cachefile should not contain a TGT).
At the moment we populate the cachefile in this way thanks to the kinit command with the -S option.
kinit permits to request an "initial" service ticket (In the future we will try to implement a way to populate a cache file with a service ticket acquired thanks to a TGT--stored in a different safe place--).
Security is a key point of our work, the documented ksu behaviour looked exactly what we need.
Regards
Fabiano
 

On 13 November 2017 at 23:21, Greg Hudson via RT <rt-comment@krbdev.mit.edu> wrote:
Show quoted text
Thanks for the bug report, and apologies for not having time to look
into this last week.

It looks like ksu's behavior changed in release 1.13 as a result of
this pull request:

https://github.com/krb5/krb5/pull/170

although it may have been partially broken since referrals support
was introduced in release 1.6.  Pull request 170 was motivated by a
bug caused by the referrals changes.  At that time, we didn't realize
that the fix we arrived at (simplifying the ksu code) created a
mismatch with the documented behavior.

I can see several possible remedies here:

1. Change the documentation to match the code (talk only about using
a cached TGT).

2. Restore the documented behavior, but only make it work if the
canonicalized local hostname matches the host principal in the ccache
service ticket and the system keytab.

3. Restore the documented behavior, and make it work for any host
principal in the system keytab.

The serverfault post contains a lot of detail about the test case,
but doesn't explain why the documented behavior is important in this
use case.  Is there a reason why it's not sufficient for ksu to look
for a TGT in the ccache and make a TGS request to verify it?

From: Fabiano Tarlao <ftarlao@gmail.com>
Date: Tue, 14 Nov 2017 00:31:15 +0100
Subject: Re: [krbdev.mit.edu #8619] ksu command doesn't use service ticket in cache file but always re-requests to TGS
To: rt-comment@krbdev.mit.edu, rt@krbdev.mit.edu
RT-Send-Cc:
Download (untitled) / with headers
text/plain 2.5KiB
Hi,
thank you for looking into this issue.
From my point of view there are two main reasons to restore the documented ksu behaviour:
1) to not perform useless requests to TGS/DC, to spare resources; performing the TGS requests also raises the ksu execution latency..
2) from a security standpoint, to reduce the potential "attack surface"; this point is far more important to us, let me elaborate a bit:

A potential attacker may, in a limited time window, have the opportunity to stole the cached krb tickets. One TGT permits the attacker to impersonate the user for all resources/services in the domain; a service ticket (not forwardable) limits the attacker to impersonate the user only on the current host/service.

Taking this into account.. in order to use ksu.. we would like to populate the Krb cachefile only with the end-server service ticket (the cachefile should not contain a TGT).
At the moment we populate the cachefile in this way thanks to the kinit command with the -S option.
kinit permits to request an "initial" service ticket (In the future we will try to implement a way to populate a cache file with a service ticket acquired thanks to a TGT--stored in a different safe place--).
Security is a key point of our work, the documented ksu behaviour looked exactly what we need.
Regards
Fabiano
 

On 13 November 2017 at 23:21, Greg Hudson via RT <rt-comment@krbdev.mit.edu> wrote:
Show quoted text
Thanks for the bug report, and apologies for not having time to look
into this last week.

It looks like ksu's behavior changed in release 1.13 as a result of
this pull request:

https://github.com/krb5/krb5/pull/170

although it may have been partially broken since referrals support
was introduced in release 1.6.  Pull request 170 was motivated by a
bug caused by the referrals changes.  At that time, we didn't realize
that the fix we arrived at (simplifying the ksu code) created a
mismatch with the documented behavior.

I can see several possible remedies here:

1. Change the documentation to match the code (talk only about using
a cached TGT).

2. Restore the documented behavior, but only make it work if the
canonicalized local hostname matches the host principal in the ccache
service ticket and the system keytab.

3. Restore the documented behavior, and make it work for any host
principal in the system keytab.

The serverfault post contains a lot of detail about the test case,
but doesn't explain why the documented behavior is important in this
use case.  Is there a reason why it's not sufficient for ksu to look
for a TGT in the ccache and make a TGS request to verify it?

From: Fabiano Tarlao <ftarlao@gmail.com>
Date: Tue, 21 Nov 2017 21:48:56 +0100
Subject: Re: [krbdev.mit.edu #8619] ksu command doesn't use service ticket in cache file but always re-requests to TGS
To: rt-comment@krbdev.mit.edu, rt@krbdev.mit.edu
RT-Send-Cc:
Download (untitled) / with headers
text/plain 2.9KiB
Hi,
just for the sake of curiosity,
have you taken any decision between changing the code to adhere documentation or changing the documentation?
Regards

I repeat also the previous mail (cause the bug tracker system had problems days ago):

Hi,
thank you for looking into this issue.
From my point of view there are two main reasons to restore the documented ksu behaviour:
1) to not perform useless requests to TGS/DC, to spare resources; performing the TGS requests also raises the ksu execution latency..
2) from a security standpoint, to reduce the potential "attack surface"; this point is far more important to us, let me elaborate a bit:

A potential attacker may, in a limited time window, have the opportunity to stole the cached krb tickets. One TGT permits the attacker to impersonate the user for all resources/services in the domain; a service ticket (not forwardable) limits the attacker to impersonate the user only on the current host/service.

Taking this into account.. in order to use ksu.. we would like to populate the Krb cachefile only with the end-server service ticket (the cachefile should not contain a TGT).
At the moment we populate the cachefile in this way thanks to the kinit command with the -S option.
kinit permits to request an "initial" service ticket (In the future we will try to implement a way to populate a cache file with a service ticket acquired thanks to a TGT--stored in a different safe place--).
Security is a key point of our work, the documented ksu behaviour looked exactly what we need.
Regards
Fabiano

On 14 November 2017 at 00:31, Fabiano Tarlao <ftarlao@gmail.com> wrote:
Show quoted text
 

On 13 November 2017 at 23:21, Greg Hudson via RT <rt-comment@krbdev.mit.edu> wrote:
Thanks for the bug report, and apologies for not having time to look
into this last week.

It looks like ksu's behavior changed in release 1.13 as a result of
this pull request:

https://github.com/krb5/krb5/pull/170

although it may have been partially broken since referrals support
was introduced in release 1.6.  Pull request 170 was motivated by a
bug caused by the referrals changes.  At that time, we didn't realize
that the fix we arrived at (simplifying the ksu code) created a
mismatch with the documented behavior.

I can see several possible remedies here:

1. Change the documentation to match the code (talk only about using
a cached TGT).

2. Restore the documented behavior, but only make it work if the
canonicalized local hostname matches the host principal in the ccache
service ticket and the system keytab.

3. Restore the documented behavior, and make it work for any host
principal in the system keytab.

The serverfault post contains a lot of detail about the test case,
but doesn't explain why the documented behavior is important in this
use case.  Is there a reason why it's not sufficient for ksu to look
for a TGT in the ccache and make a TGS request to verify it?


I can look into changing the code's behavior, but not on any specific
time table. ksu isn't a terribly high priority component for the
project.

From your stated security motivation, it sounds like you are building a
scripted or programmatic system on top of ksu to allow specific
operations to be performed at an escalated privilege level. I don't
think ksu makes a great building block. Without knowing the full
parameters of the system I can't say what would make a better building
block, but perhaps remctl (
https://www.eyrie.org/~eagle/software/remctl/ ) would be better.
From: Fabiano Tarlao <ftarlao@gmail.com>
Date: Tue, 21 Nov 2017 22:35:57 +0100
Subject: Re: [krbdev.mit.edu #8619] ksu command doesn't use service ticket in cache file but always re-requests to TGS
To: rt-comment@krbdev.mit.edu, rt@krbdev.mit.edu
RT-Send-Cc:
Yes, this is our goal, we already have services in execution on each host, for this reason ksu seems to fit well our needs but the fact it needs the TGTs is the only defect.
I have never heard about this remctl, very interesting, I'll check it immediately. Great!
Regards 


On 21 November 2017 at 22:00, Greg Hudson via RT <rt-comment@krbdev.mit.edu> wrote:
Show quoted text
I can look into changing the code's behavior, but not on any specific
time table.  ksu isn't a terribly high priority component for the
project.

From your stated security motivation, it sounds like you are building a
scripted or programmatic system on top of ksu to allow specific
operations to be performed at an escalated privilege level.  I don't
think ksu makes a great building block.  Without knowing the full
parameters of the system I can't say what would make a better building
block, but perhaps remctl (
https://www.eyrie.org/~eagle/software/remctl/ ) would be better.

From: Fabiano Tarlao <ftarlao@gmail.com>
Date: Tue, 21 Nov 2017 22:35:57 +0100
Subject: Re: [krbdev.mit.edu #8619] ksu command doesn't use service ticket in cache file but always re-requests to TGS
To: rt-comment@krbdev.mit.edu, rt@krbdev.mit.edu
RT-Send-Cc:
Yes, this is our goal, we already have services in execution on each host, for this reason ksu seems to fit well our needs but the fact it needs the TGTs is the only defect.
I have never heard about this remctl, very interesting, I'll check it immediately. Great!
Regards 


On 21 November 2017 at 22:00, Greg Hudson via RT <rt-comment@krbdev.mit.edu> wrote:
Show quoted text
I can look into changing the code's behavior, but not on any specific
time table.  ksu isn't a terribly high priority component for the
project.

From your stated security motivation, it sounds like you are building a
scripted or programmatic system on top of ksu to allow specific
operations to be performed at an escalated privilege level.  I don't
think ksu makes a great building block.  Without knowing the full
parameters of the system I can't say what would make a better building
block, but perhaps remctl (
https://www.eyrie.org/~eagle/software/remctl/ ) would be better.