Cannot open log for source {0} -- again

Discussion in 'ASP .Net Security' started by craig.wagner@gmail.com, Mar 31, 2005.

  1. Guest

    I've done a ton of searching on this error and have not found any
    solution that actually solves the problem.

    My environment is Windows XP Professional with SP2. I'm using VS.NET
    2003 and .NET Framework v1.1.

    I created a brand new ASP.NET application to ensure that some other
    aspect of my real app wasn't causing the problem. I put a button on the
    form and added the following lines of code.

    System.Diagnostics.EventLog log =
    new System.Diagnostics.EventLog( "Application", ".", "aaa" );
    log.WriteEntry( "hello" );

    That resulted in the "Requested registry access is not allowed"
    exception being thrown.

    Did some searching and found this article.

    http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q329291

    Decide to use "First Approach" and go into registry to add new registry
    key:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\Application\aaa

    Run the app again, now it logs correctly.

    Go into web.config and add:

    <identity impersonate="true" />

    This should result in the application running under the identity of the
    IUSR account, because that is the account that anonymous access is
    configured to use.

    Now I'm getting.

    InvalidOperationException: Cannot open log for source {0}. You may not
    have write access.

    I tried adding the IUSR account to the Administrators group. Same
    error.

    Just for kicks, I configured the anonymous user as the local-machine
    Administrator account. Everything worked.

    I created a new account called blah. Put it in the Guests group and
    made it the anonymous use. Everything worked.

    Switched back to the IUSR account for the anonymous user. Failed.

    What is it about the IUSR account that it won't work? Why would another
    account that appears to be identically configured work?
    , Mar 31, 2005
    #1
    1. Advertising

  2. When you add an existing user to a group, the new group membership will not
    take effect until the next time the access token for the account is
    generated. For typical user accounts, this will be at the next login. For
    the IUSR account, this is far more difficult to control. The best way to
    ensure that the token is refreshed is to reboot the machine.

    BTW, adding a user to the administrators groups is not exactly the safest
    way to gain write access to the application event log...



    <> wrote in message
    news:...
    > I've done a ton of searching on this error and have not found any
    > solution that actually solves the problem.
    >
    > My environment is Windows XP Professional with SP2. I'm using VS.NET
    > 2003 and .NET Framework v1.1.
    >
    > I created a brand new ASP.NET application to ensure that some other
    > aspect of my real app wasn't causing the problem. I put a button on the
    > form and added the following lines of code.
    >
    > System.Diagnostics.EventLog log =
    > new System.Diagnostics.EventLog( "Application", ".", "aaa" );
    > log.WriteEntry( "hello" );
    >
    > That resulted in the "Requested registry access is not allowed"
    > exception being thrown.
    >
    > Did some searching and found this article.
    >
    > http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q329291
    >
    > Decide to use "First Approach" and go into registry to add new registry
    > key:
    >
    > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\Application\aaa
    >
    > Run the app again, now it logs correctly.
    >
    > Go into web.config and add:
    >
    > <identity impersonate="true" />
    >
    > This should result in the application running under the identity of the
    > IUSR account, because that is the account that anonymous access is
    > configured to use.
    >
    > Now I'm getting.
    >
    > InvalidOperationException: Cannot open log for source {0}. You may not
    > have write access.
    >
    > I tried adding the IUSR account to the Administrators group. Same
    > error.
    >
    > Just for kicks, I configured the anonymous user as the local-machine
    > Administrator account. Everything worked.
    >
    > I created a new account called blah. Put it in the Guests group and
    > made it the anonymous use. Everything worked.
    >
    > Switched back to the IUSR account for the anonymous user. Failed.
    >
    > What is it about the IUSR account that it won't work? Why would another
    > account that appears to be identically configured work?
    >
    Nicole Calinoiu, Apr 4, 2005
    #2
    1. Advertising

  3. Guest

    > When you add an existing user to a group, the new
    > group membership will not take effect until the
    > next time the access token for the account is
    > generated. For typical user accounts, this will
    > be at the next login. For the IUSR account, this
    > is far more difficult to control. The best way to
    > ensure that the token is refreshed is to reboot the
    > machine.


    I was finding this to be the case. I also found that doing an iisreset
    after changing group membership solved the problem.

    I have since been able to determine that the offending element in the
    whole thing seems to be the Guests group. If the IUSR account is a
    member of the Guests group, regardless of any other group membership
    then writing to the event log fails (i.e. IUSR could be a member of
    Administrators as well as Guests and it would still fail). I removed
    IUSR from all groups and it worked. So apparently it has nothing to do
    with the IUSR account but rather the Guests group. There must be an
    explicit "deny" somewhere in the system for that group that is causing
    the failure, but I have been unable to locate it with regmon, filemon,
    and auditing.

    > BTW, adding a user to the administrators groups
    > is not exactly the safest way to gain write access
    > to the application event log...


    I'm fully aware of that. Unfortunately, given the thundering silence
    that is the response to this problem it becomes necessary to try
    various combinations to see what might work so one can compare the
    differences between account and group permissions in an attempt to
    figure out exactly what is necessary to make it work. I realize using
    the Administrators group or Administrator account is not a long-term
    solution, it was simply another data point in trying to narrow down the
    problem.
    , Apr 4, 2005
    #3
  4. <> wrote in message
    news:...
    <snip>
    > I have since been able to determine that the offending element in the
    > whole thing seems to be the Guests group. If the IUSR account is a
    > member of the Guests group, regardless of any other group membership
    > then writing to the event log fails (i.e. IUSR could be a member of
    > Administrators as well as Guests and it would still fail). I removed
    > IUSR from all groups and it worked. So apparently it has nothing to do
    > with the IUSR account but rather the Guests group. There must be an
    > explicit "deny" somewhere in the system for that group that is causing
    > the failure, but I have been unable to locate it with regmon, filemon,
    > and auditing.


    Perhaps the
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\Application\RestrictGuestAccess
    value?


    >
    >> BTW, adding a user to the administrators groups
    >> is not exactly the safest way to gain write access
    >> to the application event log...

    >
    > I'm fully aware of that. Unfortunately, given the thundering silence
    > that is the response to this problem it becomes necessary to try
    > various combinations to see what might work so one can compare the
    > differences between account and group permissions in an attempt to
    > figure out exactly what is necessary to make it work. I realize using
    > the Administrators group or Administrator account is not a long-term
    > solution, it was simply another data point in trying to narrow down the
    > problem.


    Removing the guest restriction probably isn't the way to go either. If you
    really need to write directly to the event log from your web application
    (which isn't necessarily a great idea in the first place), a better approach
    might be to run your application under another user context. This could be
    accomplished simply by mapping anonymous use of your applicaiton to another
    user in IIS.
    Nicole Calinoiu, Apr 4, 2005
    #4
  5. <> wrote in message
    news:...
    <snip>
    > From what I've been able to determine, the Guests group and the Users
    > group are
    > virtually identical, with the exception of being able to write to the
    > event log.
    > I seem to recall even seeing somewhere (and of course I can't find the
    > reference
    > now) that said something to the effect that Users and Guests had the same
    > privileges except for the Guest account, which was further restricted.


    Not true. The exact differences depend on the platform, but you might want
    to start at
    http://www.microsoft.com/technet/pr...elp/f6e01e51-14ea-48f4-97fc-5288a9a4a9b1.mspx
    if you're interested in comparing the groups.


    >
    >>If you
    >>really need to write directly to the event log from your web application
    >>(which isn't necessarily a great idea in the first place), a better
    >>approach
    >>might be to run your application under another user context. This could
    >>be
    >>accomplished simply by mapping anonymous use of your applicaiton to
    >>another
    >>user in IIS.

    >
    > The above doesn't make sense to me, for two reasons.
    >
    > 1. The way the app is set up, there is a global exception handler in
    > Global.asax. It sends the user to a generic error page. That page captures
    > the
    > exception and logs it. That way our IT Ops group can set up monitors on
    > the
    > event log and we can be proactive about investigating problems with the
    > site. I
    > don't see the problem. It seems to me plenty of applications log
    > unexpected
    > behavior to the event log so details can be captured for later
    > investigation.


    Sure, but web applications are a poor candidate for writing to the
    application log for security reasons. Even if you're only logging
    exceptions, a malicious user of the web application could cause your event
    log to either fill or dump (clearing old entries to make place for new ones)
    simply by forcing exceptions, thereby exposing you to either a denial of
    service attack (via log filling) or hiding of clues to other activities (via
    log dumping). For this reason, you would be better off writing to a custom
    log rather than the default application log. At least with this approach,
    abuse of your web application won't affect the logging activities of local
    applications. You should also select the fill/dump behaviour of your custom
    log carefully since you'll still be subject to the DOS vs overwrite issue,
    even if it's restricted to only the single application.



    > 2. What difference does it make if I create a new account to run the
    > application
    > under or simply make IUSR a member of Users? Either way I've got an
    > account that
    > has the access it needs.


    If you grant the permission to the IUSR account, all web applications that
    run under this account will gain the permission. If you grant the
    permission to a new account that is used for only your application, other
    applications will still be unable to write to the log.



    > In effect, we have done #2 anyway. Our IT Ops group has set up the same
    > user on
    > each server in the farm (e.g. IUSR_TheWebUser, not the real name BTW).
    > They
    > could have called the account Bob, but they chose to use the IUSR prefix
    > for
    > whatever reason. That is the context in which the web applications (a mix
    > of
    > ASPNET and ASP) run. That way a consistent user is granted access to
    > external
    > resources (e.g. shares on the NAS).


    That's fine if only your application (and/or others that also require the
    same logging permissions) are run under this account. However, applications
    that cannot be trusted to write to the log should not run under an account
    with logging permissions.


    >
    > --
    > Craig Wagner, craig.wagner(at)comcast.net
    > Portland, OR
    >
    > "Don't ban high-performance vehicles, ban low-performance drivers!"
    Nicole Calinoiu, Apr 6, 2005
    #5
  6. Joseph MCAD Guest

    April 6, 2005

    I haven't read all of this thread, but check the Web Application Cannot
    Access Event Log 4/4/2005 in microsoft.public.dotnet.security. I have
    already helped some one out there and it appears that everything is solved!
    :)

    Joseph MCAD


    "Craig Wagner" <> wrote in message
    news:...
    > "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote:
    >
    >>Sure, but web applications are a poor candidate for writing to the
    >>application log for security reasons. Even if you're only logging
    >>exceptions, a malicious user of the web application could cause your event
    >>log to either fill or dump (clearing old entries to make place for new
    >>ones)
    >>simply by forcing exceptions, thereby exposing you to either a denial of
    >>service attack (via log filling) or hiding of clues to other activities
    >>(via
    >>log dumping). For this reason, you would be better off writing to a
    >>custom
    >>log rather than the default application log. At least with this approach,
    >>abuse of your web application won't affect the logging activities of local
    >>applications. You should also select the fill/dump behaviour of your
    >>custom
    >>log carefully since you'll still be subject to the DOS vs overwrite issue,
    >>even if it's restricted to only the single application.

    >
    > So when you said that writing to the event log from a web app wasn't a
    > good
    > idea, what you really meant was writing to the default application event
    > log
    > wasn't a good idea.
    >
    > Now what if there are no other apps running on the server? This is the
    > only
    > application.
    >
    >>That's fine if only your application (and/or others that also require the
    >>same logging permissions) are run under this account. However,
    >>applications
    >>that cannot be trusted to write to the log should not run under an account
    >>with logging permissions.

    >
    > Agreed. But every application running on the server is an in-house
    > developed
    > application, so they can all be trusted to write to the log and, in fact,
    > we
    > want them logging a subset of their activities and unhandled exceptions
    > should
    > they occur for troubleshooting and debugging purposes.
    >
    > We could mitigate some of the potential for abuse by having each
    > application
    > (assuming there was more than one at some point) write to a different
    > custom
    > event log I suppose. But it seems to me the bottom line from this thread
    > is that
    > we just keep moving or mitigating the potential for trouble.
    >
    > And I purposely used the term "potential" twice, because we're a very
    > targeted
    > site used by our clients only. Yes, someone could stumble on it and try to
    > be a
    > dick and bring it down, but we're hardly worth the effort. We've had no
    > incidents in the past five years. Sure, ignorance is no defense, and it
    > isn't
    > the only thing we do to take steps to protect ourselves, but we also need
    > to
    > weigh potential against complexity.
    >
    > --
    > Craig Wagner, craig.wagner(at)comcast.net
    > Portland, OR
    >
    > "Don't ban high-performance vehicles, ban low-performance drivers!"
    Joseph MCAD, Apr 7, 2005
    #6
  7. "Craig Wagner" <> wrote in message
    news:...
    > "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote:

    <snip>
    > So when you said that writing to the event log from a web app wasn't a
    > good
    > idea, what you really meant was writing to the default application event
    > log
    > wasn't a good idea.


    Writing to a custom event log incurs less overall risk than writing to the
    default application log, but I still wouldn't consider it to be a
    particularly wonderful approach for many situations.


    > Now what if there are no other apps running on the server? This is the
    > only
    > application.


    I suspect that you might other applications (e.g.: IIS) writing to the
    application event log on your server.


    >>That's fine if only your application (and/or others that also require the
    >>same logging permissions) are run under this account. However,
    >>applications
    >>that cannot be trusted to write to the log should not run under an account
    >>with logging permissions.

    >
    > Agreed. But every application running on the server is an in-house
    > developed
    > application, so they can all be trusted to write to the log and, in fact,
    > we
    > want them logging a subset of their activities and unhandled exceptions
    > should
    > they occur for troubleshooting and debugging purposes.


    Today, every application meets these criteria. Tomorrow, something new may
    be installed.


    > We could mitigate some of the potential for abuse by having each
    > application
    > (assuming there was more than one at some point) write to a different
    > custom
    > event log I suppose. But it seems to me the bottom line from this thread
    > is that
    > we just keep moving or mitigating the potential for trouble.


    Yup. Personally, I would probably choose an alternate mechanism for
    tracking application events. However, it's really a risk-management issue
    more than anything else, and nobody else can specify your level or risk
    tolerance for you....


    > And I purposely used the term "potential" twice, because we're a very
    > targeted
    > site used by our clients only. Yes, someone could stumble on it and try to
    > be a
    > dick and bring it down, but we're hardly worth the effort. We've had no
    > incidents in the past five years. Sure, ignorance is no defense, and it
    > isn't
    > the only thing we do to take steps to protect ourselves, but we also need
    > to
    > weigh potential against complexity.


    As a trade-off between complexity and security, why not at least have all
    your in-house apps write to a single custom log rather than the main
    application event log? Besides avoiding the possibility of filling the main
    log, you'll also gain the advantage of having all your applications' events
    isolated in a single file that doesn't need to be filtered to eliminate
    "noise" from other applications.


    >
    > --
    > Craig Wagner, craig.wagner(at)comcast.net
    > Portland, OR
    >
    > "Don't ban high-performance vehicles, ban low-performance drivers!"
    Nicole Calinoiu, Apr 7, 2005
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. CM
    Replies:
    0
    Views:
    335
  2. CM
    Replies:
    0
    Views:
    315
  3. CM
    Replies:
    0
    Views:
    337
  4. John

    Cannot open log for source

    John, Jan 19, 2005, in forum: ASP .Net Security
    Replies:
    1
    Views:
    299
    Daniel Fisher\(lennybacon\)
    Jan 30, 2005
  5. pat eyler
    Replies:
    1
    Views:
    444
    Masayoshi Takahashi
    Mar 5, 2005
Loading...

Share This Page