I'm referring to the system of low-level, medium-level, adminstrative (high) level application as process privileges. Do you believe those are security boundaries?
If so, and if they can be violated, shouldn't the flaw be classified as a vulnerability?
I'm referring to the system of low-level, medium-level, adminstrative (high) level application as process privileges. Do you believe those are security boundaries? If so, and if they can be violated, shouldn't the flaw be classified
as a vulnerability?
And this is why discussing security is hard, because you're using the word "privilege" to mean something entirely different to what "privilege" means in the context of the NT security model. It's like discussing a piece of code and using words like variable,
method, function, class and object as if they were interchangable.
As to your actual question, if the two applications are running in the same NT Session, then they aren't seperated by a security boundary even if they happen to be running with different user tokens. This is why the so-called "Shatter Attack" isn't a security
vulnerability and it's also why UAC isn't a security boundary (since they're on the same desktop, hence the same session). Permissions/integrity levels don't define security boundarys in Windows, Sessions do.
Now, if you want my opinion, the future of Windows security design should involve re-architecting things so that a "desktop" in the visual sense (and not necessarily in the NT sense) can display content from individual NT Sessions and keep them entirely
independent. At that point, we'd be a lot closer to an ideal situation where you can get much of the benefits of having true "Standard User" accounts without having to endure the full on Fast User Switching experience just to complete a single administrative
task in a truly secure fashion.