[gentoo-user] Re: Switching default tmpfiles and faster internet coming my way.
Michael Orlitzky wrote: > On 12/6/20 11:57 AM, Martin Vaeth wrote: >> Michael Orlitzky wrote: >>> >>> Why are you focusing on /tmp and /var/tmp? >> Because only world-writable directories are the ones which >> can be exploited unless the tmpfiles.conf author does >> something malevolent or extremely stupid. > > This is completely untrue You are right: It is untrue that even /tmp and /var/tmp are under danger if the *.conf files are neiter malevolent nor stupid. On my system there is no such file, and I have quite some packages installed. I doubt that any gentoo package contains such a *.conf file which could trigger a problem even on /tmp or /var/tmp, even if that should not have been deleted on boot. > but I'm not about to get into an argument over something > that you can easily check yourself. Caveat emptor. Such a statement without a proof is called FUD. If you find a *.conf file in some package or ebuild which constitutes a problem for proper usage of opentmpfiles, you should post it.
Re: [gentoo-user] Re: Switching default tmpfiles and faster internet coming my way.
On 12/6/20 11:57 AM, Martin Vaeth wrote: Michael Orlitzky wrote: Why are you focusing on /tmp and /var/tmp? Because only world-writable directories are the ones which can be exploited unless the tmpfiles.conf author does something malevolent or extremely stupid. This is completely untrue, but I'm not about to get into an argument over something that you can easily check yourself. Caveat emptor.
[gentoo-user] Re: Switching default tmpfiles and faster internet coming my way.
antlists wrote: > On 06/12/2020 07:55, Martin Vaeth wrote: >> Dale wrote: >>> It sounds like a rather rare problem. Maybe even only during boot up. > >> It is a non-existent problem on openrc if you clean /tmp and /var/tmp >> on boot (which you should do if you use opentmp): > > Which breaks a lot of STANDARDS-COMPLIANT software. Actually, /var/tmp needs not be cleaned at boot to be on the safe side: grep /var/tmp /usr/lib/tmpfiles.d/* /usr/lib/tmpfiles.d/portage-ccache.conf:x /var/tmp/ccache /usr/lib/tmpfiles.d/systemd-tmp.conf:x /var/tmp/systemd-private-%b-* /usr/lib/tmpfiles.d/systemd-tmp.conf:X /var/tmp/systemd-private-%b-*/tmp /usr/lib/tmpfiles.d/systemd-tmp.conf:R! /var/tmp/systemd-private-* /usr/lib/tmpfiles.d/tmp.conf:q /var/tmp 1777 root root 30d The q entry is irrelevant for the intended usage of opentmpfiles, and the others cannot be exploited.
[gentoo-user] Re: Switching default tmpfiles and faster internet coming my way.
Michael Orlitzky wrote: > > Why are you focusing on /tmp and /var/tmp? Because only world-writable directories are the ones which can be exploited unless the tmpfiles.conf author does something malevolent or extremely stupid. > To pick a relevant example relevant? > If that was a 'Z' entry, or if it created another portage:portage > directory beneath /var/cache/eix In other words: If the completely harmless example would have been replaced by an intentionally malevolent one, this could do harm. With this logic, installing systemd-opentmpfiles is the same security risk: If its ebuild would just contain the line chmod -R /* everybody could easily become root on your system when you install it.
[gentoo-user] Re: Switching default tmpfiles and faster internet coming my way.
Michael wrote: > > Given M.Orlitzky's comments and discussions with systemd devs he shared, > what's the optimal solution for OpenRC users, who want to avoid systemd? Simply stay with opentmpfiles. > Rely on ebuild creators and maintainer checks to guard against these inherent > vulnerabilities? Rely on ebuild creators to not write into world-writable directories during emerge. This should never happen in the first place.
Re: [gentoo-user] Re: Switching default tmpfiles and faster internet coming my way.
On Sun, Dec 6, 2020 at 8:45 AM Michael wrote:
>
> The objectives of RHL and Poettering are not necessarily aligned
> with mine. For example, as I was installing sys-apps/systemd-tmpfiles I
> noticed systemd selecting as default DNS and NTP servers belonging to Google.
> Not something I would consciously use on my non cloud-hosted/server-farm
> administered laptop.
I think their intent is for distros to tailor such things to their
intended uses. Having a default to fall back to Google DNS/NTP is
probably a good choice for a distro oriented to home-use/etc. I think
resolved still gets configured to use the DHCP-provided DNS server by
default and uses Google as a backup to this.
In any case, the behavior is configurable at build-time so distros
would be expected to adjust it. A google backup probably doesn't make
sense in an environment where you run a central DNS, especially if you
host internal DNS/etc.
The behavior is also runtime-configurable, assuming you know that you
need to adjust it. First you can always just set your own resolv.conf
and glibc does its thing. If you still want to use resolved then you
can also configure its runtime config.
Getting back to you thinking RHL's needs aren't aligned to your own,
you might consider that RHL doesn't actually ship systemd with the
upstream defaults. Assuming CentOS follows them the latest systemd
source rpm I could find from them contains:
-Dntp-servers='0.%{ntpvendor}.pool.ntp.org 1.%{ntpvendor}.pool.ntp.org
2.%{ntpvendor}.pool.ntp.org 3.%{ntpvendor}.pool.ntp.org'
-Ddns-servers=''
So, they're tailoring RHEL for the corporate environment, and they're
not making the systemd upstream follow their own internal needs, even
though they're the ones paying for much of it. They made the upstream
default one that probably would appeal to most community distros.
--
Rich
Re: [gentoo-user] Re: Switching default tmpfiles and faster internet coming my way.
On Sunday, 6 December 2020 13:01:40 GMT antlists wrote: > On 06/12/2020 12:54, Rich Freeman wrote: > > I think the idea of having something more cross-platform is a good > > one, though there is nothing really about systemd that isn't "open" - > > it is FOSS. It just prioritizes using linux syscalls where they are > > useful over implementing things in a way that work on other kernels, > > which is more of a design choice than anything else. I mean, it is no > > more wrong to use linux-specific syscalls than for the linux > > developers to create them in the first place. > > After all, it's not as if SysVinit is portable ... hint - it ISN'T. > Nobody uses it but linux distros stuck in the past. > > Cheers, > Wol It's not the naming of files which bothers me in particular and I won't rehash arguments for and against systemd. I think such arguments have been exhausted on this list and others many times over. I'm happy to have the choice of OpenRC and I remain cautious of the insidious Big-Tech takeover of the Linux ecosystem. The objectives of RHL and Poettering are not necessarily aligned with mine. For example, as I was installing sys-apps/systemd-tmpfiles I noticed systemd selecting as default DNS and NTP servers belonging to Google. Not something I would consciously use on my non cloud-hosted/server-farm administered laptop. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: Switching default tmpfiles and faster internet coming my way.
On 12/6/20 2:55 AM, Martin Vaeth wrote:
Dale wrote:
It sounds like a rather rare problem. Maybe even only during boot up.
It is a non-existent problem on openrc if you clean /tmp and /var/tmp
on boot (which you should do if you use opentmp):
The purpose of opentmpfiles is to fill these directories with
certain data during boot, and when run only during boot
(as it is supposed to be) there is nothing wrong with it.
Why are you focusing on /tmp and /var/tmp? These entries are exploitable
everywhere. To pick a relevant example, app-portage/eix installs the
following:
$ cat /usr/lib/tmpfiles.d/eix.conf
d /var/cache/eix 0775 portage portage -
If that was a 'Z' entry, or if it created another portage:portage
directory beneath /var/cache/eix, then the "portage" user could easily
gain root whenever opentmpfiles is run. That happens not only on
reboots, but also when a package is (re)installed. Again, picking on
eix's ebuild:
pkg_postinst() {
tmpfiles_process eix.conf
...
(The portage user gain already gain root, but you get the idea.)
Re: [gentoo-user] Re: Switching default tmpfiles and faster internet coming my way.
On 06/12/2020 12:54, Rich Freeman wrote: I think the idea of having something more cross-platform is a good one, though there is nothing really about systemd that isn't "open" - it is FOSS. It just prioritizes using linux syscalls where they are useful over implementing things in a way that work on other kernels, which is more of a design choice than anything else. I mean, it is no more wrong to use linux-specific syscalls than for the linux developers to create them in the first place. After all, it's not as if SysVinit is portable ... hint - it ISN'T. Nobody uses it but linux distros stuck in the past. Cheers, Wol
Re: [gentoo-user] Re: Switching default tmpfiles and faster internet coming my way.
On 06/12/2020 07:55, Martin Vaeth wrote: Dale wrote: It sounds like a rather rare problem. Maybe even only during boot up. It is a non-existent problem on openrc if you clean /tmp and /var/tmp on boot (which you should do if you use opentmp): Which breaks a lot of STANDARDS-COMPLIANT software. /var/tmp is *specified* as "surviving a reboot", so cleaning it on startup is not merely non-standard, but *forbidden* by the standard - said standard being the Filesystem Hierarchy Standard ... For example, editors assume /var/tmp is a safe place to stash their files so they can recover from a system crash. (I used to mount /var/tmp as a tmpfs until I found that out ...) Cheers, Wol
Re: [gentoo-user] Re: Switching default tmpfiles and faster internet coming my way.
On Sun, Dec 6, 2020 at 7:37 AM Neil Bothwick wrote: > > Maybe the devs need to rename the systemd-tmpfiles package to satisfy > those that break out in a sweat at the mention of the s-word :) Or maybe people who care a great deal about the filenames of stuff just could rename them as they prefer? :) And if the part you don't like is what website or tarball the source is distributed from, well, it is FOSS so you can always just host it yourself. opentmpfiles is just a reimplementation of systemd-tmpfiles in bash with the goal of running on platforms that don't support linux syscalls (and I guess bash makes everything better cause C became corrupt the moment Lennart learned how to program in it...). So, if systemd-tmpfiles does something you don't like, chances are it is just a matter of time before opentmpfiles does too. I think the idea of having something more cross-platform is a good one, though there is nothing really about systemd that isn't "open" - it is FOSS. It just prioritizes using linux syscalls where they are useful over implementing things in a way that work on other kernels, which is more of a design choice than anything else. I mean, it is no more wrong to use linux-specific syscalls than for the linux developers to create them in the first place. In some situations the linux-specific stuff lets things be done that aren't practical with pure POSIX and safer manipulation of links is apparently one of them. Really what probably wouldn't hurt is some kind of FOSS POSIX-extension effort that tries to standardize stuff like this so that it can be implemented across other kernels in a standard way, at least for things like this which seem really useful. I suspect that the systemd folks might be willing to accept cross-platform improvements if it were practical to do so, and if not you could always fork it. -- Rich
Re: [gentoo-user] Re: Switching default tmpfiles and faster internet coming my way.
On Sun, 6 Dec 2020 at 13:37, Neil Bothwick wrote: > Despite the claims that systemd is > monolithic, it is not. It is an ecosystem comprised of many parts, some > of which can be used without any other systemd components, like > systemd-tmpfiles and systemd-boot, not to mention udev. Despite repeated claims that it is not, all evidence points to it being very much a monolithic code base, with tight coupling between most of the parts. That you can disable compilation of so many parts that some of the parts appear as stand-alone after compilation is not evidence against that. > Maybe the devs need to rename the systemd-tmpfiles package to satisfy > those that break out in a sweat at the mention of the s-word :) Since the compilation of this package consists of downloading a systemd release, and disabling building of almost everything but this component, it seems to very much be named correctly as it is. Regards, Arve
Re: [gentoo-user] Re: Switching default tmpfiles and faster internet coming my way.
On Sun, 06 Dec 2020 10:45:38 +, Michael wrote: > Given M.Orlitzky's comments and discussions with systemd devs he > shared, what's the optimal solution for OpenRC users, who want to avoid > systemd? systemd-tmpfiles != systemd. Despite the claims that systemd is monolithic, it is not. It is an ecosystem comprised of many parts, some of which can be used without any other systemd components, like systemd-tmpfiles and systemd-boot, not to mention udev. Maybe the devs need to rename the systemd-tmpfiles package to satisfy those that break out in a sweat at the mention of the s-word :) -- Neil Bothwick I can't walk on water, but I can stagger on alcohol. pgpdUNg9s1gAH.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Re: Switching default tmpfiles and faster internet coming my way.
On Sunday, 6 December 2020 07:55:29 GMT Martin Vaeth wrote: > Dale wrote: > > It sounds like a rather rare problem. Maybe even only during boot up. > > It is a non-existent problem on openrc if you clean /tmp and /var/tmp > on boot (which you should do if you use opentmp): > > The purpose of opentmpfiles is to fill these directories with > certain data during boot, and when run only during boot > (as it is supposed to be) there is nothing wrong with it. > > The situation is different for systemd which runs tmpfiles > periodically to clean up data from /tmp and /var/tmp > (something which should argueably be done by a dedicated tool > instead of putting two different functionalities into the same > tool - the usual systemd misconception of trying to be monolithic). > > There is a certain danger if you install a new package whose > ebuild processes on installation a certain tmpfiles.conf > which writes into one of the world-writable directories /tmp or > /var/tmp: Such an ebuild does an inherently unsafe thing during > installation (but it doesn't matter whether it does this using > opentmpfiles or by calling the shell commands manually), and I > would not hesitate to file a bug against such an ebuild. Given M.Orlitzky's comments and discussions with systemd devs he shared, what's the optimal solution for OpenRC users, who want to avoid systemd? Rely on ebuild creators and maintainer checks to guard against these inherent vulnerabilities? Or install --oneshot systemd-tmpfiles, at least temporarily until an OpenRC solution is cooked? signature.asc Description: This is a digitally signed message part.
[gentoo-user] Re: Switching default tmpfiles and faster internet coming my way.
Dale wrote: > > It sounds like a rather rare problem. Maybe even only during boot up. It is a non-existent problem on openrc if you clean /tmp and /var/tmp on boot (which you should do if you use opentmp): The purpose of opentmpfiles is to fill these directories with certain data during boot, and when run only during boot (as it is supposed to be) there is nothing wrong with it. The situation is different for systemd which runs tmpfiles periodically to clean up data from /tmp and /var/tmp (something which should argueably be done by a dedicated tool instead of putting two different functionalities into the same tool - the usual systemd misconception of trying to be monolithic). There is a certain danger if you install a new package whose ebuild processes on installation a certain tmpfiles.conf which writes into one of the world-writable directories /tmp or /var/tmp: Such an ebuild does an inherently unsafe thing during installation (but it doesn't matter whether it does this using opentmpfiles or by calling the shell commands manually), and I would not hesitate to file a bug against such an ebuild.
