EBPFGuard: a Rust Library Mitigation of Threats Using LSM Hooks
deepfence.io
deepfence.io
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.
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 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.
Is there an automated tool for this? The guys behind DefenderControl threw in the towel and discontinued it.
Some more examples of Rust and eBPF
if i’m using custom lsm rules, i want them baked into the kernel and impossible to disable without replacing the kernel.