1 - cups-browsed is able to install printers automatically (without the requirement of user confirmation) by listening to UDP packets on port 631.
2 - Attacker uses this "feature" to install a fake printer with a custom driver (which is also installed without user confirmation and can be downloaded from an arbitrary host) which specifies the "command to run" when a print job is sent.
3 - User prints something in the fake printer and the "command to run" is executed.
I would rather expect this kind of change came later, when there has been a huge push to make the "linux desktop" more user-friendly.
1999 sounds like the time when people were a bit more expected to mess with config file and somehow always had a root terminal around. If anything, keep in mind that in 1999 it was still a rite of passage to have to learn how to write the X11 configuration file (what used to be xorg.conf)
I’d shift that a little earlier (XF86 autoprobing worked for a lot of hardware by the turn of the century) but especially also recognize the competitive environment. Mac, Windows, OS/2, etc. users had been using local network discovery since the 80s, and the people trying to popularize Linux on the desktop were all too aware of the “by and for computer nerds” reputation they were trying to shake, and a lot of people still thought about corporate networks as isolated enclaves where nothing too dangerous happened. The threat model for a lot of people, even server admins who should have known better, was more along the lines of “someone will print a picture of their butt on your desktop printer” rather than “your workstation is now being used to attack the accounting system”.
A nice intermediate I use is baking the paths into the source code, so that I only recompile when I add files, but I can hot-swap contents without even restarting the server.
Although if you start caching contents in memory (which is faster) you would have to at least kill the server and restart it. Or signal a reload.
The current release is a prebuilt binary, giving users flexibility in how they use the software. The open-source model is still being decided, but a license file is included in the downloaded tarball.
Some (maybe most or all) of these devices require an external service to be used. That means it will work as longs as the service exists. You are in the hands of the vendor. My dream is to make devices like this and make them remotely accessible through Tor; that way it can be fully local but remotely accessible from anywhere in the world.
I bought a few Reolink cameras (around $50 each) and they have pan/tilt and don't require the internet. In fact, I didn't even connect them to it, I connect to them via my Tailscale VPN and they support this mode explicitly, and work perfectly (obviously real-time notifications don't work).
There's already a series posted a week ago for 6.12 that will ungate PREEMPT_RT on x86, ARM and RISC-V; it only modifies the Kconfig entries to enable it[1]. So I'd say it's hardly a bet!
PREEMPT_RT would be a boon for audio/video work, hope it finally goes in. Not everyone who needs it knows they need it, let alone how to compile it, and having it in-tree would massively simplify the process for distros to [re-]package a proper RT kernel.
Yes, that's why it's a config option; but if the code is in the kernel a distro can package up a preempt-rt kernel by flipping the config flag rather than maintaining an out-of-tree patchset, which is a _much_ lower burden.
I long for the day when Linux apps will be transparently compiled in a way that the time-critical bits will run as ebpf progs and communicate with user space through io_uring and sched_ext will allow the system to be tailored to very specific workloads. Imagine games! How much of a difference that could make! It is a shame that games vendors simply ignore Linux.
So the thing I've heard from dtrace people is that eBPF still is not really "there". I've never gotten a clear answer about _why_ this is the case, though I feel like there was implications that, basically, eBPF programs are brittle/don't actually capture everything well?
They generally have a very latency sensitive input/rendering loop. Performance analysis can be challenging, but with the right tools it can be much easier.
The thing that we need in order for your dream to become a reality is excellent user space frameworks, so I encourage you (and anyone else) to go build one or (better) find one you like and contribute.
A commonly used alternative in the microcontroller world is to simply stack a few diodes. Very simple alternative which I have seen being used a few times.
reply