Then they say admin to kernel (in this case) isn’t a security boundary.
While also saying that driver signing enforcement is a security feature.
Which is what’s being bypassed here.
But they claim in this case it’s not crossing a security boundary.
Please make sense.
They do make sense. You're missing something critical in the argument.
> So what’s interesting is MS say that UAC isn’t a security boundary. Which is some users to admin.
This is incorrect. UAC is for already-admin users; it's not "some users to admin". The security boundary exists around standard users, not admin users.
This might not be what you like, which I totally get, but it does make sense. If you want a security boundary, don't create a user in the Administrators group.
As a user aren't you essentially forced to this to have a usable desktop experience? I mean, sure, there is a boundary.. but it's drawn rather carelessly around the entire stack.
Can't you just install it at the user level? https://code.visualstudio.com/docs/setup/windows#_user-setup...
Sure, if you want your ordinary non-admin user to have write access to the executables, which makes it a lot easier for some malicious piece of software to hack them since it no longer needs to get root permissions.
As if non-admins have no way to create a new executable and run those instead? Windows has a million ways to run code, both visibly and invisibly. Why would malware prefer to trash an executable that the user relies on for daily work and risk revealing its presence so quickly?
There's not a lot a typical user does that requires admin. For the odd software that breaks Windows' conventions, it's usually enough to install it outside of Program Files.
Of course with the push towards Microsoft accounts for login, this might soon be difficult.
Meaning, in a user's home directory somewhere? That's even worse, because now that user has write access to the executables. Which makes it even easier for some nefarious piece of software to pwn those executables, since they don't even need to get root permission.
You cannot compromise an executable run without permission and magically get Administrator or some higher privilege level without another exploit. Sure that specific user's data may be compromised but in the end the system remained secure.
Also keep in mind Microsoft by default has a ton of sandboxes and checks on those applications which will likely get caught as well should that compromised application try to access something it shouldn't.
I don't personally know of a mass security event involving Windows that cannot be chuaked up to failing to implement security updates. Sure Microsoft has some massive security issues but in general their track record isn't as bad as people try to make it out as.
There are enough reasons to hate windows without making up new ones.
The recent global ClownStrike outage?
If you aren't entirely in the know crowdstrike had a very similar issue a few months before with Redhat distros so was that a Redhat issue?
If you meant "caused by", then maybe use that instead of "involving"? ;)
I'm not that worried about that, as the executable won't get admin privileges without some exploit, so I don't go there. But it's an option.
You have to switch to your admin account for some settings and maybe half the time you are installing new software, but everyday stuff now works well without privileges
There are still too many applications that unnecessarily require admin credentials to do something (I'd love the system to report exactly what the app is trying to do) but it is a lot better than it used to be
Specially when it asks me if I should allow HP printer driver to download new updates. No thanks I'll keep the minimal driver Mr. HP.
Basically this is the default way Linux works (not entirely the same but similar enough) with sudo. And the way that every corporate IT department runs windows.
Another advantage is that if some malicious app tries to access something it shouldn't you will immediately know as the admin pop up will trigger.
Kinda sorta. Here "not entirely the same but similar enough" means "doing the one major thing that Linux does not force you to do", namely, creating a whole separate user account just so that MS can make the braindead claim that a security boundary isn't being crossed when you enter admin permissions from an Administrator account. On a Linux system you only need to create one user account, and put it in the sudoers group, and Linux then properly treats every attempt to do something with sudo as crossing a security boundary and acts accordingly.
I think you are very confused about what a Linux user actually has to do--and not do.
> create a second unprivileged account and log into that instead of root.
No, you create one account. The root account doesn't have to be created. It's automatically there, built into the system. On Windows, you have to explicitly create two separate accounts, one with Administrator privileges and one without.
Correct, but you're missing the point. There's practically no difference between Linux and Windows when you need to escalate privileges, except having to enter credentials for another (privileged) user than your current (unprivileged) user. The security boundary is there and the user experience is basically the same. Everything else is just nitpicking.
Which makes no sense. The fact that a user is in the Administrators group does not mean every single action they take should automatically have root permissions, or that using the UAC prompt to get root permission for a particular action shouldn't be treated as crossing a security boundary. On my Linux system, the fact that my user is in the sudoers group doesn't mean Linux just throws up its hands and says, oh well, can't enforce any security boundary now for what that user does. MS is simply punting here. But of course Windows was never designed for security, and what braindead security it does offer was bolted on as an afterthought.
You're twisting what "makes sense" means here. What they're saying makes sense with respect to the current design. They have had a design with one sharp security boundary and maintained it... for decades. Their statement is entirely consistent with that, and in no way nonsensical. You're saying it "doesn't make sense" to mean "I think this is poor design, and there should be multiple layers of security boundaries", and you're obviously welcome to have that opinion, but that doesn't mean their disagreement implies their statement is nonsense.
Sure you can tweak it to only allow certain commands, restrict it to another group, etc. Which would be equivalant to, in Windows, probably using another group(s) than Administrators and assign privilegas as appopriate.
I have a lot of unfavorable opinions of security fundamentals in Windows but you're barking up the wrong tree here.
From your other comment in this thread:
> The issue is not that people don't understand how MS defines what is and is not a security boundary.
With all due respect, check your assumptions...
I have a theory that there's basically two types of disagreements, disagreements on definitions, and disagreements on value systems.
In this case Microsoft values downplaying this issue, so when that is at the top of their value system their decisions should make sense following that.
Since this is just a pet theory I'm very interested to hear critiques on it.
Disagreements on definition are a little bit easier, because then you can just talk about the definitions and resolve your differences there... For example let's say IDK You're trying to sort out how to design a software system, and everyone is speaking in terms of design patterns, but they haven't yet spelled out the details of what those designed patterns are, then that could probably lead to a lot of confusion if when you say A I think of A', and another person is thinking of A''.
Other people opposed gay marriage because it went against their values. No matter what you wanted to call it, they were opposed to gay people living together and sharing their lives.
I chose this example because it's the first time I noticed that some disagreements are about the definition of a word, and it's an especially clear example of that. It's silly how huge disagreements about a single word can become.
There are also people who disguise their value disagreement as a definition disagreement. This is a form of bad faith arguing.
I think there's another example around trans-vocabulary:
The analog of the 1st half is "I'm not going to stop you from cutting off your man bits, but don't expect me to call you a 'woman'. 'Trans woman' is ok because that's a new word, but 'woman' already has a meaning and don't try to change it."
The analog of the 2nd half is "You shouldn't do that because you're a man and you need to act like one." Or perhaps it's an affront to nature or the divine.
> Other people opposed gay marriage because it went against their values.
This difference does not matter - the outcome was the same. Stop treating bigots with kid gloves.
Religious logic is like this. It presupposes a greater mystery that has been partially revealed to us. It also presupposes that our fallible logic cannot on its own understand the truth. In other words it defines faith as believing in the greater truth even if the world and every one says we are foolish to believe in such fairy tales.
There's three forms of disagreements.
1. Disagreements on definitions
2. Disagreements on facts
Kind of hard to disagree on logical implications
3. Disagreements on value systems
Not to be dense, which is most difficult?
Sorry, this is not a value system disagreement. It's definitions, pure and simple. As I mentioned in my sibling comment, the definition (and thus boundary) has been pretty sharp and clear for decades: the user group. If you're a standard user, such as in the "Users" or "Guests" groups, you're behind the boundary. If you're in the "Administrators" group, you're already past it.
That's all there is to it.
I think the sibling comment accidentally put it better.
> There are also people who disguise their value disagreement as a definition disagreement.
Or maybe even more to the point: they are twisting their definitions to support their values.
I think we can agree on this.
> Or maybe even more to the point: they are twisting their definitions to support their values. I think we can agree on this.
I take it you're insinuating I'm one of these people here?
Hasn't group membership been the defining security boundary in Windows for over two decades?
Yes, it is. The issue is not that people don't understand how MS defines what is and is not a security boundary. The issue is that MS's definition is for the benefit of MS, not for the benefit of the user. That's a value system disagreement.
That's a communication failure, not a value system disagreement.
> The issue is that MS's definition is for the benefit of MS, not for the benefit of the user. That's a value system disagreement.
Just because two entities differ on their values that doesn't mean everything they disagree on is their values.
In this case, the fact that users and Microsoft differ on what constitutes a security boundary is 100% a definitional disagreement.
Now MS obviously has had their own values and reasons for not establishing other security boundaries people would like, and that is a value system disagreement. But even if their values agreed with yours and they hated the current design just like you, the fact of the matter would still be that user account groups are the boundaries in the current design, and that would still imply this isn't crossing a security boundary, making the disagreement on that definitional.
I never made any such claim.
> the fact that users and Microsoft differ on what constitutes a security boundary
I never made that claim either.
> MS obviously has had their own values and reasons for not establishing other security boundaries people would like, and that is a value system disagreement.
Thank you for agreeing with the claim I actually did make.
Both UAC and sudo are just OS level cookie dialog boxes. Let's get rid of all three.
We need to give up on the UAC/sudo/etc. style of user based privilege escalation and instead sandbox apps, not users, just like Android and iOS do.
This is about drivers...
2) driver vulnerabilities are there regardless of user setup. Making a user click a UAC button doesn't make the vulnerability disappear
You can run that display driver in whatever security context you want be it “root” or its own constrained context but that doesn’t change the fact that other things in the system, running under their own security contexts, are feeding that driver stuff. And given there is generally only one display output, or sound output, or whatever, all things in the system have to use it for output, making it more privileged than the rest.
Whatever security context a display driver runs in, that context by requirement has to be more privileged than whatever context your browser or a calculator app runs in. To make changes to that shared display driver, you need to cross some kind of security boundary and it would be nice to make sure the user is who they say they are, they are allowed to do the requested action and they are made aware of the change. Thus methods like UAC and sudo.
I’m not sure how you can escape that. Removing sudo and UAC doesn’t change the fact that something wants to mess with a shared resource running with some kind of elevated privilege.
UAC and Sudo are pretty different when you actually compare their implementations and not just purpose.
Sudo is just a text prompt, UAC's design includes an entire isolated desktop to ensure fake prompts and such can't happen.
Man i stop here since you don't even know what a driver is, and no, nor Redox or macOS can do anything against a bad/hostile but signed driver.
But you obviously don't know what drivers are (hint..communicating directly with hardware)
To be fair, that's misconstruing UAC and CredUI/Secure Desktop a little. There probably is merit in switching to an isolated desktop session when seeking consent, or user credentials, despite the fact that UAC/the AuthZ part within a user account has flaws. I think another issue is probably that most user's exposure to UAC is on machine's they're the sole user and administrator of; it's a different ballgame in enterprises where the end user is probably the least privileged principal logged into a particular PC.
Windows et al have Sandboxed apps, but which apps and which users should be allowed to do system-level confirmation type changes? iOS and Android are (for the most part) on single user devices, you still need some sort of AuthZ system to decide who and which apps can change what on multi-user systems.
Those OS go out of the way preventing features that hinder usefulness of the devices. Such as recording phone calls. Allowing the blocking of network IP addresses and domains. While supplying monolithic integration that is limited to all but the OS maintainers.
Google dialer does not allow for integration of 3rd party contacts. It is built around Google remote storage. Apple Messenger doesn't allow for conversing with non Apple device users except for insecure text messaging while promoting cyber bullying with green vs blue text.
Another security and business risk of using Google or Apple for content storage with limited recourse when they lock out our accounts.
> Those OS go out of the way preventing features that hinder usefulness of the devices.
But one isn't necessarily synonymous with the other.
Mac OS is slowly going in this direction. Their policy these days is that apps shouldn't be able to do dangerous things by default, but should have the ability to ask for any specific privilege, if and when they need it.
Instead of getting a generic "this app wants admin privileges" popup, you get a "this app wants access to the files in your Documents folder" popup. This makes a lot more sense, lets you deny specific permissions while allowing others, and actually tells the user what the app needs the privileges for.
The more dangerous the privilege, the more involved the setup process is. The most dangerous privilege of all, that of installing your own kernel extensions, which can do (almost) everything and are your final option when there's truly no API for what you need to do, is gated behind a reboot into recovery mode.
This is combined with new, more secure APIs, so that privilege escalation is often entirely unnecessary. For example, most things that were formerly accomplished via kernel drivers can now be done with sandboxed, userspace processes, and there are APIs like the photo picker, where the user picks what photos to share in a system-managed window, that require no extra privilege because the system knows that the user just clicked on a photo in the context of that app.
However, if you read the article, the vulnerability is enabled by a race condition in a Windows security component, so really just a bug here, even if Microsoft is trying to deflect from that.
UAC is not a security boundary by design.
> It’s important to be aware that UAC elevations are conveniences and not security boundaries …
- Mark Russinovich, Microsoft Corporation [1]
[1] https://web.archive.org/web/20080101143433/http://www.micros...