MSDN Magazine - November 2008 - (Page 68)

Built-in user has Read, ReadEA, Execute, ReadAttr, RCtl, and Sync, = GRGX over C:\Windows and GRGX over subdirectories and their files below C:\Windows. All system files and folders have protected ACLs that grant Trusted Installer full control. The control of files by Trusted Installer is not expressed in the declaration on the system root directory but in the separate declarations of the Windows components. Setting Safe File System Permissions Now that you have some idea of how file system ACLs work and how to read them, let’s look at setting them. If you are installing an application, you should install this to the default Program Files location. The default ACLs for this location give full control to Administrator and Local System, which is appropriate. If you install an application to some other location or grant the user the ability to choose his preferred location for an application, you have a problem: the default ACLs for other drives and for nonsystem and non-application areas of the system drive are not secure enough. In such cases, you must explicitly ACL your folders with the appropriate protected DACLs. The simplest and safest choice for installing an application is to duplicate the security settings on the Program Files folder. If you choose not to do this, set When setting DACLs, you don’t want administrators executing code written by a user. the DACL so that non-administrators cannot change DACLs or ownership of executables and cannot write, append, or delete files in directories containing executables. The basic rule if you are setting DACLs is that you do not want administrators or other users executing code that was written by a user. This is particularly a problem if the folder in question would be presumed to be trusted, typically by being in a trusted area (Windows, Program Files, and so forth). Doing so allows Elevation of Privilege (EoP) to administrator and increases the risk of cross-user attacks. Thus, if a user can write files to such a folder, other users and administrators should not be able to execute them. At first glance, it would appear that you should not let users write to folders in Windows, System, Program Files, and so on, at any time. It turns out there are valid reasons for doing so. The most common is to record error log data. If the executable is running under the user’s credentials and has to log an error, it needs write/append access to the error log/logging folder. (If you logged errors to per-user locations on a multi-user system, you would have the logging data spread over the system instead of being associated with the executable. Applications and services typically write to a shared folder or registry key.) You’ll find the same issues in the registry, where error information is frequently stored in specified machine registry keys by a process running with user permissions. 68 msdn magazine Do not mix user writeable files with executable files. Use separate directories for files that must be trusted (such as executables) and files that must not be trusted (anything potentially written by an untrusted user). ACL the directories appropriately—administrator control over the executables and user read/execute, but not write. The same guidance applies to registry keys and subkeys. Client and server differ here: server administrators are assumed to be far more knowledgeable than users running as administrator. Server administrators know that they must not execute code from untrusted areas of the system. By establishing a naming convention to isolate data files from executables in the system, you provide the administrator guidance concerning the trustworthiness of the executable—logging subdirectories are not trustworthy, thus users must not have the ability to create or modify these subdirectories, as this would enable them to spoof safe naming rules. In the client environment, it is far easier to fool the administrative user into executing code. With such naive administrators, directories that have user write must not allow administrator execute privileges in order to prevent a user from installing an executable and then fooling an administrative user into running it and compromising the system. For example, if your application or service needs to store log information that will be written to under user privileges, you should create a logging subdirectory to hold this data. This subdirectory should not allow admin execute. One way to do this is to add a leading explicit deny for file execute to everybody, such as D;OI;WP;;;WD. This prevents cross-user attacks in directories that allow file write or modify to users. There are many cases where it is expected that users will share data (though we do not want users sharing and executing code from a shared area). For example, a home user (or his photo-viewing application) is likely to create a folder such as C:\Photos. The user expects to be able to allow multiple users to write to this folder and have multiple users edit the various photos in this folder. The default ACLs on the root of the system drive on Windows Vista support this. The other common sharing situation is a folder in which users place data for other users to read. Only the creator of the data is allowed to delete or modify the data, but other users may copy it and then edit the copy. This is a shared read scenario, and it is the default for the system drive on Windows Server 2008. Consider the case where you choose to lock down the system drive and, specifically, ACL folders for sharing. You have to choose the ACLs that are appropriate for these two rather common scenarios. We want administrators to be able to manage the objects and we want to prevent security issues associated with execution of code in these folders (note that the ACEs here prevent even the owner from executing code from these folders). Here’s a Shared Read ACE: D:P(D;OI;WP;;;WD)(A;OICI;FA;;;BA)(A;OICI;FA;;;SY)(A;OICI;FA;;;CO) (A;CI;0x1200af;;;AU)(A;OI;GR;;;AU) And here is a Collaborative ACE: D:P(D;OI;WP;;;WD)(A;OICI;FA;;;BA)(A;OICI;FA;;;SY)(A;OICI;FA;;;CO) (A;OICI;SDGRGW;;;AU) Note that both ACLs start with a deny execute ACE for everybody, object inherit (to apply it to files), to prevent user system and crossFile and Registry Permissions

Table of Contents Feed for the Digital Edition of MSDN Magazine - November 2008

Contents MSDN Magazine - November 2008 Toolbox CLR Inside Out Data Points Cutting Edge Security Briefs Test Your Security IQ Agile SDL Access Control Utility Spotlight RIA Test Run Wicked Code Foundations Team System End Bracket

MSDN Magazine - November 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.