Like this old one:
“Global themes can also break your system. They include code and there was a infamous incident where installing a one deleted the user’s home directory due to a bug.”
Have the devs done anything for that to not to happen again?(besides fixing that one bug?)
Like redesigning the system so a bug can do anything other than change the theme!?
Besides putting warnings? That don’t fix the problem just an sign which people will ignore!
Maby the themeing system needs an re-design?
To future proofing theme install making the whole theme system better and easier?
I don’t no?!
I’m not a coder or designer just spewing ideas and questions.
You’re quite correct, you cannot fix ‘Stupid’. Just as with people who think they can install Gnome, then ‘try out Plasma’ by also installing KDE - then complaining that this messes up their system (whilst other folks spout ‘I didn’t have any issues, just do it!’).
This is why I think the lowest bar that any nOOb should learn to pass is an ability to take snapshots and backups so that when anything goes wrong, they can just restore the system.
However, neither should you take away the choice for people to easily grab global themes and execute installations… other than tell people that it is unsupported and (as USER content) inherently risky.
The only way to ‘redesign the system’ to prevent this would be to Gnomify it, by curbing your options to theme your system.
Personally, I don’t use Global Themes, I think the first upgrade should be that you can set up your system, and then SAVE that as a Global Theme… but instead I have to use a tool like Konsave if I want to do that.
The concept behind a Global Theme is fine - but it includes many different areas of the system which means that to execute a FULL sweeping theme template you must allow full access to all areas of your system.
So if you don’t feel safe when you read the warning, you have two choices…
Don’t apply a Global Theme from an untrusted source
Be sure of your rollback strategy when disaster strikes and just do it anyway.
While i think the ability to custom anything is good.
The fact is there is a back door to allow this is of concern. Does this flaw rreally allow for root to be leveraged without (interactively) informing the user and/or requesting sudo.
Just a little banner is not enough to potentially thwart a rather serious attack vector.
In that case i think global themes neds amassive rework.
Does anyone else know if this is tracked via CVE.
Most people understand if you change anything under the hood (there be dragons) but not leveraging sudo for the task seems like we are opening our doors to malicious attacks.
In the particular case that came up last year, a bug in a specific theme’s script caused it to run rm -rf very broadly. That executed without prompting for user-owned data, and caused a privilege escalation prompt to appear for root-owned data. Superuser access was not obtained automatically or secretly, nor was it granted by the user.
You can try it yourself by attempting to install a Global Theme that includes SDDM theming through the “Get New” dialog - you’ll be prompted for superuser/root authorization when placing files in root-owned locations, or changing settings in root-owned files.
Whilst my userdata is important the prospect (seemingly benign) of having a theme unkowingly leverage unsanctioned and concerning code on my system is moreof an issue.
Trojans , keyloggers and the likes should concern people more.
Code execution if it goes unoticed can have devestating consequences.
Your password and giving admin rights is always a ‘back door’ which could, theoretically, be exploited.
This is one reason why people harp on about ‘trusted sources’ for getting software. However, the KDE Store is not a ‘trusted source’. It is simply a USER REPOSITORY - where anyone can make an account and start uploading themes. Just look at how much annoying spam there is - especially in the crazy ‘anime’ cursors with a couple of dozen uploads every minute.
I have little fear that there will be actual malware - and the problems we’ve seen are not malware issues… but rather a ‘bug’ with a specific theme. Global Themes require root access - if you don’t like it, then just don’t use them. I only ever used the original Global Themes, and then applied separate things (like Darkly, Klassy, icons, plasma styles etc) and to be honest, the main ‘customisation’ is generally just the colours applied.
With any kind of USER REPOSITORY, it’s your responsiblity to inspect the material before giving the rights. There is nothing that can be done about that… and nobody has the time to vet what most user repositories contain - you must rely entirely on judgement and your ability to read/parse the ratings and comments - and to visit the source material and look for issues and comments there.
If you are not comfortable, then you should not do it…
@Johnjohn: Yes true (to your last statement), but this was a bug (not malware) and it wasn’t unsanctioned the user wanted to install it and indeed had to go look for it to install it.
And due to the nature of the bug previous installations and any ratings the theme had would not have been a warning.
On an individual level - just don’t install ones that you haven’t personally vetted You should treat it with the same level of care that you treat anything else you’d download from a user’s git repository, website, or other non-curated source, and run under your user account’s privileges.
If you are an admin for other devices, you could use kiosk mode - as described in David’s blog post linked above - to restrict users’ ability to install their own theme packages.
is there any mitigations to the latter to stop code from being run which is Not the theme managers?
You should treat it with the same level of care that you treat anything else you’d download from a user’s git repository, website, or other non-curated source, and run under your user account’s privileges.