Re: IIS 6.0 cgi process not running as same user as worker process?
From: David Wang [Msft] (someone_at_online.microsoft.com)
Date: 05/12/04
- Next message: MAARTEN: "EVENT id 5000 CATAGORY :DEVICES"
- Previous message: David Wang [Msft]: "Re: Intermittent http return code 400 to one client only"
- In reply to: Issac Goldstand: "IIS 6.0 cgi process not running as same user as worker process?"
- Next in thread: Issac Goldstand: "Re: IIS 6.0 cgi process not running as same user as worker process?"
- Reply: Issac Goldstand: "Re: IIS 6.0 cgi process not running as same user as worker process?"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 12 May 2004 03:47:43 -0700
No... This is a frequently misunderstood feature.
On Windows, executing code has both a thread token and a process token. If
the thread token is set (i.e. impersonated), then it is used to execute
code; otherwise, the process token is used.
The Application Pool Identity merely allows you to customize the process
token. It does not mean that IIS is going to execute all code on the server
using this identity.
In fact, IIS executes code using impersonation by default, meaning the
identity that is executing the code comes from authentication (or IUSR in
the case of anonymous). This allows you to create users on NT and use IIS
to login as those users -- which allows IIS to leverage the rich
authentication/authorization infrastructure from NT. This is why CGIs are
launched using the impersonated identity.
Prior IIS versions had a fixed "LocalSystem" as the process identity -- not
exactly secure. Allowing the process token to be customizable is a form of
security lockdown since it represents a "sandbox" of maximum privilege that
code inside the AppPool can obtain. Users may authenticate and directly
elevate privileges (through impersonation), but any other code can only have
process identity... and IIS sets it to be a low-privileged Network Service
user by default, meaning that in the event of any exploitation, Network
Service is the identity... and not Local System.
Now, script engines, CGI, and ISAPI may choose to use impersonation or
not -- for example, it is configurable to have IIS launch CGI as either the
impersonated user or process identity (it's controlled by a metabase
property, "CreateProcessAsUser", and it defaults to "1" [which means to
impersonate]), and ASP.Net also allows users to choose "impersonate" or not.
In your case, I think you want to set "W3SVC/CreateProcessAsUser" property
to be 0. This will make your CGIs launch as app pool identity.
-- //David IIS This posting is provided "AS IS" with no warranties, and confers no rights. // "Issac Goldstand" <isaac@cpan.org> wrote in message news:OOESgZ5NEHA.3744@TK2MSFTNGP11.phx.gbl... Hi list, I've set up an application pool to run as a specific user which I set up properly (member of IIS_WPG, relevant security policy, relevant NTFS permissions, etc). When I run a Perl CGI in this application pool, the w3wp process runs as my user, but the Perl processes seems to be running as the IUSR_ user (which is the default anonymous access user for that app). Isn't the whole idea of setting the application pool user to avoid this? I have no problem with IUSR_ user being used to serve static content, but why run scripts? Very confused, Issac
- Next message: MAARTEN: "EVENT id 5000 CATAGORY :DEVICES"
- Previous message: David Wang [Msft]: "Re: Intermittent http return code 400 to one client only"
- In reply to: Issac Goldstand: "IIS 6.0 cgi process not running as same user as worker process?"
- Next in thread: Issac Goldstand: "Re: IIS 6.0 cgi process not running as same user as worker process?"
- Reply: Issac Goldstand: "Re: IIS 6.0 cgi process not running as same user as worker process?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|