create new tag
, view all tags
I'd be interested in hearing tips for secure setup of TWiki - TWikiInstallationGuide and TWikiOnSourceForge have some info on permissions, but the recommended setup is quite insecure. I'm particularly thinking of non-root TWiki administrators who are trying to avoid leaving all files world-writeable - modern Unixes and Linux don't allow files to be chowned to someone else's userid (e.g. from twiki to nobody), so leaving files as 644 mode is not possible.

The Apache docs say that there should never be files owned by 'nobody', so that an Apache hole doesn't let the intruder overwrite files. Obviously, TWiki's recommended setup breaks this - some way of making the CGI scripts setuid or setgid to twiki might be a good idea perhaps (although this would break ModPerl)?

Also, maybe there should be an agreed way of reporting security holes to the CoreTeam by email, so they can be patched before the hole is announced? Mainly an issue for Internet TWiki sites but could also affect large intranets.

-- RichardDonkin - 15 Jun 2001

If its important to not use nobody or the www-user users under apache you can use the suexec mechanism

-- NicholasLee - 15 Jun 2001

Thanks for the pointer to suexec.

How do people manage TWiki security? Do you just keep normal users off your server, and have files as mode 666, or do you have files owned by 'nobody' and mode 644? How do you get round the problems of not being able to do things from the command line if all files and dirs are owned by 'nobody' and mode 644?

It does seem like suexec would be the best solution overall. I suppose those using ModPerl will have root anyway, since mod_perl is quite a big security hole if allowed for normal CGI developers, so the fact that suexec doesn't work with mod_perl is not such a big deal - i.e. if you have root you can easily set up the ModPerl version of Apache to run as user 'twiki' (a separate httpd is recommended if you have any non-CGI pages on your site, for performance reasons - this could still run as 'nobody').

-- RichardDonkin - 16 Jun 2001

A less restrictive, but reasonably secure mode could be achieved by wrapping some calls with a sudo directive. i.e. /usr/bin/sudo -u twiki ci $FileName. And then restricting the sudo tables to a very specific set of commands. It's straight forward, and should be as secure as sudo itself. I needed to grant different user privileges to apache for a particular cgi script for just one command, so I just wrapped the command inside a sudo call.

Granted, a lot of the file access done by twiki would become more convoluted, but there might be a workaround to this by implementing our own suexec mechanism. That is, as all the file writing is already done in a single place, this particular script could have a suid "wrapper" program that could handle the calls as the respective user.

-- EdgarBrown - 24 Aug 2001

Glad TWiki.org is back at last! I think the recent security breach and subsequent outage raises the importance of SecureSetup - perhaps something on this topic could be added to the documentation?

BTW the table shown below is actually visible in the text when editing, rather than as a form - is this intentional?

-- RichardDonkin - 22 Oct 2001

I'm sure it's not intentional, and, on my home TWiki it usually results when I use some incorrect HTML tags (fail to use a closing </verbatim> tag or something similar). I'm looking for the problem. Oops, I see the <!--TWikiCat--> <p> tags somehow got stuck on the end of EdgarBrown's signature (and RichardDonkin's comments got inbetween it and the rest of the table's HTML -- I'm moving it and then will save my edits to see if that fixes the problem. If not, I'll be back. Nope, that didn't fix the problem, I'm looking again. Well, no I can't find the problem -- maybe some other cause.

-- RandyKramer - 22 Oct 2001

Given that we've just had quite a long outage due to lack of SecureSetup on sourceforge, I'm surprised that nobody else has commented here!

-- RichardDonkin - 26 Oct 2001

CGIwrap is an alternative to Apache's suexec, and is apparently better - there is at least one TWiki site running OK under cgiwrap, but see CobaltRaqInstall for a patch that may be needed, and links about cgiwrap.

-- RichardDonkin - 28 Feb 2002

Interesting sample chapter on secure CGI programming at http://www.oreilly.com/catalog/cgi2/chapter/ch08.html

-- RichardDonkin - 28 Mar 2002

Some more resources:

-- RichardDonkin - 31 Mar 2002

See also TaintChecking and TWikiOnWebHostingSites (where cgiwrap etc are a very good idea!).

-- RichardDonkin - 27 Apr 2002

Here's a good page on writing secure CGI - short but useful. Some parts don't apply to TWiki (e.g. banning CGI file uploads), but most of it does, including installing the files as mode 0555 on Unix (i.e. read-only for all users).

-- RichardDonkin - 03 Aug 2002

I already figured out something like the classic suexec or cgiwrap configuration, as mentioned in UnixTWikiFileOwnership, rolling my own set-group-id scripts. I should probably post my copious notes on my setup, and alternatives. Basically two approaches:

-- AndyGlew - 15 Apr 2003

Good to see your notes on this - I agree that this sort of SecureSetup is better than just relying on TaintChecking, since the latter doesn't address CGI scripts owned by other users on the server.

-- RichardDonkin - 15 Apr 2003

I think that the recent firedrill related to SecurityAlertGainAdminRightWithTWikiUsersMapping emphasizzes my security philosophy, as described in:

Briefly stating my philosophy:

  • Don't trust applications to do their own security
    • In particular, don't trust TWiki security
  • Rely on "standard" OS level security features
  • Run applications at the lowest possible security

level to accomplish their work

Reluctantly, I treat Apache webserver security as "OS-like": it isn't as good as OS security, and as commonly deployed it often isn't secure at all.

But if you employ webserver based security - webserver based authentication, as well as any extra layers of authentication you want to add in a thin layer of scripts, then you can reasonably upgrade your security, and have it apply to all web applications, as opposed to having to make separate, idiosyncratic, changes to each application's configuration - one change for TWiki, a different one for your bug tracker, etc.

Have the webserver/scripts exec your web applications in appropriate minimally endowed UNIX groups/users (or with apppropriate capabilities). Do not run all of the web application as a single user, unless all of the data the application can access is at the same security level.

This is a lesson that, apparently, needs to be learned over and over again.

-- AndyGlew - 06 Nov 2003

I agree with the philosophy you describe Andy, why reimplement security, and doing it poorly because security is hard, I'm just not able to follow it all the time because the only place I have access to the built-security mechanisms is on our intranet, where it doesn't matter anyway (for twiki that is). : (

-- MattWilkie - 07 Nov 2003

For people who can install their own modules in Apache, check out mod_security, which prevents certain classes of attack by cleaning up URLs, and can have signatures for specific attacks as well. Quite configurable, and might well have prevented the recent TWikiSecurity alert re the search hole.

-- RichardDonkin - 13 Dec 2004

I've been discussing this in RequireEXPLICITTagToEnableHTML and UsersCanPutJavascriptInTopics to address the issues raised there.

You are quite right; use of mod_security could have prevented the search incident and can prevent a wide number of other attacks. This is not meant to discourage a code audit and clean-up of Twiki. Elimination of "backticks" and use of shell should be an important part of making TWiki more secure against one class of attack. However, the scope and capabilities of mod_security are more wide ranging.

-- AntonAylward - 13 Dec 2004

  1. I asked dreamhost about mod_security: they said they would not support it.
  2. If we rely on "standard" OS level security features and don't use the TWiki security features then we cannot oust the BasicAuthentication system used by TWiki, and I suppose, then we can't address the lack of a logout button. It would useful if someone could check my assumptions here.

-- MartinCleaver - 13 Dec 2004

Martin - I searched dreamhost forum looking for your discussion with them and, strangely, found instead this thread from today suggesting that they are supporting mod_security.

-- LynnwoodBrown - 14 Dec 2004

Great. Thanks Lynnwood. I had started to think that they were behind the times, especially as it was one of a sequence of things Dreamhost had said they wouldn't support. (The other notable one was Perl 5.8 - to which they replied that they were waiting for Debian Woody to support it; they did not reply to my suggestion of having a shared area for beta-quality software).

Perhaps Anton or Andy (our resident security experts) can advise: does mod_security offer any remedy to the basic auth problem? (Other views welcome too, of course!)

-- MartinCleaver - 14 Dec 2004

It's pretty easy to build Perl 5.8.5 on Dreamhost - just download the source, set it up for something like ~/locperl58 as the PREFIX, and watch out for BuildingPerlCwdIssue (patch on that page for CPAN:Cwd). You may have to restart the build a few times but a Perl built like this has been working for me on my UTF-8 test site for some time.

Once you have Perl 5.8 built, the installation is just like DreamhostSetupNotes, except for a different shebang line pointing to the new Perl.

-- RichardDonkin - 14 Dec 2004

Ah. I see that confusion is on the rise again. "Security" is a great portmanteau word, a gunny sack that gets filled with all kind of "stuff".

mod_security is a filter. It controls what passes into the web server. Identifcation, authoentication and authoization are also to do with security. So is disaster recovery. lets not talk about them, eh?

mod_security is a filter. Its like a spam filter or a filter that takes HTML-mail or RTF mail and strips out potentialy nasty stuff, for various values of nasty. Or you could think of it like a net-nanny. It prevents certain things getting past in the

    data stream

In other topics I point out that you can have a read-only TWiki that has security problems. The %SEARCH bug of a few weeks ago was an example of this. The attacker doens't need to have the ability to create or edit a topic, just to go to the WebSearch topic and fill in a suitably framed string with shell metacharacters.

Being read-ony doesn't mean that it can't accept input. That's where a fitler on the input data stream comes into play.

One proposed "fix" involved breaking a lot of TWiki's existing functionality. mod_security wouldn't do that, but would place other restrictions on what could be entered. Thw specifics of the "what" are, of course, configurable according to your needs and risk tollerance, and what you percieve the threat issues to be. This is how I believe security should be addressed, and so I was delighted to stumble across mod_security.

One of my concerns is about what legitmate users can and should be allowed to do. Saying they can't create or edit topics to input HTML is, I think, a wrong approach. There are many things we can't do any other way in Twiki, most notably create forms. Yes, there are other Wikis -- I'm looking at some in Ruby, a beautiful OO language -- which support a ML that allow for creating forms and hence avoid the need to do it with HTML. But until and unless TWiki has such ML capabilities and can handle tables much, much better we are going to have to live with HTML.

I thought for a while that if we abolished the "edit" capability and made all input via these nifty little %COMMENT boxes we could put an immense amount of checking in the code for %COMMENT. And yes, that's the problem -- an immense amout of perl code.

mod_security is compiled C code. As in "performance".

Perhaps we need a topic to discuss configuration with mod_security? Why? Becuase it is configurable and differnet people may want different capabilities.

As for I-A-A -- Idnetification, Authentication and Audthorization, see SessionPlugin for a start. You're not going to oust Apache's BasicAuthentication but perhaps the identifcation and authetication model can be better spec'd and abstracted. The inportant thing is to get rid of the "nobody logged in means TWikiGuest" concept. To misquote the readical feminists .... null means null.

And don't tell me there isn't one bit of difference between null and space, because that's exactly how much difference there is.
-- Larry Wall

-- AntonAylward - 15 Dec 2004

I'm flattered that MartinCleaver named me as a security expert. Hmmm... maybe that's false modesty... I am expert in several areas of security, but by no means all, but part of being an expert is knowing the limits of your knowledge.

So, no, I am afraid that I cannot state an opinion as to whether Apache mod_security is sufficiently secure. I would hope that the Apache folk have validated it. I would hope that they have a continuing program to validate it. But I don't know this.

However, one of the rules of security is, if you don't know that it is secure, don't trust it. So, personally, I would not trust mod_security.

Sure, I might use Apache mod_security in an installation. But I would not trust it to be completely secure.

The only things I have reasonable confidence in, apart from not connecting to any network, are things such as

  • UNIX chroot boxes. All non-trivial network services should be placed in separate chroot boxes, and the boxes should be populated with as few other programs as possible.
    • Hopefully, no other program that allows a network port to be opened.
    • Unfortunately, the ability to execute almost-arbitrary Perl code in plugins provides the ability to open sockets. See below.
  • within the chroot box, the twiki cgi scripts should be deprivilged. They should NOT run as the same user or group as the webserver.

But not many people are that rich. If you are rich enough

  • the twiki server should be on an isolated machine
  • a separate physical box should monitor the traffic to the server.
    • ideally, this is a fully separate box, but a software firewall could be acceptable; it's just easier to compromise
    • the firewall should prohibit all non-HTTP traffic to the machine that carries the twiki server. That way, even if an attacker breaks out of the box, he can't do that much...
      • Oh, yeah? What if the attacker can take over HTTP service? Deprivileging the twiki scripts via setuid and setgid within the chroot box helps.

Only after I have done this minimal stuff - chroot, setuid/gid deprivileging, and restricting networjk connections to the machine running twiki - would I bother with stuff like

  • Apache mod_security
  • Perl Safe
    • By the way, I know that Perl Safe has security holes in things like DESTRUCTORs
    • But I think those holes will be fixed; starting to use Perl Safe now is a step in the right direction.

-- AndyGlew - 27 Dec 2004

"... Only After ..."

Well, I'd do a lot of things a long time before that. I'd make use of Twiki's own access control to make sure that casual users - "guests" and anonymous users (since Twiki has a problem telling the difference between the three aspects of secutity -- Identification, authentication and authorization) can't hack at system settings.

We absolutely must consider TWikiPreferences and each web's WebPreferences to be absolutely inviolate. They must be DENYCHANGE to at least TWikiGuest.

My personal opinion, sicne I am a securtiy expert in a number of fields, is that just about all the key configuration needs to be strapped down, and much of it should be DENYVIEW to most users for a number of reasons. We can start with all the 'tables' and 'settings' that a hacker would go for first of all, the key configuration and administration files.

You know what they are, don't you? All that stuff in the Main and the TWiki webs.

Oh, and the dot-htpassword file.

What, you mean you have't configured apache to prevent people reading that? What about keeping people from browsing data and pub directly? Have you taken care of that?

No, this is even more fundamental than chroot jails and deprivelidging. Not only that but its documented in the cookbooks. The "Example httpd.conf entries" in TWikiInstallationGuide#Step_1_Create_Configure_the_Dire show how to make twiki/data/ and twiki/templates' proof against casual browsing that can bypass the access controls. Personally I'd see about strapping down twiki/pub as well.

You think this isn't a serious security concern? You think that issues like the backticks in search are a more serious issue? Perhaps, but if you do you'd beter not be culpable of these straight forward ommission that are going to be under your control.

MartinCleaver has put together some tools for looking at sites to see what revision level the base and plugins are. Great tool. But it has some spin-offs. It can automate some other security tests as well.

Take a look at this: http://wikiconsulting.com/view/PublicWikisOverview/FieldSelect?fieldname=Exposed%20MAINWEB.TWikiPreferences&sortcol=2&table=1&up=1#sorted_table and this: http://wikiconsulting.com/view/PublicWikisOverview/FieldSelect?fieldname=Exposed+Data

Andy may be right, but there are even more fundamental principles than he raises.

  1. Fix the stuff that is easy and within your control
  2. Apply the principle of defence in depth

mod_security doens't have to be foolproof (and since its up to mere mortals to configure it how can it be?). But it does represent another layer of security that can address some risks that other layers cannot or do not. It will protect you from things that Chrooting and deprivielidging cannot.

Strap down what you can, what is under your control; do that first. Protect aginst casual attacks or simple minded autmated tools. Its easy. "Just do it".

-- AntonAylward - 28 Dec 2004

I think Andy is being unreasonable for a number of reasons.

First and foremost he's treating this as a technical problem to which he proposes a solution. Security isn't like that; security is aboiut Risk Management and is statistical. Its about what risk and what loss you are willing to accept and how much you are willing tp pay in terms of time, money and effort, to ensure that comfort level.

As I hope I've hinted at strongly above, flutzing about backticks when you have't done the very basic Apache and access control strap-down of your system means your efforts are mistpalced and you are failing to address the real issues.

In many ways security is easy - but its requires a lot of boring atention to detail. A LOT.

My concern with my sytems are not preventing people 'owning' the machine - what can they do with it? - but from doing things which will require effort and time on my part (which is the same as money since I could be doing other things, earning revenue) to restore the system.

Proper configuration of Apache and access control will go a long way towards that. The return for the effort invested is high.

Failing to follow though on these simple precautions puts my system at high risk to the casual hacker. I know that no system is proof against a determined attacker with time and tools, but I don't want to be victim to every script-kiddie that comes by.

-- AntonAylward - 28 Dec 2004

I'll agree to AntonAylward's bromide that security is risk management. But I will disagree: there are (have been, and continue to be) computer systems that are proof against a determined hacker with time and tools.

Note that I said "computer system". Social engineering is always a weakness.

Okay, okay... password guessing is always a vulnerability. For that matter, there is a chance that you can guess a private key. But, until RSA or ECC is broken, the chance of that is low.

Also, I am only talking about external hackers. I am not talking about the sort of hacker who was involved in the original build, who has left a trapdoor behind. Unfortunately, such trapdoor building hackers have been involved in Perl, so all is suspect. Trying to make TWiki, or anything built on Perl, internally secure is risk management; but trying to prevent a hacked TWiki or Perl from getting access to stuff it should not is not risk management, if you are running on trusted hardware and OS.

But overall, apart from password or key guessing, and so long as an undetected bit flip does not skip a security check, it is possible to build a provably system. IMHO the attitude that this cannot be done is part of the problem that has produced so much insecure code.


I am not a security administrator. But I have been involved with the design of Secure OSes, and I continue to be involved with the design of secure hardware.

I.e. I am a builder, not an administrator.

If you are in the position of taking components that others have built, then you are into the risk management phase. Risk management is the only thing that security administrators can take. And, yes, I use a risk management approach in systems I administer.


It is also apparent that I and AntonAylward are worried about two different aspects of security.

Neither of us want the TWiki system, or the webserver that is running on it, to be hacked, taken down, etc.

But most of the stuff I have posted about twiki security is intended to prevent a twiki server that has been hacked from being used to access any other non-twiki or non-webserver data.


Anyway... I am mainly cruising by here to see if any progress has been made on the access control issue for TWiki.

-- AndyGlew - 24 Jun 2005

It's worth checking out ExitPlugin - can be used to avoid sensitive intranet topic names appearing in referrer information when clicking links to external websites.

-- RichardDonkin - 05 Feb 2006

Now that my employers past past and present, Intel and AMD, have announced that they are both going to support virtual machines in differet ways (I worked on VMX at Intel; I did not at AMD), I can point to particulars:

I would seriously think about installing your twiki server in a virtual machine of its own.

Unfortunately, you will probably want to be able to mount the twik servers filesystems via NFS on other virtual machines.

But, at least you could try to make sure that the virtual machine that the twikiserver was running on had no mounts from other locations. I.e. allow it to server incoming traffic only, not outgoing.

Actually, people have been able to do this with VMware for years. I will admit, however, that I found VMware a pain to administer when I wanted to use it just for myself.

More on Vmware: VMware is distributing "application specific virtual machines in a box". Configuring a virtual machine to run twiki would be a perfect example of this.

BTW, in my latest twiki installation I take a simpler, but less secure, approach. The twikiserver runs as user http group www - I don't like this, because a successful attacker could access other twiki data, but I have to live with it. The twiki area is owned by user http, group "my-unix-project-group"., and is r-xr-s--- - i.e. user and group accessible, group-setuid to propagate group ownership, but world inaccessible. All of the files within the twiki directory tree are 777, world accessible.

This is somewhat secure because only user "http" or group "my-unix-project-group" can pass through the root of the filesystem. 777 access is needed because twiki is in group www, not setuid or setgid to a group I'm in - so the least common denominator is 777, so that both I and http can work in the filesystem.

I hate this - it's an accident waiting to happen. E.g. if somebody changes the access for the root of the twiki filesystem, or if somebody decides to put stuff on a different disk using symlinks.

But it is reasonably secure. I'd prefer setgid or chroot, but Intel's IT department is not very willing to support that.

-- AndyGlew - 23 Mar 2006

TWikiVMDebianStable is a pre-defined VMware virtual machine that includes TWiki 4.0. It doesn't really address security that well at present but can be used as basis for a secure setup.

-- RichardDonkin - 05 Jul 2006

Edit | Attach | Watch | Print version | History: r36 < r35 < r34 < r33 < r32 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r36 - 2006-07-05 - RichardDonkin
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.