Using Enterprise Library Logging Securely with ASP.NET Applications

Using the EL Logging Application Block with ASP.NET is a little tricky -- primarily due to the fact that, in a well secured ASPX app, the logging code will fail due to a lack of write permissions.

First, let's consider the security aspects. In order to keep ASPX apps locked down, I don't allow any users to write to the ASPX app's v-root hierarchy (except Admins & VS Devs groups of course). For example, an ASPX app may map to:

c:\inetpub\wwwroot\WebApp1

with directory hierarchy (under WebApp1 dir) containing folders such as:

bin
SubFolder1
SubFolder1

The WebApp1, WebApp1/SubFolder1 and WebApp1/SubFolder2 dirs may all contain .aspx or other script/executable files. I want the absolute minimum number of users to be able to write to this dir. Otherwise, the more people who have access (even via hacking), the more risk exposure to script injections, etc.

I frequently find that a developer's "solution" is to enable Write permissions on the v-root. This is a horrible mistake and practically unsecures the ASPX app. The correct (and secure) approach is to:

1. Create a separate directory to store the log files
2. Grant the (IIS 6.0) App Pool's Identity write permission to the new directory
3. Configure the logging distributor to point to target the new directory

Create a Directory for Log Files
Simply use Windows Explorer, the Command Prompt or the Installer to create a dir for the log files. I typically create this as a sub-dir of the v-root (e.g., c:\inetpub\wwwroot\WebApp1\Logs)

Grant Write Permission
Again, use Windows Explorer, an Installer Custom Action, or other method to grant Write permission to the appropriate identity. I typically grant Write permission to IIS_WPG since all App Pool Identities must belong to this group. However, if you use multiple app pools with differing identities, then you should grant permission to that specific identity -- this will protect against other App Pool Identities from writing to the Log dir. (If your ASPX app uses end-user impersonation, see the Impersonation Issues section below)

Configure the Logging Distributor
Now that you have created the log dir and given the App Pool's Identity permission to Write to the dir, you need to instruct the Logging Application Block to use this dir for the output log files. Where the output file (typically "trace.log") is stored is controlled by fileName attribute of the sink element in the logging distributor configuration file (typically "loggingDistributorConfiguration.config"). Simply change the fileName attribute by prepending the relative path information.

<loggingDistributorConfiguration>
<xmlSerializerSection Â… >
<enterpriseLibrary.loggingDistributorSettings
defaultCategory="General" defaultFormatter="Text Formatter" ... >
<sinks>
<sink xsi:type="FlatFileSinkData" name="Flat File Sink" fileName=".\Logs\trace.log" ... />
</sinks>

...

</enterpriseLibrary.loggingDistributorSettings>
</xmlSerializerSection>
</loggingDistributorConfiguration>

Impersonation Issues
If your ASPX app employs end-user impersonation, then you'll need to make a choice.

1. Unimpersonate -- more secure, but a little more difficult to get right
   
2. Use custom group which holds Write Permission; add end-users to this group
3. Stop using end-user impersonation (don't impersonate or impersonate specific identity rather than end-user)
   

I prefer #1 when #3 is not an option. To implement #1, google for info on System.Security.Principal.WindowsIdentity.Impersonate(IntPtr.Zero). This call has the effect of causing the thread to go back to its original identity. Be sure to use catch/finally with Revert in the Finally block. Otherwise, you'll create a large security hole.