5 ms·

Linux is so weird with its approach to security. So many prevention tools and LSMs but it is the easiest platform for post exploitation. For one a lot of effort

by _8j50 3y ago

Linux is so weird with its approach to security. So many prevention tools and LSMs but it is the easiest platform for post exploitation. For one a lot of effort goes into stopping you from getting root but all if it revolves around the sysadmin not making one of many mistakes and even as root, instead of having a sane way of signing kernel modules by a trusted party (distro), they take great pains to make it hard to do bad stuff like preventing hooks and other things being used by LKMs. Linux security is architected by really smart figures that are mentally stuck on ideologies and silver bullets, don't get me wrong, if setup right Linux is difficult for attackers but that rarely ever happens. There are too many "well if a threat actor can do that then you have bigger problems" type of oldschool legacy thinking. What I really want in Linux is good defaults that treat users as infants playing with scisssors. Get over the whole "centralized anything is bad" b.s., and for distros to have good monitoring tools. Detection deserves more priority than prevention. Imagine having all the difficult to tune LKM rules, auditd,etc... play nice with each other and alert visually on the desktop and insist on you giving them your email or whatever so the distro managed alerting servers can alert you on stuff. On windows even when I disable defender it secretly monitors stuff and re-enables some features when it sees weird things (and MS would even alert your people if you are an enterprise customer and it is a serious threat) and it can be one of the hardesr hurdles to overcome. To fully disable defender or AV, you have to exploit a vulnerable signed driver, on linux just rm -rf stuff and unload it as root because "if they have root, you have bigger problems" Nothing against this tool, at least they seem to have detection (alerting?) in mind as well from what I skimmed.

LinuxBender 3y ago
What I really want in Linux is good defaults I agree with the sentiment but experience tells me that Linux would have poor adoption should that become the case. I have implemented secure defaults via OS images in different environments from Dev to Staging to Production and in all environments any mitigating control that was not specified in a customer contract was backed out eventually with exception of the PCI environment. But in spirit I agree and miss the security controls and defaults that were in OpenVMS. Those controls made it into NT but were mostly all opened up by default to improve adoption. I had the same challenges getting SELinux deployed everywhere. People that strayed far from defaults and application best practices would shake their fists at it and in some places it was set permissive. There are even non security defaults such as over-commit that were adjusted to improve adoption by developers and became the basis of OOM circular arguments across the internet.
lima 3y ago
What I really want in Linux is good defaults that treat users as infants playing with scisssors Sounds like you want Chromium OS :-) Fully open source, Linux-based, and it's hardened to the point where neither the user, nor an attacker, can execute any abitrary code outside a sandbox without a Chrome and/or Linux 0day. You even get VMs with seamless Wayland-based desktop integration with a normal Linux distro inside, and you can create multiple VMs if you have different security levels. If you enable crash reporting, Google will find and triage crashes for you and would quite possibly catch buggy exploits, and maybe tell you about it. But, this is very far from what most people want in a Linux distro.
josephcsible 3y ago
The reason I use Linux and not Windows is that I like that it doesn't work in any of the ways you want your OS to work. I want my OS to treat me like a responsible adult, not like I'm an infant running with scissors.
- _8j50 3y ago
  That's what I mean about terrible undying ideologies plaguing Linux. I get it, I feel the same way too but what you don't get is most humans can't painstakingly configure Linux to be secure. What you end up having is something worse than Windows, a system where because you think you are "responsible" it is secure, your false sense of security as a result will cause you more harm. What I want is for Linux to have good and secure defaults that assume I am an infant with scissors but then if I want to change that and stab myself with a scissor, it lets me do so in the most efficient way possible.
0cf8612b2e1e 3y ago
I have become increasingly concerned about non-privilege escalation security breaches. As a developer, I run so much code in the form of tools, libraries, etc which are barely vetted, yet they have full access to read and upload everything on my system. SSH keys, credentials, env files are all a minor project takeover away because there is effectively zero user space isolation. Running everything inside a guest VM is looking like an unceasingly sane strategy.
- jeroenhd 3y ago
  I've worked with someone who insisted on running every different project or third party tool in a separate Vagrant machine. At first I scoffed at it, because it seemed like such a waste of resources (this was before VT-d was mainstream let alone other optimizations), but over the years I've only gained more respect for their approach. One problem that I always come back to when I try to set up such restrictions if the lack of GPU access from a VM. A relatively recent standard for virtual GPUs should work on all major players, but both on Intel and Nvidia I've never gotten it to work without crashes or glitches on my hardware. These days, Linux's containerization API seems mature enough to set usable limits. It's possible to escape containers through kernel exploits and misconfigurations (i.e. the "docker-in-docker" setups) but honestly I'm mostly trying to protect one of the million files yarn downloads for me to read my ~/.ssh directory. I believe systemd-run should allow me to run many dev tools with proper sandboxing if I call it right, but I haven't bothered to read up on it yet. I'm also slightly annoyed at the lack of good tooling for setting up quick and dirty network namespaces. The tools I've seen seem to assume that whatever namespace I want to set up will be part of my permanent machine setup, with changes to system daemon config all over the place. Another path to consider is switching to more hardware backed storage. I've put my SSH key in my TPM and no malware is ever going to exfiltrate the private key from there. I've thought up some theoretical solutions to the API access problem and the best I've been able to come up with has been a TPM-backed dom0 VM with the rest of the system in dom1, all other hardware forwarded through VT-d and friends, with access to the dom0 VM only through some kind of interactive protocol, possibly with some kind of network-based permission prompt before key access (i.e. click allow on your phone for the secret VM to share the product key). It would probably work, but I have no illusions about someone making something like that that's going to be usable on a normal user desktop, let alone a mobile device (with all of its power management challenges).
jeroenhd 3y ago
> What I really want in Linux is good defaults that treat users as infants playing with scisssors. You're not alone! Distros have been trying to fix the "user got pwned so attacker basically has root" problem for a while now. One approach people tried for a while was the SELinux/AppArmor method. This works great for server daemons but there's nothing for user facing applications. Docker and other types of containers replaced most of that approach as far as I can tell, and SystemD replaced the parts that couldn't easily be containerized. On the user facing side, Flatpak and (sadly) Snap have become mainstream as ways to limit exposure. You can drop a file into ~/Downloads, but if you exploit the browser you won't be able to access ~/.ssh/ because of sandboxing constraints. There are problems to this approach. First of all, nobody is going to rewrite thirty years of software to work with the latest and greatest New Thing. Old stuff will need to work the old way or will need to be wrapped in some kind of compatibility layer that will be annoying to deal with because it requires unsealing the secure outer shell. Then there are the users. Linux users hate change of any kind. There are still many vocal people who will curse out anything that contains systemd. Their unique preferences include storing their personal files in some kind of recursively linked directory structure operating from ~/.myhome/tmp using a bespoke encryption algorithm and if you dare touch it, you might as well be Micro$oft itself. These are a tiny minority of any community, but they'll crawl out of the woodworks in any discussion of your proposal. There's also actionability to take into account. If I'd get some kind of LKM or auditd popup on my laptop, I would have no idea what to do next. Is it bad if something is touching /var/run/udev0.elf? Is that just some part of my system I never knew about? Whatever alerting system you build, you'll need some kind of decision making process that clearly labels what each message means, why that's bad, how to verify that this is actually a problem and what steps to take next. That's an immense documentation task nobody is going to want to undertake. I like the general direction Linux is taking. Sandboxing applications makes sense and Flatpak seems to be here to stay. systemd is making restriction privileges very easy (if only distros would actually use it...) and using Docker for deployment (as non-root users) seems to be taking hold over the old ways. There are still things to be gained, like proper Linux antivirus engines for end users. ClamAV is nice but if it doesn't come preinstalled with live file access, it may as well not be there at all. The monitoring tools are already there. Everything is stored in journald and the various other log files, ready to be scooped up. Set up FileBeat and Kibana (or a more dedicated dashboard) and you've got more alerts and telemetry than you could ever wish. There are tools out there that try to be a security log monitor, but many of them end up being unmaintained and lacking support of that one specific tool you really need it to analyze. Windows suffers from many of the same issues regarding "well if they've got root you're already screwed". If you've got NTAUTORITY\SYSTEM, all of your fancy protection mechanisms quickly fall apart. Large parts of Windows' security layers are set up to prevent attackers from gaining privileges and most of them are ineffective with default settings. UAC bypasses can be found everywhere unless you put the UAC slider all the way to the top and/or log in as a non-administrator user. Driver signing is a bother, but loading drivers with known exploits is easy and basically hands you the same privileges. There's virtualisation based security and the VM based Windows sandbox thing, but that's not necessarily going to solve anything unless the attackers are after something stored inside those layers. The difference is perhaps that Windows has you operate with admin privileges much less often (although you shouldn't underestimate all of the hidden elevation with the UAC defaults!) compared to Linux.
no_time 3y ago
>To fully disable defender or AV, you have to exploit a vulnerable signed driver. Is there an automated tool for this? The guys behind DefenderControl threw in the towel and discontinued it.

by _8j50 3y ago

LinuxBender 3y ago

What I really want in Linux is good defaults I agree with the sentiment but experience tells me that Linux would have poor adoption should that become the case. I have implemented secure defaults via OS images in different environments from Dev to Staging to Production and in all environments any mitigating control that was not specified in a customer contract was backed out eventually with exception of the PCI environment. But in spirit I agree and miss the security controls and defaults that were in OpenVMS. Those controls made it into NT but were mostly all opened up by default to improve adoption. I had the same challenges getting SELinux deployed everywhere. People that strayed far from defaults and application best practices would shake their fists at it and in some places it was set permissive. There are even non security defaults such as over-commit that were adjusted to improve adoption by developers and became the basis of OOM circular arguments across the internet.

lima 3y ago

What I really want in Linux is good defaults that treat users as infants playing with scisssors Sounds like you want Chromium OS :-) Fully open source, Linux-based, and it's hardened to the point where neither the user, nor an attacker, can execute any abitrary code outside a sandbox without a Chrome and/or Linux 0day. You even get VMs with seamless Wayland-based desktop integration with a normal Linux distro inside, and you can create multiple VMs if you have different security levels. If you enable crash reporting, Google will find and triage crashes for you and would quite possibly catch buggy exploits, and maybe tell you about it. But, this is very far from what most people want in a Linux distro.

josephcsible 3y ago

The reason I use Linux and not Windows is that I like that it doesn't work in any of the ways you want your OS to work. I want my OS to treat me like a responsible adult, not like I'm an infant running with scissors.

_8j50 3y ago
That's what I mean about terrible undying ideologies plaguing Linux. I get it, I feel the same way too but what you don't get is most humans can't painstakingly configure Linux to be secure. What you end up having is something worse than Windows, a system where because you think you are "responsible" it is secure, your false sense of security as a result will cause you more harm. What I want is for Linux to have good and secure defaults that assume I am an infant with scissors but then if I want to change that and stab myself with a scissor, it lets me do so in the most efficient way possible.

0cf8612b2e1e 3y ago

I have become increasingly concerned about non-privilege escalation security breaches. As a developer, I run so much code in the form of tools, libraries, etc which are barely vetted, yet they have full access to read and upload everything on my system. SSH keys, credentials, env files are all a minor project takeover away because there is effectively zero user space isolation. Running everything inside a guest VM is looking like an unceasingly sane strategy.

jeroenhd 3y ago
I've worked with someone who insisted on running every different project or third party tool in a separate Vagrant machine. At first I scoffed at it, because it seemed like such a waste of resources (this was before VT-d was mainstream let alone other optimizations), but over the years I've only gained more respect for their approach. One problem that I always come back to when I try to set up such restrictions if the lack of GPU access from a VM. A relatively recent standard for virtual GPUs should work on all major players, but both on Intel and Nvidia I've never gotten it to work without crashes or glitches on my hardware. These days, Linux's containerization API seems mature enough to set usable limits. It's possible to escape containers through kernel exploits and misconfigurations (i.e. the "docker-in-docker" setups) but honestly I'm mostly trying to protect one of the million files yarn downloads for me to read my ~/.ssh directory. I believe systemd-run should allow me to run many dev tools with proper sandboxing if I call it right, but I haven't bothered to read up on it yet. I'm also slightly annoyed at the lack of good tooling for setting up quick and dirty network namespaces. The tools I've seen seem to assume that whatever namespace I want to set up will be part of my permanent machine setup, with changes to system daemon config all over the place. Another path to consider is switching to more hardware backed storage. I've put my SSH key in my TPM and no malware is ever going to exfiltrate the private key from there. I've thought up some theoretical solutions to the API access problem and the best I've been able to come up with has been a TPM-backed dom0 VM with the rest of the system in dom1, all other hardware forwarded through VT-d and friends, with access to the dom0 VM only through some kind of interactive protocol, possibly with some kind of network-based permission prompt before key access (i.e. click allow on your phone for the secret VM to share the product key). It would probably work, but I have no illusions about someone making something like that that's going to be usable on a normal user desktop, let alone a mobile device (with all of its power management challenges).

jeroenhd 3y ago

> What I really want in Linux is good defaults that treat users as infants playing with scisssors. You're not alone! Distros have been trying to fix the "user got pwned so attacker basically has root" problem for a while now. One approach people tried for a while was the SELinux/AppArmor method. This works great for server daemons but there's nothing for user facing applications. Docker and other types of containers replaced most of that approach as far as I can tell, and SystemD replaced the parts that couldn't easily be containerized. On the user facing side, Flatpak and (sadly) Snap have become mainstream as ways to limit exposure. You can drop a file into ~/Downloads, but if you exploit the browser you won't be able to access ~/.ssh/ because of sandboxing constraints. There are problems to this approach. First of all, nobody is going to rewrite thirty years of software to work with the latest and greatest New Thing. Old stuff will need to work the old way or will need to be wrapped in some kind of compatibility layer that will be annoying to deal with because it requires unsealing the secure outer shell. Then there are the users. Linux users hate change of any kind. There are still many vocal people who will curse out anything that contains systemd. Their unique preferences include storing their personal files in some kind of recursively linked directory structure operating from ~/.myhome/tmp using a bespoke encryption algorithm and if you dare touch it, you might as well be Micro$oft itself. These are a tiny minority of any community, but they'll crawl out of the woodworks in any discussion of your proposal. There's also actionability to take into account. If I'd get some kind of LKM or auditd popup on my laptop, I would have no idea what to do next. Is it bad if something is touching /var/run/udev0.elf? Is that just some part of my system I never knew about? Whatever alerting system you build, you'll need some kind of decision making process that clearly labels what each message means, why that's bad, how to verify that this is actually a problem and what steps to take next. That's an immense documentation task nobody is going to want to undertake. I like the general direction Linux is taking. Sandboxing applications makes sense and Flatpak seems to be here to stay. systemd is making restriction privileges very easy (if only distros would actually use it...) and using Docker for deployment (as non-root users) seems to be taking hold over the old ways. There are still things to be gained, like proper Linux antivirus engines for end users. ClamAV is nice but if it doesn't come preinstalled with live file access, it may as well not be there at all. The monitoring tools are already there. Everything is stored in journald and the various other log files, ready to be scooped up. Set up FileBeat and Kibana (or a more dedicated dashboard) and you've got more alerts and telemetry than you could ever wish. There are tools out there that try to be a security log monitor, but many of them end up being unmaintained and lacking support of that one specific tool you really need it to analyze. Windows suffers from many of the same issues regarding "well if they've got root you're already screwed". If you've got NTAUTORITY\SYSTEM, all of your fancy protection mechanisms quickly fall apart. Large parts of Windows' security layers are set up to prevent attackers from gaining privileges and most of them are ineffective with default settings. UAC bypasses can be found everywhere unless you put the UAC slider all the way to the top and/or log in as a non-administrator user. Driver signing is a bother, but loading drivers with known exploits is easy and basically hands you the same privileges. There's virtualisation based security and the VM based Windows sandbox thing, but that's not necessarily going to solve anything unless the attackers are after something stored inside those layers. The difference is perhaps that Windows has you operate with admin privileges much less often (although you shouldn't underestimate all of the hidden elevation with the UAC defaults!) compared to Linux.

no_time 3y ago

>To fully disable defender or AV, you have to exploit a vulnerable signed driver. Is there an automated tool for this? The guys behind DefenderControl threw in the towel and discontinued it.