FSF Blogs: Free Software Supporter -- Issue 199, November 2024
Welcome to the Free Software Supporter, the Free Software Foundation's (FSF) monthly news digest and action update -- being read by you and 231,355 other activists.
#gnu
GNUnet News: GNUnet 0.22.2
GNUnet 0.22.2
This is a bugfix release for gnunet 0.22.1. It fixes some regressions and minor bugs.
Links
- Source: https://ftpmirror.gnu.org/gnunet/gnunet-0.22.2.tar.gz ( https://ftpmirror.gnu.org/gnunet/gnunet-0.22.2.tar.gz.sig )
- Source (meson): https://buildbot.gnunet.org/releases/gnunet-0.22.2-meson.tar.gz ( https://buildbot.gnunet.org/releases/gnunet-0.22.2-meson.tar.gz.sig )
- Detailed list of changes: https://git.gnunet.org/gnunet.git/log/?h=v0.22.2
- NEWS: https://git.gnunet.org/gnunet.git/tree/NEWS?h=v0.22.2
- The list of closed issues in the bug tracker: https://bugs.gnunet.org/changelog_page.php?version_id=459
The GPG key used to sign is: 3D11063C10F98D14BD24D1470B0998EF86F59B6A
Note that due to mirror synchronization, not all links may be functional early after the release. For direct access try https://ftp.gnu.org/gnu/gnunet/
FSF Events: Free Software Directory meeting on IRC: Friday, November 1, starting at 12:00 EDT (16:00 UTC)
Join the FSF and friends on Friday, November 1 from 12:00 to 15:00 EDT (16:00 to 19:00 UTC) to help improve the Free Software Directory.
FSF Blogs: FSD meeting recap 2024-10-25
Check out the important work our volunteers accomplished at today's Free Software Directory (FSD) IRC meeting.
"Manche Anwender:innen sind es auch einfach satt, sich von Microsoft gängeln zu lassen und wünschen sich ein freies und selbstbestimmtes Betriebssystem und Anwendungen für ihren täglichen Gebrauch."
#GNU/Linux #Umstieg #Windows #Microsoft #Privatsphäre #Datenschutz #Freiheit #PoweredByRSS
Debian is Debian 🐧✊
#debian #linux #gnu #distro #distribution #nerd #humor #software #os #discussion
www-ru @ Savannah: Разговор о свободных программах в Москве
Компьютеры и сети содействуют нам в борьбе за свободу: они помогают посвятить время и силы важным общественным инициативам, организовывать протесты, защищаться от цензуры.
Но свободны ли наши компьютеры? И свободны ли мы как пользователи?
Обсудим эти вопросы 25 октября в 19:00 в Открытом пространстве с Глебом Ерофеевым — активистом движения за свободные программы и волонтёром проекта "ГНУ", который в 1983 году запустил философ и активист Ричард Столлман.
Команда проекта "ГНУ" занимается разработкой свободного софта и техноэтическим активизмом, чтобы дать пользователям контроль над их компьютерами и искоренить несправедливость, которую приносят в общество собственнические программы.
Адрес: Плетешковский пер., 8с1 (м. "Бауманская").
Участие бесплатно. Приветствуются пожертвования в пользу пространства.
MediaGoblin — https://mediagoblin.org/
The origins of GNU MediaGoblin date back to 2008, when a gathering was held at the Free Software Foundation in order to discuss the path that Internet communities should take. The answer was that restrictive and centralized structures were both technically and ethically doubtful, and may harm the typical fairness and availability of the Internet. Several projects have since appeared to prevent this, including Identi.ca, Libre.fm, Diaspora, among others.
The MediaGoblin project remains in active development. — https://en.wikipedia.org/wiki/MediaGoblin
Parabola GNU/Linux-libre: manual intervention required for local pacman repositories
NOTE: pacman v7 is currently in [libre-testing]; but it will be promoted to libre soon
from arch:
With the release of [version 7.0.0] pacman has added support for downloading packages as a separate user with dropped privileges.
For users with local repos however this might imply that the download user does not have access to the files in question, which can be fixed by assigning the files and folder to the alpm group and ensuring the executable bit (+x) is set on the folders in question.
$ chown :alpm -R /path/to/local/repo
Remember to [merge the .pacnew] files to apply the new default.
Pacman also introduced [a change] to improve checksum stability for git repos that utilize .gitattributes files. This might require a one-time checksum change for PKGBUILDs that use git sources.
11 Russians removed from Linux kernel software development project over alleged “compliance requirements” — https://theins.ru/en/news/275585
see: [PATCH] MAINTAINERS: Remove some entries due to various compliance requirements. - Greg Kroah-Hartman — https://lore.kernel.org/all/2024101835-tiptop-blip-09ed@gregkh/ [archive] [via]
#gnu #linux #Kroah-Hartman #russia @fefe
FSF News: FSF is working on freedom in machine learning applications
BOSTON (October 22, 2024) -- The Free Software Foundation (FSF) has announced today that it is working on a statement of criteria for free machine learning applications, which will require the software, as well as the raw training data and associated scripts, to grant users the four freedoms.
command line - Why is a virtual terminal “virtual”, and what/why/where is the “real” terminal? - Ask Ubuntu — https://askubuntu.com/questions/14284/why-is-a-virtual-terminal-virtual-and-what-why-where-is-the-real-terminal
#terminals #gnu #linux #unix
GNU Guix: Build User Takeover Vulnerability
A security issue has been identified in guix-daemon which allows for a local user to gain the privileges of any of the build users and subsequently use this to manipulate the output of any build. Your are strongly advised to upgrade your daemon now (see instructions below), especially on multi-user systems.
This exploit requires the ability to start a derivation build and the ability to run arbitrary code with access to the store in the root PID namespace on the machine the build occurs on. As such, this represents an increased risk primarily to multi-user systems and systems using dedicated privilege-separation users for various daemons: without special sandboxing measures, any process of theirs can take advantage of this vulnerability.
Vulnerability
For a very long time, guix-daemon has helpfully made the outputs of failed derivation builds available at the same location they were at in the build container. This has aided greatly especially in situations where test suites require the package to already be installed in order to run, as it allows one to re-run the test suite interactively outside of the container when built with --keep-failed. This transferral of store items from inside the chroot to the real store was implemented with a simple rename, and no modification of the store item or any files it may contain.
If an attacker starts a build of a derivation that creates a binary with the setuid and/or setgid bit in an output directory, then, and the build fails, that binary will be accessible unaltered for anybody on the system. The attacker or a cooperating user can then execute the binary, gain the privileges, and from there use a combination of signals and procfs to freeze a builder, open any file it has open via /proc/$PID/fd, and overwrite it with whatever it wants. This manipulation of builds can happen regardless of which user started the build, so it can work not only for producing compromised outputs for commonly-used programs before anybody else uses them, but also for compromising any builds another user happens to start.
A related vulnerability was also discovered concerning the outputs of successful builds. These were moved - also via rename() - outside of the container prior to having their permissions, ownership, and timestamps canonicalized. This means that there also exists a window of time for a successful build's outputs during which a setuid/setgid binary can be executed.
In general, any time that a build user running a build for some submitter can get a setuid/setgid binary to a place the submitter can execute it, it is possible for the submitter to use it to take over the build user. This situation always occurs when --disable-chroot is passed to guix-daemon. This holds even in the case where there are no dedicated build users, and builds happen under the same user the daemon runs as, as happens during make check in the guix repository. Consequently, if a permissive umask that allows execute permission for untrusted users on directories all the way to a user's guix checkout is used, an attacker can use that user's test-environment daemon to gain control over their user while make check is running.
Mitigation
This security issue has been fixed by two commits. Users should make sure they have updated to the second commit to be protected from this vulnerability. Upgrade instructions are in the following section. If there is a possibility that a failed build has left a setuid/setgid binary lying around in the store by accident, run guix gc to remove all failed build outputs.
The fix was accomplished by sanitizing the permissions of all files in a failed build output prior to moving it to the store, and also by waiting to move successful build outputs to the store until after their permissions had been canonicalized. The sanitizing was done in such a way as to preserve as many non-security-critical properties of failed build outputs as possible to aid in debugging. After applying these two commits, the guix package in Guix was updated so that guix-daemon deployed using it would use the fixed version.
If you are using --disable-chroot, whether with dedicated build users or not, make sure that access to your daemon's socket is restricted to trusted users. This particularly affects anyone running make check and anyone running on GNU/Hurd. The former should either manually remove execute permission for untrusted users on their guix checkout or apply this patch, which restricts access to the test-environment daemon to the user running the tests. The latter should adjust the ownership and permissions of /var/guix/daemon-socket, which can be done for Guix System users using the new socket-directory-{perms,group,user} fields in this patch.
A proof of concept is available at the end of this post. One can run this code with:
guix repl -- setuid-exposure-vuln-check.scm
This will output whether the current guix-daemon being used is vulnerable or not. If it is vulnerable, the last line will contain your system is not vulnerable, otherwise the last line will contain YOUR SYSTEM IS VULNERABLE.
Upgrading
Due to the severity of this security advisory, we strongly recommend all users to upgrade their guix-daemon immediately.
For Guix System, the procedure is to reconfigure the system after a guix pull, either restarting guix-daemon or rebooting. For example:
guix pull
sudo guix system reconfigure /run/current-system/configuration.scm
sudo herd restart guix-daemon
where /run/current-system/configuration.scm is the current system configuration but could, of course, be replaced by a system configuration file of a user's choice.
For Guix running as a package manager on other distributions, one needs to guix pull with sudo, as the guix-daemon runs as root, and restart the guix-daemon service, as documented. For example, on a system using systemd to manage services, run:
sudo --login guix pull
sudo systemctl restart guix-daemon.service
Note that for users with their distro's package of Guix (as opposed to having used the install script) you may need to take other steps or upgrade the Guix package as per other packages on your distro. Please consult the relevant documentation from your distro or contact the package maintainer for additional information or questions.
Conclusion
Even with the sandboxing features of modern kernels, it can be quite challenging to synthesize a situation in which two users on the same system who are determined to cooperate nevertheless cannot. Guix has an especially difficult job because it needs to not only realize such a situation, but also maintain the ability to interact with both users itself, while not allowing them to cooperate through itself in unintended ways. Keeping failed build outputs around for debugging introduced a vulnerability, but finding that vulnerability because of it enabled the discovery of an additional vulnerability that would have existed anyway, and prompted the use of mechanisms for securing access to the guix daemon.
I would like to thank Ludovic Courtès for giving feedback on these vulnerabilities and their fixes — discussion of which led to discovering the vulnerable time window with successful build outputs — and also for helping me to discover that my email server was broken.
Proof of Concept
Below is code to check if your guix-daemon is vulnerable to this exploit. Save this file as setuid-exposure-vuln-check.scm and run following the instructions above, in "Mitigation."
(use-modules (guix)
(srfi srfi-34))
(define maybe-setuid-file
;; Attempt to create a setuid file in the store, with one of the build
;; users as its owner.
(computed-file "maybe-setuid-file"
#~(begin
(call-with-output-file #$output (const #t))
(chmod #$output #o6000)
;; Failing causes guix-daemon to copy the output from
;; its temporary location back to the store.
(exit 1))))
(with-store store
(let* ((drv (run-with-store store
(lower-object maybe-setuid-file)))
(out (derivation->output-path drv)))
(guard (c (#t
(if (zero? (logand #o6000 (stat:perms (stat out))))
(format #t "~a is not setuid: your system is not \
vulnerable.~%"
out)
(format #t "~a is setuid: YOUR SYSTEM IS VULNERABLE.
Run 'guix gc' to remove that file and upgrade.~%"
out))))
(build-things store (list (derivation-file-name drv))))))
GNU Health: GHCon2024, the GNU Health Conference . Palermo, Italy
Dear community:
We’re excited to announce the IX International GNU Health Conference, that will take place in beautiful Sicily, Italy, at the University of Palermo this December 15th.
Mount Etna rising over suburbs of Catania, Sicily (Wikimedia)
The GNU Health Conference (GHCon) is the annual conference that brings together enthusiasts and developers of GNU Health, the Libre digital health ecosystem. The conference will have thematic sessions, lightning talks and implementation cases to get to know the GNU Health and other Free/Libre software communities from around the world.
We will show the upcoming features of the Health and Hospital Information System, standards, security, privacy, the GNU Health Federation and MyGNUHealth (the Personal Health Record).
GHCon2024 – The IX International GNU Health Conference
The XVII International Workshop on eHealth in Emerging Economies (IWEEE) is about Social Medicine and addressing the reality of the underprivileged around the world. There will be workshops to debate, and share experiences from humanitarian organizations and from those working in field of Social Medicine.
In the evening we will announce and honor the winners of the GNU Health Social Medicine awards.
We are counting on you to get the most out of the conference. Most importantly, we want you to have fun, feel at home, and enjoy being part
of the GNU Health community.
Looking forward to seeing you in Sicily!
Happy Hacking!
GHCon2024 homepage: https://www.gnuhealth.org/ghcon
Registration: https://my.gnusolidario.org/ghcon2024-registration/
Follow us in Mastodon (https://mastodon.social/@gnuhealth) for the latest news.
You can share the news using the tag #GHCon2024
health @ Savannah: GHcon2024, the GNUHealth Conference will be in Palermo, Italy - December 15th
Dear community:
We're excited to announce the IX International GNU Health Conference, that will take place in beautiful Sicily, Italy, at the University of Palermo this December 15th.
The GNU Health Conference (GHCon) is the annual conference that brings together enthusiasts and developers of GNU Health, the Libre digital health ecosystem. The conference will have thematic sessions, lightning talks and implementation cases to get to know the GNU Health and other Free/Libre software communites from around the world.
We will show the upcoming features of the Health and Hospital Information System, standards, security, privacy, the GNU Health Federation and MyGNUHealth (the Personal Health Record)
The XVII International Workshop on eHealth in Emerging Economies (IWEEE) is about Social Medicine and addressing the reality of the underprivileged around the world. There will be workshops to debate, and share experiences from humanitarian organizations and from those working in field of Social Medicine.
In the evening we will announce and honor the winners of the GNU Health Social Medicine awards.
We are counting on you to get the most out of the conference. Most importantly, we want you to have fun, feel at home, and enjoy being part of the GNU Health community!
Happy Hacking!
Homepage: https://www.gnuhealth.org/ghcon
Registration: https://my.gnusolidario.org/ghcon2024-registration/
Follow us in Mastodon (https://mastodon.social/@gnuhealth) for the latest news.
Happy hacking!
You can share the news using the tag #GHCon2024