pnutzh4x0r

Following arguments on the Linux kernel mailing list the past few days over some Linux kernel maintainers being against the notion of Rust code in the mainline Linux kernel and trying to avoid it and very passionate views over the Linux kernel development process, Asahi Linux lead developer Hector Martin has removed himself from being an upstream maintainer of the ARM Apple code.

cross-posted from: https://lemmy.ndlug.org/post/1401792

This report summarizes insights from the inaugural 2024 Open Source Software Funding Survey, a collaboration between GitHub, the Linux Foundation, and researchers from Harvard University. The objective of the survey was to better understand how organizations fund, contribute to, and otherwise support open s ource software.

Survey Respondents 159 respondents to the survey collectively contribute $1.7 billion (2023 USD) in annual value to open source. 86% comes in the form of contribution labor by employees. Extrapolating survey to all organizations active in open source Using the survey responses on contribution, we estimate that organizations contribute $7.7 billion annually to OSS.

Bcachefs lead developer Kent Overstreet published a Patreon post this evening entitled "Trouble in the kernel" where he explained:

"TLDR: the future of bcachefs in the kernel is uncertain, and lots of things aren't looking good.

Linus has said he isn't accepting my 6.13 pull request, per "an open issue with the CoC board", and at this point I have no idea what's going on with the CoC board. I, for my part, have felt for quite some time that there are issues about our culture and the way we do work that need to be raised, and that hasn't been going anywhere - hence this post."

It appears that the source of this violation can be found in this Linux kernel mailing list thread.

I saw plenty of efforts that aim to create a Linux distribution for non-enthusiasts, for people who just want to use their computers, and not care about the details - A Desktop for All on the GNOME blog, most recently. While I commend the effort, my own experience is that these efforts are futile, and start off from a fundamentally wrong premise: that people are willing (let alone wanting) to manage their own operating systems.

...

My family is using Linux because that’s the system I can maintain for them. Apart from my Dad, they never installed Linux, and never will. They don’t install software, they don’t upgrade, they don’t change settings either. All of that is something I do for them. And to do so effectively, I need a distribution I am familiar with, one that is also flexible enough to fine-tune for every member of the family, because they prefer fundamentally different things!

...

The common pattern between all these three is that neither of them maintains their own systems. I do. As such, how beginner friendly the distribution is, is meaningless. The users of the system don’t care, they’ll never see those parts. They’ll have a preconfigured system maintained by someone else, and that’s exactly what they want. To make this work, I’m using distributions I am familiar with. For my parents, that’s Debian, because I was a Debian person when their systems were installed. For my Wife, it is NixOS, because I’m a NixOS person now. For the Twins, it will likely be NixOS too.

A new patch series posted today to the Linux kernel mailing list would block kernel modules/drivers from TUXEDO Computers from accessing GPL-only symbols in the kernel.

TUXEDO Computers maintains a set of kernel drivers currently out-of-tree for their various laptops for additional functionality around power profiles, keyboard backlight controls, WMI, sensor monitoring, the embedded controller, and other functionality. They have said they want to eventually mainline these drivers but in the name of allowing for rapid hardware support they maintain them out-of-tree and ship them with their Ubuntu-based TUXEDO OS and also have the driver sources available via GitLab.

The issue at hand though is that these kernel drivers marked as GPLv3+ and that conflicts with the upstream Linux kernel code licensed as GPLv2. There was a commit to change the driver license from GPLv3 to GPL(v2) but was reverted by TUXEDO Computers on the basis of "until the legal stuff is sorted out."

Update: TUXEDO Computers Relicenses Some Of Their Drivers To GPLv2

As of yesterday, TUXEDO Computers has now been able to re-license their driver consisting of fully in-house code from GPLv3 to GPLv2+. These are the TUXEDO Computers drivers where it's all written by TUXEDO employees and not having to worry about code from any third-party developers or other vendors.

The gxtp7380, ite_8291, ite_8291_lb, ite_8297, stk8321, tuxedo_compatibility_check, tuxedo_nb02_nvidia_power_ctrl, and tuxedo_tuxi drivers are the initial ones able to be moved to the GPLv2+ licensing for satisfying upstream Linux kernel developers. Moving the other drivers to GPLv2+ will take longer due to needing to check with the associated parties that contributed to those drivers.

If you love exploit mitigations, you may have heard of a new system call named mseal landing into the Linux kernel’s 6.10 release, providing a protection called “memory sealing.” Beyond notes from the authors, very little information about this mitigation exists. In this blog post, we’ll explain what this syscall is, including how it’s different from prior memory protection schemes and how it works in the kernel to protect virtual memory. We’ll also describe the particular exploit scenarios that mseal helps stop in Linux userspace, such as stopping malicious permissions tampering and preventing memory unmapping attacks.

Memory sealing allows developers to make memory regions immutable from illicit modifications during program runtime. When a virtual memory address (VMA) range is sealed, an attacker with a code execution primitive cannot perform subsequent virtual memory operations to change the VMA’s permissions or modify how it is laid out for their benefit.

...

mseal digresses from prior memory protection schemes on Linux because it is a syscall tailored specifically for exploit mitigation against remote attackers seeking code execution rather than potentially local ones looking to exfiltrate sensitive secrets in-memory.

...

From the disallowed operations, we can discern two particular exploit scenarios that memory sealing will prevent:

• Tampering with a VMA’s permissions. Notably, not allowing executable permissions to be set can stop the revival of shellcode-based attacks.
• “Hole-punching” through arbitrary unmapping/remapping of a memory region, mitigating data-only exploits that take advantage of refilling memory regions with attacker-controlled data.

...

There are likely many other use cases and scenarios that we didn’t cover. After all, mseal is the newest kid on the block in the Linux kernel! As the glibc integration completes and matures, we expect to see improved iterations for the syscall to meet particular demands, including fleshing out the ultimate use of the flags parameter.

Drivers passing through San Francisco have a new roadside distraction to consider: billboards calling out businesses that don't cough up for the open source code that they use.

The signs are the work of the Open Source Pledge – a group that launched earlier this month. It asks businesses that make use of open source code to pledge $2,000 per developer to support projects that develop the code. So far, 25 companies have signed up – but project co-founder Chad Whitacre wants bigger firms to pay their dues, too.

Google is developing a Terminal app for Android that'll let you run Linux apps. It'll download and run Debian in a VM for you.

...

Engineers at Google started work on a new Terminal app for Android a couple of weeks ago. This Terminal app is part of the Android Virtualization Framework (AVF) and contains a WebView that connects to a Linux virtual machine via a local IP address, allowing you to run Linux commands from the Android host. Initially, you had to manually enable this Terminal app using a shell command and then configure the Linux VM yourself. However, in recent days, Google began work on integrating the Terminal app into Android as well as turning it into an all-in-one app for running a Linux distro in a VM.

...

Google is still working on improving the Terminal app as well as AVF before shipping this feature. AVF already supports graphics and some input options, but it’s preparing to add support for backing up and restoring snapshots, nested virtualization, and devices with an x86_64 architecture. It’s also preparing to add some settings pages to the Terminal app, which is pretty barebones right now apart from a menu to copy the IP address and stop the existing VM instance. The settings pages will let you resize the disk, configure port forwarding, and potentially recover partitions.

...

If you’re wondering why you’d want to run Linux apps on Android, then this feature is probably not for you. Google added Linux support to Chrome OS so developers with Chromebooks can run Linux apps that are useful for development. For example, Linux support on Chrome OS allows developers to run the Linux version of Android Studio, the recommended IDE for Android app development, on Chromebooks. It also lets them run Linux command line tools safely and securely in a container.

cross-posted from: https://lemmy.ndlug.org/post/1225458

Powered by the latest Linux 6.11 kernel series, Ubuntu 24.10 features the latest and greatest GNOME 47 desktop environment for the Ubuntu Desktop flavor with additional patches for Mutter and GNOME Shell to enhance stability and performance. In addition, the Ubuntu Dock now visualizes Snap refreshes and includes better handling for PWAs installed via the Chromium Snap.

...

Under the hood, Ubuntu 24.10 comes with an updated toolchain that includes GCC 14.2, GNU Binutils 2.43.1, GNU C Library 2.40, LLVM 19, Rust 1.80, Go 1.23, OpenSSL 3.3, systemd 256.5, Netplan 1.1, and .NET 8. The Ubuntu Desktop installer was also updated with support for local file paths for autoinstall import.

...

Ubuntu 24.10 will be supported for only nine months, until July 2025. If you’re looking for long-term support, you should download and install Ubuntu 24.04 LTS (Noble Numbat), which is supported until at least 2029.

Official Website: Ubuntu 24.10 (Oracular Oriole)

The Linux Mint 22.1 distribution was slated for release in December 2024 with a revamped Cinnamon theme and better package management.

Slated for release in December 2024, near the Christmas holidays, Linux Mint 22.1 will ship with the soon-to-be-released Cinnamon 6.4 desktop environment featuring a revamped theme that’s much darker and contrasted than before, rounded elements, redesigned dialogs, and a gap between the applets and the panel.

More from the Mint Monthly News: September 2024

The transition towards Aptkit and Captain is now finished. Starting with Linux Mint 22.1, set to be released this December, none of our projects will depend on aptdaemon, synaptic, gdebi or apturl anymore.

Exploit of a combination of several bugs - Overhyped but not that severe - Fixes already available

...

Canonical’s security team has acted immediately to quickly apply the patches which Michael Sweet (author and maintainer of CUPS) had already prepared for CUPS, cups-browsed, libcups-filters, libppd, and cups-filters (in the time from the first report until then I was some days off and I was also on the Open Source Summit Europe, thanks, Michael Sweet, for stepping in, also thanks to Zdenek Dohnal from Red Hat) to the appropriate in all supported Ubuntu versions, so that at the time of disclosure most fixes were already in place. They also reported in an Ubuntu blog. They tell users what to do, from turning off cups-browsed or at least its legacy CUPS browsing support to updating their systems as the fixes were already available. Thanks a lot to Seth Arnold, Marc Deslauriers, Diogo Sousa, Mark Esler, Luci Stanescu, and more.

...

The X post really overhyped the vulnerability. Attacks from the internet are not very probable due to the fact that servers on the internet do not have cups-browsed and CUPS installed and CUPS/cups-browsed setups are there usually only in NAT-protected local networks with desktop machines and print servers. And the remote code execution is also rather restricted, as CUPS filters are not running as root, but as the system user “lp” which cannot even read user’s home directories. In addition, the remote code execution only happens when a user actually prints a job on the fake printer. Actually assigned scores ended up between 8.4 and 9.1.

There's been talk of this unauthenticated RCE vulnerability coming with a CVSS 9.9 rating but none of the technical details were publicly known until it was made public just now at the top of the hour. Simone Margaritelli discovered this vulnerability and has shared a write-up around this potentially very impactful Linux vulnerability.

This vulnerability, fortunately, doesn't affect the Linux kernel but rather CUPS... The print server commonly used on Linux systems and other platforms.

...

From Attacking UNIX Systems via CUPS, Part I:

"A remote unauthenticated attacker can silently replace existing printers’ (or install new ones) IPP urls with a malicious one, resulting in arbitrary command execution (on the computer) when a print job is started (from that computer)."

...

This remote code execution issue can be exploited across the public Internet via a UDP packet to port 631 without needing any authentication, assuming the CUPS port is open through your router/firewall. LAN attacks are also possible via spoofing zeroconf / mDNS / DNS-SD advertisements.

Besides CUPS being used on Linux distributions, it also affects some BSDs, Oracle Solaris, Google Chrome OS, and others.

As of writing there is no Linux fix available for this high profile security issue. In the meantime it's recommended to disable and remove the "cups-browsed" service, updating CUPS, or at least blocking all traffic to UDP port 631.