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

GRASS GIS GRASS GIS developer
21

Hi,

Some more user comments: When we installed RStudio server in our company, our network administrator actually only agreed, because we could limit the listening-addresses / the server was not available from the internet and only accessible within the trusted company network. The same would likely be true for a GRASS web-interface too. So like Massimo, I would guess that the “trused-user” approach would be the most popular…

In fact, the only use-case I can imagine for an anonymous web access to a GRASS installation would be demonstration / marketing, that people can have a closer look without installing. But that would require, that the web UI is comparable to the desktop solution to give a comparable impression… Would be anonymous www-access be possible at all? I mean, how would one exclude concurrent use of a mapset, i.e. two anonymous users accessing the same mapset at the same time?

Cheers

Stefan

···

From: grass-dev-bounces@lists.osgeo.org [mailto:grass-dev-bounces@lists.osgeo.org] On Behalf Of epi
Sent: 9. mars 2014 15:28
To: Glynn Clements
Cc: grass-dev@lists.osgeo.org
Subject: Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI

Glynn,

I’aware that the “security risk handling” in a web app is a hard and hot topic, hopefully a lot of project are working on this direction

Of course a web-ui for grass will be designed for registered users and not for the anonymous www (password, registration and https can be implemented)

The “web-shell” feature is obviously reserved to only “trusted users”.

without this assumption application like Rstudio or IPython notebook should not exist.

A multi user approach needs to be based IMHO on unix each user has to have its own home and access to filesystem. If this is not enough the application can be restricted to a chroot jail but this is not part of the UI development (is more a sys admin choice)

For the authorization protocol it can be implemented using PAM. (i guess is what Rstudio is using)

WT has a mature authentication module

http://www.webtoolkit.eu/wt/blog/2011/11/29/wt___jwt_3_2_0

http://www.webtoolkit.eu/wt/blog/2013/08/07/security__wt_and_the_new_breach_vulnerability/

The potential user of a web ui for grass, need to be a trusted user in any case and need to go trough a registration process where an admin as to approve it. not anonymous users allowed.

I guess the code behind the web-ui has to sanitize each text entry, will be this enough ?

A “sanitize inspection” on all the “input” coming from the web-ui can be performed and this will be part of the UI itself, not of the grass modules. with the aim to avoid people doing something like … http://xkcd.com/327/ :wink:

Massimo.

On Mar 8, 2014, at 11:42 AM, Glynn Clements <glynn@gclements.plus.com> wrote:

Rashad M wrote:

My main concern would be security.

You will need to thoroughly sanitise all inputs. You cannot rely upon
GRASS modules to do this, as e.g. most string handling uses fixed-size
buffers, so you need to explicitly limit the length of any arguments
to avoid the possibility of buffer overruns.

I am not clear with this. maybe security and web apps are creating me a
confusion.

If you do not understand the principles of secure programming, you
shouldn’t attempt to write a web interface to GRASS.

GRASS modules typically do not attempt to be secure against invalid
input. If you’re providing access to “untrusted” users (users who
aren’t supposed to have the full privileges of the account under which
the modules are executed), you will need to prevent invalid input from
reaching the modules.

–
Glynn Clements <glynn@gclements.plus.com>

grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

22

Hi Stefan,

about anonymous access, the app can use a demo location that is generated on the fly using cloning a "template location".
If i well remember, PyWPS does something like that.

But you need to be limit the number of available instance running … (has to be a configurable option), to avoid a server overload.
how may anonymous users can test the app at the same time is up to the capabilities of your server.

Cheers,
Massimo.

On Mar 9, 2014, at 4:37 PM, Blumentrath, Stefan <Stefan.Blumentrath@nina.no> wrote:

Hi,

Some more user comments: When we installed RStudio server in our company, our network administrator actually only agreed, because we could limit the listening-addresses / the server was not available from the internet and only accessible within the trusted company network. The same would likely be true for a GRASS web-interface too. So like Massimo, I would guess that the “trused-user” approach would be the most popular…

In fact, the only use-case I can imagine for an anonymous web access to a GRASS installation would be demonstration / marketing, that people can have a closer look without installing. But that would require, that the web UI is comparable to the desktop solution to give a comparable impression… Would be anonymous www-access be possible at all? I mean, how would one exclude concurrent use of a mapset, i.e. two anonymous users accessing the same mapset at the same time?

Cheers
Stefan

From: grass-dev-bounces@lists.osgeo.org [mailto:grass-dev-bounces@lists.osgeo.org] On Behalf Of epi
Sent: 9. mars 2014 15:28
To: Glynn Clements
Cc: grass-dev@lists.osgeo.org
Subject: Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI

Glynn,

I’aware that the "security risk handling" in a web app is a hard and hot topic, hopefully a lot of project are working on this direction
Of course a web-ui for grass will be designed for registered users and not for the anonymous www (password, registration and https can be implemented)

The “web-shell” feature is obviously reserved to only “trusted users”.
without this assumption application like Rstudio or IPython notebook should not exist.

A multi user approach needs to be based IMHO on unix each user has to have its own home and access to filesystem. If this is not enough the application can be restricted to a chroot jail but this is not part of the UI development (is more a sys admin choice)

For the authorization protocol it can be implemented using PAM. (i guess is what Rstudio is using)
WT has a mature authentication module

http://www.webtoolkit.eu/wt/blog/2011/11/29/wt___jwt_3_2_0
http://www.webtoolkit.eu/wt/blog/2013/08/07/security__wt_and_the_new_breach_vulnerability/

The potential user of a web ui for grass, need to be a trusted user in any case and need to go trough a registration process where an admin as to approve it. not anonymous users allowed.

I guess the code behind the web-ui has to sanitize each text entry, will be this enough ?
A "sanitize inspection" on all the “input” coming from the web-ui can be performed and this will be part of the UI itself, not of the grass modules. with the aim to avoid people doing something like .. http://xkcd.com/327/ :wink:

Massimo.

On Mar 8, 2014, at 11:42 AM, Glynn Clements <glynn@gclements.plus.com> wrote:

Rashad M wrote:

My main concern would be security.

You will need to thoroughly sanitise all inputs. You cannot rely upon
GRASS modules to do this, as e.g. most string handling uses fixed-size
buffers, so you need to explicitly limit the length of any arguments
to avoid the possibility of buffer overruns.

I am not clear with this. maybe security and web apps are creating me a
confusion.

If you do not understand the principles of secure programming, you
shouldn't attempt to write a web interface to GRASS.

GRASS modules typically do not attempt to be secure against invalid
input. If you're providing access to "untrusted" users (users who
aren't supposed to have the full privileges of the account under which
the modules are executed), you will need to prevent invalid input from
reaching the modules.

--
Glynn Clements <glynn@gclements.plus.com>
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

23

Hi Stefan,

···

On Mon, Mar 10, 2014 at 7:00 AM, epi <massimodisasha@gmail.com> wrote:

Hi Stefan,

about anonymous access, the app can use a demo location that is generated on the fly using cloning a “template location”.

If i well remember, PyWPS does something like that.

But you need to be limit the number of available instance running … (has to be a configurable option), to avoid a server overload.
how may anonymous users can test the app at the same time is up to the capabilities of your server.

This is more of a customization of webGRASS. WebGRASS UI is the web extestion to run grass modules. If you want to allow anonymous users or trusted users is a question of deployment. Some webmapping framework allows a demo users and the person who installs webgrass on their server be it on internet or else, he must know his users as any other typical web application. For example you can deploy your data on internet using web services and map viewer client like OpenLayers and allow anonymous users or setup a login and allow only verified users. Again the the login could use (OAuth, simple db login, manual verification, auto email verification etc.). This shouldn’t be a part of web framework in my opinon. Rather web application allows such provision in a non coupled way.

In case of webgrass we decide to have trusted login by default.

Cheers,
Massimo.

On Mar 9, 2014, at 4:37 PM, Blumentrath, Stefan <Stefan.Blumentrath@nina.no> wrote:

Hi,

Some more user comments: When we installed RStudio server in our company, our network administrator actually only agreed, because we could limit the listening-addresses / the server was not available from the internet and only accessible within the trusted company network. The same would likely be true for a GRASS web-interface too. So like Massimo, I would guess that the “trused-user” approach would be the most popular…

In fact, the only use-case I can imagine for an anonymous web access to a GRASS installation would be demonstration / marketing, that people can have a closer look without installing. But that would require, that the web UI is comparable to the desktop solution to give a comparable impression… Would be anonymous www-access be possible at all? I mean, how would one exclude concurrent use of a mapset, i.e. two anonymous users accessing the same mapset at the same time?

Cheers
Stefan

From: grass-dev-bounces@lists.osgeo.org [mailto:grass-dev-bounces@lists.osgeo.org] On Behalf Of epi
Sent: 9. mars 2014 15:28
To: Glynn Clements
Cc: grass-dev@lists.osgeo.org
Subject: Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI

Glynn,

I’aware that the “security risk handling” in a web app is a hard and hot topic, hopefully a lot of project are working on this direction

Of course a web-ui for grass will be designed for registered users and not for the anonymous www (password, registration and https can be implemented)

The “web-shell” feature is obviously reserved to only “trusted users”.

without this assumption application like Rstudio or IPython notebook should not exist.

A multi user approach needs to be based IMHO on unix each user has to have its own home and access to filesystem. If this is not enough the application can be restricted to a chroot jail but this is not part of the UI development (is more a sys admin choice)

For the authorization protocol it can be implemented using PAM. (i guess is what Rstudio is using)

WT has a mature authentication module

http://www.webtoolkit.eu/wt/blog/2011/11/29/wt___jwt_3_2_0

http://www.webtoolkit.eu/wt/blog/2013/08/07/security__wt_and_the_new_breach_vulnerability/

The potential user of a web ui for grass, need to be a trusted user in any case and need to go trough a registration process where an admin as to approve it. not anonymous users allowed.

I guess the code behind the web-ui has to sanitize each text entry, will be this enough ?

A “sanitize inspection” on all the “input” coming from the web-ui can be performed and this will be part of the UI itself, not of the grass modules. with the aim to avoid people doing something like … http://xkcd.com/327/ :wink:

Massimo.

On Mar 8, 2014, at 11:42 AM, Glynn Clements <glynn@gclements.plus.com> wrote:

Rashad M wrote:

My main concern would be security.

You will need to thoroughly sanitise all inputs. You cannot rely upon
GRASS modules to do this, as e.g. most string handling uses fixed-size
buffers, so you need to explicitly limit the length of any arguments
to avoid the possibility of buffer overruns.

I am not clear with this. maybe security and web apps are creating me a
confusion.

If you do not understand the principles of secure programming, you
shouldn’t attempt to write a web interface to GRASS.

GRASS modules typically do not attempt to be secure against invalid
input. If you’re providing access to “untrusted” users (users who
aren’t supposed to have the full privileges of the account under which
the modules are executed), you will need to prevent invalid input from
reaching the modules.

–
Glynn Clements <glynn@gclements.plus.com>

grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

–

Regards,
Rashad

24

epi wrote:

I guess the code behind the web-ui has to sanitize each text entry,
will be this enough ?

A "sanitize inspection" on all the �input� coming from the web-ui
can be performed and this will be part of the UI itself, not of the
grass modules. with the aim to avoid people doing something like ..
http://xkcd.com/327/ :wink:

That's the main thing.

If you allow the user to e.g. provide names for maps, such names
should be limited to alphanumeric characters and limited to a
reasonable length.

If you allow the user to provide a list of inputs, limit both the
maximum number of items and the total length of the resulting textual
representation.

And so on.

In short, GRASS modules are designed for use by local users who
already have shell access, so there hasn't been any need to program
defensively. The OS prevents people from e.g. reading or writing files
which they aren't supposed to.

--
Glynn Clements <glynn@gclements.plus.com>

25

Glynn,

I understood the risk and I agree in toto with you.
For the web-ui interface we can define the rules for each kind of entry
and publish the rules/restriction on a help page .
Then when an invalid input exception is raised the ui will point the user to read the rules page.

Massimo.

On Mar 10, 2014, at 12:02 PM, Glynn Clements <glynn@gclements.plus.com> wrote:

epi wrote:

I guess the code behind the web-ui has to sanitize each text entry,
will be this enough ?

A "sanitize inspection" on all the �input� coming from the web-ui
can be performed and this will be part of the UI itself, not of the
grass modules. with the aim to avoid people doing something like ..
http://xkcd.com/327/ :wink:

That's the main thing.

If you allow the user to e.g. provide names for maps, such names
should be limited to alphanumeric characters and limited to a
reasonable length.

If you allow the user to provide a list of inputs, limit both the
maximum number of items and the total length of the resulting textual
representation.

And so on.

In short, GRASS modules are designed for use by local users who
already have shell access, so there hasn't been any need to program
defensively. The OS prevents people from e.g. reading or writing files
which they aren't supposed to.

--
Glynn Clements <glynn@gclements.plus.com>

26

On Mon, Mar 10, 2014 at 10:19 PM, epi <massimodisasha@gmail.com> wrote:

Glynn,

I understood the risk and I agree in toto with you.
For the web-ui interface we can define the rules for each kind of entry
and publish the rules/restriction on a help page .
Then when an invalid input exception is raised the ui will point the user
to read the rules page.

This is what GRASS parser system [1] is trying to define, so you

should/need to use it for that. However, it might not be sufficient (1). In
this case, you should not try to workaround it but suggest and improvement
for GRASS parser instead.

(1) E.g. standard options [2] are defined in the library and modules are
using them but they are not visible in the interface (since they are
translated to more basic types), so some information is lost.

[1] http://grass.osgeo.org/programming7/gislib_cmdline_parsing.html
[2] http://grass.osgeo.org/programming7/parser__standard__options_8c.html

Massimo.

On Mar 10, 2014, at 12:02 PM, Glynn Clements <glynn@gclements.plus.com>
wrote:

>
> epi wrote:
>
>> I guess the code behind the web-ui has to sanitize each text entry,
>> will be this enough ?
>>
>> A "sanitize inspection" on all the �input� coming from the web-ui
>> can be performed and this will be part of the UI itself, not of the
>> grass modules. with the aim to avoid people doing something like ..
>> http://xkcd.com/327/ :wink:
>
> That's the main thing.
>
> If you allow the user to e.g. provide names for maps, such names
> should be limited to alphanumeric characters and limited to a
> reasonable length.
>
> If you allow the user to provide a list of inputs, limit both the
> maximum number of items and the total length of the resulting textual
> representation.
>
> And so on.
>
> In short, GRASS modules are designed for use by local users who
> already have shell access, so there hasn't been any need to program
> defensively. The OS prevents people from e.g. reading or writing files
> which they aren't supposed to.
>
> --
> Glynn Clements <glynn@gclements.plus.com>

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

27

Vaclav,

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.

Develop the sanitizer on the web-ui code and do not touch the g.parser source code.

The sanitizer code will following the guidelines found at the page [thanks] you pointed :
“Complete Structure Members Table”

but extending the restrictions to what Glynn suggested :
size constraint, alphanumeric characters, maximum number of items in a list and more.

this restriction will be true for the web-ui but not for the desktop gui
hence the need to leave untouched the grass command line parser code.

does this make sense for you ?

Massimo.

···

On Mon, Mar 10, 2014 at 10:19 PM, epi <massimodisasha@gmail.com> wrote:

Glynn,

I understood the risk and I agree in toto with you.
For the web-ui interface we can define the rules for each kind of entry
and publish the rules/restriction on a help page .
Then when an invalid input exception is raised the ui will point the user to read the rules page.

This is what GRASS parser system [1] is trying to define, so you should/need to use it for that. However, it might not be sufficient (1). In this case, you should not try to workaround it but suggest and improvement for GRASS parser instead.

(1) E.g. standard options [2] are defined in the library and modules are using them but they are not visible in the interface (since they are translated to more basic types), so some information is lost.

[1] http://grass.osgeo.org/programming7/gislib_cmdline_parsing.html

[2] http://grass.osgeo.org/programming7/parser__standard__options_8c.html

Massimo.

On Mar 10, 2014, at 12:02 PM, Glynn Clements <glynn@gclements.plus.com> wrote:

epi wrote:

I guess the code behind the web-ui has to sanitize each text entry,
will be this enough ?

A “sanitize inspection” on all the �input� coming from the web-ui
can be performed and this will be part of the UI itself, not of the
grass modules. with the aim to avoid people doing something like …
http://xkcd.com/327/ :wink:

That’s the main thing.

If you allow the user to e.g. provide names for maps, such names
should be limited to alphanumeric characters and limited to a
reasonable length.

If you allow the user to provide a list of inputs, limit both the
maximum number of items and the total length of the resulting textual
representation.

And so on.

In short, GRASS modules are designed for use by local users who
already have shell access, so there hasn’t been any need to program
defensively. The OS prevents people from e.g. reading or writing files
which they aren’t supposed to.

–
Glynn Clements <glynn@gclements.plus.com>

grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

28

On Mon, Mar 10, 2014 at 11:04 PM, epi <massimodisasha@gmail.com> wrote:

Vaclav,

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.

Develop the sanitizer on the web-ui code and do not touch the g.parser
source code.

The sanitizer code will following the guidelines found at the page
[thanks] you pointed :
“Complete Structure Members Table”

but extending the restrictions to what Glynn suggested :
size constraint, alphanumeric characters, maximum number of items in a
list and more.

this restriction will be true for the web-ui but not for the desktop gui
hence the need to leave untouched the grass command line parser code.

does this make sense for you ?

Yes, it does. For example, if module accepts parameter of type string,

parser checks nothing in this case. However, web UI (1) should have the
information (obtained from `--interface-description` XML) that it is a
string and restrict the string to 255 characters (just an example).

(1) Actually, both the web GUI and something which is behind it on server
side should have this check. In GUI, you want to tell the user that the
input is invalid before sending the data for processing but also once data
are at the server they should be checked again for case that somebody is
not using the GUI but just sending the data to server side of the
application (in order to bypass the GUI check). The web development
framework may (or may not) solve these two steps for you at once.

Vaclav

Massimo.

On Mar 10, 2014, at 10:32 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:

On Mon, Mar 10, 2014 at 10:19 PM, epi <massimodisasha@gmail.com> wrote:

Glynn,

I understood the risk and I agree in toto with you.
For the web-ui interface we can define the rules for each kind of entry
and publish the rules/restriction on a help page .
Then when an invalid input exception is raised the ui will point the user
to read the rules page.

This is what GRASS parser system [1] is trying to define, so you

should/need to use it for that. However, it might not be sufficient (1). In
this case, you should not try to workaround it but suggest and improvement
for GRASS parser instead.

(1) E.g. standard options [2] are defined in the library and modules are
using them but they are not visible in the interface (since they are
translated to more basic types), so some information is lost.

[1] http://grass.osgeo.org/programming7/gislib_cmdline_parsing.html
[2] http://grass.osgeo.org/programming7/parser__standard__options_8c.html

Massimo.

On Mar 10, 2014, at 12:02 PM, Glynn Clements <glynn@gclements.plus.com>
wrote:

>
> epi wrote:
>
>> I guess the code behind the web-ui has to sanitize each text entry,
>> will be this enough ?
>>
>> A "sanitize inspection" on all the �input� coming from the web-ui
>> can be performed and this will be part of the UI itself, not of the
>> grass modules. with the aim to avoid people doing something like ..
>> http://xkcd.com/327/ :wink:
>
> That's the main thing.
>
> If you allow the user to e.g. provide names for maps, such names
> should be limited to alphanumeric characters and limited to a
> reasonable length.
>
> If you allow the user to provide a list of inputs, limit both the
> maximum number of items and the total length of the resulting textual
> representation.
>
> And so on.
>
> In short, GRASS modules are designed for use by local users who
> already have shell access, so there hasn't been any need to program
> defensively. The OS prevents people from e.g. reading or writing files
> which they aren't supposed to.
>
> --
> Glynn Clements <glynn@gclements.plus.com>

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

29

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 :slight_smile: 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.

? 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.

--

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. :slight_smile:

regards,
Hamish

30

That’s how we’d like to design the gui modules, using g.parser to generate the module descriptions and then use this information to generate the code to render each module. i Guess wx gui works this way.
PyQt does something similar with .ui files generated in designer. In our case the .ui is the module description and is generated by g.parser.

I can see your idea of having the gui code to do a first check when the module is filled on the client and a second check server side when the instruction is received. thanks to share it.
Essentially any command string received by the server will be parsed and checked for the validity of each entry (in regards of the module being executed) .
This make perfectly sense to me.

Massimo.

···

On Mon, Mar 10, 2014 at 11:04 PM, epi <massimodisasha@gmail.com> wrote:

Vaclav,

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.

Develop the sanitizer on the web-ui code and do not touch the g.parser source code.

The sanitizer code will following the guidelines found at the page [thanks] you pointed :
“Complete Structure Members Table”

but extending the restrictions to what Glynn suggested :
size constraint, alphanumeric characters, maximum number of items in a list and more.

this restriction will be true for the web-ui but not for the desktop gui
hence the need to leave untouched the grass command line parser code.

does this make sense for you ?

Yes, it does. For example, if module accepts parameter of type string, parser checks nothing in this case. However, web UI (1) should have the information (obtained from --interface-description XML) that it is a string and restrict the string to 255 characters (just an example).

(1) Actually, both the web GUI and something which is behind it on server side should have this check. In GUI, you want to tell the user that the input is invalid before sending the data for processing but also once data are at the server they should be checked again for case that somebody is not using the GUI but just sending the data to server side of the application (in order to bypass the GUI check). The web development framework may (or may not) solve these two steps for you at once.

Vaclav

Massimo.

On Mar 10, 2014, at 10:32 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:

On Mon, Mar 10, 2014 at 10:19 PM, epi <massimodisasha@gmail.com> wrote:

Glynn,

I understood the risk and I agree in toto with you.
For the web-ui interface we can define the rules for each kind of entry
and publish the rules/restriction on a help page .
Then when an invalid input exception is raised the ui will point the user to read the rules page.

This is what GRASS parser system [1] is trying to define, so you should/need to use it for that. However, it might not be sufficient (1). In this case, you should not try to workaround it but suggest and improvement for GRASS parser instead.

(1) E.g. standard options [2] are defined in the library and modules are using them but they are not visible in the interface (since they are translated to more basic types), so some information is lost.

[1] http://grass.osgeo.org/programming7/gislib_cmdline_parsing.html

[2] http://grass.osgeo.org/programming7/parser__standard__options_8c.html

Massimo.

On Mar 10, 2014, at 12:02 PM, Glynn Clements <glynn@gclements.plus.com> wrote:

epi wrote:

I guess the code behind the web-ui has to sanitize each text entry,
will be this enough ?

A “sanitize inspection” on all the �input� coming from the web-ui
can be performed and this will be part of the UI itself, not of the
grass modules. with the aim to avoid people doing something like …
http://xkcd.com/327/ :wink:

That’s the main thing.

If you allow the user to e.g. provide names for maps, such names
should be limited to alphanumeric characters and limited to a
reasonable length.

If you allow the user to provide a list of inputs, limit both the
maximum number of items and the total length of the resulting textual
representation.

And so on.

In short, GRASS modules are designed for use by local users who
already have shell access, so there hasn’t been any need to program
defensively. The OS prevents people from e.g. reading or writing files
which they aren’t supposed to.

–
Glynn Clements <glynn@gclements.plus.com>

grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

31

On Mar 11, 2014, at 12:36 AM, Hamish <hamish_b@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 :slight_smile: 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. :slight_smile:

regards,
Hamish

32

googling i found the ulimit should take care of memory usage :

https://unix.stackexchange.com/questions/34334/how-to-create-a-user-with-limited-ram-usage

http://ss64.com/bash/ulimit.html

On Mar 11, 2014, at 1:20 AM, epi <massimodisasha@gmail.com> wrote:

On Mar 11, 2014, at 12:36 AM, Hamish <hamish_b@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 :slight_smile: 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. :slight_smile:

regards,
Hamish

33

Hamish wrote:

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.

Memory limits can be enforced by setrlimit(), via the "ulimit" shell
command or the pam_limits module.

However, you can't set cumulative limits[1]. You can limit the memory
usage of an invidivual process, and limit the total number of
processes for a single user (UID), but you can't set a cumulative
limit below the product of the maximum number of processes times the
maximum memory per process.

Disk usage can be restricted by using quotas or by creating a separate
filesytem (e.g. on a loop device) for each account.

CPU usage can be restricted on a per-process basis via setrlimit()
etc. Again, there's no way to set a cumulative limit. Also, "nice" can
be used to de-prioritise processes so that more important processes
aren't pre-empted.

[1] On Linux, control groups (cgroups) can be used to "partition"
system resources. Virtual machines are another potential solution,
albeit a rather heavy-weight one.

--
Glynn Clements <glynn@gclements.plus.com>

34

Hi Rashad and Massimo,

can you please summarize the basic ideas at:

https://trac.osgeo.org/grass/wiki/GSoC/2014#Web-basedGUIforGRASSGIS

···

?

35

Hi Vaclav,

Sure. Will update the ideas page today.

···

On Wed, Mar 12, 2014 at 3:45 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:

Hi Rashad and Massimo,

can you please summarize the basic ideas at:

https://trac.osgeo.org/grass/wiki/GSoC/2014#Web-basedGUIforGRASSGIS

–

Regards,
Rashad

?