1 Describing ACLs
ACL stands for Access Control List, and is a list of permissions associated with an object. Each of these permission entries is called an ACE (Access Control Entry) which contains permissions associated with a particular object for a particular identity. In our case we are interested in file system objects, and one can set ACLs on files/directories on an NTFS file system. The most common permissions of interest in ACE are Read, Write, Execute and List Folder Contents.
1.1 Read / Write Permissions
The read and write permissions give read and write access to the filesystem object respectively.
1.2 List Folder Contents Permission
The list folder content permission is used for displaying the contents of a folder and is required to register file change notifications on a directory.
1.3 Execute Permission
The execute permission is used to specify if the OS should execute (run) a particular application as the specified user. This will not cover dynamic application scenarios, like PHP or ASP.Net. You are running code when you invoke a .php or .aspx file, but not from the perspective of the Operating System. Instead of setting the execute permission, you should look into using the Script/Execute permissions in Section 1.5.
1.4 Full Control
The full control permission gives all access to the file system object. You should never have to use this sort of permission. The granular read/write permissions are what you want to use.
1.5 IIS Script / Execute Permissions
Dynamic content, like .php and .aspx files need the script permission to function. But looking at the file system ACLs, you will find an Execute flag, but nothing really for Script. The reason for this is that IIS has special configuration to denote if a particular file is dynamic content and this is stored in IIS configuration, outside file system ACLs. Whenever we talk about Script or Execute permissions, it is the IIS configuration we are talking about and not the file system Execute permission.
1.6 Object Inheritance
File system ACLs are usually inherited from their parents. So in some cases the parent directory might have very loose ACLs that will need to be overridden at the child level to adequately lock content. In the hosted scenario, this is not likely to be a issue though, since the permissions at the root are very few.
2 Common IIS Identities
You can either allow or deny permissions to particular identities through ACLs to secure your content. So before we delve into ACLs, it is important to go through a list of commonly used identities in IIS. In general there are two places where identities come into play. One is the process identity, and this is the identity that the IIS worker process is launched with. The second is the request handler identity which we get from authentication of the request.
2.1 Worker Process Identity (WPI)
The worker process identity is the identity that your IIS worker process is running as. This process identity is configurable through the Application Pool configuration settings in IIS. IIS 6.0 on Windows Server 2003 and IIS 7.0 on Windows Server 2008 have the “Network Service” identity as the default WPI. Windows Server 2008 R2 however uses the application pool identity (see below) as the default WPI. If your application authenticates and impersonates, your request hander identity will be the authenticated user identity. So for PHP if your php.ini has fcgi.impersonate set to true (which is recommended for IIS), then your PHP processes are running as the authenticated user. It is important to note that in the case of anonymous authentication, the authenticated user would be the configured anonymous user (see section 2.3 for more details).
2.2 IIS_IUSRS
This is a built-in identity group that is a container of all worker process identities (WPI) on the server. IIS will automatically include all worker process user identities in this group and there is no need to add them manually. On IIS 6 (Windows Server 2003) this group is called IIS_WPG. This is an overarching group that contains all worker process identities, and as such, is not a good candidate to use for isolating content. Any application running in any application pool would be running as an identity that falls into this group, hence giving this group Read access would mean that all applications would be able to read your content.
2.3 IUSR / Anonymous User Identity
The IUSR account is a built-in identity that is the default used to denote the user identity for anyone using anonymous authentication. The anonymous user identity is configurable and can be set to an identity besides this built-in identity. In practice, you should configure a custom account for the anonymous user account and never use the built-in account.
It is important to understand that in IIS, the anonymous user is not the lack of an authenticated user. Rather, anonymous requests should be considered as requests where the authenticated user is the anonymous user identity.
2.4 Application Pool Identity
This is a virtual identity associated with a particular application pool. Whenever a user creates an application pool, a virtual identity (security identifier, SID) is created with it, and this identity is injected into the IIS worker process, so that the worker process running under this application pool will have access to content with permissions locked to this virtual identity. In Windows Server 2008 SP2+, the administrator has the ability to create their worker processes with this virtual identity. This is configurable in the IIS application pool configuration settings as the ‘Application Pool Identity’ type and this is the default WPI identity type for Windows Server 2008 R2. The reason for this change is because this is identity is unique to the application pool that created it and can hence be used to isolate content on the server to application pools more effectively
2.5 Authenticated User Identity
If your application uses any form of Authentication (including anonymous authentication) , then this is the identity of the authenticated user. In the anonymous authentication case, this identity would be your configured anonymous user identity (see 2.3).
3 IIS Execution Pipeline
It is important to understand the basics of the IIS execution pipeline to get a basic understanding of what identities are applicable at what stages. Instead of delving into all the stages of the request pipeline we will address the two parts of the pipeline that are of interest to us.
3.1 Authentication
Before authentication, the authenticated user context is unknown. Hence at this time all IIS worker processes are running as the WPI. The reason this is important to note is because if you have a PHP request that is trying to access content before the request is authenticated, then the WPI will need access to the content. This scenario comes into play when using the Global rules for URL Rewriter, that run in the global pre-begin request phase of the IIS pipeline, that occurs much before authentication. The URL Rewriter has the ability to process rules differently based on if the resource being accessed is a file or a directory. For this to be evaluated, a filesystem access needs to occur, and due to its position in the execution pipeline, this access request will occur as the WPI.
Post authentication the authenticated user context is set but you are not necessarily impersonating until your request gets mapped to a handler. So for phases in between authentication and handler mapping you are most likely to be running as WPI.
3.2 Handler mapping
In this phase of the execution pipeline, your request gets mapped to a handler, e.g. requests to *.php will get mapped to the fast CGI handler. After this mapping occurs and you have impersonation enabled, the handler identity is the Authenticated User, and all resource access in this phase will occur using the authenticated user identity.
4 Which identity should I use?
Figuring out the right accounts to grant permissions depend on your application’s profile and critical resources. The main considerations are what permissions to grant and if you are authenticated or not.
4.1 Granting the right permissions
Anything that is not user-uploaded needs only read access on the file system. The obvious exception to this is dynamic content like your PHP and ASP.Net applications. All your .php, .aspx files and the like will need to have IIS script permission as well. If you have executables that you need to run, then they would need to have the IIS execute permission as well as be properly configured in the CGI Restriction List.
Content that is going to be uploaded by a user should be in a separate folder that you would give write access to. However it is important not to give this folder IIS execute or script permissions, otherwise users may be able to upload malicious code and execute it.
In general, the WPI should have Read access to all your content for your application to work correctly.
4.2 Apps that require authentication
In the authenticated access case, you ideally want to lock down all resources to a group containing all authenticated users. If you have different categories of users (admin and non-admin) you should have to separate groups and give access accordingly. For example if your application has an Admin directory which contains administration scripts, you would give only the admin group permissions to read this directory. If your application is impersonating, then the handler identity is the authenticated user; otherwise it will be your WPI. If you have set fcgi.impersonate to true in your php.ini file then your fcgi processes’ identity will be the authenticated user identity; otherwise it will be the same as the WPI. Using this information an admin can figure out the right set of ACLs that need to be placed on the content.
4.3 Apps that run anonymously
It is important to note that running anonymously on IIS means that you are authenticated as the anonymous user identity. In this case, you ideally want to lock down resources to either the application pool identity or your custom configured anonymous identity. It is recommended to give access to the application pool identity over the anonymous identity in this case. If you were to give IIS_IUSRS group access to your content, it would mean that apps running in any application pool would have access to your content. If you allow anonymous users to upload files, your app should ensure further checks on the kinds of content they can upload to keep the server secure.
5 How do I set ACLs
There are several ways through the shell that you can set your ACLs, including command line tools like icacls.exe. For the purpose of this document, we will focus on the Web Deployment Tool manifest (XML) mechanism you would use to set ACLs. . This is the mechanism that would be applied if you were to install an application through the Web Deployment Tool or the Web Platform Installer.
If I want to give Read , Execute and Write permissions to MyApp file system directory for user Foo, you would add the following line to your manifest.xml file
<setAcl path=”MyApp” setAclAccess=”ReadAndExecute, Write” setAclUser=”Foo” />
If I want to set the ACL on the path MyApp/Upload to allow anonymous users to upload content, you would add the following line to your manifest.xml file
<setAcl path=”MyApp/Upload” setAclAccess=”Write” setAclUser=”anonymousAuthenticationUser” />
Note that anonymousAuthenticationUser is a special token that will resolve to your configured anonymous authentication identity.
If I want to grant Read access to the MyApp\Data folder for the application pool identity, you should add the following line to the manifest.xml file.
<setAcl path=”MyApp/Data” setAclAccess=”Read” />
Note that we did not use setAclUser here. The default value for this is Application Pool Identity, so skipping that in this case is fine.
6 Links
Understanding the Built In User and Group Accounts in IIS7
Related Content
Comments