Re: [gentoo-dev] PSA: switching default tmpfiles virtual provider
On Sun, Nov 29, 2020 at 4:50 PM William Hubbs wrote: > > On Thu, Nov 26, 2020 at 07:55:33AM +0100, Piotr Karbowski wrote: > > Hi, > > > > On 25/11/2020 22.57, Georgy Yakovlev wrote: > > > systemd-tmpfiles does not depend on any systemd-isms, does not need dbus, > > > and is just a drop-in replacement, the only step needed is to emerge the > > > package. > > > it's a simple single binary + manpage, binary links to libacl and couple > > > other > > > system libs. > > > > Can confirm that systemd-tmpfiles works fine on OpenRC systems. Been > > using it since end of October. > > > > Two things that are different in terms of interface to opentmpfiles is > > that systemd-tmpfiles does not have --dry-run runtime option, and it > > will complain if any /usr/lib/tmpfiles.d/*.conf uses /var/run instead of > > /run, but that's just an warning. > > Also, have we tested this on musl systems? > > My plan is to take the tmpfiles code from systemd, like eudev and elogin > have done, and rewrite it to not use the systemd libraries so it will be > more portable. I think this is a bigger task than you realize. Even if you manage to get an initial rewrite done, you would also need to keep up with feature updates systemd releases. That hasn't worked out for eudev, and I doubt it would work out for this yet-to-exist tmpfiles project. Maintaining a patchset against the systemd sources is probably the best path forward on this.
Re: [gentoo-dev] PSA: switching default tmpfiles virtual provider
On Thu, Nov 26, 2020 at 07:55:33AM +0100, Piotr Karbowski wrote: > Hi, > > On 25/11/2020 22.57, Georgy Yakovlev wrote: > > systemd-tmpfiles does not depend on any systemd-isms, does not need dbus, > > and is just a drop-in replacement, the only step needed is to emerge the > > package. > > it's a simple single binary + manpage, binary links to libacl and couple > > other > > system libs. > > Can confirm that systemd-tmpfiles works fine on OpenRC systems. Been > using it since end of October. > > Two things that are different in terms of interface to opentmpfiles is > that systemd-tmpfiles does not have --dry-run runtime option, and it > will complain if any /usr/lib/tmpfiles.d/*.conf uses /var/run instead of > /run, but that's just an warning. Also, have we tested this on musl systems? My plan is to take the tmpfiles code from systemd, like eudev and elogin have done, and rewrite it to not use the systemd libraries so it will be more portable. Once this happens, I'll probably switch the provider back to opentmpfiles. William signature.asc Description: PGP signature
Re: [gentoo-dev] PSA: switching default tmpfiles virtual provider
On 25.11.2020 13:57, Georgy Yakovlev wrote: > Hi, > > In case you don't know, opentmpfiles has an open CVE > CVE-2017-18925: root privilege escalation by symlink attack > https://github.com/OpenRC/opentmpfiles/issues/4 > It has been an issue for quite a while, reported 3 years ago, > and not much changed since. > Also it lacks any sort of testing, and master branch is in a non-working > state at time of writing, latest version is masked.[0] > > Due to nature of opentmpfiles (it's a POSIX sh script), > it may be impossible to fix symlink handling and TOCTOU races. > As a consequence I'll be switching default tmpfiles > provider to sys-apps/systemd-tmpfiles by the end of the week by updating > virtual/tmpfiles ebuild. > > pros of systemd-tmpfiles: > 0) Secure. > 1) Reference implementation. > 2) Supports all features, because ^. > 3) Has working tests. > 4) Has millions of users as part of systemd. > 5) upstream supports standalone usecase/build our ebuild uses. [1][2] > 6) drop-in replacement, just emerge and forget. > > systemd-tmpfiles does not depend on any systemd-isms, does not need dbus, > and is just a drop-in replacement, the only step needed is to emerge the > package. > it's a simple single binary + manpage, binary links to libacl and couple other > system libs. > > existing installations will not be affected, but openrc users are welcome to > opt-in by running 'emerge --oneshot systemd-tmpfiles' > > [0] https://bugs.gentoo.org/751739 > [1] https://github.com/systemd/systemd/pull/16061 > [2] > https://github.com/systemd/systemd/pull/16061/commits/db64ba81c62afa0e0d3e95c4a3e1ec3dd9a471a4 This is done in https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ab23417927d8454c8bb1c0ae52a5cac79d140b94 signature.asc Description: PGP signature
Re: [gentoo-dev] PSA: switching default tmpfiles virtual provider
On 11/26/20 5:57 PM, Thomas Deutschmann wrote: > > I disagree here: Packages installing tmpfiles configs requiring > recursive chown on each boot are doing something wrong from my P.O.V. No argument there, but me thinking they're wrong doesn't stop people from doing it. > Note that hardlinks aren't even fixed for systemd's tmpfiles provider. > It will always rely on fs.protected_hardlinks for example. And checking > for hardlinks like happened to address CVE-2017-18078 will create > another TOCTOU race. Where is the follow-up report for this? Systemd only supports Linux, and sets fs.protected_hardlinks=1 itself. There's not much more we can ask from them. I normally err on the side of caution, but if someone goes out of their way to disable a security setting, I don't consider it CVE-worthy if the thing that setting was preventing is now exploitable. > In short: As long as it is possible for attacker to write to directory > you are working on you can never do mentioned things in a safe way. You > first have to revoke access for everyone except you and then you can > start checking file per file... but *no* implementation is doing > something like that. This came up in the old (late 1990s, early 2000s) LKML discussions about the protected_* sysctls. The Right Thing To Do is to drop privileges to the user who owns the directory if you need to do stuff in a directory that a user owns or can write to. To quote your earlier message: > Rule of thumb: Just make sure that you only create top level directories. ...and then drop privileges.
Re: [gentoo-dev] PSA: switching default tmpfiles virtual provider
On Thu, 2020-11-26 at 17:45 -0500, Michael Orlitzky wrote: > On 11/26/20 5:37 PM, Peter Stuge wrote: > > Georgy Yakovlev wrote: > > > I'll be switching default tmpfiles provider to sys-apps/systemd- > > > tmpfiles > > > by the end of the week by updating virtual/tmpfiles ebuild. > > > > Michael Orlitzky wrote: > > > Corollary: the tmpfiles.d specification can only be implemented > > > (safely) > > > on Linux after all. > > > > So should virtual/tmpfiles differentiate based on system? > > > > There's no scenario where opentmpfiles is preferable. > > systemd-tmpfiles with the fs.protected_hardlinks=1 sysctl is secure on > Linux. On other kernels, you're out of luck -- none of the options are > secure. Securing the service manager on other kernels would require > dropping tmpfiles entirely, and major changes to OpenRC. > ...which is mostly a theoretical exercise, because we only support Linux anyways.
Re: [gentoo-dev] PSA: switching default tmpfiles virtual provider
On 2020-11-26 21:36, Michael Orlitzky wrote: Most of these security issues were fixed in systemd-tmpfiles years ago, and you can easily find upstream tmpfiles.d entries that contain e.g. "Z" entries. In that case, the upstream file is not in error, and root doesn't have to be actively tricked into installing anything -- it will just happen. I disagree here: Packages installing tmpfiles configs requiring recursive chown on each boot are doing something wrong from my P.O.V. like you can never safely do that (you can only take precaution like not following symlinks but in this case you don't do what you were asked to do so you shouldn't return 'Yup, I chowned everything like you asked me to do'). Opentmpfiles literally cannot fix this. There is no POSIX API to safely handle hardlinks. At best it can be reduced to the same race condition we have in checkpath, but the entire project would have to be rewritten in C to accomplish even that. Note that hardlinks aren't even fixed for systemd's tmpfiles provider. It will always rely on fs.protected_hardlinks for example. And checking for hardlinks like happened to address CVE-2017-18078 will create another TOCTOU race. Where is the follow-up report for this? In short: As long as it is possible for attacker to write to directory you are working on you can never do mentioned things in a safe way. You first have to revoke access for everyone except you and then you can start checking file per file... but *no* implementation is doing something like that. And keep in mind: We are talking about an attack vector where we already assume someone successfully compromised an application and can now do everything the application user can do for which we do the work in tmpfiles config. Saying that systemd's implementation is more secure than OpenTmpfiles' implementation when you are still able to escalate privileges is very misleading. -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] PSA: switching default tmpfiles virtual provider
On 11/26/20 5:37 PM, Peter Stuge wrote: > Georgy Yakovlev wrote: >> I'll be switching default tmpfiles provider to sys-apps/systemd-tmpfiles >> by the end of the week by updating virtual/tmpfiles ebuild. > > Michael Orlitzky wrote: >> Corollary: the tmpfiles.d specification can only be implemented (safely) >> on Linux after all. > > So should virtual/tmpfiles differentiate based on system? > There's no scenario where opentmpfiles is preferable. systemd-tmpfiles with the fs.protected_hardlinks=1 sysctl is secure on Linux. On other kernels, you're out of luck -- none of the options are secure. Securing the service manager on other kernels would require dropping tmpfiles entirely, and major changes to OpenRC.
Re: [gentoo-dev] PSA: switching default tmpfiles virtual provider
> On 26 Nov 2020, at 22:37, Peter Stuge wrote: > Michael Orlitzky wrote: >> Corollary: the tmpfiles.d specification can only be implemented (safely) >> on Linux after all. > > So should virtual/tmpfiles differentiate based on system? > It won’t be keyworded where it’s not available so Portage will skip over it. systemd only supports certain platforms. > > //Peter > signature.asc Description: Message signed with OpenPGP
Re: [gentoo-dev] PSA: switching default tmpfiles virtual provider
Georgy Yakovlev wrote: > I'll be switching default tmpfiles provider to sys-apps/systemd-tmpfiles > by the end of the week by updating virtual/tmpfiles ebuild. Michael Orlitzky wrote: > Corollary: the tmpfiles.d specification can only be implemented (safely) > on Linux after all. So should virtual/tmpfiles differentiate based on system? //Peter
Re: [gentoo-dev] PSA: switching default tmpfiles virtual provider
On 11/26/20 10:07 AM, Thomas Deutschmann wrote: > > Only root is allowed to write to these directories. In other words: To > exploit this, a malicious local user (or a remote attacker who already > gained user access) would have to trick root into creating specially > crafted tmpfiles config allowing for race conditions first (according to > the 10 immutable laws of security, if this is already possible, you are > already lost). Most of these security issues were fixed in systemd-tmpfiles years ago, and you can easily find upstream tmpfiles.d entries that contain e.g. "Z" entries. In that case, the upstream file is not in error, and root doesn't have to be actively tricked into installing anything -- it will just happen. Opentmpfiles literally cannot fix this. There is no POSIX API to safely handle hardlinks. At best it can be reduced to the same race condition we have in checkpath, but the entire project would have to be rewritten in C to accomplish even that. Corollary: the tmpfiles.d specification can only be implemented (safely) on Linux after all.
Re: [gentoo-dev] PSA: switching default tmpfiles virtual provider
Hi, I don't have any objections regarding the change of the default tmpfiles provider but I would like to classify the vulnerability: On 2020-11-25 22:57, Georgy Yakovlev wrote: In case you don't know, opentmpfiles has an open CVE CVE-2017-18925: root privilege escalation by symlink attack https://github.com/OpenRC/opentmpfiles/issues/4 It has been an issue for quite a while, reported 3 years ago, and not much changed since. Don't get scared by 'root privilege escalation': *Any* problem in *any* tmpfiles provider will *always* allow for root privilege escalation because this service is run by root early at boot. In theory you could create a user for this service but you would need CAP_DAC_OVERRIDE privileges which would again allow for root privilege escalation. Regarding CVE-2017-18925 itself: First you have to understand that anyone can request a CVE and that it isn't CNA's job to verify your report. That's it, having a CVE doesn't mean that a problem was confirmed. A CVE is just an identifier which should allow anyone who want to talk about the same problem to do that. For example when we file bug 123 in bugs.gentoo.org and Fedora would have the same package and experience the same issue they would file bug 456 in their bug tracker -- the goal of a CVE is just to connect information regarding the same issue -- in this example, the CVE would get references to Gentoo's bug 123 and Fedora's bug 456. The bug itself is about a race condition. This race condition is real. However, the impact is questionable: tmpfiles service will only process files from /etc/tmpfiles.d/*.conf /run/tmpfiles.d/*.conf /usr/lib/tmpfiles.d/*.conf Only root is allowed to write to these directories. In other words: To exploit this, a malicious local user (or a remote attacker who already gained user access) would have to trick root into creating specially crafted tmpfiles config allowing for race conditions first (according to the 10 immutable laws of security, if this is already possible, you are already lost). If root doesn't install any tmpfiles config which will create such a race condition and if package maintainer will take care that their packages won't do the same, you are fine. Rule of thumb: Just make sure that you only create top level directories. If something already exists, error out. Because whenever you try to work in a directory where any other user is able to write to at the same time, you are always vulnerable to such a race condition (that's why you should have a second level for actual user data and keep first level for ACL handling -- the service user must only be allowed to pass through this directory). PS: Just to avoid any misunderstandings: OpenTmpfiles should of course try to fix/avoid this problem if possible. Security is a layered process (like an onion) and having multiple safe-guards is always a good thing. -- Regards, Thomas Deutschmann / Gentoo Security Team fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] PSA: switching default tmpfiles virtual provider
Hi, On 25/11/2020 22.57, Georgy Yakovlev wrote: > systemd-tmpfiles does not depend on any systemd-isms, does not need dbus, > and is just a drop-in replacement, the only step needed is to emerge the > package. > it's a simple single binary + manpage, binary links to libacl and couple other > system libs. Can confirm that systemd-tmpfiles works fine on OpenRC systems. Been using it since end of October. Two things that are different in terms of interface to opentmpfiles is that systemd-tmpfiles does not have --dry-run runtime option, and it will complain if any /usr/lib/tmpfiles.d/*.conf uses /var/run instead of /run, but that's just an warning. Regardless, it's just a drop-in replacement, have not noticed any issues. -- Piotr.
[gentoo-dev] PSA: switching default tmpfiles virtual provider
Hi, In case you don't know, opentmpfiles has an open CVE CVE-2017-18925: root privilege escalation by symlink attack https://github.com/OpenRC/opentmpfiles/issues/4 It has been an issue for quite a while, reported 3 years ago, and not much changed since. Also it lacks any sort of testing, and master branch is in a non-working state at time of writing, latest version is masked.[0] Due to nature of opentmpfiles (it's a POSIX sh script), it may be impossible to fix symlink handling and TOCTOU races. As a consequence I'll be switching default tmpfiles provider to sys-apps/systemd-tmpfiles by the end of the week by updating virtual/tmpfiles ebuild. pros of systemd-tmpfiles: 0) Secure. 1) Reference implementation. 2) Supports all features, because ^. 3) Has working tests. 4) Has millions of users as part of systemd. 5) upstream supports standalone usecase/build our ebuild uses. [1][2] 6) drop-in replacement, just emerge and forget. systemd-tmpfiles does not depend on any systemd-isms, does not need dbus, and is just a drop-in replacement, the only step needed is to emerge the package. it's a simple single binary + manpage, binary links to libacl and couple other system libs. existing installations will not be affected, but openrc users are welcome to opt-in by running 'emerge --oneshot systemd-tmpfiles' [0] https://bugs.gentoo.org/751739 [1] https://github.com/systemd/systemd/pull/16061 [2] https://github.com/systemd/systemd/pull/16061/commits/db64ba81c62afa0e0d3e95c4a3e1ec3dd9a471a4 signature.asc Description: PGP signature
