And you posted this because.....? You think that this person's blog is trying to steal your data from Carbon, a well known code screenshot sharing tool? What data would Carbon even have to be able to steal?
Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting.
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.
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.
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.
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.
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.
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.
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).
This is literally all I can think about these days. I’m getting paranoid and I want to start my OS from a clean slate and use sandboxing for every project. I spend so much time auditing random scripts and libraries because I run them on my laptop.
But sandboxing options aren’t that great right now. Docker doesn’t cut it because it isn’t a security sandbox, and full blown VMs with vagrant have too much friction and needs lots of resources.
I think this is something where Firecracker (Amazon’s lightweight VM) can really shine. But it needs a better a DevEx to act as a disposable/reusable environment that’s easy to start up, easy to specify dependencies. Maybe something uniting firecracker and nix would be the sweet spot for both isolation and reproducibility.
I’m rambling but it feels like this should be a solved problem, maybe it is and I don’t know where to look.
That is probably an option, but I would have some practical concerns. I know Linux is multi-user, but given the majority of systems are single-user, I wonder how well modern software deals with that kind of environment.
1) Can I run the project-user account within my real account? Having to launch a DE as the dedicated guest would quickly grow old as I need to multi-task work, and each account would need all sorts of common configuration (browser, email, chat applications, credentials to server X). Which would end up leaking many secrets to the project-account. If I can run the project-account within my real account - do all GUI apps work? Can I launch VS Code as the project-user without issue? Or will extensions make some assumptions about logged in user vs user account running the application and bork things?
2) How good do I have to be in my op-sec? Running a project-account is going to encounter friction where some resource is "local" to my real account but denied to the project-account. What do I have to do to give limited peak to that data? How easy would it be to slip up and make the entire exercise a charade because I screwed up the isolation?
Running a VM is probably little different, but I think the isolated-by-default would make the security boundaries more clear and maintainable. Especially since the VS Code Remote Extensions (the best part of the platform) should make this kind of workflow more practical.
> 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 some...
19 comments
[ 3.3 ms ] story [ 59.3 ms ] threadLinux 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.
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.
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.
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.
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).
But sandboxing options aren’t that great right now. Docker doesn’t cut it because it isn’t a security sandbox, and full blown VMs with vagrant have too much friction and needs lots of resources.
I think this is something where Firecracker (Amazon’s lightweight VM) can really shine. But it needs a better a DevEx to act as a disposable/reusable environment that’s easy to start up, easy to specify dependencies. Maybe something uniting firecracker and nix would be the sweet spot for both isolation and reproducibility.
I’m rambling but it feels like this should be a solved problem, maybe it is and I don’t know where to look.
1) Can I run the project-user account within my real account? Having to launch a DE as the dedicated guest would quickly grow old as I need to multi-task work, and each account would need all sorts of common configuration (browser, email, chat applications, credentials to server X). Which would end up leaking many secrets to the project-account. If I can run the project-account within my real account - do all GUI apps work? Can I launch VS Code as the project-user without issue? Or will extensions make some assumptions about logged in user vs user account running the application and bork things?
2) How good do I have to be in my op-sec? Running a project-account is going to encounter friction where some resource is "local" to my real account but denied to the project-account. What do I have to do to give limited peak to that data? How easy would it be to slip up and make the entire exercise a charade because I screwed up the isolation?
Running a VM is probably little different, but I think the isolated-by-default would make the security boundaries more clear and maintainable. Especially since the VS Code Remote Extensions (the best part of the platform) should make this kind of workflow more practical.
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 some...
Is there an automated tool for this? The guys behind DefenderControl threw in the towel and discontinued it.
if i’m using custom lsm rules, i want them baked into the kernel and impossible to disable without replacing the kernel.
Some more examples of Rust and eBPF