Item1415: Change _default.WebPreferences to limit access to AdminGroup only

To avoid the _default web being modified either accidentally or maliciously, suggest that change access to the _default web be limited to AdminGroup in the default distribution. This is a safer default; admin users can loosen the restriction in their installation if desired.

Also suggest changing ManagingWebs to remind the admin user to check the WebPreferences topic for a newly created web and set any required macros appropriately. If _default.WebPreferences is changed to restrict access, then an explicit mention of the access controls would be useful.

If this task is done, not sure if it should be released to the 1.0.x stream, as it is a change in default behaviour. It is a security-related issue to a degree, as I believe any public Foswiki installation ought to lock down access to the _default web.

---

Setting WaitingFor field to Crawford as this issue is related to security. -- IsaacLin - 03 Apr 2009

---

Not sure how that connection comes about; Kenneth is probably more "on top of" security than me. FWIW I agree with your conclusions above, but changing the _default web security will involve some code as the restriction has to be lifted somehow when a new web is created. Relying on manual intervention to do that is not an option IMHO.

-- CrawfordCurrie - 04 Apr 2009

Mainly because I've gotten responses primarily from you on the security mailing list. I think it would be discovered very quickly if the restrictions had not been adjusted as desired, so personally I don't have an issue with leaving it up to the admin to modify the WebPreferences topic accordingly (and at the same time, take the opportunity to tweak any other necessary preference settings). Not sure what the best next step is: solicit additional feedback? Make a feature proposal?

-- IsaacLin - 04 Apr 2009

I thought that webs / topics, etc. beginning with underscore were at one point supposed to be "hidden" from the web interface. Is _default really supposed to be visible and editable or should it be hidden from access except when used as a template?

-- GeorgeClark - 05 Apr 2009

There is an actual problem with the _default web being editable by anyone registered by default.

Not as a real security issue as such but as a spam issue. People do not check up on the _default web so a spammer can create topics there and put attachments of questionable nature and it can stay for months undetected.

So I agree that action is needed.

BUT I do not think blocking access to everybody by default is a good solution because

• Upgraders hate that the default web gets modified. I have personally changed _WebPreferences in _default web on both my Motion site and on my Motorola site. And in different ways. The Motion site has the _default web write access blocked to protect against spam. And the Motorola site has the web protected against guest read access because that is the default for all our webs.
• The admin will forget to change the settings when he creates a new web. It does not help documenting. We drown the admin in words. Here we really need to apply the "don't make me think" principle.

I cannot see that any non-admin should ever need to change topics in _default web.

I do see the need to allow general write access to hidden webs. Some applications seen recently uses topics in a hidden web and the creation and editing of topics in these webs need to be not blocked.

So my view on this is that

• We should change the CODE so that _default web editing is hardcoded to require admin rights.
• But hidden webs as such should not be hardcoded to be blocked against editing.
• The _default web should be left as it is today

-- KennethLavrsen - 05 Apr 2009

A malicious user can subvert the access control system by adding in hidden preference settings to different topics, or even precreating strategically named topics with hidden preference settings granting access.

How about adding form fields to the web creation form prompting for which groups should have read access, which should have write, and which group is the web admin group? These values can then be used to set ALLOWWEBVIEW, ALLOWWEBCHANGE, and ALLOWTOPICCHANGE in the WebPreferences topic, and the default settings in the web being used as a template won't matter. Security controls is an area where the admin really must think about what is appropriate.

-- IsaacLin - 05 Apr 2009

I think the idea of specifying access controls up-front is a very good one, myself, and have upgraded it to Urgent targeting 1.1.

For now I changed the default permissions on webs to the creator of the web; it's up to them to relax the permissions. This has allowed me to restrict the _default and _empty webs to AdminGroup.

-- CrawfordCurrie - 23 Apr 2009

Expanding upon some of the statements from George and Kenneth, perhaps any web starting with _ can be treated as an internal implementation that should not be editable by anyone other than AdminGroup and perhaps a new MaintainGroup -- it may be useful to have introduce this concept more generally (with of course a configurable name to allow conflicts to be avoided). This would address upgrades as well as fresh installations. (For fresh installations, this approach doesn't differ very much functionally from changing the default permissions, but if changing the default permissions is deemed too much of a change for the 1.0.x stream, then it could be alternate interim solution.)

-- IsaacLin - 23 Apr 2009

I think given the change I already made this is fixed enough for 1.1. If you want more, then please raise a new report.

-- CrawfordCurrie - 06 Aug 2009