Friday, 24 October 2008

LogDisplayName: A Case Study in Windows in Object-Level Security

Surely awesome Windows progammers don't need event logs (a feature of NT since 1993, only relatively recently been seen in retail Windows) since they can program their own application logging without much fuss. Still, knowledge of the Event Logging API (exposed in .NET's System.Diagnostics namespace) is a prerequisite before once can be deemed a Windows master programmer. Hacking event logs also illustrates interesting points regarding "secure methods" in Windows.

Let's see what event logs look like in XP and Vista.

EventLog objects have "secure" methods (LogDisplayName)

Write a small program using System.Diagnostics.EventLog.GetEventLogs() method and logobject.LogDisplayName property to find and display event logs to the user. You will be flooded with SecurityExceptions! Here are the reasons!

1. Running code from an untrusted location (e.g. untrusted UNC path) - this results in the following: System.Security.SecurityException: Request for the permission of type 'System.Diagnostics.EventLogPermission' (insert culture and public key token info here) failed. Copying the assembly locally worked, but there were still exceptions.

2. Protected Registry Access - my locally-running program worked fine for Internet Explorer, Hardware Events and some others but not for My Computer. The error was: System.Security.SecurityException: Requested registry access is not allowed. The answer lay in the registry itself. Right clicking on "Eventlog" in the registry (below) revealed all.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog

This idea of "secure methods" in an API resemble the "object model guard" on the Outlook API. This prevents client programs e.g. automatically sending email on behalf of the user, without explicit user consent. A buzzword for this concept of "secure methods" is object-level security. A rather old but useful post on SecurityException debugging .NET can be found here, on the .NET security blog. "Secure methods" are also configurable in Java via the SecurityManager class.

No comments: