Kernel Hardening: Protect Linux user accounts against brute force attacks

https://github.com/Kicksecure/security-misc

by CHEF-KOCH • 2 years ago

153 104 2 years ago

github.com

CHEF-KOCH• 2 years ago

The title is actually shortened, the project offers much more, make sure you read the Readme.

fsflover2• 2 years ago

I prefer to rely on Qubes OS for a reasonable security.

quarterdime• 2 years ago

If you are using qubes, you are likely using kicksecure. Whonix (used by many qubes users) is based on kicksecure.

fsflover2• 2 years ago

It's true, however the main security measure of Qubes-Whonix is not Kicksecure but hardware virtualization, which isolates Tor Browser (anon-whonix) from VM establishing the Tor connection (sys-whonix). Kicksecure is of secondary importance.

josephcsible12• 2 years ago

Kexec is disabled as it can be used to load a malicious kernel and gain arbitrary code execution in kernel mode.

Only root can kexec anyway. "Hardening" guidance that suggests limiting the root user feels like an attempt to boil the frog of widespread Linux DRM.

nimbius2• 2 years ago

Disabling kexec would prevent unauthorized operation in the event of a zero-day root compromise. It would require a reboot to re-enable, which should generate a security event in a SIEM or central monitoring for unauthorized change in operating state.

Borealid• 2 years ago

How would it require a reboot to re-enable? The root user can write directly to kernel memory by a number of means, patching the kernel live to re-enable kexec.

Closing those holes requires using a pretty extensive MAC policy restricting root in all sorts of ways.

olliej• 2 years ago

This sounds like it’s doing something similar to system integrity protection on mac+iOS where the security model is “root cannot write to kernel memory”. Because otherwise all you have to do is get root access to control a system, which is pretty easy given that getting root generally just means tricking the user into entering their password (because they’re generally in the sudoers group), or spying on other user processes (like xterm or whatever). Gaining root on a normal user machine is not hard if that’s your goal, and given a security model that depends entirely on not getting root it’s the obvious first step.

josephcsible12• 2 years ago

This reminds me of https://xkcd.com/1200/ - what would someone who gets into a normal user machine like that care about kernel access for? This type of "protection" feels like it only hurts legitimate users without even slightly inconveniencing actual bad guys.

charcircuit16• 2 years ago

The existence of the root user is bad security. Any distro serious about security should disable it and strip it of as much power as possible. It is such a juicy target for attackers due to how much power it has and most distros protect it poorly by having programs such as sudo installed allowing an attacker to easily escalate their privileges.

josephcsible12• 2 years ago

How do you propose that the owner of a system should be able to administer it?

teo_zero• 2 years ago

I think sudo done well could be exactly what you're advocating for: configure all possible commands that a user should be allowed to execute as superuser for ordinary and extra-ordinary maintenance and prohibit everything else (especially sudo -i).

znpy5• 2 years ago

Nah. Root user actual capabilities can be limited in a number of ways.

On RHEL this is done by default via SELinux.

If you define a policy that prevents anyone from doing kexec, and enable the boolean to prevent root from disabling enforcing mode for selinux, there you go, done with tools that have been available for ~15-20 years.

viraptor• 2 years ago

The intention is for it to be accessible by root only. But if you get a situation where either that check fails, or you can convince some root process to kexec without further checks, you have a problem. If you know you're not using kexec, you can get rid of that whole issue.

saagarjha• 2 years ago

I generally dislike such lists because nobody goes through them and analyzes which ones work and which things just seem like they improve security without doing anything at all.

Modified3019• 2 years ago

Is there some sort of way to to keep a browser profile inaccessible to anything run by the user that isn't the browser, while still having the browser itself being usable by the user?

fbdab103• 2 years ago

QubesOS? I would love to know the answer, but I think it is going to be a long time before we have proper application sandboxing on Linux.

The browser is likely the biggest threat vector running on my machine, yet there are no easy ways to lock it down to just reading/writing Downloads and its own cache.

bombcar2• 2 years ago

That's part of the problem, but remember your browser has all your cookies and such - the sites that keep you logged in even when you close the window (like email).

So if anything else can read the browser's data, it can get that.

hwbunny• 2 years ago

AppArmor is fairly easy.

Timber-6539• 2 years ago

You can run Firefox in a docker container. Not sure how much GPU performance you can squeeze out of it but it's doable.

mnahkies• 2 years ago

You can (allow) access to GPU for cuda applications in docker containers, so I'd be surprised if it wasn't possible to get video acceleration to work normally

usr1106• 2 years ago

I use firejail. At least the browser cannot see arbitrary files in my home directory, like ssh or gpg keys, password manager, and everthing else. To share files between the browser and the rest ~/Downloads can be used.

Disclaimer: Critics say firejail is too complicated to be audited and adds too much attack surface of its own.

yjftsjthsd-h2• 2 years ago

Sure; take your pick: Firejail, flatpak/bubblewrap/bubblejail, docker/podman.

mmsc• 2 years ago

Yes, you can run Firefox as its own user. I wrote about this about a decade ago; https://www.openwall.com/lists/oss-security/2023/10/24/2

DaSHacka2• 2 years ago

The gentoo wiki also has some information about this

https://wiki.gentoo.org/wiki/Simple_sandbox#larry_runs_firef...

keepamovin• 2 years ago

Run your browser on a remote machine? Using say BrowserBox: https://github.com/BrowserBox/BrowserBox

Full disclaimer: my company develops it.

harporoeder• 2 years ago

There are lots of ways to protect your system from a browser exploit via containers, another user, a vm, etc as brought up by other people responding. However protecting a browser from other applications is basically impossible unless you also sandbox everything else you are doing. Even if you run a browser in a VM some other process run as your user could just automate clicking the UI to do whatever. If you go qubes style and isolate everything from everything then it is fine.

bombcar2• 2 years ago

Protecting the browser from other applications is arguably more important now than protecting applications from the browser; as the browser contains all your security information (cookies, etc) necessary to login (or be logged in) on all your important sites.

People have been hacked by malicious Minecraft mods uploading browser data to nefarious places.

efitz• 2 years ago

This list is pretty awesome and the work is impressive.

I wonder what percentage of applications break or have such slow performance that they become unusable, when this set of mitigations is enabled.

Foxboron• 2 years ago

Parts of this seems dated. I'm pretty sure the entropy changes suggested doesn't really add anything after the recent (~2 years ago) rework of `/dev/random` in the kernel.

It doesn't mention `systemd-homed` which might be useful in some cases and the kernel module signing portion is just... wrong or misguided.

Kernel Hardening: Protect Linux user accounts against brute force attacks

Related Stories