I agree with the general sentiment. Thank you for mentioning that!
Though, the use of sudo nano
might still pose a risk if any software found on the system is either vulnerable/exploitable, not trusted, or simply exploitative. In that case, like what's achieved through sandboxing i.e. not allow the software to go beyond their intended scope, it makes sense to put a limit on the capabilities of the software. And to that effect, the use of sudoedit
still offers merit over sudo nano
.
Though, if the user doesn't (already) rely on bubblejail, firejail, Flatpak etc for what they offer in sandboxing. And/or if said user simply doesn't care for the principle of least privilege, then the use of sudo nano
is perfectly valid.
Thank you for your elaborate answers!
Qubes OS has a very steep learning curve due to its difficult usability, so the answer would be “both”. I am willing to tackle and overcome, but I’m not ready to put in that work yet, if at all.
Qubes OS is definitely more involved than the average distro, so I can understand why you feel that way.
I have a really funny story regarding threat models. When I first got into privacy 2-3 years ago, I had the goal of getting as deep as I could (the “strictest threat model possible”) and work backwards to find out what I was willing to allow.
Hahaha 🤣, very relatable; I almost wanted to learn SELinux for hardening purposes. Thankfully, Qubes OS exists as my endgame, which deterred (most of) the motivation (and need) to comprehend SELinux in the first place.
I have a “subconscious” threat model. I have, over the past week, started working on answering the classic questions. I am trying to protect against “evil” corporations, and such, I must also protect myself against some low level government threats. My threat model “philosophy” is: I will not use a piece of software if it actively goes against me in terms of privacy. Windows, for example, is a pain to try to use while maintaining privacy.
We can work with that, though I kindly implore you to further work out your threat model. It will(/should) give you some peace of mind (or at least a security/privacy roadmap on which you can (slowly but steadily) work towards). If I would have to distill your philosophy, it would be something like "be protected from attacks targeted towards low(er) hanging fruit". Would that be fair?
You are the third person to recommend SecureBlue (I’ve been keeping track), and since it is a “Fedora Atomic spin” (Fedora Atomic as well as Atomic distros in general were also recommended three times each), I believe I will switch to it to see how it is.
Great choice! FWIW, I've also been on it for a couple of weeks now and I've really been enjoying it. Before, I had my own custom image that was built using the (legacy-)template from uBlue. I tried to harden it myself 😅, and I would argue I did and achieved some cool stuff with it. But, it's very clear that my technical knowledge doesn't even come close to that of secureblue's maintainers. I just wish I had rebased earlier 😅.
By the way, I love the mention of GrapheneOS, since that will eventually (finances be blessed) be my main mobile OS
I definitely agree with that sentiment. Btw, FWIW, I know for a fact that at least one individual that's associated with GrapheneOS has 'contributed' to secureblue.
I wish there was a true “Linux alternative to GrapheneOS”.
Hehe, without going into what that actually means and would entail, I agree 😜.
So I would like to ask a couple of questions:
Qubes OS (Tried it twice, not ready yet)
Is Qubes OS not ready yet for your intended workflow/usage? Or are you not ready to make the complete switch (yet)?
For me, it has been incredibly difficult to find a properly privacy oriented Linux distro that also has ease of use.
Unfortunately, in almost all cases, increased security/privacy is achieved through the loss of convenience. Therefore, you should ask yourself what the minimum level of security/privacy is that you absolutely require/need. How's your threat model defined (if at all)?
My issue with Fedora is the lack of proper sandboxing, and it seems as though Qubes is the only one that really takes care in sandboxing apps.
I agree that there's still a long road ahead until we have on Linux whatever is found on GrapheneOS or Qubes OS. I'm aware that you can technically utilize VMs on any distro, but the experience will not be as streamlined (nor as secure) as you may find on Qubes OS. But, Flatpak does offer some sandboxing. And while it may not be as powerful as you may want, and some apps may not utilize portals as they should. Still, it's definitely worthwhile and perhaps the best we've got currently. Furthermore, bubblejail allows you to (relatively easily) utilize (some of) the technology that's used to sandbox Flatpak apps for all your non-Flatpak apps. It can be found on Copr if you choose to stick to Fedora.
On that note, the maintainers of the aforementioned Copr package have built an interesting project for those that seek security-focused (or simply hardened) images of Fedora Atomic; (aptly named) secureblue. It's still a relatively young project, but their innovations have definitely been noteworthy and it seems to have a bright future ahead.
While we're in the vicinity of 'hardened-for-you'-distros, we should mention Kicksecure. By contrast, this is a well-established distro by the people that also develop Whonix.
Without hearing your answers to my questions, I think these two are the primary candidates. Though sticking to Fedora ain't a bad choice either.
so I run
sudo nano /etc/default/grub
For improved security during file edits that require root access, it's highly advised to use sudoedit
(or sudo -e
). This method is considered the standard practice to avoid the security pitfalls associated with directly invoking editors with sudo
. To ensure the use of nano
with sudoedit
, simply set the VISUAL
environment variable with export VISUAL=nano
before running sudoedit
. Alternatively, for a one-off command: VISUAL=nano sudoedit /path/to/file
.
Please note that while sudoedit
is a safer starting point, it's not the only method available. Alternatives such as doas
, doasedit
, or leveraging polkit
with pkexec
can offer even more controlled and secure ways to manage file editing with elevated privileges. However, it's perfectly acceptable to stick with sudoedit
, as it's a commonly trusted tool.
Be aware that direct usage of sudo nano
or other editors is strongly discouraged. It bypasses important security mechanisms and can lead to inadvertent system-wide risks.
EDIT: changed VISUAL=nano sudoedit
to VISUAL=nano sudoedit /path/to/file
.
Yeah, I wouldn't abandon a perfectly working system for one that straight up dies for nothing.
Maybe, if you've got some spare space on your system, consider dual-booting it. If the issues persist, then Kubuntu 24.04 LTS sounds good as a replacement.
As I've been daily driving Fedora Silverblue for almost two years now, I always am astonished whenever I hear horror stories from other users that have broken their systems due to seemingly innocent actions. I hope this was just a dud due to the VM environment and isn't representative of KDE Neon's stability; which I've actually heard good things about*.
I'm personally also most fond of picking the independent (so not a derivative) distro that best suits your needs and customize it from there, unless the planned modifications are hard and/or cumbersome to realize and a popular derivative that streamlines most of that already exists.
KDE Neon is indeed an excellent distro if you like KDE Plasma. I would love to read your findings/evaluation on that 😉!
@Throwaway1234
@sh.itjust.works