Does Gentoo focus currently more on systemd?

[NeddySeagoon]

ndk,

vi vs emacs
vhs vs betamax
8-track vs cassette
dvdhd vs bluray
systemd vs ...

Don't treat Gentoo as another distro. It will bite you.
Its a toolkit you use to design and build your own Linux distro.
Use the tools as you wish but take care not to cut yourself

You can use Gentoo to do

Code: Select all

emerge @Debian

if you want to.
Writing the Debian set and determining the USE flags is left as as exercise for the reader :)

[ndk]

ndk,

vi vs emacs
vhs vs betamax
8-track vs cassette
dvdhd vs bluray
systemd vs ...

Don't treat Gentoo as another distro. It will bite you.
Its a toolkit you use to design and build your own Linux distro.
Use the tools as you wish but take care not to cut yourself

You can use Gentoo to do

Code: Select all

emerge @Debian

if you want to.
Writing the Debian set and determining the USE flags is left as as exercise for the reader

That was a reason why I started using Linux and Gentoo. As with any toolkit, there are sensible defaults that you should be able to customize.
If I have to jump through 25 million hoops to replace a default... If I have to have another tool for my tool, because the tool no longer does/looks like I want it to, it is time to find another tool.

Hopefully, I'm wrong and things will change. However judging by the level of defensiveness and belief in 'one true choice' from some of the devs here, I am rather pessimistic unfortunately. And by 'here', I don't mean this thread, I meant the discussions that were happening around eudev/udev, opentmpfiles 'deprecation', etc... As I mentioned, I've been lurking for awhile now. There is a part of the community that apparently has too much influence on the mainstream decisions that are less than ideal for those of us who still believe in having a choice.

What kind of annoys me is that opentmpfiles was 'abandoned' for sake of so-called security. If you have config that can only be written by the root and that config is compromised, you're already screwed. 'what if ebuilds are compromised' ? Nice lipstick on that horse. If ebuilds are compromised, those devs will have bigger problems.

[NeddySeagoon]

ndk,

I refer you to a previous post. Like the rest of the open source world, if you want it to change, join in and change it.

Gentoo has 127 active developers on roll call just now. Generating and carrying patch sets for $UPSTREAM is not really possible.

I keep adding the udev USE flag back into packages, so they build on my udev free main desktop.
I suspect that such patches would not be very welcome, so I don't file bugs and/or pull requests.

[ndk]

ndk,

I refer you to a previous post. Like the rest of the open source world, if you want it to change, join in and change it.

Gentoo has 127 active developers on roll call just now. Generating and carrying patch sets for $UPSTREAM is not really possible.

I keep adding the udev USE flag back into packages, so they build on my udev free main desktop.
I suspect that such patches would not be very welcome, so I don't file bugs and/or pull requests.

I refer you to https://www.gentoo.org/get-started/philosophy/
Specifically:

If the tool forces the user to do things a particular way, then the tool is working against, rather than for, the user. We have all experienced situations where tools seem to be imposing their respective wills on us. This is backwards, and contrary to the Gentoo philosophy.

If Gentoo is all about "following $UPSTREAM" and no longer about about providing people a choice, then it should be adjusted accordingly.
I'm getting tired of hearing that something is 'not possible' or 'hard' or 'not enough people'. If that is the case, either adjust expectations/philosophy or quit it.

When Gentoo started, there were less people than today, yet it provided more choices...

I'm calling quits on this conversation. No point to ponder upon obvious.

As I mentioned, I'll check if anything will be resolved a bit later. If the problem still hasn't been resolved and the writing is on the wall, I'll adjust my expectations and move on, no point to hang on to the past if the choice is no longer an option.

[NeddySeagoon]

ndk,

Take a trip down memory lane.
It my view that there is more choice now than years ago and because of the way portage has expanded, the choice is easier to exercise.

[Hu]

Your other points have been addressed in this thread extensively. As for systemd-utils, you're free to turn off every single USE flag apart from tmpfiles, which would make it identical to systemd-tmpfiles.

Why I am not surprised by your answer? I'm not asking what should I do, so don't give me your unsolicited advice. I've been using this distro longer than you are. I remember when people cared about other people's preferences...

Right. If you want to participate in threads, read them in full. This rehashing of trivialities is a waste of everyone's time.

One more cutie... Assuming for others. Thanks.

Gosh, where did Gentoo go wrong and some of its developers became so fragile and being unable to take a different viewpoint...

You raise points that were previously raised, and previously addressed. Your post gives no indication that you have read those prior responses, so from our perspective, the obvious way to handle you is to refer you back to those prior responses. asturm's point was that it is a waste of our time to retype and resend the prior responses that you apparently ignored. As regards your first post in this thread, I personally addressed those points earlier in this thread. sam_ also responded to one such post of mine adding on more detail. They may be other posts in the thread which are also pertinent to your rehashed argument, which I do not recall at the moment. If you have a new argument that is not addressed by those prior responses, you are welcome to share it.

Gentoo offers as much choice as its active maintainers can volunteer the time to provide. If that is not enough choice for you, join in and offer more, or get patches submitted upstream to create new choices for Gentoo to offer you.

We have had multiple people wishing for a resurrection of opentmpfiles for a while. Interestingly, your complaint here is yet more evidence you didn't bother to read before posting, because lumaro posted to announce maintenance of opentmpfiles and eudev. I responded to that post questioning the viability of the resurrection, but I must at least give credit that lumaro is attempting to maintain a resurrected opentmpfiles. Have you read that post? Is lumaro's project insufficient for your needs?

[GDH-gentoo]

It's Sunday, and it seems I am willing to "waste" some time

When I was looking at that CVE, I was in awe...
A "security risk" by providing a config that could only be supplied by root?

Let's be clear: are you claiming that

• CVE-2017-18925 is invalid and should be removed from the CVE list?
• CVE-2017-18925 cannot affect you in your particular case?
• You just want opentmpfiles, period, and don't really care about CVE-2017-18925? (Which is valid stance, but I wish people said it upfront)

Also, I don't uderstand your point about being root. When Portage installs files in /{usr/lib,run,etc}/tmpfiles.d, it does so as root, and when a tmpfiles processor parses those files and acts on them, it also does it as root.

Does the CVE author even understand how security works?

Judge for yourself. Are you able to refute him?

Otherwise I will have to spend my weekend get the heck out of this mess by dropping this so-called 'you have a choice' distro.

You are free to do this (although I'm curious about what would you replace Gentoo with), but lumaro's is the easiest way to keep opentmpfiles: create a local ebuild repository, retrieve the last ebuild for sys-apps/opentmpfiles using Git and put it in the repository, and also put a modified ebuild for virtual/tmpfiles that allows sys-apps/opentmpfiles as a tmpfiles provider. Done.

On the other hand, Gentoo just won't look good keeping a package with a reported, unfixed, and (so far) undisputed vulnerability in the official repository.

I also read between lines... Like here: https://github.com/OpenRC/opentmpfiles/ ... -996131106

vapier gave an opinion, but then reviewed the pull request anyway.

I'm getting tired of hearing that something is 'not possible' or 'hard' or 'not enough people'.

Offering a rant in response might be cathartic, but doesn't address any of those points.

[ndk]

Judge for yourself. Are you able to refute him?

What is here to judge? Seriously?

Take for example the following tmpfiles.d entry, in /etc/tmpfiles.d/exploit.conf:

What part of /etc/tmpfiles.d/exploit.conf is not clear? You HAVE TO BE A ROOT to do this. If you already have a root, WHY THE HELL would anyone bother to write another exploit for the same system?

And by the way: https://bugs.gentoo.org/842216
It looks systemd-tmpfiles suffers from the same 'exploit'...

[GDH-gentoo]

What part of /etc/tmpfiles.d/exploit.conf is not clear? You HAVE TO BE A ROOT to do this.

And? I still do not understand your point. When your service manager of choice runs opentmfiles (or its counterpart in OpenRC-0.17) and parses /etc/tmpfiles.d/exploit.conf, you are root.

If you already have a root, WHY THE HELL would anyone bother to write another exploit for the same system?

Huh?

And by the way: https://bugs.gentoo.org/842216
It looks systemd-tmpfiles suffers from the same 'exploit'...

Addressed by mv in this very thread.

I'd like an answer to the first question in my previous post.

[ndk]

What part of /etc/tmpfiles.d/exploit.conf is not clear? You HAVE TO BE A ROOT to do this.

And? I still do not understand your point. When your service manager of choice runs opentmfiles (or its counterpart in OpenRC-0.17) and parses /etc/tmpfiles.d/exploit.conf, you are root.

If you already have a root, WHY THE HELL would anyone bother to write another exploit for the same system?

Huh?

And by the way: https://bugs.gentoo.org/842216
It looks systemd-tmpfiles suffers from the same 'exploit'...

Addressed by mv in this very thread.

I'd like an answer to the first question in my previous post.

I see... you have troubles understanding the basic concepts...
Here's a link for you: https://letmegooglethat.com/?q=A+Guide+ ... lation&l=1
I sure hope you're not one of the other so Gentoo devs...

[pingtoo]

Here's a link for you: https://letmegooglethat.com/?q=A+Guide+ ... lation&l=1
I sure hope you're not one of the other so Gentoo devs...

I really want to support your argument, and I mostly agree with you about the security prospective point. but the link you provided about is not able to get anywhere, do you mean it be a joke?

[pingtoo]

What part of /etc/tmpfiles.d/exploit.conf is not clear? You HAVE TO BE A ROOT to do this.

And? I still do not understand your point.

I think @ndk point is that he expect /etc/tmpfiles.d be root writable only, in order to deploy a exploit for a non-root user, this non-root user must gain root privilege to write in to /etc/tmpfiles.d, but since the user can gain root privilege, what is the point of securing the tmpfiles.d provider? I do think if someone have root privilege to deploy something configuration to be executed by even system-tempfile, the system-tempfile will also suffer from same problem.

[GDH-gentoo]

I see... you have troubles understanding the basic concepts...

Then enlighten us. You haven't so far.

Here's a link for you: https://letmegooglethat.com/?q=A+Guide+ ... lation&l=1

Yeah. As far as I can tell, CVE-2017-18925 is a case of "2. Exploiting services which are running as root". So?

I sure hope you're not one of the other so Gentoo devs...

Do you see a "Developer" badge under my username?

I'd like an answer to the first question in post #8717993.

[GDH-gentoo]

I think @ndk point is that he expect /etc/tmpfiles.d be root writable only, [...]

It is root-only. No disagreement here.

[...] in order to deploy a exploit for a non-root user, this non-root user must gain root privilege to write in to /etc/tmpfiles.d, [...]

That user can be any user capable or running the package manager to install packages. Some of them can, and do, ship tmpfiles.d *.conf files.

[...] what is the point of securing the tmpfiles.d provider?

Preventing a vulnerability when such a file is parsed and acted on. The mere presence of the file is not a threat per se.

[...] the system-tempfile will also suffer from same problem.

I don't like the whole tmpfiles.d concept, but one of the points raised in this thread is that if that happens, systemd-tmpfiles has someone in charge of fixing it, opentmpfiles, not so much.

[pingtoo]

[...] in order to deploy a exploit for a non-root user, this non-root user must gain root privilege to write in to /etc/tmpfiles.d, [...]

That user can be any user capable or running the package manager to install packages. Some of them can, and do, ship tmpfiles.d *.conf files.

[...] what is the point of securing the tmpfiles.d provider?

Preventing a vulnerability when such a file is parsed and acted on. The mere presence of the file is not a threat per se.

May be it is my poor English understanding so I apologise where I was not explicit, my intention for above two sentences is together to try to said if someone already have the root privilege. no matter how secure the tmpfile.d provider is, the system already compromised. BTW, I do understand in gentoo in order to deploy package, it must be root.

I would argue that there is no vulnerability need to prevent in tmpfile.d provider, since security is not the function of tmpfiles.d provide. Just like systemp-tmpfiles can not preventing a explicit configuration mistake that cause system vulnerability.

[Hu]

As I explained previously, you cannot assume that because the root user (as the Portage process) installed a dangerous file that this implies that a malicious actor has full root privilege. Mere negligence on the part of a non-malicious developer who legitimately uses tmpfiles can lead to the installation of a dangerous tmpfiles configuration file. An unprivileged malicious actor can then try to attack when opentmpfiles unsafely processes this dangerous file.

As far as I know, no one has seriously proposed that Portage can have a simple automated check to recognize and reliably block all dangerous tmpfiles configuration files. I interpret this absence to mean that there is no one who (1) has the expertise to make such a check, and (2) has the interest to spend the time writing it. Additionally, it may (or may not) be the case that the tmpfiles language is too flexible to write a check that has 0% false negatives (failing to recognize bad files) and an acceptable rate of false positives (wrongly rejecting safe files).

[pingtoo]

As I explained previously, you cannot assume that because the root user (as the Portage process) installed a dangerous file that this implies that a malicious actor has full root privilege. Mere negligence on the part of a non-malicious developer who legitimately uses tmpfiles can lead to the installation of a dangerous tmpfiles configuration file. An unprivileged malicious actor can then try to attack when opentmpfiles unsafely processes this dangerous file.

As far as I know, no one has seriously proposed that Portage can have a simple automated check to recognize and reliably block all dangerous tmpfiles configuration files. I interpret this absence to mean that there is no one who (1) has the expertise to make such a check, and (2) has the interest to spend the time writing it. Additionally, it may (or may not) be the case that the tmpfiles language is too flexible to write a check that has 0% false negatives (failing to recognize bad files) and an acceptable rate of false positives (wrongly rejecting safe files).

But that is my point, it is not tmpfiles.d provider responsibility to be absolutely secure, it is the function of the entire system and the process to make secure.

The exploit CVE-2017-18925 does not apply to Gentoo. Because it is unlike the exploit example presented by the CVE author. opentmpfiles/OpenRC does not provide same opportunity as systemd where in systemd tmpfiles.d provider can be trigger executed at time while system is operation. whereas in Gentoo tmpfiles.d only triggered at reboot or someone execute emerge. The example in the CVE said a process need to monitoring the tmpfiles.d execution and capture the moment when a race condition happen in order to get the exploit to open to the malicious actor. And I don't think it is possible to predict when a emerge happen and the particular emerge event will trigger a tmpfiles.d exercise.

The bad actor who can execute emerge does not require tmpfiles.d provider to gain privileged access, have the right to execute emerge already is much bigger security risk.

[Hu]

How can the system fulfill its responsibility of security if it relies on a component that is known to have a security weakness, and the system cannot reliably avoid triggering that weakness?

A Gentoo system administrator may run emerge at arbitrary times, and if unprivileged users have shell access, they can leave a process waiting and watching for emerge to run. Exact prediction is not necessary, because the attacker faces little or no downside to failing.

Although rare, I cannot rule out that there are some Gentoo systems where use of sudo or similar has granted an otherwise unprivileged user the ability to use emerge in a very restricted way. For example, the user might be permitted to run sudo /usr/local/bin/update-specific-ebuild.sh, where that script runs emerge with hard-coded options and with no option for the user to vary the inputs. This would seem safe at first look, but would allow the user to repeatedly and at-will run the ebuild(s) associated with this script. If one of those ebuilds triggers tmpfiles processing, then the user can attach this opentmpfiles problem at-will.

The core problem though is that Gentoo cannot ship a package with a known security defect and no mitigation.

[pingtoo]

The core problem though is that Gentoo cannot ship a package with a known security defect and no mitigation.

I totally agree with this. However one must know it is truly security defect.

How can the system fulfill its responsibility of security if it relies on a component that is known to have a security weakness, and the system cannot reliably avoid triggering that weakness?

Again, my point was that Gentoo did avoid trigger the weakness. But in general I agree with the statement.

A Gentoo system administrator may run emerge at arbitrary times, and if unprivileged users have shell access, they can leave a process waiting and watching for emerge to run. Exact prediction is not necessary, because the attacker faces little or no downside to failing.

I admit I did not think of this, I need to rethink my logic, may be I am wrong here.

Although rare, I cannot rule out that there are some Gentoo systems where use of sudo or similar has granted an otherwise unprivileged user the ability to use emerge in a very restricted way. For example, the user might be permitted to run sudo /usr/local/bin/update-specific-ebuild.sh, where that script runs emerge with hard-coded options and with no option for the user to vary the inputs. This would seem safe at first look, but would allow the user to repeatedly and at-will run the ebuild(s) associated with this script. If one of those ebuilds triggers tmpfiles processing, then the user can attach this opentmpfiles problem at-will.

I need to think about this. I feel this somewhat wrong at fundamental security practice, but I cannot find a reason at this moment. so I will reserve my judgement.

[egberts]

OMG!

Executing emerge --depclean is now begging for systemd, et. al. I am using OpenRC for exactly that reason.

Not this systemd-tmpfiles and now systemd-utils?!

Who is actually doing the EMBRACING, ENGULFING, and possibly the EXTINGUISHING with systemd?

This is shit for brain and a dead albatross being placed around the neck of Gentoo.

(disgusted)

[figueroa]

egberts, you have found but not understood the authoritative voices in this thread. This is not an OMG moment.

[egberts]

Yeah, I get that.

Now doing the

https://wiki.gentoo.org/wiki/User:Neddy ... 21_Edition

[figueroa]

Yeah, I get that.

Now doing the
https://wiki.gentoo.org/wiki/User:Neddy ... 21_Edition

Good for you!

[NeddySeagoon]

egberts,

That guide is woefully incomplete. I'll answer questions in you start discussion topics or post in the Unsupported Software forum here.

systemd-utils is what was three separate ebuilds of systemd bits and pieces rolled into one ebuild for ease of maintenance.

[stefan11111]

I will revive this thread as I was pointed to it a few days ago.
As far as I can see these are the options:
-Keep using systemd-tmpfiles.
-Use opentmpfiles or a fork.
-Freeze openrc at version 0.17.
I have opened this thread about it:
https://forums.gentoo.org/viewtopic-t-1161826-highlight-.html
On my system, simply unmerging systemd-tmpfiles and adding virtual-tmpfiles to package.provided seemed to do the trick.
I have noticed no issues regarding it since starting that thread.
These are the packages that have a dependency on tmpfiles:

Code: Select all

$ equery d tmpfiles
 * These packages depend on tmpfiles:
app-portage/eix-0.36.6 (virtual/tmpfiles)
app-portage/gentoolkit-0.6.1-r3 (virtual/tmpfiles)
net-fs/samba-4.16.8 (virtual/tmpfiles)
sys-apps/man-db-2.11.2 (virtual/tmpfiles)
sys-apps/openrc-0.46 (virtual/tmpfiles)

The list is smaller than in the original thread because I managed to remove dbus from my system.
So how many packages actually need tmpfiles?