A global theme on the KDE third party store had an issue where it executed a script that removed user’s data. It wasn’t intended as malicious, but a mistake in some shell parsing. It was promptly identified and removed, but not before doing some damage to that user.
This has started a lot of discourse around the concept of the store, security and upstream KDE. With the main question how can a theme have access to do this?
David Edmundson
That ‘some damage’ was personal data loss, which is quite something to happen after installing a theme. KDE kind of shot itself in the foot here by having something called ‘global themes’, which is a combination of themes for various elements of the desktop, like the application style, icon theme, cursor theme, colour scheme, and so on, but also things like panel layout and even widgets, applets, and other things that can run code. Some of these global themes use shell scripts to implement the more advanced aspects of their themes, and all these things combined means that global themes installed through KDE’s own built-in theme installer can cause some serious damage.
The problem is getting some attention now, and I hope they can find a way to make this process more transparent for end users, so people know what they’re getting themselves into. I’m not advocating for dumbing all this stuff down – this isn’t iOS or whatever – but better communication, perhaps clearer labels and warnings are definitely needed.
https://xkcd.com/1200/
This would have likely been prevented by intra-account role-based access control managed by the installer. Themes in general are only going to need write access to their configuration directory and maybe a temporary directory and read access to their own data/scripts and whatever system-wide data and scripts they require, so they shouldn’t have permissions to do anything more.
It’s 2024. We really should be moving beyond security models intended for 70s-era timesharing minicomputers. Of course, that’s easier said than done, since conventional Unices like Linux seem to be pretty heavily built around the traditional Unix security model and anything else is a hacky add-on that’s a pain to configure and use. The OS I’m working on will invert this and relegate traditional Unix security to a compatibility environment implemented with a filesystem overlay, with the built-in security model being based on a mix of roles and capability sharing (the API will still be highly compatible with Linux except when it comes to security).
I agree. For better or worse these legacy designs have a lot of staying power.
I don’t doubt you can do better. I’m interested in things like this, academically speaking. However the major players like linux are the only platforms that carry real influence. Outside innovators are always destined to be steamrolled by a linux-centric project. I really did enjoy building operating systems too and I felt (and still feel) there are lots of areas for improvement over others, but existence in the long tail is not fun and I saw the writing on the wall. For all the effort one puts in, it’s hard to justify such meager economic returns.