8 ms·

I am nuts into linux desktop security, but I cannot imagine recommending this to even other developers, let alone non-dev users. There are just too many usabili

I am nuts into linux desktop security, but I cannot imagine recommending this to even other developers, let alone non-dev users. There are just too many usability tradeoffs, the whole thing is a major time waster, and you have to deal with a lot of breakage. Making basic security measures easy to implement is what's going to help in the long run.

hospitalJail 3y ago
>I am nuts into linux desktop security What things do I need to worry about? I'm about to make the switch from Windows to Linux. Is it general 'dont run things you don't trust'? keep things updated? Use good passwords?(do I need to change a setting to prevent brute forcing?) Am I missing anything?
- smoldesu 3y ago
  "read scripts before you run them" is a good bit of advice. Some little things can help you protect your GUI apps if you're extra paranoid (eg. Wayland is more secure, Flatpak offers additional sandboxing with bubblewrap) but not everything is necessary. If you use a mainstream distro like Fedora or Ubuntu, its default configuration should be safe enough to use like Windows. Just remember that there isn't really any antivirus or Microsoft Defender to save you if you really mess up. I do offline backups of important work on all my devices, for this reason partially.
  - hospitalJail 3y ago
    >Some little things can help you protect your GUI apps if you're extra paranoid Can you explain this? What are the exploits? Is it the equivalent of running a .exe or .jar on windows, but with an extra layer of protection? (Or am I trying to shove my windows ideas into linux?)
    - smoldesu 3y ago
      > Can you explain this? What are the exploits? Traditional desktop Linux allows different apps to more-or-less freely communicate with each other (called the x11 protocol). This works really well for old apps (and admittedly not too bad for new ones) but is very slow and exposes a lot of bugs. On top of this, you have potential exploits in your filesystem from loosely permissioning important settings and identity files. So, the attack surface for a traditional Linux distro is relatively large. > Is it the equivalent of running a .exe or .jar on windows, but with an extra layer of protection? Kinda! Linux software is distributed as packages, which contains a binary (the exe/jar portion), a dependency manifest and whatever static content it needs. A sandbox like Flatpak will take those packages and put it into a sandbox, to prevent hostile interprocess communication and filesystem exploits. None of these mitigations are perfect per-se (nor are they on Mac/Windows), so use them wisely if you intend to use them at all. I have used a non-sandboxed system to run old 90s Windows games for years though, and haven't picked up any significant issues. YMMV, it is Linux after all :P
      - hospitalJail 3y ago
        >Traditional desktop Linux allows different apps to more-or-less freely communicate with each other (called the x11 protocol). Oh gosh. I'm getting heart palpitations :P Is this a common attack vector then? Seems like an easy way to get an overflow error, or elevate privilege's.
        bombolo 3y ago
        Not common at all. Because most software comes from distributions, not from warez.exe. Sandbox comes with a heavy usability price, so they are lax by default. For example you protect your files, but then you can't load your photos to facebook because your browser doesn't have access.
        t0astbread 3y ago
        There's also a newer protocol called "Wayland" which aims to avoid some issues with X11 (and is also a general architecture overhaul). GNOME and KDE support it out of the box and iirc at least GNOME also enables it by default. There are some tradeoffs though. Some things like screen sharing might be worse on Wayland (e.g. I can't share a single window, only whole screens) and some apps don't support Wayland at all (including for example all of the IntelliJ IDEs). The latter can be circumvented by enabling XWayland (basically an X server running side by side with the Wayland compositor to handle X11-only apps). In that case you're left with the X11 security model for apps not running natively on Wayland.
  - TacticalCoder 3y ago
    > "read scripts before you run them" is a good bit of advice. I always read the script and do also verify they're only using ASCII chars (and if they're not, I check which Unicode shenanigan is ongoing). For example: ... $ file /usr/local/bin/somescript.sh /usr/local/bin/somescript.sh: Bourne-Again shell script, ASCII text executable FWIW most of the scripts out there are only ever using ASCII chars.
    - chaxor 3y ago
      How do you check it without running something that may execute it? Many scripts will execute if opened with vi or even cat or printf from what I understand.
      - cyberbanjo 3y ago
        Source for executing files with cat? That certainly defies my understand of how cat works.
        RadiozRadioz 3y ago
        Maybe they mean that it can include control characters that mess up your terminal and make it look like something malicious is happening, which of course is not the same as executing it (and has a warning anyway).
      - JohnFen 3y ago
        > Many scripts will execute if opened with vi I haven't encountered this. You can execute scripts intentionally in vi, and I assume you could configure it to happen automatically, but can this happen without you making some sort of effort to enable it? What scripts present such a risk? What vi configuration is required to stop this? Same question wrt cat.
      - deadbunny 3y ago
        (n)vi(m), cat, less/more do not execute scripts on read. That would be utterly insane.
      - deleted 3y ago
- mecsred 3y ago
  All three of those are great things to do. The fact that you know to mention them makes me think you don't need to worry much. When Linux people say they're into security, it usually means research level computer science, not "I don't want my laptop to get malware".
  - hospitalJail 3y ago
    The only caveat I'd like to say, I think we shouldnt assume every user isnt a VIP. I'm not a VIP, but I have some huge huge huge secrets that are worth at least a million dollars, maybe 10s of millions of dollars, that I need to access with a computer. Malware means potentially losing millions or tens of millions of dollars. I'm so afraid of those secrets, I don't even access them on my windows computers unless necessary. I'd love to be comfortable doing this, but given anyone can seemingly make a python keylogger, I'm not really comfortable using my computer(windows or linux) for this purpose. Gaming/updating my website/etc... all of that, who cares if I'm hacked, I got backups. I just havent found a great way to keep secrets that need to go online.
    - mecsred 3y ago
      I'd recommend not taking any security advice from internet forums at all if millions are on the line, regardless of OS. I'd hire a professional to harden the computer I want to use for that and wouldn't use it for anything else. An apple device would probably be my go-to there over any Linux system.
- dannymi 3y ago
  If you run programs that you can't trust (for example because the source is unavailable and/or nobody reads it, no one is a gatekeeper of program updates etc), then you are opening yourself to attack because the default unix security model is just as bad as the Windows one. (The Windows one used to be much worse, but it isn't anymore, now they are the same badness) Nowadays, the web browser is used as a platform to run programs on and so it has a lot of access to weird things (multiple monitors, local filesystem, ...) so one has to be careful what you enable there--since you probably run a lot of Javascript written by shady people you don't know. The Linux desktop security model has user accounts, and then files have permissions for those users (yeah, there are also user groups, whatever). That means if you have a misbehaving (or malicious) program, it can read stuff in your home directory since that's owned by the same user account--so it can read your saved passwords, delete all your photos, figure out your banking info--but hey, at least it can't remove your printer (since for the latter you need to use the root user account :P) /s . There are mitigations against that and the easiest (and crappiest) one is containerization: just run each program in an isolated virtual-machine-like-thing and they can't access other program's data (i.e. the rest of YOUR data) in the first place. Then there's SELinux which flips this entire thing on its head. By default, nobody can do anything (that's the first very good decision!). If a process wants to do things, there has to be a policy installed that mentions that specific thing to be allowed and when. Otherwise no go. This way of working is much safer, BUT someone has to maintain those policies! And it must not be the program's author since he could just add whatever line he wants to have to the policy--and that's obviously bad. So who does it? Usually the Linux distribution's maintainer. Or, more commonly, nobody--so there's no policy for your favorite program and so it won't work.
  - anthk 3y ago
    Containers are not virtual machines.
    - egberts1 3y ago
      But container is a form of virtualization.
- guy98238710 3y ago
  The core three tenets are drive encryption (easy), regular wipes (10h/year), and sandboxing (crazy expensive at the moment). That gives you decent security.
  - bojo 3y ago
    What is the 10h/year metric?
  - PhilipRoman 3y ago
    If you have a basic understanding of mounts, sandboxing a program in bubblewrap is pretty easy. And of course there are pre-made solutions like firejail.
    - mrob 3y ago
      >sandboxing a program in bubblewrap is pretty easy It's not easy. Just getting the mounts right is not sufficient. You also need to consider syscalls. E.g. TIOCSTI is permitted by default and allows an easy sandbox escape. See [0]CVE-2017-5226. TIOCLINUX can also allow sandbox escapes. This can be prevented with the --new-session option, but that breaks interactive terminals, e.g. it causes ctrl-C to restore input to the parent shell while simultaneously running the child shell on the same terminal with the same inputs, which makes it unusable. The alternative is compiling a seccomp BPF program to filter the syscalls, and loading it with the --seccomp option, but even this is non-trivial, e.g. see [1]CVE-2019-10063. This is also a case of "enumerating badness"; there's no guarantee that other syscalls are not also exploitable. [0] https://nvd.nist.gov/vuln/detail/CVE-2017-5226 https://nvd.nist.gov/vuln/detail/CVE-2017-5226 [1] https://nvd.nist.gov/vuln/detail/CVE-2019-10063 https://nvd.nist.gov/vuln/detail/CVE-2019-10063
      - PhilipRoman 3y ago
        Ah it sure does feel good to be humbled. Glad to know my personal setups are not affected as they do not give access to the outer tty but at the same time - WTF is going on inside developers heads!? I've noticed a trend of adding N deeply intertwined features which then interact in N! different ways and no one bothers to define rigorous semantics for them. And then you have to get a PhD in Linux just to understand whether your system is vulnerable when you use POSIX message queues inside a FUSE filesystem inside an unprivileged user namespace inside chroot inside setarch running in 9 nested terminal sessions. I think I'm starting to understand why some people swear by the BSDs. Edit: just checked and OpenBSD has indeed removed TIOCSTI in 2017.
vidyesh 3y ago
I feel every privacy & security measure taken be it on your system or just your browser config needs to be understood properly before applying. So I think there is value in recommending such articles to everyone interested, as it would open them to understanding attack/leak vectors and be aware of those. The fallacy that anything that isn't Windows is safe needs to come with a caveat that blind trust with the basic security policies can lead to disaster.
kelvie 3y ago
Completely agree. I also went through this exercise, having switched from a Chromebook (RIP pixelbook, probably my favourite computer until it died) to Linux on Framework, where I set this up from scratch. Anyone can say what they want about chromeOS not being a real OS (I disagree, that's off-topic), but it was built to be secure-by-default -- at least with regard to basically everything in this article. Even with a stock, up-to-date linux kernel (I use arch BTW), there are a ton of gotchas, such as the fact that lockdown mode disables hibernate (!)-- I needed to patch the kernel to tell it I know better (there are some good LWN articles on why they did it, it's cause there are far too many gotchas): https://gist.github.com/kelvie/917d456cb572325aae8e3bd94a9c1350 https://gist.github.com/kelvie/917d456cb572325aae8e3bd94a9c1... Chromebook on Framework actually seems like a great value prop in this regard, but of course you have to sell your metadata to big G.
- 7speter 3y ago
  Most people disable hibernate because they use ssd’s for boot disks, no?
  - kogir 3y ago
    Hibernate is usually used to allow the computer to shut down completely and not remain in standby, saving battery. It’s not about boot speed anymore.
    - patrick451 3y ago
      Yeah, mine too. Getting to hte grub menu takes probably 90 seconds. Booting from there takes about 10. I'd love to know why that is.
  - kelvie 3y ago
    It's not really boot speed that's the issue, it's just that, like on my work Macbook, when I close my laptop's lid on Friday to catch the train, I expect: 1. The laptop to sleep 2. After some time, it'll hibernate so it doesn't drain the entire battery over the weekend 3. When I fire it up on monday, whatever I was working on is still there. It's hard to do this without hibernate (or a _really_ efficient sleep). You actually have to configure sleep-then-hibernate on systemd for this to work right. Again, I still think chromeOS is the future of the linux desktop (again, if you don't mind Google watching over).
JohnFen 3y ago
All security (computer or otherwise) is a balance between being usable and being secure. The ideal balance point is a very individual thing.

hospitalJail 3y ago

>I am nuts into linux desktop security What things do I need to worry about? I'm about to make the switch from Windows to Linux. Is it general 'dont run things you don't trust'? keep things updated? Use good passwords?(do I need to change a setting to prevent brute forcing?) Am I missing anything?

smoldesu 3y ago
"read scripts before you run them" is a good bit of advice. Some little things can help you protect your GUI apps if you're extra paranoid (eg. Wayland is more secure, Flatpak offers additional sandboxing with bubblewrap) but not everything is necessary. If you use a mainstream distro like Fedora or Ubuntu, its default configuration should be safe enough to use like Windows. Just remember that there isn't really any antivirus or Microsoft Defender to save you if you really mess up. I do offline backups of important work on all my devices, for this reason partially.
- hospitalJail 3y ago
  >Some little things can help you protect your GUI apps if you're extra paranoid Can you explain this? What are the exploits? Is it the equivalent of running a .exe or .jar on windows, but with an extra layer of protection? (Or am I trying to shove my windows ideas into linux?)
  - smoldesu 3y ago
    > Can you explain this? What are the exploits? Traditional desktop Linux allows different apps to more-or-less freely communicate with each other (called the x11 protocol). This works really well for old apps (and admittedly not too bad for new ones) but is very slow and exposes a lot of bugs. On top of this, you have potential exploits in your filesystem from loosely permissioning important settings and identity files. So, the attack surface for a traditional Linux distro is relatively large. > Is it the equivalent of running a .exe or .jar on windows, but with an extra layer of protection? Kinda! Linux software is distributed as packages, which contains a binary (the exe/jar portion), a dependency manifest and whatever static content it needs. A sandbox like Flatpak will take those packages and put it into a sandbox, to prevent hostile interprocess communication and filesystem exploits. None of these mitigations are perfect per-se (nor are they on Mac/Windows), so use them wisely if you intend to use them at all. I have used a non-sandboxed system to run old 90s Windows games for years though, and haven't picked up any significant issues. YMMV, it is Linux after all :P
    - hospitalJail 3y ago
      >Traditional desktop Linux allows different apps to more-or-less freely communicate with each other (called the x11 protocol). Oh gosh. I'm getting heart palpitations :P Is this a common attack vector then? Seems like an easy way to get an overflow error, or elevate privilege's.
      - bombolo 3y ago
        Not common at all. Because most software comes from distributions, not from warez.exe. Sandbox comes with a heavy usability price, so they are lax by default. For example you protect your files, but then you can't load your photos to facebook because your browser doesn't have access.
      - t0astbread 3y ago
        There's also a newer protocol called "Wayland" which aims to avoid some issues with X11 (and is also a general architecture overhaul). GNOME and KDE support it out of the box and iirc at least GNOME also enables it by default. There are some tradeoffs though. Some things like screen sharing might be worse on Wayland (e.g. I can't share a single window, only whole screens) and some apps don't support Wayland at all (including for example all of the IntelliJ IDEs). The latter can be circumvented by enabling XWayland (basically an X server running side by side with the Wayland compositor to handle X11-only apps). In that case you're left with the X11 security model for apps not running natively on Wayland.
- TacticalCoder 3y ago
  > "read scripts before you run them" is a good bit of advice. I always read the script and do also verify they're only using ASCII chars (and if they're not, I check which Unicode shenanigan is ongoing). For example: ... $ file /usr/local/bin/somescript.sh /usr/local/bin/somescript.sh: Bourne-Again shell script, ASCII text executable FWIW most of the scripts out there are only ever using ASCII chars.
  - chaxor 3y ago
    How do you check it without running something that may execute it? Many scripts will execute if opened with vi or even cat or printf from what I understand.
    - cyberbanjo 3y ago
      Source for executing files with cat? That certainly defies my understand of how cat works.
      - RadiozRadioz 3y ago
        Maybe they mean that it can include control characters that mess up your terminal and make it look like something malicious is happening, which of course is not the same as executing it (and has a warning anyway).
    - JohnFen 3y ago
      > Many scripts will execute if opened with vi I haven't encountered this. You can execute scripts intentionally in vi, and I assume you could configure it to happen automatically, but can this happen without you making some sort of effort to enable it? What scripts present such a risk? What vi configuration is required to stop this? Same question wrt cat.
    - deadbunny 3y ago
      (n)vi(m), cat, less/more do not execute scripts on read. That would be utterly insane.
    - deleted 3y ago
mecsred 3y ago
All three of those are great things to do. The fact that you know to mention them makes me think you don't need to worry much. When Linux people say they're into security, it usually means research level computer science, not "I don't want my laptop to get malware".
- hospitalJail 3y ago
  The only caveat I'd like to say, I think we shouldnt assume every user isnt a VIP. I'm not a VIP, but I have some huge huge huge secrets that are worth at least a million dollars, maybe 10s of millions of dollars, that I need to access with a computer. Malware means potentially losing millions or tens of millions of dollars. I'm so afraid of those secrets, I don't even access them on my windows computers unless necessary. I'd love to be comfortable doing this, but given anyone can seemingly make a python keylogger, I'm not really comfortable using my computer(windows or linux) for this purpose. Gaming/updating my website/etc... all of that, who cares if I'm hacked, I got backups. I just havent found a great way to keep secrets that need to go online.
  - mecsred 3y ago
    I'd recommend not taking any security advice from internet forums at all if millions are on the line, regardless of OS. I'd hire a professional to harden the computer I want to use for that and wouldn't use it for anything else. An apple device would probably be my go-to there over any Linux system.
dannymi 3y ago
If you run programs that you can't trust (for example because the source is unavailable and/or nobody reads it, no one is a gatekeeper of program updates etc), then you are opening yourself to attack because the default unix security model is just as bad as the Windows one. (The Windows one used to be much worse, but it isn't anymore, now they are the same badness) Nowadays, the web browser is used as a platform to run programs on and so it has a lot of access to weird things (multiple monitors, local filesystem, ...) so one has to be careful what you enable there--since you probably run a lot of Javascript written by shady people you don't know. The Linux desktop security model has user accounts, and then files have permissions for those users (yeah, there are also user groups, whatever). That means if you have a misbehaving (or malicious) program, it can read stuff in your home directory since that's owned by the same user account--so it can read your saved passwords, delete all your photos, figure out your banking info--but hey, at least it can't remove your printer (since for the latter you need to use the root user account :P) /s . There are mitigations against that and the easiest (and crappiest) one is containerization: just run each program in an isolated virtual-machine-like-thing and they can't access other program's data (i.e. the rest of YOUR data) in the first place. Then there's SELinux which flips this entire thing on its head. By default, nobody can do anything (that's the first very good decision!). If a process wants to do things, there has to be a policy installed that mentions that specific thing to be allowed and when. Otherwise no go. This way of working is much safer, BUT someone has to maintain those policies! And it must not be the program's author since he could just add whatever line he wants to have to the policy--and that's obviously bad. So who does it? Usually the Linux distribution's maintainer. Or, more commonly, nobody--so there's no policy for your favorite program and so it won't work.
- anthk 3y ago
  Containers are not virtual machines.
  - egberts1 3y ago
    But container is a form of virtualization.
guy98238710 3y ago
The core three tenets are drive encryption (easy), regular wipes (10h/year), and sandboxing (crazy expensive at the moment). That gives you decent security.
- bojo 3y ago
  What is the 10h/year metric?
- PhilipRoman 3y ago
  If you have a basic understanding of mounts, sandboxing a program in bubblewrap is pretty easy. And of course there are pre-made solutions like firejail.
  - mrob 3y ago
    >sandboxing a program in bubblewrap is pretty easy It's not easy. Just getting the mounts right is not sufficient. You also need to consider syscalls. E.g. TIOCSTI is permitted by default and allows an easy sandbox escape. See [0]CVE-2017-5226. TIOCLINUX can also allow sandbox escapes. This can be prevented with the --new-session option, but that breaks interactive terminals, e.g. it causes ctrl-C to restore input to the parent shell while simultaneously running the child shell on the same terminal with the same inputs, which makes it unusable. The alternative is compiling a seccomp BPF program to filter the syscalls, and loading it with the --seccomp option, but even this is non-trivial, e.g. see [1]CVE-2019-10063. This is also a case of "enumerating badness"; there's no guarantee that other syscalls are not also exploitable. [0] https://nvd.nist.gov/vuln/detail/CVE-2017-5226 https://nvd.nist.gov/vuln/detail/CVE-2017-5226 [1] https://nvd.nist.gov/vuln/detail/CVE-2019-10063 https://nvd.nist.gov/vuln/detail/CVE-2019-10063
    - PhilipRoman 3y ago
      Ah it sure does feel good to be humbled. Glad to know my personal setups are not affected as they do not give access to the outer tty but at the same time - WTF is going on inside developers heads!? I've noticed a trend of adding N deeply intertwined features which then interact in N! different ways and no one bothers to define rigorous semantics for them. And then you have to get a PhD in Linux just to understand whether your system is vulnerable when you use POSIX message queues inside a FUSE filesystem inside an unprivileged user namespace inside chroot inside setarch running in 9 nested terminal sessions. I think I'm starting to understand why some people swear by the BSDs. Edit: just checked and OpenBSD has indeed removed TIOCSTI in 2017.

vidyesh 3y ago

I feel every privacy & security measure taken be it on your system or just your browser config needs to be understood properly before applying. So I think there is value in recommending such articles to everyone interested, as it would open them to understanding attack/leak vectors and be aware of those. The fallacy that anything that isn't Windows is safe needs to come with a caveat that blind trust with the basic security policies can lead to disaster.

kelvie 3y ago

Completely agree. I also went through this exercise, having switched from a Chromebook (RIP pixelbook, probably my favourite computer until it died) to Linux on Framework, where I set this up from scratch. Anyone can say what they want about chromeOS not being a real OS (I disagree, that's off-topic), but it was built to be secure-by-default -- at least with regard to basically everything in this article. Even with a stock, up-to-date linux kernel (I use arch BTW), there are a ton of gotchas, such as the fact that lockdown mode disables hibernate (!)-- I needed to patch the kernel to tell it I know better (there are some good LWN articles on why they did it, it's cause there are far too many gotchas): https://gist.github.com/kelvie/917d456cb572325aae8e3bd94a9c1350 https://gist.github.com/kelvie/917d456cb572325aae8e3bd94a9c1... Chromebook on Framework actually seems like a great value prop in this regard, but of course you have to sell your metadata to big G.

7speter 3y ago
Most people disable hibernate because they use ssd’s for boot disks, no?
- kogir 3y ago
  Hibernate is usually used to allow the computer to shut down completely and not remain in standby, saving battery. It’s not about boot speed anymore.
  - patrick451 3y ago
    Yeah, mine too. Getting to hte grub menu takes probably 90 seconds. Booting from there takes about 10. I'd love to know why that is.
- kelvie 3y ago
  It's not really boot speed that's the issue, it's just that, like on my work Macbook, when I close my laptop's lid on Friday to catch the train, I expect: 1. The laptop to sleep 2. After some time, it'll hibernate so it doesn't drain the entire battery over the weekend 3. When I fire it up on monday, whatever I was working on is still there. It's hard to do this without hibernate (or a _really_ efficient sleep). You actually have to configure sleep-then-hibernate on systemd for this to work right. Again, I still think chromeOS is the future of the linux desktop (again, if you don't mind Google watching over).

JohnFen 3y ago

All security (computer or otherwise) is a balance between being usable and being secure. The ideal balance point is a very individual thing.