More secure permissions for /root and /etc/sysctl.conf

[Rodney W. Grimes]

> Hi Rodney,
> 
> first, thanks for all the input I received from various people. I updated the differential and backed out the changes to /etc/sysctl.conf. I wasn?t aware that sysctl can be invoked from anybody.
> 
> In the corrected differential [1] I changed the permission for /root to 0750 in the hope that this could be integrated into FreeBSD. I know that people shouldn?t store sensitive information in /root but I have seen it to often in the past.

I still can not support that as a change:
a) It has been 755 for 26 years on FreeBSD and also as long as
   I can remeber (aka v4 research).  Changing it would be a POLA
   violation.

b) No known security flaw has been shown other than user error.

c) The default for home directories in all the BSD's I looked at
   are 755.

d) All distributions I looked at ship /root as 755.  This would be
   FreeBSD as the odd man out.

e) This still appears to be an attempt to impose ones own preferences
   as defaults upon the community.  Defaults are resonable, but not
   necessarily correct for everyone.

> Best regards,
> 
> Gordon
> 
> [1] https://reviews.freebsd.org/D23392 <https://reviews.freebsd.org/D23392>
> 
> > Am 31.01.2020 um 11:25 schrieb Rodney W. Grimes <freebsd-rwg at gndrsh.dnsmgr.net>:
> > 
> >>>>> I don't see the point in making this change to sysctl.conf.  sysctls
> >>>>> are readable by any user.  Hiding the contents of sysctl.conf does not
> >>>>> prevent unprivileged users from seeing what values have been changed
> >>>>> from the defaults; it merely makes it more tedious.
> >>>> true. but /root should be root only readable
> >>> 
> >>> Based on what?  What security does this provide to what part of the system?
> >> based on common sense
> > 
> > Who's common sense, as mine and some others say this is an unneeded
> > change with no technical merit.
> > 
> > You have provided no technical reasons for your requested change,
> > yet others have presented technical reasons to not make it,
> > so to try and base a support position on "common sense" is kinda moot.
> > 
> > We actually discussed this at dinner tonight and no one could come up
> > with a good reason to lock /root down in such a manner unless someone
> > was storing stuff in /root that should probably not really be stored
> > there.  Ie, there is a bigger problem than chmod 750 /root is going to
> > fix.
> > 
> > 
> > -- 
> > Rod Grimes                                                 rgrimes at freebsd.org
> 

-- 
Rod Grimes                                                 rgrimes at freebsd.org