- cross-posted to:
- linux@lemmy.ml
You must log in or register to comment.
Great time to mention tools like testdisk that can easily recover data that has been recently deleted on common filesystems.
This is why we need sandboxing. Right now the Linux desktop is still lacking in terms of security
@possiblylinux127 @wisha And how would sandboxing a malicious script inside a theme that is supposed to change the look of your desktop work? They installed and ran something that rm’d their home directory. I’m honestly curious how you’d solve this.
A more locked-down theming API could help. For example Firefox themes are always 100% safe to install. That said, Firefox themes are almost useless (they’re more like color schemes lol), and no one wants to lose KDE’s powerful customizability so 🤷🤷
What do you mean? I have Firefox themes that change the whole look of the browser, using userchrome.css.
That’s obviously not what OP was referring to when mentioning “Firefox themes”.
Maybe, I was showing that there were better ways to theme Firefox though
Perhaps having different categories with different limitations would work well. Using the firefox example, prioritize the use of WebExtensions, but keep XUL/XPCOM with appropriate warnings.
If it ran in a sandbox it would just wipe its own files instead of the system. Under no circumstances should a plugin from some random guy online be running with such high privileges
@possiblylinux127 I was asking how you’d run something that modded the whole UI … sandboxed.
You would need to expose some sort of hook that allows modifications
SELinux? Apparmor? (Serious question, I don’t know if there might be features that render those two inadequate)
Not malicious. Just buggy – a downright nasty bug, but a bug.
Reading the comments, looks like bad/old code mixed with a big update rather than anything malicious. I even ran into themes that killed my KDE last night. Had to purge the configs themes to get it working. Damn glad I didn’t wipe my entire setup.
Correct. The theme creator missed a variable that is not part of the Plasma environment anymore, and instead of running
rm -Rf [something]it run
rm -Rf😬
Extensions need to follow standards, and be installed as non-executable files in defined categories.
Everything else has to be removed or behind a huge warning.
That is not possible. widgets and Global themes have to be able to execute code to work.
By the way: the code was not malicious, just badly written.
deleted by creator
I think that is one of the questions being debated by the Plasma developers. You may have more luck getting a complete answer here:
Why do global themes need to do that? Arent they just color and image files, maybe audio?
It doesnt really matter if the code was malicious or not, this should not be possible.
Another example of how damn insecure linux is. Just because its not the snap store, we dont have tons of malicious addons on pling.
That is regular themes.
_Global_ themes also modify the desktop’s behavior and hence contain code to do that.
@Pantherina
Yeah, by the same logic lets also call hotdogs dangerous because people have also choked on them!https://nypost.com/2023/07/11/4-year-old-girl-dies-after-choking-on-costco-hot-dog-report/
At some point we should understand and agree that PEBKAC is a real thing. Logic dictates not to blame Linux and hotdog, and instead understand the consequence of using unverified/unvetted software.
Well, yes: the store does advise caution, as we have little control over themes and widgets uploaded by their parties. The same way we would advise caution about running random software downloaded from the internet. That said, it does say KDE Store, so we should have some degree of control over it for our users’ sake. That is what we are working on.
That said part II, we can’t do with it the wider communities support. There simply isn’t the human resources necessary. The 2 options we have are to close down the store completely (but then people will just go to random GitHub repos and download stuff from there), or try to leverage the community to help us locate and remove (or at least quarantine) dodgy products.
One obvious fact that I though would never need to be reiterated (but here we are):
Almost all OpenSource licenses approved by OSI and/or FSF have “Disclaimer of Warranty” clause in one way or another. This is from MIT:
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
https://opensource.org/license/mit
More examples:
https://opensource.org/license/gpl-3-0#section15And this too. I mean, it is not like it is the fine print either. They capitalise the whole paragraph.
Absolutely, and I would like to help with that.
But I think there are multiple parts to this:
- Fix the backends so that for example dolphin extensions are directly installed in the correct way and dont even need such scripts
- Restrict extensions and themes to be nonexecutable at least by default
- Involve the community to mark “dangerous addons” that need executable scripts to install themselves or work; and to report malicious addons; and to add an enforced test before the addon is published
Of course a dolphin extension always executes code. I think hiring a bunch of KDE users as pretesters could work, to enforce that every extension needs to be tested by the 2 community members to end up in the store. There could also always be a way to unhide untested addons etc.
And enforcing stricter guidelines for the extensions is also important of course
This makes no sense.
The equivalent would be
A: have a hotdog you buy, which you eat with your teeth and your gut and you know how to do it (and also that hotdog doesnt interfere with your body, its a theme not actual molecules that comparison still makes no sense)
B: have a hotdog that decides how it is eaten, and manipulates your body to eat it in any arbitrary way
@Pantherina
I’m sorry that this bug have happened.But did you, or whoever faced this bug, “eat” it with your “teeth” though? No they didn’t. Why? Because like any proprietary software, OpenSource tools also come with certain terms and conditions that user is expected to read, digest, understand, accept, and then utilize the tool:
https://fosstodon.org/@Mehrad/112128648273530651
User had all the possible chance in the world to read the code and make sure it doesn’t do what it’s not supposed to do.
🧵👇Yes for sure, but Firefox, Android etc are also all opensource and allow to install only opensource components, still their model is way more secure.
But for sure, KDE will never become as restricted, as otherways these extensions would not exist.
@Pantherina
I agree, although there are three things worth mentioning:-
The conventional Android is not that opensource. It is bundled with tons of proprietary Google stuff. That’s why de-googled Android does not provide as smooth experience.
-
Android does not restrict you to “only OpenSource” components. WhatsApp for example is widely used and is not FLOSS.
🧵 👇🏼
-
I thought wayland was supposed to improve security. Were the past 18 years a lie?
Uhm, Wayland improves security but its just one component. Will a bash script work the same on Wayland as on XOrg? Yes.
You must have heard that old chestnut about how “the weakest security link in the security chain is the user” by now. There is nothing any technology can do if the user decides to install insecure stuff. Even before today, the KDE Store prominently displayed warnings about being careful with the content.
