Steampipe: All SQL All The Time

Although modern Linux has slightly shifted, the old Unix mantra was: everything’s a file. With Steampipe, a better saying might be: everything’s a SQL table. The official tagline is “select * from cloud” which also works. The open-source program relies on plugins, and there are currently 140 sources ranging from GitHub to Google Sheets and more.

There are command line interfaces for the major platforms. You can also add the system to PostgresSQL or SQLite for even more SQL goodness. Continue reading “Steampipe: All SQL All The Time”

Linux Fu: Forward To The Past!

Ok, so the title isn’t as catchy as “Back to the Future,” but my guess is a lot of people who are advanced Linux users have — at least — a slight interest in retrocomputing. You’d like an Altair, but not for $10,000. You can build replicas of varying fidelities, of course. You can also just emulate the machine or a similar CP/M machine in software. There are many 8080 or Z80 emulators out there, ranging from SIMH to MAME. Most of these will run on Linux or — at the least — WINE. However, depending on your goals, you should consider RunCPM. Why? It runs on many platforms, including, of course, Linux and other desktop systems. But it also will work with the Arduino, Teensy, ESP32, or STM32 processors. There is also experimental support for SAM4S and Cyclone II FPGAs.

It’s pretty interesting to have one system that will work across PCs and embedded hardware. What’s more is that, at least on Linux, the file system is directly translated (sort of), so you don’t have to use tricks or special software to transfer files to and from CP/M. It is almost like giving Linux the ability to run CP/M software. You still have to have virtual disks, but they are nothing more than directories with normal files in them.

Goals

Of course, if your goal is to simulate a system and you want to have 180 kB floppies or whatever, then the direct file system isn’t a benefit. But if you want to use CP/M software for education, nostalgia, or cross-development, this is the way to go, in my opinion.

It isn’t just the file system, either. If you need a quick utility inside your bogus CP/M environment, you can write it in Lua, at least on desktop systems. On the Arduino, you can access digital and analog I/O. Theoretically, you could deploy an embedded Altair for some real purpose fairly cheaply. Continue reading “Linux Fu: Forward To The Past!”

This Week In Security: Broken Shims, LassPass, And Toothbrushes?

Linux has a shim problem. Which naturally leads to a reasonable question: What’s a shim, and why do we need it? The answer: Making Linux work wit Secure Boot, and an unintended quirk of the GPLv3.

Secure Boot is the verification scheme in modern machines that guarantees that only a trusted OS can boot. When Secure Boot was first introduced, many Linux fans suggested it was little more than an attempt to keep Linux distros off of consumer’s machines. That fear seems to have been unwarranted, as Microsoft has dutifully kept the Linux Shim signed, so we can all run Linux distros on our Secure Boot machines.

So the shim. It’s essentially a first-stage bootloader, that can boot a signed GRUB2 or other target. You might ask, why can’t we just ask Microsoft to sign GRUB2 directly? And that’s where the GPLv3 comes in. That license has an “anti-tivoization” section, which specifies “Installation Information” as part of what must be provided as part of GPLv3 compliance. And Microsoft’s legal team understands that requirement to apply to even this signing process. And it would totally defeat the point of Secure Boot to release the keys, so no GPLv3 code gets signed. Instead, we get the shim.

Now that we understand the shim, let’s cover how it’s broken. The most serious vulnerability is a buffer overflow in the HTTP file transfer code. The buffer is allocated based on the size in the HTTP header, but a malicious HTTP server can set that value incorrectly, and the shim code would happily write the real HTTP contents past the end of that buffer, leading to arbitrary code execution. You might ask, why in the world does the shim have HTTP code in it at all? The simple answer is to support UEFI HTTP Boot, a replacement for PXE boot.

The good news is that this vulnerability can only be triggered when using HTTP boot, and only by connecting to a malicious server or via a man-in-the-middle attack. With this in mind, it’s odd that this vulnerability is rated a 9.8. Specifically, it seems incorrect that this bug is rated low complexity, or a general network attack vector. In Red Hat’s own write-up of the vulnerability, they argue that the exploitation is high complexity, and is only possible from an adjacent network. There were a handful of lesser vulnerabilities found, and these were all fixed with shim 15.8. Continue reading “This Week In Security: Broken Shims, LassPass, And Toothbrushes?”

How A Steam Bug Once Deleted All Of Someone’s User Data

In a retrospective, [Kevin Fang] takes us back to 2015, when on the Steam for Linux issue tracker [keyvin] opened an issue to report that starting the Steam client after moving the Steam folder had just wiped all of his user data, including his backup drive mounted under /media. According to [keyvin], he moved the standard ~/.local/share/steam to a drive mounted under /media and symlinked ~/.local/share/steam to this new location on the external drive. He then tried starting Steam, which failed, before Steam crashed and tried reinstalling itself. That’s when [keyvin] realized that Steam had apparently recursively deleted everything owned by his user from the root folder.

The infamous Valve code that made Linux users sad.
The infamous Valve code that made Linux users sad.

In the issue thread, user [doofy] got hit by the same bug when trying to directly start the ~/.local/share/steam/steam.sh script with debugging enabled. He then was the first to point out the rm -rf in that steam.sh script, but since this particular line is in a function only called when Steam tries to remove and reinstall itself to ‘fix’ a botched start, how did this happen? Ultimately it seems to be because of the STEAMROOT variable being set to an empty string, and another unset variable triggering the reset_steam() function, leading to the demise of all the user data.

Since then Valve has presumably fixed the issue, as no further users have filed tickets, but it’s concerning that a similar issue seems to still exist on Windows. Whether or not the original Linux issue has been fixed, it shows clearly how one should always check return values and perhaps, just maybe, never do an automated rm -rf or equivalent.

Continue reading “How A Steam Bug Once Deleted All Of Someone’s User Data”

Linux Fu: Where’s That Darn File?

Disk storage has exploded in the last 40 years. These days, even a terabyte drive is considered small. There is one downside, though. The more stuff you have, the harder it is to find it. Linux provides numerous tools to find files when you can’t remember their name. Each has plusses and minuses, and choosing between them is often difficult.

Definitions

Different tools work differently to find files. There are several ways you might look for a file:

  1. Find a file if you know its name but not its location.
  2. Find a file when you know some part of its name.
  3. Find a file that contains something.
  4. Find a file with certain attributes (e.g., larger than 100 kB)

You might combine these, too. For example, it is reasonable to query all PDF files created in the last week that are larger than 100 kB.

There are plenty of different types of attributes. Some file systems support tags, too. So, you might have a PERSONAL tag to mark files that apply to you personally. Unfortunately, tool support for tags is somewhat lacking, as you’ll see later.

Another key point is how up-to-date your search results are. If you sift through terabytes of files for each search, that will be slow. If you keep an index, that’s fast, but the index will quickly be out of date. Do you periodically refresh the index? Do you watch the entire file system for changes and then update the index? Different tools do it differently. Continue reading “Linux Fu: Where’s That Darn File?”

OpenWRT To Mark 20 Years With Reference Hardware

The OpenWRT project is now two decades old. The project has come a long way since Linksys was forced to release the GNU-licensed code for the original WRT54G router from which the project takes its name. They’ve marked the occasion in an interesting manner: by proposing that the plethora of devices supported by the OS be joined by a fully upstream-supported reference hardware platform.

Spec-wise it’s what you would expect for a hackable router platform in 2024. A MediaTek chipset can be found at its centre, but the hardware is not in this case the important bit. Here will be a platform that won’t have to rely on proprietary manufacturer BLOBs, and which will thus likely continue to have up-to-date kernel support long into the future. So many enticing SBCs fall in this regard, and many retain ossified kernel versions after their manufacturers tire of them as a result.

It appears that the future of this project will be subject to an OpenWRT community vote, and we sincerely hope that it will come to fruition. Meanwhile, we couldn’t resist a peek at the status of the router that started it all, by our reckoning the original WRT54G was last supported by the OS over a decade ago.

FLOSS Weekly Episode 764: You Have To Be Pretty Cynical

This week Jonathan Bennett and Katherine Druckman talk with benny Vasquez, chair of AlmaLinux, all about the weird road we’ve been on with Enterprise Linux distributions, and how that’s landed us here, where we have AlmaLinux, Rocky Linux, and multiple other Red Hat downstream distros. What’s the difference between those projects, and why does it matter?

Projects need more than just developers. How do you keep members doing documentation, bug hunting, outreach, and even graphic design plugged in and feeling like part of the team? How do you walk the narrow line between the different directions a project can drift, setting up your community for long term success? And where’s the most surprising place benny has found AlmaLinux running? And why is benny’s first name never capitalized? Give this week’s show a listen to find out!

Continue reading “FLOSS Weekly Episode 764: You Have To Be Pretty Cynical”