Any Linux Distro that protects shadow file using SELinux or something else even against root, similar to PPL in Windows?
Posted by BitDrill@reddit | linux | View on Reddit | 19 comments
In Windows, only PPL processes are allowed to read (or inject) lsass process memory and get process hashes. so even SYSTEM processes cannot read the hashes from lsass.
Was wondering, is there any Distro in Linux that has a similar protection? Meaning, even as an attacker I gain root, I still wouldn't be able to read the password hashes from the shadow file? Tried chagpt but it said no, and at least in my Fedora and Ubuntu no such protection seems to be implemented.
I know that I can probably do it by myself using SELinux rules, but I am looking for any distro that has implemented this by default because that would be interesting and impressive.
Any distro?
AutoModerator@reddit
This submission has been removed due to receiving too many reports from users. The mods have been notified and will re-approve if this removal was inappropriate, or leave it removed.
This is most likely because:
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.
GregoryKeithM@reddit
there is no "root" or "similar to windows" together anywhere on earth.
pebenito@reddit
Any distro that supports SELinux is likely to support this. The SELinux policy on these distros are modular, so modules can be disabled, removed, or replaced. As others mention, the default policies have unconfined login users, so the key is to change the default logins to a confined domain and then disable the unconfined (and unconfineduser on Fedora/RHEL/Alma/Rocky/etc.) modules.
Caveat: The Fedora policy may have hard-coded unconfined access.
That being said, any process that can do policy changes could undo this, so this is, at best, a protection against admin errors, not a determined sysadmin maliciously intending to get the hashes. If you truly want an immutable policy after boot, then you'd need to do some policy source changes to eliminate all policy modification access.
You can use the sesearch tool (setools-console package) to see what rules allow reads to /etc/shadow by:
# sesearch -A -t shadow_t -c file -p read
I haven't tested this, but the process would roughly be:
change mapping of Linux user accounts to SELinux user:
# sudo semanage login -m -s sysadm_u __default__
# sudo semanage login -m -s sysadm_u root
Log in to another console to make sure it's configured correctly and if so, log out of this terminal. `id -Z` should report sysadm_u:sysadm_r:sysadm_t:s0-s0:c0.c1023 or something similar (main thing is no unconfined) in the new terminal.
Disable the unconfined module. Don't remove it, as next time the distro policy updates it will be reinstalled:
# sudo semanage module -d unconfined
# sudo semanage module -d unconfineduser (Fedora, etc.)
Source: I am an SELinux maintainer
gordonmessmer@reddit
I've created a throwaway CentOS Stream 10 VM for testing purposes. I've followed your directions, verified that enforcing mode is "Enforcing", and verified that
idindicates that my session's context issysadm_u:sysadm_r:sysadm_tI'm still able to read the /etc/shadow file. Some of the restrictions specified in sysadm_selinux(8) are working as expected, so the user does appear to be confined to an extent, but there are issues.
Even if this mode restricted access to /etc/shadow, there would be gaps. For example, as you suggested, I can undo policy changes, or change enforcing mode to "permissive". Because
deny_ptraceis off by default, I can also ptrace binaries that transition to other domains, which means that I can read the hashes by tracing thepasswdcommand, which can read /etc/shadow. (And generally, if I can attach a debugger to a process, I can cause that process to do pretty much anything.)You can definitely impose a lot of restrictions on the admin user, but the consequence is that a lot of stuff that admins expect to be able to do stops working. At some point, I think any reasonable person would conclude that the answer is less "restrict the admin login with SELinux" and more "adopt a workflow that deploys only images, and do not allow admin login at all."
pebenito@reddit
I can't speak to the content of Fedora policy (or its derivatives), as I don't maintain it. If you tried this on a Debian or Gentoo system you would probably have different results. For example, there is no "deny_ptrace" upstream but instead an "allow_ptrace" that is off by default.
I'm not saying SELinux is the only option here; I responded since it was mentioned. There are gaps if you take the policy as shipped by the distro, since they want as many of their users to have security benefit from SELinux without making it so restrictive users want to disable it. My point is if you're willing to make policy changes, you can strip permission to setenforce, ptrace, etc. and get the desired effect.
gordonmessmer@reddit
We agree on that point, but I'm trying to answer the question that OP is asking, directly. They said they are "looking for any distro that has implemented this by default," and in a follow up comment asking "why in Linux we aren't trying to improve this a little using selinux."
So we can suggest that a site with strict requirements could develop a local policy that confines the admin user, and does not allow ptrace, and does not allow the admin to change security contexts, or booleans, or policies, unless they can boot into a mode that allows such things. But suggesting that a distribution do that by default is going to be very difficult, because such a system would be very limited and largely perceived as being unusable. It's hard enough to convince people to keep SELinux enabled as it is. :)
Kasoo@reddit
Obviously its not a linux distro, but If you want to see an actually robust SELinux system implementation you should look at Android.
Modern Android devices are very well locked down via SELinux and most system/root level processes are basically unable to touch anything but the files/devices they need to do their job.
Also many system/root processes have execmem/execmod limitations, so they can't even map new executable code within them (other than read-only system libraries).
Seperately, Android also has a system-wide seccomp policy which limits all processes to only the syscalls implemented by libc, reducing the kernel attack surface.
aperson1054@reddit
Also Android doesn't even use UNIX users(is that what they are called?) for actual users
Kasoo@reddit
Well, sort of.
Android generates per app user/group to enable isolation between apps, however Android also supports multiple users too (though most don't use the feature) and in that case the generated users also account for that.
So for example there will be
u0_a100for App number 100 for user 0, andu1_a100for that same app when run by a different user. So apps are isolated from each other, but also themselves when run by a different user.ThomasterXXL@reddit
If you set up a work profile (or use Shelter/Insular), then that profile gets its own user.
daemonpenguin@reddit
In short, no. You might be able to set something like this up, but it would be tricky. Because you would need to find a way for the login process to read the file without root bring able to. But root can usually switch to being any user on the system.
Of course, root being able to read the shadow file is not a real issue because the hashes are salted. Being able to read the shadow file does not really help an attacker much, especially if they are already root. They can already login as anyone they want.
What you probably want to do instead is lock the root account and limit access to admin tools using sudo rules.
pfp-disciple@reddit
A very narrow niche scenario could be using a short-lived (to minimize detection) root session to extract the shadow file for offline analysis.
daemonpenguin@reddit
I mean, you could do that, but what would be the point? In this scenario you already have root access. You can already access information such as which hashes are being used, su to any user on the system, change account credentials. There isn't any practical benefit to analyzing the shadow file once you already have root access.
pfp-disciple@reddit
Extracting passwords (assuming a bad salt) to try on other systems is one (Hollywood style) purpose.
Like I said, a very narrow niche. Not especially likely. But I could imagine someone targeting a celebrity (likely to reuse passwords) attempting this to gain access to finances or private data for blackmail.
_ahrs@reddit
If you're worried about that then I hope your system has good auditing. The only way to prevent against intrusions like that is to have auditd logging absolutely everything and piping it to another machine over the network so it can be analysed properly and you can change all the passwords after an intrusion has been noticed. I know banks, insurers, financial institutions, etc, will go this far with their security but most other people won't bother.
pfp-disciple@reddit
I wonder if r/cybersecurity might have some experience or knowledge on this topic
gordonmessmer@reddit
There are a bunch of reasons that wouldn't work; one of them is that SELinux policies usually don't confine the login shell.
The POSIX system and security model simply isn't granular enough to support something like this. If your environment's security policy dictates that an attacker should not have access to password hashes, then don't put password hashes on your systems. Use Kerberos.
BitDrill@reddit (OP)
But aren't kerberos tickets also inside of a process memory which an attacker would be able to dump and usee as pass the ticket? So this doesn't solve it either, in windows tickets are inside lsaas which is ppl. I am just wondering why in Linux we aren't trying to improve this a little using selinux, I can't any document or blogpost for doing this
gordonmessmer@reddit
Because it's very very difficult to confine the login shell and still have a system that is useable.
The side effect of "everything is a file" is that everything uses the same APIs for different tasks, and it becomes very difficult to confine the use of those APIs.