¿Cuál es el riesgo de cambiar los permisos de la clave de registro del Registro de eventos de seguridad a las operaciones de TI?

Background

Muchos desarrolladores están reduciendo innecesariamente la seguridad del registro de eventos, o requieren que las aplicaciones se ejecuten en modo Administrador solo para que puedan usar el registro de eventos con este código C # o VB:

  EventLog.[WriteEntry][1]("MyBadApp", "This will cause an exception for ASP.NET and non admins", EventLogEntryType.Error, 10);

... y luego no crea un instalador que cree las claves de registro necesarias para "MyBadApp"

Más información

Si eso se ejecuta bajo Network Service , ASP.NET, WCF, una cuenta de servicio y está usando una cuenta que no es de administrador, ocurrirá la siguiente excepción ... pero quién sabe si o dónde se registrará (Pegar por el bien de Google)

System.Security.SecurityException: The source was not found, but some or all event logs could not be searched.  Inaccessible logs: Security.
   at System.Diagnostics.EventLog.FindSourceRegistration(String source, String machineName, Boolean readOnly)
   at System.Diagnostics.EventLog.SourceExists(String source, String machineName)
   at System.Diagnostics.EventLog.VerifyAndCreateSource(String sourceName, String currentMachineName)
   at System.Diagnostics.EventLog.WriteEntry(String message, EventLogEntryType type, Int32 eventID, Int16 category, Byte[] rawData)
   at System.Diagnostics.EventLog.WriteEntry(String source, String message, EventLogEntryType type, Int32 eventID, Int16 category, Byte[] rawData)
   at System.Diagnostics.EventLog.WriteEntry(String source, String message, EventLogEntryType type, Int32 eventID)
   at **YOUR.CUSTOM.BROKEN.CODE.HERE(ResolvedMessageEventSource source, QueuedMessageEventArgs e) in c:\test2\YourProjectHere\Class1.cs:line 116**

 ----  SNIP Possibly more stuff here --
System.Threading._ThreadPoolWaitCallback.PerformWaitCallbackInternal(_ThreadPoolWaitCallback tpWaitCallBack)
   at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(Object state)
The Zone of the assembly that failed was:
MyComputer

Microsoft es consciente de este problema, pero es por diseño para un acceso rápido y sucio a EventLog. Cada vez que se llama a WriteEntry , el sistema enumerará el registro y buscará el "Nombre de origen" que la aplicación especificó. . Si no existe, entonces será creado.

El problema es que durante la enumeración, se golpea el registro de seguridad y se lanza una excepción. Los desarrolladores que no creen un instalador o que, de lo contrario, creen una clave de registro para "MyBadApp" volverán a la creación dinámica de eventos y verán este problema.

Esto es así por diseño y afecta a WriteEntry y menos frecuentemente WriteEvent (los desarrolladores de WriteEvent suelen crear un instalador)

Solución

Hay 3 soluciones que conozco:

1. Haga que la aplicación se ejecute como Administrador (mal)

2. Cambie los permisos en las claves de registro

3. Cree un instalador que haga la clave de registro para la aplicación (la mejor solución)

Pregunta

¿Qué es lo peor que puede pasar con una aplicación que cambia los permisos de la clave de registro de seguridad?

• ¿Puede leer el registro de eventos de seguridad?

• ¿Puede cambiar o modificar las entradas del registro de eventos de seguridad?

• ¿Puede falsificar eventos de seguridad que no son los suyos?

• ¿Puede eso conducir a un DoS?