[mapserver-users] Mapserver Security [SEC=UNCLASSIFIED]

Roppola, Antti - BRS Antti.Roppola at daff.gov.au
Thu Jul 30 03:12:50 EDT 2009


Hi Bill,

That's because it's not Apache reading the content in the directory.
Apache is running the CGI and the CGI is accessing the directory
directly. The CGI is already "behind" the access policy layer.

As the CGI is usually running as the Apache user, it has the same access
level as the Apache user (i.e. everything that any Apache process can
see).

It's not *that* great a problem as you can only interact with content
using methods supported by the Mapserver CGI. For example, "draw".
Mapserver is unlikely to have any methods that will enable wholesale,
unaltered transfer of raw content, using mapserver to access most files
is unlikely to elicit a useful response.

Some ideas:
 - Wrap your CGI and use _established_ tools to test/assert canoncial
paths on inputs
	* Within the CGI wrapper i.e. Might Perl's bless/taint be
applicable?
	* using server level tools like mnodern equivalents to
"mod_security"?
	* Home brew regexp style security tools are probably always
faulty
 - Your CGI wrapper could use sudo to contain different contexts to
different roles/permissions
 - Put sensitive data into a database (like PostGIS) and use RDBMS
roles/permssions (with login details kept out of the map file!)
 - Use security frameworks like SELinux or AppArmor to assert contexts
(example below)

The last option makes it easy to restrict particular CGIs to particular
paths and is probably easiest to manage. Say put a sensitive map ito a
separate VirtualHost with its own CGI and use SELinux or AppArmor to
restrict each VirtualHost to its own content. In a single host system,
you could keep two CGIs and place a context policy on the generic
mapserv.exe that keeps it out of "theDir". Here's a sample snippet from
an AppArmor context that could be applied:
	1) Allow that conext to execute object as in a specified
location ("bin/*.sh", think "mapserv.exe")
	2) Those executables are only allowed to read .jar files (think
"path/*.map") from another specified location

/data/some/app {
...
  /data/some/app/bin/*.sh rix,
  /data/some/app/common/**.jar r,
...

By no means a "ready rolled" solution, but rather some avenues to
explore.

Cheers,

Antti

-----Original Message-----

It works fine, but I don't know why it works because it accesses the
mapfile in /theDir/, and /theDir is supposed to be password protected
now by Apache. To make sure that I didn't already have a valid user in
my browser, I shut it down and then tried again. When I ran that wrapper
it picked up its info from the mapfile and then happily drew the map
using the web template file that's also in that "protected" directory. 
It's as if there was no security at all!


------
IMPORTANT - This message has been issued by The Department of Agriculture, Fisheries and Forestry (DAFF). The information transmitted is for the use of the intended recipient only and may contain sensitive and/or legally privileged material. It is your responsibility to check any attachments for viruses and defects before opening or sending them on. 

Any reproduction, publication, communication, re-transmission, disclosure, dissemination or other use of the information contained in this e-mail by persons or entities other than the intended recipient is prohibited. The taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error please notify the sender and delete all copies of this transmission together with any attachments. If you have received this e-mail as part of a valid mailing list and no longer want to receive a message such as this one advise the sender by return e-mail accordingly. Only e-mail correspondence which includes this footer, has been authorised by DAFF 

------



More information about the mapserver-users mailing list