RFC rpc.gssd enhancement

RFC rpc.gssd enhancement

[Lukas Hejtmanek]

Hello,

would it be acceptable to add an option for rpc.gssd to use host keytab if
user's kerberos ticket is not available?

Consider the following scenario:
1) machine has NFS mounted /home using kerberos authentication
2) user logs in, sshd creates krb ticket ($HOME/.k5login needs to be world
readable to allow kerberized access, e.g., using kerberos ticket)
3) user stays logged in and krb ticket expires
4) kinit to renew ticket produces strange error because $HOME is not
accessible and a new ticket is not created.

So, I think in this case, I would like to see rpc.gssd uses host keytab while
user's ticket is not available, which maps to nobody/nogroup, but kinit should
succeed. 

Or are there any other options if one is using kerberized homes only?

-- 
Lukáš Hejtmánek

Re: RFC rpc.gssd enhancement

[Steve Dickson]

Hello,

On 11/28/2016 01:37 PM, Lukas Hejtmanek wrote:
> Hello,
> 
> would it be acceptable to add an option for rpc.gssd to use host keytab if
> user's kerberos ticket is not available?
I'm not sure how this would work.

The kernel would do an upcall to the user's
creds but they have expired. Now if this 
new option is set, rpc.gssd would used 
the machine's cred? It seems to me that
would not be too secure.
 
> 
> Consider the following scenario:
> 1) machine has NFS mounted /home using kerberos authentication
> 2) user logs in, sshd creates krb ticket ($HOME/.k5login needs to be world
> readable to allow kerberized access, e.g., using kerberos ticket)
> 3) user stays logged in and krb ticket expires
> 4) kinit to renew ticket produces strange error because $HOME is not
> accessible and a new ticket is not created.
> 
> So, I think in this case, I would like to see rpc.gssd uses host keytab while
> user's ticket is not available, which maps to nobody/nogroup, but kinit should
> succeed.
Who is going the kinits in this scenario?

 
> 
> Or are there any other options if one is using kerberized homes only?
> 
I'm pretty sure sssd will what you are looking for.

steved.

Re: RFC rpc.gssd enhancement

[Lukas Hejtmanek]

Hello,

On Tue, Nov 29, 2016 at 01:37:00PM -0500, Steve Dickson wrote:
> The kernel would do an upcall to the user's
> creds but they have expired. Now if this 
> new option is set, rpc.gssd would used 
> the machine's cred? It seems to me that
> would not be too secure.

maybe it is not considered secure, but it is still more secure to me than
using sec=sys. 

the problem is, that kerberized home is problem for .k5login file and also for
.ssh/authorized_keys. While the .k5login file is accessed with root context
(sshd), the authorized_keys is accessed with user context, so login via ssh
pubkey is not possible at all. 

moreover, consider scenario where a user has symlink from his/her home to NFS
share, without kerberos ticket, logon process can get stucked until he/she has
the ticket. The ticket cannot be created until success logon. 

> > Consider the following scenario:
> > 1) machine has NFS mounted /home using kerberos authentication
> > 2) user logs in, sshd creates krb ticket ($HOME/.k5login needs to be world
> > readable to allow kerberized access, e.g., using kerberos ticket)
> > 3) user stays logged in and krb ticket expires
> > 4) kinit to renew ticket produces strange error because $HOME is not
> > accessible and a new ticket is not created.
> > 
> > So, I think in this case, I would like to see rpc.gssd uses host keytab while
> > user's ticket is not available, which maps to nobody/nogroup, but kinit should
> > succeed.
> Who is going the kinits in this scenario?

the user comes back and wants to issue kinit. Kinit fails due to eperm on
anything in $HOME. The user has to log off and on again.

> I'm pretty sure sssd will what you are looking for.

how this could help me to work around expired tickets?

-- 
Lukáš Hejtmánek

Re: RFC rpc.gssd enhancement

[Steve Dickson]

On 11/29/2016 01:48 PM, Lukas Hejtmanek wrote:
> Hello,
> 
> On Tue, Nov 29, 2016 at 01:37:00PM -0500, Steve Dickson wrote:
>> The kernel would do an upcall to the user's
>> creds but they have expired. Now if this 
>> new option is set, rpc.gssd would used 
>> the machine's cred? It seems to me that
>> would not be too secure.
> 
> maybe it is not considered secure, but it is still more secure to me than
> using sec=sys. 
True.

> 
> the problem is, that kerberized home is problem for .k5login file and also for
> .ssh/authorized_keys. While the .k5login file is accessed with root context
> (sshd), the authorized_keys is accessed with user context, so login via ssh
> pubkey is not possible at all. 
What would the .k5login look like and what would the principal look like?
My apologies but I'm not very familar with how sshd interacts with 
the .k5login. 

> 
> moreover, consider scenario where a user has symlink from his/her home to NFS
> share, without kerberos ticket, logon process can get stucked until he/she has
> the ticket. The ticket cannot be created until success logon.
Yeah... This has been a long running problem which is why
I'm curious about your RFC... 
 
> 
>>> Consider the following scenario:
>>> 1) machine has NFS mounted /home using kerberos authentication
>>> 2) user logs in, sshd creates krb ticket ($HOME/.k5login needs to be world
>>> readable to allow kerberized access, e.g., using kerberos ticket)
>>> 3) user stays logged in and krb ticket expires
>>> 4) kinit to renew ticket produces strange error because $HOME is not
>>> accessible and a new ticket is not created.
>>>
>>> So, I think in this case, I would like to see rpc.gssd uses host keytab while
>>> user's ticket is not available, which maps to nobody/nogroup, but kinit should
>>> succeed.
>> Who is going the kinits in this scenario?
> 
> the user comes back and wants to issue kinit. Kinit fails due to eperm on
> anything in $HOME. The user has to log off and on again.
I see.

> 
>> I'm pretty sure sssd will what you are looking for.
> 
> how this could help me to work around expired tickets?
> 
sssd will renew the ticket before it expired (I think).
But the user has to be known to a ipa-server on 
an ipa-client, so this may not be workable... 

steved.

Re: RFC rpc.gssd enhancement

[Olga Kornievskaia]

On Mon, Nov 28, 2016 at 1:37 PM, Lukas Hejtmanek <xhejtman@ics.muni.cz> wro=
te:
> Hello,
>
> would it be acceptable to add an option for rpc.gssd to use host keytab i=
f
> user's kerberos ticket is not available?
>
> Consider the following scenario:
> 1) machine has NFS mounted /home using kerberos authentication
> 2) user logs in, sshd creates krb ticket ($HOME/.k5login needs to be worl=
d
> readable to allow kerberized access, e.g., using kerberos ticket)
> 3) user stays logged in and krb ticket expires
> 4) kinit to renew ticket produces strange error because $HOME is not
> accessible and a new ticket is not created.

Why is kinit accessing something from $HOME. What distro are you using
to run kinit (or any other info to explain use of $HOME)?

I just ran kinit on RHEL7.2 and it nowhere does it read $HOME.

What I read here is that user has expired creds and is trying to
access a kerberized NFS file. The operation MUST fail, there is no way
around it. There shouldn't be any fixes that would allow for a user to
access files without credentials.

So in the environment where for whatever reason your kinit requires
read of $HOME, you must make sure credentials are refreshed before
they expire. Steve has mentioned that sssd takes on this
responsibility.

> So, I think in this case, I would like to see rpc.gssd uses host keytab w=
hile
> user's ticket is not available, which maps to nobody/nogroup, but kinit s=
hould
> succeed.
>
> Or are there any other options if one is using kerberized homes only?
>
> --
> Luk=C3=A1=C5=A1 Hejtm=C3=A1nek
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RFC rpc.gssd enhancement

[Lukas Hejtmanek]

On Tue, Nov 29, 2016 at 02:28:10PM -0500, Steve Dickson wrote:
> > maybe it is not considered secure, but it is still more secure to me than
> > using sec=sys. 
> True.

So, I was asking, if I provide such patch, will it be accepted into mainline
nfs-utils?

> > the problem is, that kerberized home is problem for .k5login file and also for
> > .ssh/authorized_keys. While the .k5login file is accessed with root context
> > (sshd), the authorized_keys is accessed with user context, so login via ssh
> > pubkey is not possible at all. 
> What would the .k5login look like and what would the principal look like?
> My apologies but I'm not very familar with how sshd interacts with 
> the .k5login. 

ok, I did more testing. It seems that kinit does not search ~/.k5login but
~/.krb5/config.

If NFS client gets permission denied, it is ok and kinit just creates a new
ticket.

However, if user has ticket that expired, NFS client returns EKEYEXPIRED
instead of EPERM. In such a case, kinit/kdestoy does not deal with this errno
and returns:
kinit: krb5_init_context failed: 127
or
kdestroy: krb5_init_context failed: 127

if you do rm /tmp/krb5cc_`id -u`_*, EKEYEXPIRED is changed to EPERM and
kinit/kdestroy works again.


Colleague of me says that EKEYEPIRED should not be returned by NFS client at
all, EPERM should be always returned and he sees this as a bug in kernel code.

-- 
Lukáš Hejtmánek

Fwd: RFC rpc.gssd enhancement

[Andy Adamson]

Oops - forgot to 'cc the kernel list.

-->andy


---------- Forwarded message ----------
From: Andy Adamson <androsadamson@gmail.com>
Date: Fri, Dec 2, 2016 at 8:26 AM
Subject: Re: RFC rpc.gssd enhancement
To: Lukas Hejtmanek <xhejtman@ics.muni.cz>


On Fri, Dec 2, 2016 at 6:41 AM, Lukas Hejtmanek <xhejtman@ics.muni.cz> wrot=
e:
> On Tue, Nov 29, 2016 at 02:28:10PM -0500, Steve Dickson wrote:
>> > maybe it is not considered secure, but it is still more secure to me t=
han
>> > using sec=3Dsys.

That is not saying much. AUTH_SYS is _completely_ insecure. RPCSEC_GSS
with Kerberos is as secure as we get. Watering down Kerberos security
is silly. AFAICS, the only reason kinit of the user to re-establish
the Kerberos GSS context for NFS is the fact that the result of the
kinit is stored in NFS under Kerberos. That is a silly design!

>> True.
>
> So, I was asking, if I provide such patch, will it be accepted into mainl=
ine
> nfs-utils?

It shouldn't be. I strongly object. Just to be clear, here is what you
are asking:

>>So, I think in this case, I would like to see rpc.gssd uses host keytab w=
hile
>>user's ticket is not available, which maps to nobody/nogroup, but kinit s=
hould succeed.

If the above were implemented - an attacker that has rooted the  NFS
client machine, or got control of gssd in some way - which means the
attacker has the NFS client machine key, can kinit as _any_ user at
_any_ time and access _any_ users kerberos NFS share accessible from
the client machine.

That is a huge security hole and a very large security degradation!!

In the current situation, rooting the NFS client machine only gives
access (with a lot of hacking) to the non-expired in-kernel GSS
contexts of active NFS users. Once the GSS context expires, the
attacker has nothing.

>
>> > the problem is, that kerberized home is problem for .k5login file and =
also for
>> > .ssh/authorized_keys. While the .k5login file is accessed with root co=
ntext
>> > (sshd), the authorized_keys is accessed with user context, so login vi=
a ssh
>> > pubkey is not possible at all.

That is no reason to degrade Kerberos security!

I don't get this:

Here are the steps to allow the user to access the NFS kerberized share:

1) machine has NFS mounted /home using kerberos authentication
2) user logs in, sshd creates krb ticket ($HOME/.k5login needs to be world
readable to allow kerberized access, e.g., using kerberos ticket)

Why does the user kinit (e.g. the user logs in) allow sshd to create
the initial krb ticket in $HOME/<whatever> yet the user kinit to renew
said krb ticket fail? That seems to be a silly design.


>> What would the .k5login look like and what would the principal look like=
?
>> My apologies but I'm not very familar with how sshd interacts with
>> the .k5login.
>
> ok, I did more testing. It seems that kinit does not search ~/.k5login bu=
t
> ~/.krb5/config.
>
> If NFS client gets permission denied, it is ok and kinit just creates a n=
ew
> ticket.

Huh? What kinit? The NFS client (using the machine key) uses a keytab
which means no kinit is required.

Using a keytab is one way to have renewable Kerberos credentials.

The correct way to solve your problem is with renewable tickets.

I suggest you read:

https://web.mit.edu/kerberos/krb5-1.13/doc/user/tkt_mgmt.html

which includes:

"Renewable tickets can be used to obtain new session keys without the
user entering their password again. A renewable ticket has two
expiration times. The first is the time at which this particular
ticket expires. The second is the latest possible expiration time for
any ticket issued based on this renewable ticket."

Or perhaps this from microsoft:

https://social.technet.microsoft.com/Forums/windowsserver/en-US/e0c6a401-16=
09-47c9-8f1c-6437b98bef2a/how-does-kerberos-ticket-or-tgt-get-renewed-or-re=
freshed?forum=3Dwinserversecurity

"When tickets are renewable, session keys are refreshed periodically
without issuing a completely new ticket. If Kerberos policy permits
renewable tickets, the KDC sets a RENEWABLE flag in every ticket it
issues and sets two expiration times in the ticket. One expiration
time limits the life of the current instance of the ticket; the second
expiration time sets a limit on the cumulative lifetime of all
instances of the ticket.

The expiration time for the current instance of the ticket is held in
the End Time field. As with non-renewable tickets, the value in the
End Time field equals the value in the Start Time field plus the value
of the maximum ticket life specified by Kerberos policy. A client
holding a renewable ticket must send it=E2=80=94presenting a fresh
authenticator as well=E2=80=94to the KDC for renewal before the end time is
reached. When the KDC receives a ticket for renewal, it checks the
value of a second expiration time held in the Renew Till field. This
value is set when the ticket is first issued. It equals the value in
the tickets Start Time field plus the value of the maximum cumulative
ticket life specified by Kerberos policy. When the KDC renews the
ticket, it checks to determine if the renew-till time has not yet
arrived. If it has not, the KDC issues a new instance of the ticket
with a later end time and a new session key.

This means that administrators can set Kerberos policy so that tickets
must be renewed at relatively short intervals=E2=80=94every day, for exampl=
e.
When tickets are renewed, a new session key is issued, minimizing the
value of a compromised key. Administrators can also set cumulative
ticket life for a relatively long period=E2=80=94one week or one month, for
example. At the end of that time, the ticket expires and is no longer
valid for renewal."

There are many ways to set this up.

https://linux.die.net/man/1/krenew

As Steve Dickson mentioned, Red Hat SSSD does ticket renewal

>
> However, if user has ticket that expired, NFS client returns EKEYEXPIRED
> instead of EPERM.

That is because the key has expired!!!

#define EKEYEXPIRED     127     /* Key has expired */

so EKEYEXPIRED is obviously the correct error!


> In such a case, kinit/kdestoy does not deal with this errno
> and returns:
> kinit: krb5_init_context failed: 127
> or
> kdestroy: krb5_init_context failed: 127
>
> if you do rm /tmp/krb5cc_`id -u`_*, EKEYEXPIRED is changed to EPERM and
> kinit/kdestroy works again.
>
>
> Colleague of me says that EKEYEPIRED should not be returned by NFS client=
 at
> all, EPERM should be always returned and he sees this as a bug in kernel =
code.

No! EKEYEXPIRED is used to signal the user that the only reason for
the failure is that the user's credentials have expired, and that the
user therefore needs to renew her credentials. EKEYEXPIRED is exactly
the error to return.

-->Andy


>
> --
> Luk=C3=A1=C5=A1 Hejtm=C3=A1nek
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Fwd: RFC rpc.gssd enhancement

[Andy Adamson]

'cc the kerne list


-->Andy

On Fri, Dec 2, 2016 at 8:46 AM, Lukas Hejtmanek <xhejtman@gmail.com> wrote:
> On Fri, Dec 02, 2016 at 08:26:33AM -0500, Andy Adamson wrote:
>> That is not saying much. AUTH_SYS is _completely_ insecure. RPCSEC_GSS
>> with Kerberos is as secure as we get. Watering down Kerberos security
>> is silly. AFAICS, the only reason kinit of the user to re-establish
>> the Kerberos GSS context for NFS is the fact that the result of the
>> kinit is stored in NFS under Kerberos. That is a silly design!
>
> no, it is not, that is misunderstanding. kinit does not store anything in
> $HOME. Tickets are in /tmp (or maybe in $TMPDIR). However, knit searches =
for
> ~/.krb5/config at start and ~ is Kerberzied. Maybe silly design, but not =
mine
> but kerberos guys (MIT ones).

So, how does sshd allow the user to kinit on login?
Here are the steps to allow the user to access the NFS kerberized share:

1) machine has NFS mounted /home using kerberos authentication
2) user logs in, sshd creates krb ticket ($HOME/.k5login needs to be world
readable to allow kerberized access, e.g., using kerberos ticket)

Why does the user kinit (e.g. the user logs in) allow sshd to create
the initial krb ticket in $HOME/<whatever> yet the user kinit to renew
said krb ticket fail?

>
>>
>> >> True.
>> >
>> > So, I was asking, if I provide such patch, will it be accepted into ma=
inline
>> > nfs-utils?
>>
>> It shouldn't be. I strongly object. Just to be clear, here is what you
>> are asking:
>>
>> >>So, I think in this case, I would like to see rpc.gssd uses host keyta=
b while
>> >>user's ticket is not available, which maps to nobody/nogroup,

Maybe the NFS client machine key maps to nobody/nogroup in your
environment, but it does not in others. Other environments can (and
do) map the machine cred to any UID they want - including root.

user ssh's into the NFS client machine.


>>  but kinit should succeed.
>>
>> If the above were implemented - an attacker that has rooted the  NFS
>> client machine, or got control of gssd in some way - which means the
>> attacker has the NFS client machine key, can kinit as _any_ user at
>> _any_ time and access _any_ users kerberos NFS share accessible from
>> the client machine.
>>
>> That is a huge security hole and a very large security degradation!!
>
> again, huge misunderstanding. The thing I want is that user without his/h=
er
> ticket is mapped to nobody/nogroup identity.

In your environment, UID 0 on the client machine (the machine
credential in the host keytab) is mapped to nobody/nobody when
accessing the NFS server.



> I do not want any shortcut to
> fake user ticket or something. I just want the user without ticket to be
> allowed access kerberized home with nfs/$HOSTNAME identity, i.e., the sam=
e
> identity as root user uses. So potential attacker gets nothing more than
> already has if he escalates root access. And yes, the attacker has limite=
d
> access to kerberized share if only user account is compromised. But this =
is
> the decision of NFS client machine administrator. If root access is
> compromised (still, it is gssd specific and nothing prevents the attacker=
 to
> build such patch on his own), there is nothing that attackers get.
>
> --
> Luk=C3=A1=C5=A1 Hejtm=C3=A1nek

Re: Fwd: RFC rpc.gssd enhancement

[Lukas Hejtmanek]

On Fri, Dec 02, 2016 at 09:23:30AM -0500, Andy Adamson wrote:
> In your environment, UID 0 on the client machine (the machine
> credential in the host keytab) is mapped to nobody/nobody when
> accessing the NFS server.

well, ok, and this is what I want for users without kerberos tickets. Map them
to nobody/nogroup instead of error EPERM or EKEYEXPIRED. And I want this as an
option for administator of NFS client machine.

-- 
Lukáš Hejtmánek

Re: Fwd: RFC rpc.gssd enhancement

[Andy Adamson]

On Fri, Dec 2, 2016 at 9:28 AM, Lukas Hejtmanek <xhejtman@gmail.com> wrote:
> On Fri, Dec 02, 2016 at 09:23:30AM -0500, Andy Adamson wrote:
>> In your environment, UID 0 on the client machine (the machine
>> credential in the host keytab) is mapped to nobody/nobody when
>> accessing the NFS server
>
> well, ok, and this is what I want for users without kerberos tickets. Map=
 them
> to nobody/nogroup instead of error EPERM or EKEYEXPIRED. And I want this =
as an
> option for administator of NFS client machine.


>1) machine has NFS mounted /home using kerberos authentication

OK

> 2) user logs in,

You mean,  user ssh's into the NFS client machine and then runs kinit?
Or does the user run kinit locally and then use ssh to forward the
kerberos credentials?

 >sshd creates krb ticket ($HOME/.k5login

Why do you use .k5login?

from https://web.mit.edu/kerberos/krb5-1.13/doc/user/user_config/k5login.ht=
ml

The .k5login file, which resides in a user=E2=80=99s home directory, contai=
ns
a list of the Kerberos principals. Anyone with valid tickets for a
principal in the file is allowed host access with the UID of the user
in whose home directory the file resides. One common use is to place a
.k5login file in root=E2=80=99s home directory, thereby granting system
administrators remote root access to the host via Kerberos.

EXAMPLES

Suppose the user alice had a .k5login file in her home directory
containing just the following line:

bob@FOOBAR.ORG

This would allow bob to use Kerberos network applications, such as
ssh(1), to access alice=E2=80=98s account, using bob=E2=80=98s Kerberos tic=
kets. In a
default configuration (with k5login_authoritative set to true in
krb5.conf), this .k5login file would not let alice use those network
applications to access her account, since she is not listed! With no
.k5login file, or with k5login_authoritative set to false, a default
rule would permit the principal alice in the machine=E2=80=99s default real=
m
to access the alice account.


>needs to be world
>readable to allow kerberized access, e.g., using kerberos ticket)

1) Please explain what use the .k5login is in your environment.

2) IIUC only the initial ssh access works - the one that creates the
$HOME/.k5login. All other accesses fail?

3) you mentioned that it's not ~/.k5login but ~/.krb5/config that is
trying to be accessed. I can't find any doc on ~/.krb5/config. Is it
just the replacement for .k5login?

>ok, I did more testing. It seems that kinit does not search ~/.k5login but
>~/.krb5/config.

-->Andy


>
> --
> Luk=C3=A1=C5=A1 Hejtm=C3=A1nek

Re: Fwd: RFC rpc.gssd enhancement

[Lukas Hejtmanek]

This discussion seems to be a bit fubar. So I start over again.

I see three problems if $HOME is Kerberized NFS volume, I will call this NFS
client machine.

1) user logs via SSH to the NFS client machine using GSS API, i.e., the user
   has a Kerberos ticket. SSHD on the NFS client machine has to access
   ~/.k5login under root identity (usually host identity). User has to grant
   access to such identity to his/her $HOME and .k5login in there.
   Older version of Kerberos denied access if ~/.k5login had different
   permision than 0600.

2) user logs via SSH to the NFS client machine using password. He/she stays
   logged in, Kerberos ticket expires. Issuing kinit returns an error I've
   already sent, because kinit wants to read ~/.krb5/config file and gets
   EKEYEXPIRED. Kinit does not deal with such an error, it understand olny
   EPERM error. New ticket cannot be created until user deletes ticket from
   TMPDIR (rm, not kdestroy as it does not work either).

3) user wants to log via SSH to the NFS client machine using ssh public key.
   This cannot be done as ~/.ssh/authorized_keys is accessed by SSHD under
   user context (not root context), so EPERM is returned even if user grants
   access to read ~/.ssh/authorized_keys to anyone.

While nothing can be done ad 1). My proposed extension of rpc.gssd would solve
ad 2) and ad 3). As this should be purely rpc.gssd patch, possible attacker
with escalated root access is out of question because the attacker can replace
rpc.gssd on his own. And also in this case, decision whether user gets
EKEYEXPIRED/EPERM or granted access as some particular identity is desicion of
the administator of the NFS client machine.

-- 
Lukáš Hejtmánek

Re: Fwd: RFC rpc.gssd enhancement

[Andy Adamson]

On Thu, Dec 8, 2016 at 7:36 AM, Lukas Hejtmanek <xhejtman@gmail.com> wrote:
> This discussion seems to be a bit fubar. So I start over again.
>
> I see three problems if $HOME is Kerberized NFS volume, I will call this =
NFS
> client machine.
>
> 1) user logs via SSH to the NFS client machine using GSS API, i.e., the u=
ser
>    has a Kerberos ticket.

Did the user use kinit -f (to obtain a forwardable ticket)?

Do you enable credential forwarding? e.g. does the .ssh/config file contain

GSSAPIDelegateCredentials yes

>   SSHD on the NFS client machine has to access
>    ~/.k5login under root identity (usually host identity). User has to gr=
ant
>    access to such identity to his/her $HOME and .k5login in there.
>    Older version of Kerberos denied access if ~/.k5login had different
>    permision than 0600.
>
> 2) user logs via SSH to the NFS client machine using password.
> He/she stays
>    logged in, Kerberos ticket expires. Issuing kinit returns an error I'v=
e
>    already sent, because kinit wants to read ~/.krb5/config file and gets
>    EKEYEXPIRED. Kinit does not deal with such an error, it understand oln=
y
>    EPERM error. New ticket cannot be created until user deletes ticket fr=
om
>    TMPDIR (rm, not kdestroy as it does not work either).
>
> 3) user wants to log via SSH to the NFS client machine using ssh public k=
ey.
>    This cannot be done as ~/.ssh/authorized_keys is accessed by SSHD unde=
r
>    user context (not root context), so EPERM is returned even if user gra=
nts
>    access to read ~/.ssh/authorized_keys to anyone.

Yes. Isn't this the issue that forwardable kerberos tickets and ssh
with GSSAPI is designed to solve?

Why does the user want to login to the NFS client machine using the
ssh public key and not kinit -f and use forwardable tickets? Or have I
misunderstood.....

-->Andy
>
> While nothing can be done ad 1). My proposed extension of rpc.gssd would =
solve
> ad 2) and ad 3). As this should be purely rpc.gssd patch, possible attack=
er
> with escalated root access is out of question because the attacker can re=
place
> rpc.gssd on his own. And also in this case, decision whether user gets
> EKEYEXPIRED/EPERM or granted access as some particular identity is desici=
on of
> the administator of the NFS client machine.
>
> --
> Luk=C3=A1=C5=A1 Hejtm=C3=A1nek

Re: Fwd: RFC rpc.gssd enhancement

[Lukas Hejtmanek]

On Thu, Dec 08, 2016 at 08:18:02AM -0500, Andy Adamson wrote:
> On Thu, Dec 8, 2016 at 7:36 AM, Lukas Hejtmanek <xhejtman@gmail.com> wrote:
> > This discussion seems to be a bit fubar. So I start over again.
> >
> > I see three problems if $HOME is Kerberized NFS volume, I will call this NFS
> > client machine.
> >
> > 1) user logs via SSH to the NFS client machine using GSS API, i.e., the user
> >    has a Kerberos ticket.
> 
> Did the user use kinit -f (to obtain a forwardable ticket)?
> 
> Do you enable credential forwarding? e.g. does the .ssh/config file contain
> 
> GSSAPIDelegateCredentials yes

yes, but it does not help, the ticket is recreated bit later during log on
process.

> Yes. Isn't this the issue that forwardable kerberos tickets and ssh
> with GSSAPI is designed to solve?
> 
> Why does the user want to login to the NFS client machine using the
> ssh public key and not kinit -f and use forwardable tickets? Or have I
> misunderstood.....

well, for some reason for sshfs, user does not want to play with renewable
ticket, he wants just public key. But yes, instead of ssh public key, one can
use forwardable ticket but those needs to be recreated/refreshed (we have
limit for ticket duration 1 day, 7 days renewable).

-- 
Lukáš Hejtmánek

Re: Fwd: RFC rpc.gssd enhancement

[Andy Adamson]

On Thu, Dec 8, 2016 at 8:23 AM, Lukas Hejtmanek <xhejtman@gmail.com> wrote:
> On Thu, Dec 08, 2016 at 08:18:02AM -0500, Andy Adamson wrote:
>> On Thu, Dec 8, 2016 at 7:36 AM, Lukas Hejtmanek <xhejtman@gmail.com> wro=
te:
>> > This discussion seems to be a bit fubar. So I start over again.
>> >
>> > I see three problems if $HOME is Kerberized NFS volume, I will call th=
is NFS
>> > client machine.
>> >
>> > 1) user logs via SSH to the NFS client machine using GSS API, i.e., th=
e user
>> >    has a Kerberos ticket.
>>
>> Did the user use kinit -f (to obtain a forwardable ticket)?
>>
>> Do you enable credential forwarding? e.g. does the .ssh/config file cont=
ain
>>
>> GSSAPIDelegateCredentials yes
>
> yes, but it does not help, the ticket is recreated bit later during log o=
n
> process.
>
>> Yes. Isn't this the issue that forwardable kerberos tickets and ssh
>> with GSSAPI is designed to solve?
>>
>> Why does the user want to login to the NFS client machine using the
>> ssh public key and not kinit -f and use forwardable tickets? Or have I
>> misunderstood.....
>
> well, for some reason for sshfs, user does not want to play with renewabl=
e
> ticket,

do you mean forwardable ticket?

> he wants just public key. But yes, instead of ssh public key, one can
> use forwardable ticket but those needs to be recreated/refreshed (we have
> limit for ticket duration 1 day, 7 days renewable).

BTW: All kerberos tickets need to be refreshed/renewed. No exceptions :)

Wait. The user  is willing to ssh into the NFS client machine using
the ssh public key and the type kinit and enter a password, but not
willing to kinit -f enter a password and then ssh into the NFS client
machine using GSSAPI an forwardable tickets? Do I have this right?

-->Andy

>
> --
> Luk=C3=A1=C5=A1 Hejtm=C3=A1nek

Re: Fwd: RFC rpc.gssd enhancement

[Olga Kornievskaia]

On Thu, Dec 8, 2016 at 7:36 AM, Lukas Hejtmanek <xhejtman@gmail.com> wrote:
> This discussion seems to be a bit fubar. So I start over again.
>
> I see three problems if $HOME is Kerberized NFS volume, I will call this NFS
> client machine.
>
> 1) user logs via SSH to the NFS client machine using GSS API, i.e., the user
>    has a Kerberos ticket. SSHD on the NFS client machine has to access
>    ~/.k5login under root identity (usually host identity). User has to grant
>    access to such identity to his/her $HOME and .k5login in there.
>    Older version of Kerberos denied access if ~/.k5login had different
>    permision than 0600.
>
> 2) user logs via SSH to the NFS client machine using password. He/she stays
>    logged in, Kerberos ticket expires. Issuing kinit returns an error I've
>    already sent, because kinit wants to read ~/.krb5/config file and gets
>    EKEYEXPIRED. Kinit does not deal with such an error, it understand olny
>    EPERM error. New ticket cannot be created until user deletes ticket from
>    TMPDIR (rm, not kdestroy as it does not work either).
>
> 3) user wants to log via SSH to the NFS client machine using ssh public key.
>    This cannot be done as ~/.ssh/authorized_keys is accessed by SSHD under
>    user context (not root context), so EPERM is returned even if user grants
>    access to read ~/.ssh/authorized_keys to anyone.
>
> While nothing can be done ad 1). My proposed extension of rpc.gssd would solve
> ad 2) and ad 3). As this should be purely rpc.gssd patch, possible attacker
> with escalated root access is out of question because the attacker can replace
> rpc.gssd on his own. And also in this case, decision whether user gets
> EKEYEXPIRED/EPERM or granted access as some particular identity is desicion of
> the administator of the NFS client machine.
>

Why is "kinit" accessing ~/.krb5/config? Typically kinit will only
access /etc/krb5.conf.

You are describing a catch-22 system. You want to create credentials
but to create credentials you need to access a file that is protected
by the credentials. This is a badly designed setup.

kinit normally does not require access into something that is
protected by credentials gotten by kinit.

Your solution is to provide your user with "kinit" that does not
access ~/.krb5/config. Please describe the need for that file and why
it can't be satisfied using machine global /etc/krb5.conf.

Re: Fwd: RFC rpc.gssd enhancement

[Lukas Hejtmanek]

On Thu, Dec 08, 2016 at 04:11:38PM -0500, Olga Kornievskaia wrote:
> Why is "kinit" accessing ~/.krb5/config? Typically kinit will only
> access /etc/krb5.conf.
> 
> You are describing a catch-22 system. You want to create credentials
> but to create credentials you need to access a file that is protected
> by the credentials. This is a badly designed setup.
> 
> kinit normally does not require access into something that is
> protected by credentials gotten by kinit.
> 
> Your solution is to provide your user with "kinit" that does not
> access ~/.krb5/config. Please describe the need for that file and why
> it can't be satisfied using machine global /etc/krb5.conf.

debian heimdal 1.6~rc2+dfsg-9  opens ~/.krb5/config and ~/.rnd files. 
dunno why.

MIT implementation does not seem to access $HOME.

-- 
Lukáš Hejtmánek

Re: Fwd: RFC rpc.gssd enhancement

[Olga Kornievskaia]

On Thu, Dec 8, 2016 at 4:22 PM, Lukas Hejtmanek <xhejtman@gmail.com> wrote:
> On Thu, Dec 08, 2016 at 04:11:38PM -0500, Olga Kornievskaia wrote:
>> Why is "kinit" accessing ~/.krb5/config? Typically kinit will only
>> access /etc/krb5.conf.
>>
>> You are describing a catch-22 system. You want to create credentials
>> but to create credentials you need to access a file that is protected
>> by the credentials. This is a badly designed setup.
>>
>> kinit normally does not require access into something that is
>> protected by credentials gotten by kinit.
>>
>> Your solution is to provide your user with "kinit" that does not
>> access ~/.krb5/config. Please describe the need for that file and why
>> it can't be satisfied using machine global /etc/krb5.conf.
>
> debian heimdal 1.6~rc2+dfsg-9  opens ~/.krb5/config and ~/.rnd files.
> dunno why.
>
> MIT implementation does not seem to access $HOME.

When you say "MIT implementation does not seem to access $HOME", do
you mean you've build kinit from MIT source and it works? If so, then
solution seems to be to bug debian folks to investigate what happened
to their kinit?

For instance RHEL/CentOS 7 had an issue where there patched OpenSSH
looked at .k5login file where normal ssh didn't and caused problems:
https://bugzilla.redhat.com/show_bug.cgi?id=1328243

I think that might be related to your other complaint with using ssh
keys to ssh. But at the same time I can see that what's going on here
is again somewhat un-kosher. If you placed .authorized_key under
something that only user with credentials can access, then you can't
get to it without having though credentials. You have mentioned that
"authorized_key" are readable but typically ~/.ssh had 700 permission
so sshd can't get to reading "authorized_keys" file.

To summarize: i suggest that you check that if an upstream kinit (from
MIT) and upstream openssh have the problems you are describing.

And to state again: what you are asking about for gssd is not an
acceptable request in terms of security.

Re: Fwd: RFC rpc.gssd enhancement

[Olga Kornievskaia]

On Thu, Dec 8, 2016 at 4:50 PM, Olga Kornievskaia <aglo@umich.edu> wrote:
> On Thu, Dec 8, 2016 at 4:22 PM, Lukas Hejtmanek <xhejtman@gmail.com> wrote:
>> On Thu, Dec 08, 2016 at 04:11:38PM -0500, Olga Kornievskaia wrote:
>>> Why is "kinit" accessing ~/.krb5/config? Typically kinit will only
>>> access /etc/krb5.conf.
>>>
>>> You are describing a catch-22 system. You want to create credentials
>>> but to create credentials you need to access a file that is protected
>>> by the credentials. This is a badly designed setup.
>>>
>>> kinit normally does not require access into something that is
>>> protected by credentials gotten by kinit.
>>>
>>> Your solution is to provide your user with "kinit" that does not
>>> access ~/.krb5/config. Please describe the need for that file and why
>>> it can't be satisfied using machine global /etc/krb5.conf.
>>
>> debian heimdal 1.6~rc2+dfsg-9  opens ~/.krb5/config and ~/.rnd files.
>> dunno why.
>>
>> MIT implementation does not seem to access $HOME.
>
> When you say "MIT implementation does not seem to access $HOME", do
> you mean you've build kinit from MIT source and it works? If so, then
> solution seems to be to bug debian folks to investigate what happened
> to their kinit?
> For instance RHEL/CentOS 7 had an issue where there patched OpenSSH
> looked at .k5login file where normal ssh didn't and caused problems:
> https://bugzilla.redhat.com/show_bug.cgi?id=1328243
>
> I think that might be related to your other complaint with using ssh
> keys to ssh. But at the same time I can see that what's going on here
> is again somewhat un-kosher. If you placed .authorized_key under
> something that only user with credentials can access, then you can't
> get to it without having though credentials. You have mentioned that
> "authorized_key" are readable but typically ~/.ssh had 700 permission
> so sshd can't get to reading "authorized_keys" file.
>
> To summarize: i suggest that you check that if an upstream kinit (from
> MIT) and upstream openssh have the problems you are describing.

Sorry you said debian heimdal not MIT. If MIT works, I suggest
bringing this issue up on the heimdal kerberos mailing list and
describe the problem there.