openssh unix dev - Oct 2018 - please remove permission check that disallows private-group access.

Third party programs should not be dictating to users how
to manage their systems.  Things like:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0660 for '/Users/law.Bliss/.ssh/id_rsa' are too open.
It is required that your private key files are NOT accessible by others
This private key will be ignored.
Load key "/Users/law.Bliss/.ssh/id_rsa": bad permissions

1) how would you know if they are "too open".  I assign a group to
each user.  How would they claim my permissions are "bad". 

2) In this specific  case, my local-machine and domain login
are different UID's, so I put them in the same GID to allow
access no matter UID I am logged in with. 

3) It may give some users a false sense of "security" if they believe
that setting perms to something like 0600 will give them the security of
only their 1 login having access.  They had better not rely on that.

4) I no longer get the warning -- I can simple change the permission
bits to match what is wanted then add my group as an acl -- which
gives the group full access but circumvents the irrelevant warning.

5) since my home directory is exported and mountable via samba, anyone
in the administrators or Domain Admins group (among others) can read it
as well.

6) I.e. the warning message is outdated, inaccurate and not really needed.

Thanks much!
-linda

Hi,

We don't plan to remove this check. Accidental key exposure is still an
unfortunately common problem and, while this check isn't perfect, I'm
pretty sure that it avoids enough real-world misconfiguration to
justify it's continued existence.

You're right that it doesn't withstand a determined administrator
and that's fine too - it isn't supposed to.

-d

On Fri, 19 Oct 2018, L A Walsh wrote:
> Third party programs should not be dictating to users how
> to manage their systems.  Things like:
> 
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> @         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> Permissions 0660 for '/Users/law.Bliss/.ssh/id_rsa' are too open.
> It is required that your private key files are NOT accessible by others
> This private key will be ignored.
> Load key "/Users/law.Bliss/.ssh/id_rsa": bad permissions
> 
> 1) how would you know if they are "too open".  I assign a group
to
> each user.  How would they claim my permissions are "bad". 
> 2) In this specific  case, my local-machine and domain login
> are different UID's, so I put them in the same GID to allow
> access no matter UID I am logged in with. 
> 3) It may give some users a false sense of "security" if they
believe
> that setting perms to something like 0600 will give them the security of
> only their 1 login having access.  They had better not rely on that.
> 
> 4) I no longer get the warning -- I can simple change the permission
> bits to match what is wanted then add my group as an acl -- which
> gives the group full access but circumvents the irrelevant warning.
> 
> 5) since my home directory is exported and mountable via samba, anyone
> in the administrators or Domain Admins group (among others) can read it
> as well.
> 
> 6) I.e. the warning message is outdated, inaccurate and not really needed.
> 
> Thanks much!
> -linda
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>

Respectfully disagree with your risk-benefit conclusion, and concur with the
request to remove this check or modify it to be informative rather than
blocking.

Regards,
Uri

Sent from my iPhone
> On Oct 21, 2018, at 20:23, Damien Miller <djm at mindrot.org> wrote:
> 
> Hi,
> 
> We don't plan to remove this check. Accidental key exposure is still an
> unfortunately common problem and, while this check isn't perfect,
I'm
> pretty sure that it avoids enough real-world misconfiguration to
> justify it's continued existence.
> 
> You're right that it doesn't withstand a determined administrator
> and that's fine too - it isn't supposed to.
> 
> -d
> 
>> On Fri, 19 Oct 2018, L A Walsh wrote:
>> 
>> Third party programs should not be dictating to users how
>> to manage their systems.  Things like:
>> 
>> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
>> @         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
>> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
>> Permissions 0660 for '/Users/law.Bliss/.ssh/id_rsa' are too
open.
>> It is required that your private key files are NOT accessible by others
>> This private key will be ignored.
>> Load key "/Users/law.Bliss/.ssh/id_rsa": bad permissions
>> 
>> 1) how would you know if they are "too open".  I assign a
group to
>> each user.  How would they claim my permissions are "bad". 
>> 2) In this specific  case, my local-machine and domain login
>> are different UID's, so I put them in the same GID to allow
>> access no matter UID I am logged in with. 
>> 3) It may give some users a false sense of "security" if they
believe
>> that setting perms to something like 0600 will give them the security
of
>> only their 1 login having access.  They had better not rely on that.
>> 
>> 4) I no longer get the warning -- I can simple change the permission
>> bits to match what is wanted then add my group as an acl -- which
>> gives the group full access but circumvents the irrelevant warning.
>> 
>> 5) since my home directory is exported and mountable via samba, anyone
>> in the administrators or Domain Admins group (among others) can read it
>> as well.
>> 
>> 6) I.e. the warning message is outdated, inaccurate and not really
needed.
>> 
>> Thanks much!
>> -linda
>> 
>> _______________________________________________
>> openssh-unix-dev mailing list
>> openssh-unix-dev at mindrot.org
>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5801 bytes
Desc: not available
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20181022/f9f51142/attachment.p7s>

Damien Miller <djm at mindrot.org> writes:
> We don't plan to remove this check. Accidental key exposure is still an
> unfortunately common problem and, while this check isn't perfect,
I'm
> pretty sure that it avoids enough real-world misconfiguration to
> justify it's continued existence.
Maybe the check could have a configuration option to disable it?  That
ways newbies would still be protected but folks that need to use the
group permissions to sort out NFS / UID issues could still use ssh
without going to great lengths to circumvent the check?

-wolfgang