Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 01 Feb 2020 00:06:57 +0100
From:      Steffen Nurpmeso <steffen@sdaoden.eu>
To:        "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net>
Cc:        Lars Engels <lme@freebsd.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org>, Gordon Bergling <gbergling@googlemail.com>, Ryan Stone <rysto32@gmail.com>, Wojciech Puchar <wojtek@puchar.net>
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>

next in thread | previous in thread | raw e-mail | index | archive | help
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)



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200131230657.dFSLw%steffen>