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

[Rodney W. Grimes]

> Lars Engels wrote in <20200131161347.GA33086 at e.0x20.net>:
>  |On Fri, Jan 31, 2020 at 02:25:35AM -0800, Rodney W. Grimes wrote:
>  |>>>>> 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.
>  |
>  |/root can store config files and shell history with confidential
>  |information.
> 
> Absolutely.  My own /root is in fact shared in between many
> systems, and many scripts from /etc/ reach into /root/$HOSTNAME/,
> with some generics in /root/.  Practically all of that is Linux
> though.  But it is very nice, since i can share very, very much,
> and even the hostname= comes from kernel command line parameter,
> and multiplexes to entirely different setups.

This is one of those cases that I mention of probably doing something
outside the norm.  Your example of shared /root for me is a bad idea,
as if your shared /root should become unavaliable or worse deadlocked
your now in a login lockout situation to the very account you probably
need to repair the problem.

My prefered solution of what you have done is to add a private local
/nodedata/$HOSTNAME hierarchy.

> 
> efibootmgr is cool, by the way.
> 
> --steffen
> |
> |Der Kragenbaer,                The moon bear,
> |der holt sich munter           he cheerfully and one by one
> |einen nach dem anderen runter  wa.ks himself off
> |(By Robert Gernhardt)
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
> 

-- 
Rod Grimes                                                 rgrimes at freebsd.org