Date: Sat, 1 Feb 2020 12:43:22 +0100 From: Gordon Bergling <gbergling@googlemail.com> To: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net> Cc: Wojciech Puchar <wojtek@puchar.net>, FreeBSD Hackers <freebsd-hackers@freebsd.org>, Ryan Stone <rysto32@gmail.com> Subject: Re: More secure permissions for /root and /etc/sysctl.conf Message-ID: <4584E3BE-F412-4902-AFB9-CAE88D660ED1@googlemail.com> In-Reply-To: <202001311025.00VAPZts072995@gndrsh.dnsmgr.net> References: <202001311025.00VAPZts072995@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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=E2=80=99t 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=E2=80=99t store sensitive information in /root but I have = seen it to often in the past. 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@gndrsh.dnsmgr.net>: >=20 >>>>> 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 >>>=20 >>> Based on what? What security does this provide to what part of the = system? >> based on common sense >=20 > Who's common sense, as mine and some others say this is an unneeded > change with no technical merit. >=20 > 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. >=20 > 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. >=20 >=20 > --=20 > Rod Grimes = rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4584E3BE-F412-4902-AFB9-CAE88D660ED1>