[mapserver-dev] Re: MapServer security issue

[Steve Lime]

Ok, I don't think this will ever be fool proof especially if you have a
single web server with multiple applications. However, I certainly see
the wisdom in the case presented by Jan/Dan. I like the pattern-based
approach better than utilizing MS_MAPFILE because it's more flexible. I
often create a single application consisting of several config files.
So, I've added support for an environment variable called
MS_MAPFILE_PATTERN. This allows you to override the normal expression
(i.e. only end in .map) with one of your own. Unlike MS_MAPFILE this is
applied outside of the CGI application (in msLoadMapInternal()) so it
has broader use. The only reason for this is that's where the default
pattern is applied.

Note: In the spirit of this bug I also will close (disable temporarily)
another hole, the SAVEMAP option. This writes a copy of your mapfile to
a the temporary space specified in the WEB section. That's bad since the
file would be readable by anyone. The solution would be to use a non web
accessible scratch space.

All of this will be in the CVS by nights end...

Steve

Stephen Lime
Data & Applications Manager

Minnesota DNR
500 Lafayette Road
St. Paul, MN 55155
651-297-2937
>>> Jan Hartmann <jhart at frw.uva.nl> 11/20/02 08:21 AM >>>
Daniel describes exactly a project I am working with. We have done an 
Intranet project for the city of Amsterdam to monitor the distribution 
and change through time  of all kinds of population characteristics: 
income, origin, schooling etc. Data comes from many different municipal 
agencies. Most of these data are on address level, and may not be seen 
in that form outside the originating agency (privacy rules are very 
strict here). We summarized the data to different levels of aggregation 
(street, neighbourhoud, town-quarters) and decided on three access 
levels: some people should be able to see the complete data set (at the 
address level), some aggregated on streets, and the rest only the 
neighbourhoods. All three groups have access to the same set of basic 
data, and the first two groups can call more detailed maps.

The most obvious implementation is a webserver with three virtual hosts,

each with its own root directory and security permissions. The 
applications and mapfiles of these three groups would be totally 
separated, but they would access a common set of GIS files, well outside

the document trees of the servers. With Steve's permission mechanism 
within the mapfiles, no one would be able to access a GIS file he wasn't

allowed to see. However, anyone still can access a mapfile that wasn't 
meant for him. He couldn't get to its contents of course, but he could 
see the picture it generates (as long as there is a STATUS DEFAULT line 
in it).  This is certainly against the project requirements.

Another place where mapfile protection is required is a set of computers

linked by a shared filesystem like a Beowulf cluster. Here you can have 
many MapServers running who each should be unable to access the mapfiles

of any other.

Both examples are perhaps not very common (yet), but they are also not 
hypothetical. Moreover, I would like to point out a further advantage of

very strict security for MapServer, even if it is more than most people 
need at the moment. There is much interest nowadays for Open Source 
software by governments and the  European Union (I don't know what the 
situation is in the US and Canada). All those people are very much 
preoccupied by security and privacy. It would help very much to convince

them to use MapServer if we could point to this wonderful two-level 
security mechanism (mapfile and environment) which would make it 
absolutely impossible to break into any application.

Technically, I still prefer an environment variable with a regular 
expression to limit the number of mapfiles a MapServer can access. If 
left out, nothing changes and every mapfile can be accessed. If it 
contains a regular filename, only that mapfile can be accessed (this 
would be equivalent to Daniel's solution). Every possibility in between 
can be set be appropiate regexes. Would this be very difficult to 
implement? I thought it would be much like the mechanism for protecting 
th DATA statement within the MapFile.


Sorry to be so long, but this is something I am really concerned about. 
Making MapServer completely secure could help a lot to make it even more

popular in the near future. Leaving any holes would make it 
impracticable in more situations than I would like.

Jan


Steve Lime wrote:
> Yes, I see that someone could leverage one mapfile in place of
another.
> The only thing
> they could really get is a picture although with WMS there might be
> more. But it seems 
> that unless you're really are running on mutiple hosts with one
> application per host
>  there's not much that can be  done to stop it. You could create a
> pattern  to restrict 
> access but that would also  prevent legimate access.
> 
> I don't think there's much of a problem with disabling map= with
> MS_MAPFILE set, but 
> it alone probably won't do much to fix this hole since you're not
going
> to use MS_MAPFILE
> unless you only have one application. A MapServer web hotel would
> benefit, yes.
> 
> Should I make that change?
> 
> Steve
> 
> Stephen Lime
> Data & Applications Manager
> 
> Minnesota DNR
> 500 Lafayette Road
> St. Paul, MN 55155
> 651-297-2937
> 
> 
>>>>Daniel Morissette <morissette at dmsolutions.ca> 11/19/02 12:27PM >>>
> 
> Sorry to jump in the middle of this discussion... I still have several
> messages to read in this thread and I'll try to read them and comment
> as
> soon as I can find the time.
> 
> In the meantime...
> 
> Steve Lime wrote:
> 
>>In your scenario what's the benefit to the hacker in choosing
> 
> another
> 
>>mapfile? They can't get at the contents, not through the MapServer
>>and there's already a regex pattern applied to mapfile names. That
>>pattern is in the source code as opposed to the environment but I
>>see little value in something other than limiting the extension.
>>
> 
> 
> Imagine a server with multiple virtual hosts (or multiple apps) with
> some apps serving public data, and some apps serving sensitive data
> protected by some mechanism (e.g. password-protected using .htaccess
> or
> access restriction by IP address, or ???).
> 
> The hacker (or interested visitor) could use the mapserv CGI instance
> installed on the public server to open a mapfile that belongs to one
> of
> the restricted applications.
> 
> After a quick read of his message I think that's what Jan is trying to
> prevent, and I also see this as an important issue.  That's why I
> initially proposed that we modify the mapserv CGI so that the map=
> parameter is disabled, either by default at build time, or at least
> when
> the MS_MAPFILE env. var is set.
> 
> Daniel