I decided to start writing a series of articles on the identity and security mechanisms in .NET and Windows. This idea grew while talking to my -almost all of time younger- colleagues about .NET security. I started realizing that for developers who only worked in .NET environments, it is not that easy and obvious to understand how some of the .NET functionalities such as for example authentication and threading relate to the basic Windows operating system subsystems.
When developing in the .NET ecosystem we all are aware of the existence of sets of rules (or laws) that exist and that have to be respected. Examples of these laws and regulations in the .NET world are Code Access Security (CAS), Role-Based Security, AppDomain rules and many others. So when writing .NET code you have to play by the rules of the .NET world. But in the end when the .NET application is executed (and we all hope it eventually will) by the Windows operating system, a whole different set of rules apply. The reason is that the operating system treats the .NET application just like any other application or process on the machine, and here the game is played by the rules of the operating system. And since we all know that operating systems are a lot like the Old Testament gods (a lot of rules and no mercy), things can go wrong.
In a nutshell, in this series of articles I will try to explain the rules regarding identity and security in the .NET world and how they relate and map the corresponding rules in the Windows operating system world.
I will try to follow Albert Einstein's advice - keep this as simple as possible, but not simpler - and that is why this series is called "Back to basic".
Identity in the Windows world
When the operating system wants to protect access to its resources (files, communication ports, shared memory, semaphores and others) it needs to identify who is requesting access to the resource. It is clear that the process of identifying who requests access must provide strong authentication. When it is easy to fake another identity, there would be no security!
The Windows operating system grants or denies access to a resource based on an access control list (ACL). The ACL is a list of elements (ACE's) describing who can or cannot be allowed a certain type of access (Read, Write, Update or other) to the resource in question. Each ACE describes an access type for a Security Principal.
A Security Principal is an abstract term to indicate the party whishing to access the resource. Examples of Security Principal are users, machines, user groups.
A Security Principal is identified by a security identifier (SID). A SID is a structure that is unique in time and space that is issued by a trusted authority. For example, a SID representing a local user on a Windows machine is issued by the local security authority (LSA) component on the machine, while a SID representing a domain account is issued by the domain's security authority.
I won't go into details describing the format of SID's, but it is important to notice that besides the SID's issued by the authorities to identify user defined parties (such as individual users), there is a category of Well Known SID's that exist in every installation and always have the same value. Examples of Well Known SID's are the EveryOne user group, the Creator/Owner and the Administrator SID.
In the next figure the PsGetSid utility from http://www.sysinternals.com/ is used to display the SID of Everyone (Well Known SID), a local user and the machine.
Following figure shows the detail ACL for a file name MyFile.txt after the security was configured using the standard Windows explorer.
This concludes the introduction. Remember that there is a lot more to tell about SID's and ACL's (for example how inheritence works), but this should be sufficient to understand the relation with the .NET world later.
In the next part we will talk about processes, threads, process tokens and how they relate to security identifiers. After that we will have set the scene to dive into the .NET world.
No comments:
Post a Comment