|
 |
aspx thread: Security Change in ASP.NET RTM to be aware of...
Message #1 by "Scott Guthrie" <scottgu@m...> on Wed, 16 Jan 2002 01:33:30 -0800
|
|
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. This helps improve the overall
security of the system by eliminating the ability of a remote hacker to
ever 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
Message #2 by Kevin Burton <kevin.burton@i...> on Tue, 22 Jan 2002 16:28:58 -0600
|
|
I have tried giving ASPNET access to the world and I still cannot get a
simple Web Page or the QuickStart samples up. Any suggestions?
Kevin
-----Original Message-----
From: Scott Guthrie [mailto:scottgu@m...]
Sent: Wednesday, January 16, 2002 3:34 AM
To: ASP+
Subject: [aspx] Security Change in ASP.NET RTM to be aware of...
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. This helps improve the overall
security of the system by eliminating the ability of a remote hacker to
ever 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
Message #3 by Kevin Burton <kevin.burton@i...> on Tue, 22 Jan 2002 17:05:18 -0600
|
|
Maybe it would help if I posted what web.config file I have so far:
<configuration>
<system.web>
<processModel user="system" password="AutoGenerate"/>
</system.web>
</configuration>
Kevin
-----Original Message-----
From: Kevin Burton [mailto:kevin.burton@i...]
Sent: Tuesday, January 22, 2002 4:29 PM
To: ASP+
Subject: [aspx] RE: Security Change in ASP.NET RTM to be aware of...
I have tried giving ASPNET access to the world and I still cannot get a
simple Web Page or the QuickStart samples up. Any suggestions?
Kevin
-----Original Message-----
From: Scott Guthrie [mailto:scottgu@m...]
Sent: Wednesday, January 16, 2002 3:34 AM
To: ASP+
Subject: [aspx] Security Change in ASP.NET RTM to be aware of...
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. This helps improve the overall
security of the system by eliminating the ability of a remote hacker to
ever 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
|
|
|
View Cart
