Access Control Best Practices for shared hosting seem at odds with Web Site Starters

From: M. M. Rafferty (mmr_at_vistagrande.com)
Date: 09/06/05 

Date: Mon, 5 Sep 2005 17:53:26 -0700

The MS Shared Hosting Deployment Guide lists among best practices:
    Ensure strong permissions are used on Web content
    Use separate anonymous (IUSR) accounts for each Web site
    Never allow anonymous user (IUSR) Write permission

The document also describes Isolated Shared Web Hosting where each customer
has their own application pool with a unique identity. It states that the
host should "Ensure that the Customer-specific identity has the minimal
necessary permissions to system resources" but exactly what that means in
terms of ACLs apparently has been left as an exercise for the reader.

And therein lies the problem. Or at least part of it.

We are looking at the web site starter kits -- DotNetNuke and the Community
Server. It appears that both require write access for the application pool
identity below the web root. This has also come up in a few other
applications such as shopping carts we have encountered. Usually, the
requirement is to allow content management features, generally image
uploads, via the browser.

How is this not anonymous write access? Why would Microsoft recommend this
to its hosting partners?

Also, another quirk that appears to be the case, at least from what we
encountered in some experiments with the Community Server applications, is
that one seems to require the application pool identity have list permission
starting at the root of the drive all the way down to the web folder. This
seems like a bit of a privacy breach at best since it would rely only on
security through obscurity in our folder naming.

Can someone explain this apparent contradiction?

Ideally, can someone lay out the recommended ACLs for this scenario for a
web host to have in place so that customers' sites are secured and
isolated... and still able to run real ASP.NET applications?

Thanks,

Mary M. Rafferty

Relevant Pages

  • Re: Permissions for a Site -> Only x user can access to a site
    ... Is possible to assign permissions to a user or group users in order to ... Approve - Can edit and approve pages, list items, and documents. ... View Usage Data - View reports on Web site usage. ... Browse User Information - View information about users of the Web ...
    (microsoft.public.sharepoint.portalserver)
  • Re: Permissions for a Site -> Only x user can access to a site
    ... Sites can have specific permissions. ... Approve - Can edit and approve pages, list items, and documents. ... View Usage Data - View reports on Web site usage. ... Browse User Information - View information about users of the Web ...
    (microsoft.public.sharepoint.portalserver)
  • Re: Permissions for a Site -> Only x user can access to a site
    ... "Mike Walsh" wrote: ... Sites can have specific permissions. ... Approve - Can edit and approve pages, list items, and documents. ... View Usage Data - View reports on Web site usage. ...
    (microsoft.public.sharepoint.portalserver)
  • Re: Permissions for a Site -> Only x user can access to a site
    ... Sites can have specific permissions. ... Approve - Can edit and approve pages, list items, and documents. ... View Usage Data - View reports on Web site usage. ... Browse User Information - View information about users of the Web ...
    (microsoft.public.sharepoint.portalserver)
  • RE: Frontpage SE Modifying NTFS permissions
    ... The Interactive and Network group is added ... when a Web site is set to allow anonymous users to browse the site content, ... site that does not allow anonymous browsing) on the same virtual server. ... | not allow admins to keep track of permissions. ...
    (microsoft.public.frontpage.extensions.windowsnt)