[mapserver-dev] Re: MapServer security issue
steve.lime at dnr.state.mn.us
Wed Nov 20 21:20:57 EST 2002
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...
Data & Applications Manager
500 Lafayette Road
St. Paul, MN 55155
>>> 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.
Steve Lime wrote:
> Yes, I see that someone could leverage one mapfile in place of
> 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
> to use MS_MAPFILE
> unless you only have one application. A MapServer web hotel would
> benefit, yes.
> Should I make that change?
> Stephen Lime
> Data & Applications Manager
> Minnesota DNR
> 500 Lafayette Road
> St. Paul, MN 55155
>>>>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
> 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
>>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
> 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
> 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
> the MS_MAPFILE env. var is set.
More information about the mapserver-dev