'cc the kerne list
-->Andy
On Fri, Dec 2, 2016 at 8:46 AM, Lukas Hejtmanek <[email protected]> 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
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
On Fri, Dec 2, 2016 at 9:28 AM, Lukas Hejtmanek <[email protected]> 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:
[email protected]
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
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
On Thu, Dec 8, 2016 at 7:36 AM, Lukas Hejtmanek <[email protected]> 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
On Thu, Dec 08, 2016 at 08:18:02AM -0500, Andy Adamson wrote:
> On Thu, Dec 8, 2016 at 7:36 AM, Lukas Hejtmanek <[email protected]> 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
On Thu, Dec 8, 2016 at 8:23 AM, Lukas Hejtmanek <[email protected]> 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 <[email protected]> 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
On Thu, Dec 8, 2016 at 7:36 AM, Lukas Hejtmanek <[email protected]> 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.
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
On Thu, Dec 8, 2016 at 4:22 PM, Lukas Hejtmanek <[email protected]> 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.
On Thu, Dec 8, 2016 at 4:50 PM, Olga Kornievskaia <[email protected]> wrote:
> On Thu, Dec 8, 2016 at 4:22 PM, Lukas Hejtmanek <[email protected]> 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.