From owner-freebsd-hackers@freebsd.org Fri Jan 31 23:07:02 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3DE911F00EA for ; Fri, 31 Jan 2020 23:07:02 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 488Xsx2Qmxz4M16; Fri, 31 Jan 2020 23:07:01 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: by sdaoden.eu (Postfix, from userid 1000) id 1355316057; Sat, 1 Feb 2020 00:06:58 +0100 (CET) Date: Sat, 01 Feb 2020 00:06:57 +0100 From: Steffen Nurpmeso To: "Rodney W. Grimes" Cc: Lars Engels , FreeBSD Hackers , Gordon Bergling , Ryan Stone , Wojciech Puchar Subject: Re: More secure permissions for /root and /etc/sysctl.confg Message-ID: <20200131230657.dFSLw%steffen@sdaoden.eu> In-Reply-To: <202001312146.00VLkuan075352@gndrsh.dnsmgr.net> References: <202001312146.00VLkuan075352@gndrsh.dnsmgr.net> Mail-Followup-To: "Rodney W. Grimes" , Lars Engels , FreeBSD Hackers , Gordon Bergling , Ryan Stone , Wojciech Puchar User-Agent: s-nail v14.9.16 OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. X-Rspamd-Queue-Id: 488Xsx2Qmxz4M16 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of steffen@sdaoden.eu designates 217.144.132.164 as permitted sender) smtp.mailfrom=steffen@sdaoden.eu X-Spamd-Result: default: False [0.72 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.84)[-0.837,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sdaoden.eu]; RCPT_COUNT_FIVE(0.00)[6]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_SPAM_LONG(0.58)[0.579,0]; MID_CONTAINS_FROM(1.00)[]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15987, ipnet:217.144.132.0/24, country:DE]; IP_SCORE(0.27)[asn: 15987(1.39), country: DE(-0.02)] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2020 23:07:02 -0000 Rodney W. Grimes wrote in <202001312146.00VLkuan075352@gndrsh.dnsmgr.net>: |> Lars Engels wrote in <20200131161347.GA33086@e.0x20.net>: |>|On Fri, Jan 31, 2020 at 02:25:35AM -0800, Rodney W. Grimes wrote: ... |>|>>>> true. but /root should be root only readable ... |>|> 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 ... |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. Oh no, sorry for not being clear. /root is not a shared filesystem, it is just that the data under /root is mirrored to a lot of systems. I have no system where /root/ is not on the same physical storage than /etc/. I.e., if a new host enters i adjust some configurations as has to be done, and create a new directory in /root/ -- this is nothing enterprise-alike. It is just that the basic infrastructure is at a central place out of the way of package managers etc. Then adjust as few lines as possible to keep the noise ratio in between original file and packaged file low. (For example the nice rejmerge(1) on CRUX-Linux, or a find(1)+grep(1) on AlpineLinux's .apk-new backup files.) It does not always work, server configuration files for example; for those i try to append to the files which are shipped with the packages. A bit dangerous, sshd for example fixates the first it finds. But works out in practice. I even share infrastructure in between the server and the clients, regarding those scripts, it is just a matter of the existence of a file /etc/.server. Affects mostly /root/net-qos.sh. It is nothing enterprise, like i have said. |My prefered solution of what you have done is to add a private local |/nodedata/$HOSTNAME hierarchy. This would also be an option, of course. I try to stay within my bounds, i like a small /, though i am much less hysterical than i was when i was younger. The FreeBSD 5.3 system i used for over six years for example was super stripped and clean. When i compare with some servers i have ssh access to, sometimes i see temporary files which lay around for years, for example: #?0|unstable9s:sdaoden$ ll /var/tmp/ total 26560 drwxr-xr-x 35 root sys 1024 Jul 25 2011 ../ drwx------ 2 maciej XXX 512 May 26 2013 javaqwIYFm/ ...lots more Ha-ha-ha! No no, better not. Nah, it is just some home-grown private thing, with some per-hostname things, like a backup filelist (to be picked up by /root/backup.sh), cpupower settings (for /root/cpupower.sh), and ditto volume, backlight, rc-hooks (if applicable), kernel configs, filesystem snapshot lists, list of installed packages, etc. For example, on Linux, acpid sends volume adjustment event to /root/acpid.sh, that dispatches to /root/volume.sh, that sources /root/$HOSTNAME/volume, and knows what to do. Likewise with dhcpcd-hook.sh. Like so, a few lines of sh(1)ll variable assignments are usually enough to adapt to a new machine. (This includes backlights with totally different steps and min / max values, the script usually works fine regardless.) --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)