Re: installing las with dragstic security constraint (proxy,nfs read only, no telnet access)

[Jonathan Callahan <Jonathan.S.Callahan@xxxxxxxx>]

Olivier,

I must admit I'm stunned by the extent to which you've waded into the 
code and solved your own problems.  We should be paying you instead of 
the other way around.  (Oh yeah, we give the code away. ;-)

We are very interested in your code changes and can most likely be 
persuaded to give you CVS access on a separate branch for a security 
conscious version of LAS.  I do hope you can come down to Toulouse next 
week.  It'll be a great opportunity to connect and discuss some of the 
gory details of LAS problems and future work.  I suspect, however, that 
you will know more than me about several aspects of the LAS code.

a bientot j'espere


-- Jon



Olivier ARCHER wrote:

> Hi all,
>
> Here a syntesis of las installation whith dragstic security constraint:
>
> my computer department impose me several constraint installing a web 
> server in DMZ running las.
>
> DMZ constraints are:
>     * the web serveur in dmz sould not be access directly. it must be 
> behind a proxy
>
>     * service on the web server (like apache, tomcat) must be running 
> on non-standards ports.
>
>     * nfs access to LAN is restricted to nfs *read only*   
>     * no telnet acces, only http access from the LAN.
>
>
> So, In a firt time, I've done some linux debian hacking:
> the web server in dmz boot on a lightly distribution, whith network 
> and nfs support (will probably stay on a floppy disk).
> Into the LAN, I've setup a full debian install, but under a directory 
> tree, who is exported nfs ro. ( installed whith 'debootstrap' ).
> I've install las in it, and it work fine as long it was running on 
> chroot to the linux distibution, in *rw* mode.
>
> But the las server in DMZ mount the filesystem from LAN *read only*
> Problems occurs when running las from nfs read-only.
> Well I've encoutered linux problemes too. But most linux application 
> (apache, tomcat, etc ...) are FHS compliant (Filesystem Hierachie 
> Standard http://www.pathname.com/fhs/ )
> Strict compliant FHS application sould have access to:
>
> /var/cache/'aplication_name'
> http://www.pathname.com/fhs/2.2/fhs-5.5.html
>
> /var/log/'application_name'
> http://www.pathname.com/fhs/2.2/fhs-5.10.html
>
> /var/tmp
> http://www.pathname.com/fhs/2.2/fhs-5.15.html
>
> and ok course
> /tmp
>
> for a running linux booted from nfs ro, i've setup thoses directory rw:
> /var/lock
> /var/mail
> /var/run
> /var/spool
> /var/tmp
> /var/log
> /tmp
>
> in fact, (apart /tmp) those are link to /persistentrw (who is 
> preserved at reboot) or /volatilerw (who is erased at each reboot)
> (nb /persistentrw and /volatilerw are not FHS compliant, so direct 
> using is not recommended)
>
>
> For mysql on las, I've set up a link /var/lib/mysql to 
> /persistantrw/mysql
>
>
> Problemes running las are the same encountred whith a entire linux 
> distribution mounted nfs ro, or just the las tree mounted ro.
>
> * first of the problem is tomcat (catalina):
>       las come whith tomcat. and tomcat write where it has been 
> installed. the linux debian tomcat package is FHS compliant, so i use 
> it, instead of the one supplied whith las.
>
> * second problem is ferret.
>        Ferret can't open .jnl file on nfs ro. I've seen whith 
> Kevin.M.O'Brien@noaa.gov that it was a nag95 compiler bug. g77 build 
> of ferret works well on nfs ro.
>
> * third probleme is that las try to write to directory that is not 
> allowed to (conforming to FHS).
>       This probleme can be probably solved by appropriate modification 
> in ./configure
>       Well, I've answered question, and, i've after done modification 
> in  configuration output file, or in the code. I did not have time to 
> reflect change in ./configure.pl so i've got some ugly things like 
> that in the code:
> las/server/Ferret.pl
>  my $includes = ['/home/biblios/las/server/jnls', '.'];
>  my $templateConfig = {INCLUDE_PATH => $includes, EVAL_PERL => 1, 
> ABSOLUTE => 1}
> because I was not able to have $packageRoot handled correctly.
>
> So well, here las is under /home/biblios/las, who is not FHS 
> compliant. a better place should be /usr/lib/las6.1 as 
> http://www.pathname.com/fhs/2.2/fhs-4.7.html
>
> An other interresting thing in las/xml/perl/LASDB.pm:
> that    my $dir = cwd(); doesn't work on nfs ro. I Change it to  my 
> $dir = getcwd();
>
> Other code modification is mainly debug, to see where things go wrong.
>
> * fourth problem is that i can't telnet to the web server.
>      but i can have http acces to it. I'wrote simple cgi-bin script to 
> run genLas.pl, restart daemon, etc..
>
> * fift problem is the proxy.
>        In the beginning, I want the las server to run under 
> www.ifremer.fr/cersat/las. Well, I've lose hairs on it. I try 
> something like  www.ifremer.fr/lascersat, and i was thinking it was 
> ok, but last mozilla version say 'cookie problemes'. So i only found 
> room on www.ifremer.fr/las
>        The only proxy probleme I've encontred (after previous), is in 
> las/server/LAS/Server.pm
> "http://"; . $ENV{SERVER_NAME} . ":" . $ENV{SERVER_PORT} .
>             $loc . basename($_) } @{$files};
> something as to be done like
> "http://"; . $ENV{PROXY_NAME} . ":" . $ENV{PROXY_PORT} .
>             $loc . basename($_) } @{$files};
>
> * six, is not a problem, it's a dream:
>   as las is now on nfs-read only, it would be amazing to have multiple 
> las server running on the same nfs ro mounted tree (and with different 
> data, if *.xml are on an other mounted disk). This should be done by 
> getting 'on the fly' hostname, ports. depending on witch server las is 
> running on, it will know specific url it may use.
>
>   This should have advantages for developping, testing, and 
> exploitation environnement:
> While developping, developpers mount the las tree on nfs rw. They can 
> change the code, and run the las server on there developpement 
> machine. (Well, it' ok for 2 or 3 developers, but it's not cvs)
>
>   Testing should be done by simply copying the developpement tree, and 
> export it on nfs ro. The test server will mount it nfs ro.
>
>   explotation would be done by copying the testing tree to a place 
> whos is exported nfs ro on the 'real' las server.
>
> * seven, yet a other dream:
>   I believe in GNU/linux, and think that's the future of unix like 
> operating systeme. Linux packaging is easy. a dream is that las could 
> be installing whith 'apt-get install las' (apt-get doesn't only work 
> for debian, it works also with rpm). This dream should be achieved if 
> ferret and LAS are under GPL. many volunteers are waiting for new 
> application to package it... I've done it for the binary distribution 
> of ferret, but more should be done...
>
>
>
> Conclusion:
>     my las installation is a las 6.1 taken from a cvs snapshot. But 
> well, it's now differ a lot. If LAS people are interrested in having 
> thoses modification, I'll may perhaps have rw access to a cvs branch ?
>     At this time, wo don't have a dods server, we actually direct 
> acces to the netcdf file. But I've try it, and dods seems to be FHS 
> compliant. We plan to use grads-dods, who seem to work well on nfs ro, 
> and whith an http administration interface...
>
>
> So Well, I know that Jonathan.S.Callahan@noaa.gov come to France at 
> CLS next week. Tony.Jolibois@cls.fr Talk me about that, And I will try 
> to come if ifremer pay me the mission...
>
>
> --
> Olivier
> Computer Assistant