Made in Rust is not synonym of safety. Every code is as safe as its programmer made it be.
this post was submitted on 24 Nov 2023
9 points (57.9% liked)
Linux
46775 readers
1939 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
It's also as safe as the user allows. You can put in all the safety measures but that means nothing if the use disables them for convenience.
Most of security CVEs are related to memory bugs, so it's relatively more safe vs. a certain type of exploits
This is both true and terrifying.
I see you post a lot about security so I just wanted to chime in and say that maybe just use what works well for you because there's nothing inherently safe, only stuff that is easier to break and stuff that takes more time. The only real way to be safe is to be prudent with what you download and what you do on the internet.
Hmm... yes for sure, but as I am already at a point where things just work, its interesting to deal with this
This is not a very good question. If you are concerned about security you need to think about what specifically you are trying to keep safe? Here are some examples of different security scenarios:
- Do you want your computer to be safe when it is stolen?
- Do you want to run lots of native apps from untrusted sources?
- Do you want it to be used by many people and you don't want them to be able to steal each others secrets?
Each one of those questions has different means of securing the computer. With question 1, it is not so much a matter of desktop environment, rather it has more to do with using full-disk encryption, setting a boot password in UEFI, and always having your lock screen enabled.
With question 2, this is a much more difficult task and you would probably be better off running apps in a VM, or carefully crafting your "Security Enhanced" Linux profile -- or not using Linux at all, but using FreeBSD which allows you to run apps in jails.
With question 3, be more careful with filesystem permissions and access control lists, setup your sudoers file properly, and use a desktop environment with better security auditing like Gnome or KDE Plasma.
Never heard of these jails, like bubblejail? Its available on Linux too.
I know the question is vague and highly dependend on Threat model etc. Pre-enabled services, distribution adding stuff to it, SELinux confined user (not working with Plasma at all), xwayland support for keylogging chosen keys (Plasma).
Also GTK is widely used for rust apps, this doesnt exist on Plasma at all, not a problem though as Plasma is not Gnome and simply supports GTK normally.
I don't think the DE itself matters, but I can recommend using an immutable OS (makes it harder to install malware) and installing flatpak apps only. You can also use software like flatseal to further lock down permissions
Already doing that :D kinoite-main from ublue
Very good choice :D
I'm starting to think people misunderstand what an "immutable" distro really does...
Please do share with me what I do not understand.
A mostly read only filesystem built from a limited number of packages, with other files being in a fixed number of locations mean it is harder for malware to hide.
You can achieve the exact same thing with a normal distro if you mount /var and /boot separately of /. And if you get a root exploit it's just as harmful on either approach.
"Immutable" systems are meant for maintainer comfort not for user security.
No, you can't : in an immutable distro I can reasonably trace almost any file in the filesystem back to the package that created it, and know with a reasonable degree of certainty that the installed version of said file has not been tampered with. That isn't possible an a normal distro.
Sure it is, has been for decades. You can use a read-only root partition, there are many tools to ensure the integrity of everything on it, and tracing files back to their package is a very old feature.
Could you provide some criteria for what you’re looking for in the way of security? Wayland is far better for security than Xorg, but it’s hard to say how much it varies between wayland compositors. I can’t imagine it would matter too much, but depending on how much security you’re looking for, choosing more minimal software is probably better. Rust can be better for security but I’m not entirely sure how much can really get compromised through poor memory management in a window manager.
Wayland is Wayland. If you use a Wayland compositor, you're getting a lot of security by virtue of design alone. Things like keyloggers and screenrecorders will not be able to intrude on your session barring vulnerability exploits. I'm not going to touch on the relative vulnerability risk of each environment since a) they're all relatively new & b) I've never implemented Wayland myself
With that being said, here's what's not protected by Wayland regardless of the chosen compositor: microphones, webcams, keyrings, and files.
For microphones & webcams, any distro which rolls Pipewire in combination with Wayland will be sufficient to secure these. Pretty much all Wayland environments roll Pipewire so this is only important to consider if you're running your own customized environment (be sure to disable any pre-existing PulseAudio daemon after setting up Pipewire to close this security hole)
For keyrings, these are handled by your environment's polkit implementation. Much like Wayland, there are several implementations of polkit and they're all just about equally secure barring any potential vulnerabilities... Just make sure that you're using an encrypted database (usually on by default) and that you have it configured to always relock & properly prompt for the unlock key.
For file access, this is actually a core probelm with Linux as a whole -- any unsandboxed application you run will be able to read any file that you can read. The solution is to use sandboxed applications whenever possible. The easiest way to achieve this is through using flathub/flatpak applications, since they will always list out and enforce their required permissions on a per-application basis. For non-flatkpak applications, you'll need to use "jail" environments (e.g.: bubblejail, firejail) in order to artificially restrict application permissions by hand.
Things like keyloggers [...] will not be able to intrude on your session
This isn't really true. Run libinput debug-events. In most distros users will have access to run this and keylog all input events.
I use Wayland and love it, but keyloggers are not prevented on most common setups.
IF by "security" one means bugs have been prevented from living in it, there is one coded in Haskell, it may be named XMonad or something...
( .. digging .. )
Yep:
https://en.m.wikipedia.org/wiki/Xmonad
from there:
"Due to the small number of lines of code of the Xmonad application, the use of the purely functional programming language Haskell, and recorded use of a rigorous testing procedure it is sometimes used as a baseline application in other research projects. This has included re-implementation of xmonad using the Coq proof assistant,[31] a determination xmonad is an imperative program,[32] and studies of package management relating to the NixOS linux distribution.[33]"
Dig: 2000-ish lines of code.
If you're going to be that level of paranoid might as well not have graphical interface at all.
All else being equal, less code and less dependencies is safer. The bigger the application and the more it tries to do, the larger its attack surface.
(Again, all else being equal. DWM is probably smaller than Weston, but Weston doesn't let just any old process log keypresses or take screenshots, so probably at least arguable to say that Weston is (qualifier, handwave, condition, clarification) "safer.")
well, a standalone WM will usually have less code than your usual DEs, but they also can be less secure in the sense that they might not come eith built-in security features. if your screenlock is buggy (it crashes or it lets you use WM shortcut key combinations or something), that can be a problem. or other stuff regarding saved passwords and keys etc must also be done by hand then usually and depending on if you know ehat you are doing either it works well or it is less secure than a built-in feature of your DE.
also, even though you are right that bigger applications potentially have more attack surface in general, the big DEs like KDE Plasma and GNOME might be (correct me if i am wrong) tested for security more than smaller standalone WMs. but i still tend to feel "safer" when i am in control of everyrhing and the DE doesn't do all kinds of things automatically in the background.
I don't think security comes from your desktop
Your desktop handles Wayland, Xwayland, preinstalled apps, file management, some services and GUI integration, networking, Printing, Bluetooth, GPS (if available), cell data (if available)... so I would say it does in part come from the Desktop.
The Desktop is software which needs resources, gives access, reads and writes data,...
For example SELinux Confined Users break KDE, but not GNOME afaik
I don't think it does. The services and apps are all broken down into smaller chunks so there isn't going to be a clear desktop that's better. I haven't heard of any CVEs in KDE or gnome either so I'm not convinced that my desktop is a threat. For me the biggest threat is my web browser and physical security
As others said, depends on the definition.
I throw Tails into the ring.
Having a non-persistent system makes it safe in some way.
You really should press Ctrl+alt+f3 on your lock screen and get your mind blown.
That leaves the desktop running in a parallel session
I think you missed the point. Switch the tty to realize your de is irrelevant in regards to security, because you don't even need one...
Wait until you want to watch a video, look at a photo, play a game or view a PDF lol
You can do all these things on a framebuffer. Ok, maybe the game thing is a bit of a hassle, but the other stuff is totally doable.
What the duck has this to do with anything.
The entire point is that your DE has NO security features at all, those come ALL from the underlying system such as PAM for example, managing the authentication and such.
These stupid strawmans "huhr dur watch a video"
Besides that I'll just answer the straw man argument anyway because it's even stupid if you take it seriously YES YOU CAN ACTUALLY LAUNCH GUI (such as a game) DIRECTLY FROM TTY.
And I quote
LoL
Learned something, thanks
a DE gives no security features that give your system additional security, yes. indeed, a running DE makesbyour system less secure, in some sense. but exactly here you can have less and more secure DEs, and some DEs have security features that make the DE itself more secure than other DEs.
i don't really get what people mean when they say this...
when you get tty you still get no access, you need to log in as always. a DE/wm/any x11 session/a wayland session (even though wayland is more secure probs?) should pretty much always be less secure, as depending on what state it is in, what features it has, or what happens when certsin components crash somehow, you can more easily "hack" your way in that way than via doing a "ctrl+alt+F-key". so i don't get the whole "get tour mind blown" thing there, i have heard it multiple times.
or am i missing something?
Yeah you're missing the point that the mind blown is just ironic.
The entire point here was to demonstrate that the "security" features of these DEs are not implemented by the DE but by the underlying components such as PAM, and you can just ignore the DE until you have the basics fixed.
What's the point in having a super duper secure login screen if I can bypass it by booting from a USB stick for example.
reading your comments, you like to say that someone has "missed the point".
well, my point is, you should not ignore the DE. i mean, you can, if you can bypass the login as is, sure. but from a user perspective, you should not ignore it, because the DE is a potential security risk. e.g. if your screen lock crashes and whatnot.
sure, yes indeed, your DE can be as secure as you want and it doesn't matter if your underlying system is not secure. and yes indeed, with any non-encrypted drive, you can just mount the drives on another system (e.g. boot the computer from a USB drive). that almost goes without saying imo, and of course that's why an encrypted drive is recommended.
the question is, how easy is it to get to the stuff with an encrypted drive when the system is booted and the encrypted drive(s) is (are) mounted? it is not that easy. and there, the quality of your screen lock setup is the biggest risk factor, usually. if you can crash your DE/WM somehow, if it is not setup right with your display manager or something, then you might be able to get into a login (and interactive) shell of that user (maybe because it is the parent process of your WM that you started with startx).
if you "allow" your potential attacker to reboot from a usb stick, then it is obvious that your DE doesn't matter at all pretty much.
Well especially if the previous comment asked "or am I missing something".
Obviously I could be wrong that's why I said I THINK
the "missing something" was with regards to what i said about ctrl+alt+F-something not giving some extra attack point. missing something that would blow my mind. if you say the mind blowing is ironic or whtever then it doesn't matter anyway.