In an old article, Mark Russinovich defined a security boundary as:

[A] wall through which code and data can’t pass without the authorization of a security policy. User accounts running in separate sessions are separated by a Windows security boundary, for example.

Other than user accounts, what security boundaries does Windows have? Also if you run a program as a different user within your desktop session (e.g. by using the runas command), does this undermine that security boundary?

  • Your question is very broad and Microsoft has many security boundaries. This may lead to your question being closed unless you can provide specifics. Commented May 24, 2019 at 3:29
  • runas functionality is common among all operating systems. Do you have a more specific concern? Commented May 24, 2019 at 3:33

2 Answers 2


Microsoft recently shared its Security Servicing Criteria that explicitly defines security boundaries of Windows and its applications:

  • Network boundary: An unauthorized network endpoint cannot access or tamper with the code and data on a customer’s device.
  • Kernel boundary: A non-administrative user mode process cannot access or tamper with kernel code and data. Administrator-to-kernel is not a security boundary.
  • Process boundary: An unauthorized user mode process cannot access or tamper with the code and data of another process.
  • AppContainer sandbox boundary: An AppContainer-based sandbox process cannot access or tamper with code and data outside of the sandbox based on the container capabilities
  • User boundary: A user cannot access or tamper with the code and data of another user without being authorized.
  • Session boundary: A user logon session cannot access or tamper with another user logon session without being authorized.
  • Web browser boundary: An unauthorized website cannot violate the same-origin policy, nor can it access or tamper with the native code and data of the Microsoft Edge web browser sandbox.
  • Virtual machine boundary: An unauthorized Hyper-V guest virtual machine cannot access or tamper with the code and data of another guest virtual machine; this includes Hyper-V Isolated Containers.
  • Virtual Secure Mode boundary: Data and code within a VSM trustlet or enclave cannot be accessed or tampered with by code executing outside of the VSM trustlet or enclave.

User boundary says "without being authorized": by running runas, you give the authorization (by providing sufficient credentials), so the boundary is not violated.

  • The referenced data is Microsoft's definition of a vulnerability and is not in context of what OP is asking. Commented May 24, 2019 at 3:18
  • @user2320464 My question was about Microsoft's security policies regarding Windows. As Microsoft is the most authoritative source for its own policies, I'm satisfied that this answered my question.
    – ChrisD
    Commented May 24, 2019 at 9:25
  • @ChrisD You're question makes no reference to "security policies". How can you be satisfied with this answer? Commented May 24, 2019 at 15:28
  • @user2320464 The question is literally about security boundaries in Windows. The answer references the "Security Boundaries" section of an official Microsoft document. What's your point?
    – buherator
    Commented May 24, 2019 at 15:49
  • @ChrisD, no, the links in this answer provide Microsoft's definition of a vulnerability. They are by no means an exhaustive list of "Security Boundaries" nor are they a "Security Policy" in the context of OP. Commented May 24, 2019 at 15:49

Modern windows systems use UAC (User Account Control.) This works with a token based system. So for example you have a windows account, and that account has local admin.

When you login you will be issued a token that allows to execute programmes with your low level user privileges, thus limiting you to the least possible privilege.

If an executable requires elevated administrative privileges to run, when you lunch it, it will prompt you as the user to explicitly okay it.

When you do this windows will check if you have administrative privileges, which you will as you are a member of the local admin group and it will issue a token allowing that instance of the executable to run with higher level privileges.

This keeps the policy of most restrictive privilege in place, as your user account will still be running with its low level privileges, but the instance of the executable will have the higher level privilege, thus creating a security boundary.

The run as feature works in much the same way, except it will check what privileges the account that is being used to 'run as' has, instead of the account you are logged in as.

So if you are logged in as your normal user account that does not have local admin, but you do know the local administrator credentials, you can run an executable that requires elevated privileges with the run as features, use the local admin creds and again the token will be issued allowing that instance of the executable to run with the required level of privilege.

So rather than undermining the security boundary, it is in fact enabling the security boundary.

You can read more detail here.

  • Those more familiar with Linux could compare "Run as" with gksu
    – timuzhti
    Commented Jan 26, 2017 at 5:56
  • 2
    Ok, there are two things I'm not clear on. 1) Russinovich and Sinofsky explicitly state that the UAC is not a security boundary. 2) Using run as is not the same as running two users in two different desktop sessions. E,g, with run as within the same desktop session, different user applications appear to share the clipboard, drag and drop, and possibly other features I can't think off the top of my head.
    – ChrisD
    Commented Jan 26, 2017 at 17:51
  • Actually I was wrong about drag and drop but copy and paste does work.
    – ChrisD
    Commented Jan 26, 2017 at 18:01
  • Ah I see. The clipboard is shared between all process for a login session, but not between sessions, so for example if you copy to the clipboard and then switch user, you cannot paste from the other session to the current session Commented Jan 26, 2017 at 18:29
  • @TheJulyPlot So are there any other resources that are shared by all processes in the same session? Drawing the window must be in some way. Mouse and keyboard events are obviously sent to the application but can the application use the windows API to set the pointer's position on the screen? There could be many security implications to running different user applications in the same session that don't apply to running two different sessions, no? Which would suggest doing so undermines some of the security of using different user accounts and the "wall" now has holes in it (albeit small ones).
    – ChrisD
    Commented Jan 26, 2017 at 20:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .