7 ms·
Well the demo is showing a crossing of something that ms has defined to not be a real security boundary: "Administrative processes and users are considered part
by 9029 2y ago
Well the demo is showing a crossing of something that ms has defined to not be a real security boundary: "Administrative processes and users are considered part of the Trusted Computing Base (TCB) for Windows and are therefore not strong isolated from the kernel boundary." [0]
Another recent case:
https://arstechnica.com/security/2024/03/hackers-exploited-windows-0-day-for-6-months-after-microsoft-knew-of-it/ https://arstechnica.com/security/2024/03/hackers-exploited-w...
[0] https://www.microsoft.com/en-us/msrc/windows-security-servicing-criteria https://www.microsoft.com/en-us/msrc/windows-security-servic...
- morpheuskafka 2y agoOn the Linux side, SELinux which sets guardrails on the root user at the kernel level is mandatory for protecting classified information. Thus, there is most certainly a security boundary between root, let alone regular users with "admin" groups/perms, and the kernel. How can Windows, which is used all over the government, have a policy that admin users can do whatever they want with the kernel without it being a security vulnerability?
- dwattttt 2y agoBecause their policy is to not give admin to a user if you don't want them to have control of the computer?
- kchr 2y agoEven approved and trusted admins can be a liability (disgruntled employee, social engineering). Like OP said, mandatory access control (MAC) implementations like SELinux can be used to even further restrict what an administrator (or process running with admin privileges) is allowed to do.
- jeroenhd 2y agoOn the Windows side, loading arbitrary kernel code is an annoying process that involves disabling driver validation+dev mode and one or two reboots. If all components are working well, merely being an admin does not grant you arbitrary kernel access like it does on most Linux configs. You need to pay for/steal someone else's code signing certificate or reconfigure the target to boot into a special mode (that may require a Bitlocker recovery key). Nothing a malware author can't do, but like on the macOS "verify every binary" approach, a malicious actor can be blocked with a single certificate revocation at that point, no AV necessary. As for groups, Windows has a variety of groups with a range of permissions (both local and over network shares). On home installs, the default user will have all of the permissions, kind of like on how most Linux installs have a single sudo/wheel user. Every kernel object has a different ACL that can be altered down to the user level. Furthermore, Windows differentiates between various permission levels ("browser content rendering process" vs "normal process" vs "admin process"), doing things like preventing keystroke insertion into higher privileged processes running under the same user account. In office/corporate environments, the person interacting with the computer never gets admin permissions at all, so the admin/kernel boundary isn't relevant until a privilege escalation exploit is involved. Even IT administrators should almost never use real admin accounts; almost everything from changing passwords to reconfiguring permissions and settings can be done with assigning users to lower privilege groups or the right ACLs, not entirely unlike how Linux capabilities can be used to grant relatively low-power users permissions that normally only root can use. Windows's security problem isn't unlike Linux's: it can be locked down securely, but you'll break tons of applications and you'll need to read through tons of obscure documentation before you can pull it off. Out-of-the-box Windows has a lot of security features that Linux lacks, but when it comes to unmanaged home computers owned and used by normal people, neither has any real protection boundary preventing kernel access in practice.
- ruthmarx 2y agoIt's not as good as SELinux but you can limit the rights of admins with group policy so that they won't be able to install random drivers in the environments you speak of that need that boundary.