[GRASS-dev] GSoC 2014: GRAS GIS Web UI

[epi]

On Mar 11, 2014, at 12:36 AM, Hamish <hamish_b at yahoo.com> wrote:

> Massimo wrote:
> 
>> Is my understanding that the grass parsing code has to be
>> “less restrictive” for the desktop app while the sanitizer
>> has to be implemented on the web-ui side.
> 
> the locally run grass session doesn't have to be more generous in what it can accept, it's just that the local user is trusted already, and so we can get away with not having to harden every possible input. Sure we should clean those up, but there are thousands of them to fix and avoiding giving shell access to users who already have it makes the job more a matter of helping them to avoid crashes than protecting themselves from their own user account.
> 
> but, even if(/when :) we did think the code was safe from buffer overflows and injection attacks, the web ui should still sanitize inputs as an extra layer of protection, since no software can be trusted to be perfect.

gotcha.
I personally think of the web-ui user as a trusted user with his own home on the server, 
but i agree about the need to have an extra layer of security on the web-ui to check user inputs 
(a web app can be easily victim of malaware etc. enabling the possibility for the user to loose control of the app, but that’s an extreme case) 

> 
> ? Is this not true:
> Any public http ipython notebook should be running in an isolated per-session chroot jail, much like many ftp servers do, and the ipython server's port should be firewalled off from accepting connections from anything other than localhost. And even in a chroot jail a few big loops could use up all the given RAM or disk space by mistake or on purpose.
> 
> 

I see the implementation of the grass-web-shell as a second step in the web-ui development.
Most of its security issue depends by the user/admin needs.

I have an ipython notebook running on a remote server, it has a password and runs in https with an ssl cert. 
in my use case each each ipython instance runs on a specific port and use a different ssl cert.  (all this settings are stored in the ipytohn notebook profile)
 … It is not super-secure but is is enough from my needs, we are a small group (4) of trusted and well known users.

When the security needs are a high priority, tools like 
docker [1] , lxc [2] , supervisors [3] 
will let us to have more control reducing security risk.

But this king of thing is isolated from the web-ui development.

In any case the IPython-dev team is working hard on this direction, 
they just released 2.0 and from the roadmap [4] 
the multiuser interface will be released in the 3.0 version (coming out this summer)


[1] https://www.docker.io/
[2] https://linuxcontainers.org/
[3] http://supervisord.org/
[4] https://github.com/ipython/ipython/wiki/Roadmap:-IPython

[5] https://github.com/cni/ipython-hydra an old (1year) approach used at the university of standford to allow a multiuser interface to the IPYthon notebook


> 
> --
> 
> As a general thing- GSoC students are by definition still students, and I'm sure that most of us could stand to improve our coding habits too, and would welcome the opportunity. It is the mentors' role to review and teach as much as it is the student's summer job to produce code. The side goal of GSoC is to have a formal avenue to train and grow the future dev team. The more the student knows coming in the better, but we shouldn't expect them to always be experienced vetrans. Somewhere in the middle is a nice balance point. :)
> 
> 
> 
> regards,
> Hamish
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20140311/f5a27fcd/attachment-0001.html>