Item4898: tmp and working dir security needs work (docco and code

I set world rw access (777) to twiki/working/tmp so that other user command line access (and cronjob) to the cgi's was possible, and this of course causes problems:

It seems that the rcs temp file going into working/tmp is ok, as they are created with O_EXCL. CGI::Session also protects against malicious use.

1. This leaves the ip2sid file, which I think we should move out of tmp (its only used by the web-server?) * I also wonder at the implementation of _IP2SID as it seems to me to write the file every time its called, not just when it has new information, and I don't see any locking..
2. and the query passthrough files, that are write once, and then read&delete so can be trivially protected using O_CREATE|O_EXCL.
3. the tmp dir should be chmod 1777 to prevent third parties from deleting and replacing session files / the tmp dir with doctored versions (only the dir owner, and the file owner can do that)
4. if there is a dir that is world writable due to things like session files for command line access, they be in /tmp, to reduce the chance that someone can use that dir to fill the /var or /usr partition.

We need to work out the docco & permissions for the different non-web access modes for TWiki, right now, its still un-necessarily insecure if you want to allow command line access for things like view. (its a real can of worms if you want to allow command line save )

I'm just doing a quick patch for debian's 4.1.2 (something like the below), and then will wait for a little discussion.

=== TWiki.pm
==================================================================
--- TWiki.pm    (revision 27144)
+++ TWiki.pm    (local)
@@ -787,7 +787,9 @@
         }
     }
 
-    open(F, ">$passthruFilename") || die "{TempfileDir} cache not writable $!";
+    use Fcntl;
+    #passthrough file is only written to once, so if it already exists, suspect a security hack (O_EXCL)
+    open(F, ">$passthruFilename", O_RDWR|O_EXCL|O_CREAT, 0644) || die "{TempfileDir} cache not writable $!";
     $query->save(\*F);
     close(F);
     return 'twiki_redirect_cache='.$uid;
=== TWiki/Client.pm
==================================================================
--- TWiki/Client.pm     (revision 27144)
+++ TWiki/Client.pm     (local)
@@ -181,7 +181,7 @@
     return undef unless $ip; # no IP address, can't map
 
     my %ips;
-    if( open( IPMAP, '<', $TWiki::cfg{TempfileDir}.'/ip2sid' )) {
+    if( open( IPMAP, '<', $TWiki::cfg{WorkingDir}.'/ip2sid' )) {
         local $/ = undef;
         %ips = map { split( /:/, $_ ) } split( /\r?\n/, <IPMAP> );
         close(IPMAP);
@@ -189,7 +189,7 @@
     if( $sid ) {
         # known SID, map the IP addr to it
         $ips{$ip} = $sid;
-        open( IPMAP, '>', $TWiki::cfg{TempfileDir}.'/ip2sid') ||
+        open( IPMAP, '>', $TWiki::cfg{WorkingDir}.'/ip2sid') ||
           die "Failed to open ip2sid map for write. Ask your administrator to make sure that the {Sessions}{Dir} is writable by the webserver user.";
         print IPMAP map { "$_:$ips{$_}\n" } keys %ips;
         close(IPMAP);

in the 4.2 version, we should add a read&write temp file func, that we use everywhere, and also add to TWiki::Func - with a write once / over-write param? see the CGI::Session::Driver impls..

-- TWiki:Main/SvenDowideit - 29 Oct 2007

Yes, on the passthru fix, though shouldn't it be 0600 rather than 0644?

Does anyone actually use IP2SID? I suppose they might if they are frightened of the cookie monster.....

-- TWiki:Main.CrawfordCurrie - 29 Oct 2007

I don't understand point 3. Surely chmod 1777 will achieve precisely the reverse of what you say is required? Isn't chmod 700 really what you want? (Linux ignores the sticky bit AFAIK). The webserver user, and root, are the only users who should be accessing working. In a properly secure environment, cron jobs that need to write tmp should be run as the webserver user.

On that note, if we had a way to edit/install a crontab from the browser, that would be one more admin function that doesn't need shell access.

-- TWiki:Main.CrawfordCurrie - 29 Oct 2007

the root cause is really that running the twiki scripts from the command line, creates session files. Thats why I am using 1777, rather than being able to restrict access to the owner only.

I hope like hell that Linux does not ignore the sticky bit, as this was the advice given by the debian security guys

none-the less, cron is not the entire story. there are other use cases for running twiki from the cmd line.

I have to admit, I'm not totally convinced that IP2SID works anymore.

-- TWiki:Main.SvenDowideit - 29 Oct 2007

Of course you are right; the sticky bit on directories works, it's just the sticky bit on files that is ignored.

We could block the creation of a session for command-line transactions, I suppose.....

CC

Isn't it more approriate to only use sessions if its a CGI request?

-- TWiki:Main.SvenDowideit - 30 Oct 2007

I commited the passthrough fix, and the sticky bit in configure's tmp dir creation fix , and created a new bug - Item4972 to remove the session files when they're not needed.

-- SvenDowideit - 15 Nov 2007