The default pub-htaccess.txt file makes the pub directory public. Where TWiki is being used as a firm's knowledge base this is quite inappropriate: all pub files should be served by viewfile.

I'd venture that use of viewfile should be default in Dakar.

In Edinburgh it could be controlled by configure.

By the way, Does viewfile log accesses?

---

one argument against this is that the logos and css would thus also happen through viewfile. right now, i'd suggest that this sort of proposal is should be deffered as its too late to figure out all the consequesnses -- SD

1 Where can we document it? DakarReleaseNotes? 2 Is there a rule we can apply that any TWiki-supplied webs and the stuff in pub not in a web should be freely accessible whereas anything the user makes goes through viewfile?http://www.infosecwiki.com/bin/view/TWiki/TWikiRegistration

-- MC

---

DakarReleaseNotes should contain a notice of differences between CairoRelease and DakarRelease, with a link to the more-detailed instructions in one of the sections of TWikiInstallationNotes. -- WN

---

The real issue here is not whether or not /pub needs to be protected or not. That sweeping assertion is isleading and argumentative and misleading.

We already have access cotnrol for topics. If the only way to access the attachment associated with a topic were via the topic's attachment table the problem would be greatly reduced. Since TWikiPreferences is accessible so are the logos attached to it. And so forth.

The problem then becomes how do we apply fine grain access control - the topic may be accessible but do we want the attachement to be?

I would say this is again wrong thinking. Why would you show someone an attachment you don't want them to access? Why not put the restricted attachment with another topic and make that other topic restricted?

There is no reason to add unwaranted complexity.

Right now, so long as /pub is not browsable we have a layer of protection, even if it is onlya weak form - "Security by Obscurity". Yes, a user can construct a URL to access any attachment. But he has to know the name of the attachment. If the topic it is attched to is not viewable he can't see what the name of the attachment is. Yes, a 'dictionary attack' would find them. I said it was a weak form of security. But it is enough to foil the casual browser.

-- AJA

Actually views such as http://www.infosecwiki.com/pub/ are not enough to foil the casual browser.

> >MRJC> No obscurity there.
> AJA> No documents there to protect either.

-- MC

---

Also, Martin, you need to be able to differnetiate in the access control between /pub/ being accessible and being browsable.

Having Options -Indexes means that visiting http://www.infosecwiki.com/pub/ with your browser gives a 403 Forbidden message.

However that doens't stop you accessing a file such as www.infosecwiki.com/pub/Main/AntonAylward/f1000001.jpg if you know the full URL. Pictures of cats do not constitute critical documents that need to be protected, however.

-- Anton "Jumpin' Jehosephat" Aylward CISSP - "Cat Intelligence Securities Services and Patrolling" -- Uncovering Cats' Secret Names

---

Anton, how could I say it in kind words: "security by obscurity" is not an answer but an excuse, a bad one. Noone's gonna get convinced or feel any safe. MD

• I never said that "security by obscurity" was an answer. I said that if you don't know what you're looking for you're not ging to be able to find it easily. If you use Options -Indexes then people can't browse. They have to guess the URL.
  Its the difference between leaving something in the open and puting it in a drawer. The draw is not locked but you can't see its contents when casually walking though the room. Another analogy might be closed doors in an office building. You can't peer into the offices just by walking down the corridor. Its not meant to stop a determied attacker, just discourage a casual pilferer. And if you have a determined attacker then ther are many, many other things you have to worry about and human factors (such as bribery) are much more effective.
• Aren't wikis supposed to be about communities, isn't there supposed to be some basic level of trust?
  If you are feeling higly paranoid then perhaps some other tool would be more appropriate.
• The present versions of TWiki emit the URL of the attachment/embeded object. It is up to the browser to fetch it. That means any access control would have to be at the web server (?Apache?) level. Putting attachment access control under TWiki is going to need to change that. It is likely to be a far reaching change.
  -- AJA

---

Very true, but now we have one requirement for pub-htaccess.txt

For instance, http://www.infosecwiki.com/pub/CISSPForum/WebHome is fairly predictable, and any topic name that is discussed verbally is immediately unsecured. What's the point of having access controls on topics if they are not enforced for attachments? Especially true for manager types who will start by putting their thoughts in as word document attachments.

• Quite True. But why are you discussing it with people you don't want to know about it?
  Technical security measures are of no use if subverted by human behaviour. Remember "Loose Lips Sink Ships"?
  • You might have overheard or known the name of an initiative. -- MC
    • You're stretching, Martin. Like I said, if that kind of thing is happening then you have more serious security problems than the settings on /pub -- AJA
• There gets to be a point where users have to twiddle their security settigs ("do this dont do that..") so much that they give up and turn all security off. Once security get in the way of the work they are paid to do security goes out the window. Too much security is worse than no security at all. It bad enough if you have to secure each and every tpic. Thnakfully we have WEB-level access controls too.
  • But the web-level access controls are useless on attachments with the default set up. Surely the instructions for viewfile are reliable? -- MC
• Martin, if things get to be like your scenario then the manager should be using Lotus Notes not TWiki.
  -- AJA
  • TWikiMission might have something to say about that
    • So might the Business Requirements. I think they will win. -- AJA

MC

Let's think how we can secure things by default.

MC

Right. Without having to resort to such esoteric things as mod_rewrite, which is not going to be avialable to many people running on hosted sites.
-- AJA

---

Security of attachments is no less important than security of topics no matter how much you are a friend of access restrictions in a wiki environment. If you do not like to restrict your content then don't. But if you like to restrict access then you should be able to do that. And TWiki is one of the few wikis that has this feature. I like that. You don't, Anton. That's Ok.

Let's stop this fruitless discussion and come back to the real issue. Guys, sometimes discussing everything down to the philisophical implications wether some thing is blue or black does no help.

IMHO, attachments should be secured by adding a content handler into the apache api (yes an apache-only-solution) that teaches apache TWiki's ACLs. Attachments are protected by checking the topic it is attached to. Some attachments might be excluded from the ACLs by setting parameters in the .htaccess file in /pub. Let's have an vague example

PerlAccessHandler Apache::TWikiAuth
PerlAddVar TWikiAuth_AllowType css
PerlAddVar TWikiAuth_AllowWeb TWiki

This installs the access handler to be some Apache::TWikiAuth implementation, allows all css filetypes to bypass ACLs, allows access to all attachments in the TWiki web.

I've seen a crude TWikiAuth implementation somewhere on twiki.org. Forgotten where.

MD

Martin, you are right, but it's not going to happen before Dakar. I made viewfile acknoeldge perms, and that s all we have time for. CC

Ok, so if viewfile acknowledges perms, how do we ensure we always use viewfile? http://twiki.org/cgi-bin/view/Codev/SecuringAttachments

Is the mod_rewrite trick the way to go?

MC

http://koala.ilog.fr/twikiirc/bin/irclogger_log/twiki?date=2005-12-05,Mon&sel=32#l28 has more conversation I had with Ben Voui and I've emailed TWiki:Main.HolmRauchfuss for any advice.

MC

---

Undeferred, post Dakar CC

---

There's a lot of work involved here. Checking permissions is a very time-consuming job, and if it has to be done on every access, it could be a real hog.

There is no sensible way to cache authenticated accesses; at best it would be horrendously complex.

The only sensible solution I can think of is to classify the pub areas for webs into "public" and "protected". For example, the TWiki web would be a "public" area and would be openly accessible without permissions checks. All pub accesses would have to go through viewfile, so viewfile would need to be accelerated as far as possible for non-secret data. Webs would need to be configured to be protected or public in a way that can be checked really really quickly (e.g. $TWiki::cfg{Pub}{ProtectedWebs}{Secret} = 1), so TWikivariables are out.

Aside from that, I think it would be enough to redirect $cfg{PubUrlPath} to a viewfile. Has anyone tried it?

Note at the moment, using viewfile to access a resource instead of direct URL access is 1000 times slower on my machine (956ms as against 0.92ms)

CC

While I'm thinking about it... WebDAVPlugin takes permissions half-out-of-band by cacheing them in a TDB. Since this is c-code it is blazingly fast, compared to TWiki. Might be a way to do the permissions check for viewfile, though.

CC

Changed the summary to better reflect the intent

CC

I just imporved it quite a bit by reconfiguring TWiki.pm to lazy-load. Also has a performance knock-on improvement in other scripts, such as rest handlers.

Dropping this to an Enhancement, as more work on it requires a significant rewrite of viewfile, and there are other (better) approaches.

CC

Cleaned out Checkins: Was TWikirev:7255 TWikirev:7256 TWikirev:14218 TWikirev:14235 TWikirev:14298 This is all ancient history. Otherwise shows up as a work in process.

-- GeorgeClark - 02 Jan 2015