Skip Menu |
 

History Show all quoted text — Show full headers
# Wed Feb 01 11:42:30 2017 sandeep umesh <sandeepumeshbe@gmail.com> - Ticket created
From: sandeep umesh <sandeepumeshbe@gmail.com>
Date: Wed, 1 Feb 2017 19:52:40 +0530
Subject: Check for k5login permission
To: krb5-bugs@mit.edu
Download (untitled) / with headers
text/plain 687B
Download (untitled) / with headers
text/html 792B
Hello

As per our understanding, .k5login file is similar to ssh authorized_keys. A user put his keys in the authorized_keys file to ssh to a server without password.

However ssh correctly check that only the ownerhas write access (600) to authorized_keys but the same check is not perform for k5login file. Anybody with write access to another user's home directory could potentially add a .k5login file with his kerberos id to take control of that user.

Basically, in userok_k5login function, we do have a check to verify if .k5login file is owned either by the user or root. Can we also have a additional check to verify the permissions of this file to be at 600 ?

Thanks

Sandeep
# Wed Feb 01 12:15:08 2017 hartmans (Sam Hartman) - Correspondence added
From: Sam Hartman <hartmans@mit.edu>
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #8542] Check for k5login permission
Date: Wed, 01 Feb 2017 12:15:05 -0500
RT-Send-Cc:
Download (untitled) / with headers
text/plain 751B
Show quoted text
>>>>> "sandeep" == sandeep umesh via RT <rt-comment@krbdev.mit.edu> writes:

Show quoted text
sandeep> Basically, in userok_k5login function, we do have a check
sandeep> to verify if .k5login file is owned either by the user or
sandeep> root. Can we also have a additional check to verify the
sandeep> permissions of this file to be at 600 ?

I actually object to the similar check in ssh and would object to it
being added for k5login.
I've found cases where allowing posix acls or groups to update the set
of users who are permitted to become a particular shared role account is
very useful.
I understand that it means you have to set the permissions right, but
there are legitimate cases for giving other users write access to an acl
like .k5login.
# Thu Feb 02 01:08:52 2017 ghudson@mit.edu (Greg Hudson) - Correspondence added
Download (untitled) / with headers
text/plain 464B
I have the same concern as Sam. I understand the desire to police the
permissions of security-sensitive files within home directories, since
users don't always do a good job of it. (Nor does all documentation;
it's depressing how often users of shared web host systems are
instructed to use "chmod 777".) But adding a mode bit check runs the
risk of breaking deployments where permissive mode bits are intended and
safe within the context of the OS setup.