this post was submitted on 01 Aug 2024
481 points (97.1% liked)
Technology
59174 readers
2961 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related content.
- Be excellent to each another!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, to ask if your bot can be added please contact us.
- Check for duplicates before posting, duplicates may be removed
Approved Bots
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Unfortunately there's a lot more to it than that.
You're right that the "back end" of Linux systems tend to be quite hardened.
It's the desktop environments that are a concern when it comes to security hardening, IMO. Almost all servers have no DE installed so it's not something enterprise has cared about.
How much effort has been put into security on DEs? I honestly have no idea, but so far there hasn't been an enormous pressure to security harden them.
Shit, look at:
X11. It's insecure by design, yet most distros still ship with it (understandably, since Wayland isn't 100% yet).
packaged software runs as root during the whole installation period - this means that anything slipped into the install script will have full root privileges to do anything to your system. Flatpak does fix this, but normally-packaged software is still abundant.
any non-root program can change aliases in your bashrc or bash_aliases file. I.e. they can change "apt install" to some other nefarious command, or to point to a dodgy software repository, so that next time the user types "sudo apt install [XYZ]", it downloads malware or does other nasty things.
I'm absolutely clueless about this stuff and I can come up with those potential attack vectors in seconds. Imagine what a proficient hacker could do, or a hostile nation-state.
I definitely think improvements will have to be made in terms of security, and we're no doubt going to hear more about malware in the coming years. But it's not an insurmountable problem, IMO. Distros and DEs will just take time to adapt.
This is a bit overhyped.
WTF? Things that run as root, do. Things that don't, don't. Obviously most things don't.
For your own user, so what?
EDIT:
Actually it is. One can make levels over levels of isolation, sandboxes and more sandboxes, but in the end conscious hygiene matters most.
No, it isn't. If anything it's the opposite.
Under X11, any program of any kind can see the contents of another program.
Under X11, any program of any kind can see all your keypresses, whether the app is focussed, unfocused, minimised, on another virtual desktop. Anything.
Under X11, any program can inject keypresses into any other program.
Under X11, any program of any kind can access your clipboard.
And it doesn't even take root privileges. That's just the default.
The X11 system itself runs as root, though. And this opens the door for privilege escalation exploits.
That's before we even consider the devs themselves saying that the complexity, decades of spaghetti code, and unfixable bugs make it virtually impossible to patch.
X11 is a security nightmare of epic proportions. An absolutely cataclysmically insecure system. And it's one of the main reasons that X11 devs abandoned it for Wayland.
I never said that things that don't run as root run as root. That doesn't make sense, it's self contradictory.
What I said was that install scripts for repo packages always run as root. And therefore anything that makes its way into the script will be executed with root privileges. That is a risk.
What do you mean, "so what"?! A non-root program being able to highjack system commands and even gain root access isn't "so what", it's a glaring security hole.
You're right, but you're taking my words there a little too literally there.
When I say the problems aren't insurmountable I mean "with effort, a lot of these will be fixed and your system will be pretty secure", not "one day Linux systems will literally be unhackable, and no exploit or security issue will ever be found again. Security problems will be a thing of the past."
This would be the same as under Windows, no?
It usually does, but it doesn't have to.
And the new thing to replace that is still not good enough after 10 years or so.
Let's please not extrapolate the problems of your distribution to all of them.
Your user may set aliases for the shell of your user, and the program\script ran by your user can do that.
It's not a security hole at all. It's something you should be able to do for any normal use.
In short, no not really for modern windows versions, in almost all cases.
Although I don't find "well Windows does it so it must be alright" to be a great argument anyway. When someone says "top notch security", Windows isn't the first thing that springs to my mind.
Hypothetically yes, but in every single distro out there that I've seen no. And most people don't build their own from scratch.
Not in all cases, no. There are fringe usecases still being worked on. I've been using it since 2016 just fine, but my sister, who is reliant on screen readers, hasn't been able to.
Like I said, things are being worked on. This is kind of derailing the conversation away from security, though. I was talking about security.
No. It is all of them. It's a problem with all Debian-based distros, Fedora, SUSE, Arch, you name it. Installer scripts run with root privileges.
Yes... then when you run sudo thinking you're using whatever command, it can run something entirely different. How don't you see that as a problem?
WHAT?! Any program, without root privileges, being able to tamper with what commands do, and gain full root access to your system, "is not a security hole at all"??
So you download, say, a text editor. Except it's been compromised (although you don't know it). That program alters the sudo command by aliasing it to execute a curl command that encrypts your drive and shows a message that if you send ABC amount of bitcoin to XYZ wallet, then you get the decryption key.
You run sudo for any reason, e.g. to edit your fstab file, do a system update, install a package, anything, and you type your password at the prompt as usual. Unbeknownst to you, you didn't actually just run sudo plus your intended command, you just ran that aforementioned curl script, and you handed it sudo privileges. Your SSD is encrypted, your data is gone.
In your mind, that's not a security hole? That's intended behaviour? Any program should be able to do that?
I don't really know what to say to that, other than I disagree wholeheartedly.
We-ell, this thread kinda started with saying that we'll see glaring security holes with the same desktop popularity as that of Windows.
Well, then it doesn't require flatpaks and snaps to solve this huge problem, right?
You might have a path where only a certain user has 'w' rights, that's readable by everyone, and software is installed there.
You might use Nix or Guix, which are, while not traditional, still pretty normal package managers without things like bundling dependencies.
So NixOS and GuixSD would be such distributions. Admittedly I've never used them, only Guix in another distribution.
Well, since you've mentioned accessibility, some of us have AuDHD, and while each person is different, for me specifically this means that I can set up CWM or FVWM for X11, but I just can't set up Hikari for Wayland. That is, I had it kinda working, but the anxiety from setting up that and some terminal emulator with hipster XML config and DPI being wrong just made me say "fsck that" and go back. I could have tried Gnome with Wayland, but my X11 setup is more subjectively usable.
OK, I'm not sure, but I think OpenBSD and NetBSD don't run any scripts contained inside packages. They are not Linux ofc.
Yes, you can do that. You can set aliases which will look like whatever at all. How do you solve that "problem"?
OK, I'll make a shortcut here and say that if you think this is a problem, the only real fundamentally sane way to solve it is to disallow privilege elevation, say, after single mode, and boot to that in case you need to do some maintenance.
Any program that you run. Well, or one can forbid aliasing 'sudo' in the shell, of course. But you won't run out of things which can be aliased to something nasty. It will be the same as
rm -rf /advice evolving torm -rf /*Yeah, like windows did, for a long time, and from time to time still does.
It pretty much does, yes.
Ok. Not to do with security. Let's not get sidetracked.
I'm not sure about the BSDs, but I'm talking about Linux. And as it stands, the package installation step is a risky process in any distro I've ever seen. You just have to rely that no mistake will ever be made by packagers, nothing will slip past them, and that they manually and thoroughly look through every installation process of every package (which they don't).
It's an unnecessary risk that gets solved by Flatpak (plus a bunch of other security advantages)
I don't know, I'm not a security expert. But it is a problem, and a massive one.
... Or Nix/Guix, or any per-user approach to package installation, or AppImages.
Anyway, I'm not against them completely. For distributing some user applications, and maybe proprietary stuff, they are fine.
We-ell, in basic Unix-like terms you can just do a chroot while unpacking, check that no nasty places are being touched, and then rsync to root. I think some PMs already do just that.
This problem seems inherent to anything Turing-complete.
Nix is not simple, and it always seems to fuck up. AppImages have zero security advantages, they're awful. It doesn't even have sandboxing.
Lmao. Not only would that not even be effective, but that's also a ludicrous suggestion for the average user to do for every app they install. What an absurd suggestion.
Why are you so against having a secure system?
I dunno what you're on, I'm talking about the PM doing this.
I'm against believing in the concept of actually having a secure system.