[Vm-dev] gitorious / smallharbour question

[Igor Stasenko]

On 16 August 2011 23:33, laurent laffont <laurent.laffont at gmail.com> wrote:
>
>
> On Tue, Aug 16, 2011 at 9:43 PM, Igor Stasenko <siguctua at gmail.com> wrote:
>>
>> On 16 August 2011 22:02, laurent laffont <laurent.laffont at gmail.com> wrote:
>> >
>> >>
>> >> >
>> >> > On Tue, Aug 16, 2011 at 6:46 PM, Igor Stasenko <siguctua at gmail.com> wrote:
>> >> >>
>> >> >> On 16 August 2011 16:42, laurent laffont <laurent.laffont at gmail.com> wrote:
>> >> >> >
>> >> >> > Hi,
>> >> >> >
>> >> >> > for SmallHarbour I've cloned cogvm/blessed and then add security patches from SeasideHosting. See
>> >> >> > - https://gitorious.org/~laurentlaffont/cogvm/smallharbour
>> >> >> > - https://gitorious.org/~laurentlaffont/cogvm/smallharbour/commit/7f45e401f8c805021e3ef06e110e3f079fe6ecc3
>> >> >> >
>> >> >> > What's the best way to stay synchronized with cogvm/blessed commits ?
>> >> >>
>> >> >> Fist you need to add blessed as remote repository:
>> >> >>
>> >> >> git remote add blessed git://gitorious.org/cogvm/blessed.git
>> >> >>
>> >> >> Then you can simply pull changes to your branch:
>> >> >>
>> >> >> git pull blessed
>> >> >>
>> >> >> and it will merge changes automatically. (of course if there's no conflicts).
>> >> >>
>> >> >> And then
>> >> >>
>> >> >> git push
>> >> >>
>> >> >> to push updates to your own repository.
>> >> >>
>> >> >> > Is it interesting to adapt this patch for integration in cogvm/blessed ?
>> >> >>
>> >> >> Absolutely. All contributions is welcome :)
>> >> >>
>> >> >> > Is this patch good ?
>> >> >> >
>> >> >>
>> >> >> I am a bit out of context. Where i can read a description of what you did?
>> >> >
>> >> >
>> >> >
>> >> > First the changes are quite small, originally made by Nestyle (I suppose) for SesideHosting.
>> >> > This introduce the use of environment variables to restrict filesystem and port access. For example we don't want the hosted image to be able to access /etc/passwd or another account files. We don't want that 2 images use the same port.
>> >> > So this patch read these environment variables:
>> >> > export SQUEAK_PORT_LO=16400
>> >> > export SQUEAK_PORT_HI=16407
>> >> > export SQUEAK_ROOT_DIR="/service/myaccount/files"
>> >> >
>> >> > so only port between 16400 and 16407 can be opened, only /service/myaccount/files can be read/written.
>> >> > Note that in the patch port 25 (SMTP) is always accessible.
>> >> > This is very specific to SeasideHosting/SmallHarbour, so I don't think the patch should be apply as it is now in cogvm/blessed, but having such functionalities in the VM would be nice IMO.
>> >> >
>> >> > The commit is here - quite easy to read: https://gitorious.org/~laurentlaffont/cogvm/smallharbour/commit/7f45e401f8c805021e3ef06e110e3f079fe6ecc3
>> >> > Laurent.
>> >> >
>> >>
>> >> Wait. First you asking if those can be integrated, and then you saying
>> >> that its too specific..
>> >> Do you mean that we should discuss/think about integrating a more
>> >> general form of this functionality?
>> >
>> >
>> > Yes. Sorry for confusion :)
>> > Laurent.
>> >
>> As to me an environment these settings is good enough. For unix-like
>> systems it is pretty fine.
>> But for windows, a more common is to use .ini file(s) and store settings there.
>
>
> What do you think about program arguments ?  Like this:
> ./cog -port-filter 25,16400:16407 -fs-root /var/images/public/
> on Windows
> cog -port-filter 25,16400:16407 -fs-root "C:\Images\Public\"
> with
> -port-filter 25,8080,8081 means "allow only 25, 8080 and 8081"
> -port-filter 8080:8090 means "allow ports from 8080 to 8090"
>

Personally i for putting security logic at language side rather than on VM side.
I think that as long as you passing and parsing parameters at image
side, you can use any form of them.

Unless there are reasons for controlling it explicitly at VM level (so
you can run arbitrary , presumably unknown image with it).

Also, i think that it is better to reconsider security scheme we're using.
Instead of putting everything into a single place (security plugin),
each plugin by own has to know its security rules/settings.
Because if you look how security plugin interacting with other
plugins, you will find it is not very nice.

Then at plugin initialization it may request VM to provide
command-line arguments and/or extract settings from other places.
Unfortunately, command-line arguments are not exposed by VM interface
(an OSProcess plugin, for instance using linking trick to get access
to them).
We should change that.


-- 
Best regards,
Igor Stasenko AKA sig.