Re: Win2k3 Event Log and Security: Must choose between security and trustworthy

From: John Saunders (john.saunders_at_surfcontrol.com)
Date: 05/10/03

  • Next message: Susan: "(0x80004005) error" 
    Date: Fri, 9 May 2003 19:57:37 -0400

    Simply use an installer class.

    Double-click global.asax to view it in the designer.
    Open the Components tab in the toolbox and drag an EventLog to the design
    surface.
    Configure the Source, Log and Machine.
    Right-click the event log and select "Add Installer". Configure the
    installer as desired.

    When you build the web application, the installer will be built into the
    .dll in the bin\ directory.

    During deployment, after copying the files, run:

    installutil -i bin\site.dll

    This will install the event log source.

    If you use Web Setup Projects, you can have the project install the event
    log automatically by viewing the Custom Actions page and adding the .dll as
    a custom action in the Install and Uninstall phases.

    So don't give the running web site (or other application) the privileges
    necessary to install it - only the privileges necessary to run it. 

    -- 
John Saunders
Internet Engineer
john.saunders@surfcontrol.com
"Jonathan Folland" <jfolland.nospam@earthlink.net> wrote in message
news:esk8%23kHCDHA.2704@TK2MSFTNGP11.phx.gbl...
> When developing ASP.Net apps in Win2k I encountered an issue (many others
> have as well) regarding the way the EventLog.WriteEntry encounters
security
> problems when to trying to create new Event Logs and new Event Log
Sources.
> If the ASP.Net user is not defined as system or given Administrative
rights,
> it cannot create the Event Log or Source and thus cannot log to the event
> log.  There have been a number of responses placed on various news groups.
> In opinion, none of these responses adequately address the issue.
>
> The responses I have encountered include:
>
> 1) Write a Program to create the event log and its sources in the
registry.
> Run this program under a user account that has administrative privileges.
>
> In my opinion, this is not a very good solution.  What happens if a
> developer fumble fingers the name of the event log or its source or during
> coding of the application developers create new sources.  In order for
this
> to be effective, someone would need to write a program that scanned all
> source code for methods of New EventLog and WriteEntry, then parse the
> method arguments to come up with a comprehensive list of Logs and Sources.
> How many development shops are going to do this so that they can write to
> the event log?
>
> 2) Change the userName attribute in the processModel key in machine.cofig
to
> SYSTEM.
>
> First, I am not entirely certain of the security impact of doing this.  I
am
> guessing that it is not the wisest thing to do.  Regardless, this did not
> work on the Win2K3 Server machine I am using.
>
> 3) Give the ASP.Net user Administrative privileges on the machine.
>
> Clearly this represents a security problem.  However, it works on Win2k,
but
> not on Win2k3.
>
> 4) Under Win2k3, change the identity under which the default application
> pool runs from the I_WAM aco*** to System account.
>
> This is clearly a security problem, but it solves the problem of being
able
> to reliably write to the event log.
>
> The above solutions are the only ones that I have encountered to
potentially
> solve this problem.  I believe that developers must be confident that when
> they attempt to write to the event log, that the entry will be made.  In
my
> opinion, this is an absolutely critical item for "trustworthy" computing.
> Solution 1 does not present a security problem, but it presents a
> reliability problem.  The remaining solutions are all security problems.
> Thus, in my opinion, developers are faced with developing apps that are
> either not secure or not reliable.
>
> First, I am hoping that someone can respond to this with a good solution
> that solves my predicament. Second, if no reasonable solution is supplied,
I
> am hoping that Microsoft will "own up" to this issue by creating a hot fix
> for this.  Finally, (the black mail part), if neither of these occur, I am
> going to post this on every news group I can find until Microsoft
addresses
> the issue effectively, because to be quite honest, I am ticked off that I
> even have to write this.
>
> Jonathan Folland
> jfolland@no-spam.telesightcommerce.com.no-spam
>
>
  • Next message: Susan: "(0x80004005) error"