|
| Security Change in ASP.NET RTM to be aware of... |
|
|
|
|
| Messages |
|
Related Types |
This message was discovered on microsoft.public.dotnet.framework.aspnet.mobile.
Responses highlighted in red are from those people who are likely to be able to contribute good, authoratitive information to this discussion. They include Microsoft employees, MVP's and others who IMHO contribute well to these kinds of discussions.
| Scott Guthrie (VIP) |
There was one important security change between ASP.NET Beta2 and RTM that
you should watch out for when upgrading to the final bits.
Specifically, the default Windows Account under which the ASP.NET worker
process executes was changed from running as "LocalSystem" in Beta2 to
instead run under a more restricted "ASPNET" account (which we automatically
create during install).
Making this change reduces the capabilities of code running within ASP.NET.
Specifically, it means that .aspx files no longer run with local
administrative permissions. The helps improve the overall security of the
system by eliminating the ability of a remote hacker to exploit any security
holes on the server and then execute code under an administrator identity to
maliciously hack the system.
What this change also means, though, is that because ASP.NET code is now
running with reduced permissions on the system, administrators will now need
to explicitly grant the ASPNET account security ACLs to use certain Windows
features.
If appropriate ACLs are not set when attempting to use a resource, an
"access denied" exception will most likely be thrown at runtime (in some
shape or form depending upon the feature you are attempting to use).
Whenever you see one of these types of errors when running on the RTM bits,
the first thing you should investigate is what resource that page or code
was trying to execute -- and then whether the "ASPNET" account has ACL
permissions to use that resource and perform those operations. If the ASPNET
account doesn't have access -- then you'll need to either grant the ASPNET
account access to it, or alternatively modify the account the ASP.NET worker
process runs under (for example: by changing back to LocalSystem). Note that
you can change the account used within the <processModel> section of the
machine.config file.
The most common case where you will probably find that you now need to grant
ACLs is with file-system disk access. Two scenarios to explicitly watch out
for:
All File System Write Scenarios
--------------------------------
By default the ASPNET account only has access to read files from disk -- and
not to write to it. If you have a file (for example an XML text file) that
you are writing to from an ASP.NET application, then you will need to make
sure to grant the "ASPNET" account write access to either the individual
file, or the directory it is in. To do this, simply right-click the file or
folder using the file-system explorer, click the security tab within it,
select or add the "ASPNET" account from the users list, and then click the
appropriate checkboxes below to grant write access for the account.
Some File System Read Scenarios
--------------------------------
By default the ASPNET account does have access to read the disk (especially
for everything under Inetpub). However, on some servers that have been
locked down prior to installing ASP.NET, you might find that an
administrator has denied read access to all but a chosen few users. In this
case you will probably see an error (possibly a "access denied" or "file
change notification monitor failed to start") the first time you hit an
ASP.NET page on a newly installed system. This is because ASP.NET isn't able
to read from the disk of your web directory to either open/execute a .aspx
page -- or even to examine the web.config file.
To fix this, simply right-click the Inetpub directory (or whatever your web
root directory is) using the file-explorer, click the security tab within
it, select or add the "ASPNET" account from the users lists, and then click
the appropriate checkboxes below to grant read access for the account.
Note that every web directory higher than your application root will also
need read access for the ASPNET account (this is a gotcha to watch out for).
So for example, if you have a "foo" application on your server:
"http://localhost/foo"; -- you need to make sure that the "foo" application
directory has read permissions for the ASPNET account, as well as the
"Inetpub" directory (which is the logical parent directory of the
application) as well. We've seen a few (albeit rare) situations where admins
have locked down the Inetpub directory -- and these can potentially lead to
confusing error messages if you forget to check these security ACLs when
deploying your application.
Some other scenarios to watch out for
--------------------------------
A few other scenarios that will now require explict ACL permissions to be
set in ASP.NET RTM (but didn't in beta2):
-- Creating new EventLog categories dynamically
-- Creating new PerfMon categories dynamically
-- Sending email using the NT SMTPMail Service
-- Using WMI (System.Management)
-- Registering COM+ components (System.EnterpriseServices)
-- Reading the Registry or IIS Metabase
-- Reading Active Directory (with System.DirectoryServices)
We will shortly be posting a whitepaper that walks through how to perform
each of the above steps. We will post a link to it from http://www.asp.net.
Thanks,
Scott
|
|
|
| |
|
|
| |
| |
| LCR |
Hi
What is "the RTM"?
LCR
"Scott Guthrie" <Click here to reveal e-mail address> wrote in message
news:#3aeECnnBHA.2156@tkmsftngp07...
[Original message clipped]
|
|
|
| |
|
| |
| |
| Scott Guthrie (VIP) |
Sorry about that -- RTM means the final version of the product ("Release To
Manufacturing"). Those are the bits that were just released on the web.
Thanks,
Scott
"LCR" <Click here to reveal e-mail address> wrote in message
news:uVXbBr3nBHA.2440@tkmsftngp05...
[Original message clipped]
|
|
|
| |
|
|
| |
|
|
|
|
|
|
|
|
|
BootFX
Reliable and powerful .NET application framework. |
|
|
|
|
|
|
