Feedback request: ssconf

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Feedback request: ssconf

Erik Hetzner
Hi,

I have put together a small library for runtime configuration of scala
programs. It offers the following features:

* type safety: e.g., if a config value expects an int, one cannot pass
  in a string
* flexibility: config files are written in scala, so they can utilize
  any scala concepts
* defaults: specify default values
* write-once: config values can be set only once
* dependencies: config values can use other config values to set their
  own values

The project page is located at:

  https://bitbucket.org/egh/ssconf

It uses the scala compiler to read & process configuration files,
which look like:

  configVal := 10
  anotherConfigVal := configVal + 1
  arrayVal := Array("hello", "world")
  mapVal := Map("hello" -> "world")
  objVal := new ComplexObject(1, 2, 3)

I am looking for feedback, especially regarding the config file
format. Because the config files are valid scala, we are both free to
do many things and constrained at the same time. I think that the
method I have come up works well, but I am curious what others think.

I am already using this library for a number of my projects where I
need runtime configuration of values, e.g. server names, number of
threads to use, etc. I am finding it easier to use than java
properties or other ad-hoc configuration systems. I hope you will also
find it useful.

best, Erik Hetzner
Reply | Threaded
Open this post in threaded view
|

Re: Feedback request: ssconf

Justin du coeur
Hmm.  The idea's quite neat, but the word that immediately springs to my mind is "security".  This being a library, it's intended to be used widely, probably sometimes naively, and I suspect that many programmers aren't going to think carefully enough about the risks of having a runtime-modifiable code file that the program depends upon.

(The runtime-modifiable is the key thing here.  It being a config file, it's *intended* to be writeable on disc.  That puts a big bullseye on the file for hacking.  Might not be a problem, but I wouldn't take the question lightly.)

All of this can probably be addressed (and I confess, I haven't read the library itself to see whether you're already tackling this), but it's the main thing I'd worry about.  This code needs to be carefully sandboxed, or the library needs some careful thought and documentation about the security implications...

On Tue, Dec 21, 2010 at 9:20 PM, Erik Hetzner <[hidden email]> wrote:
Hi,

I have put together a small library for runtime configuration of scala
programs. It offers the following features:

* type safety: e.g., if a config value expects an int, one cannot pass
 in a string
* flexibility: config files are written in scala, so they can utilize
 any scala concepts
* defaults: specify default values
* write-once: config values can be set only once
* dependencies: config values can use other config values to set their
 own values

The project page is located at:

 https://bitbucket.org/egh/ssconf

It uses the scala compiler to read & process configuration files,
which look like:

 configVal := 10
 anotherConfigVal := configVal + 1
 arrayVal := Array("hello", "world")
 mapVal := Map("hello" -> "world")
 objVal := new ComplexObject(1, 2, 3)

I am looking for feedback, especially regarding the config file
format. Because the config files are valid scala, we are both free to
do many things and constrained at the same time. I think that the
method I have come up works well, but I am curious what others think.

I am already using this library for a number of my projects where I
need runtime configuration of values, e.g. server names, number of
threads to use, etc. I am finding it easier to use than java
properties or other ad-hoc configuration systems. I hope you will also
find it useful.

best, Erik Hetzner

Reply | Threaded
Open this post in threaded view
|

Re: Feedback request: ssconf

Jim Balter-2
Someone who can edit a disk file can generally also compile and run
it, so there's no security problem with disk files per se. The problem
comes about when the program reading and processing (and compiling)
the config file is more privileged than the level of write access to
the config file. So, for instance, a program running with
administrator privilege should check that the config file is not
writable by non-administrators. For non-executable config files, a
program only has to be well-behaved for all possible values of all
config variables ... which still leaves plenty of room for security
violations, but not nearly as much as when the config file is an
arbitrary Turing Machine. (And, since Scala isn't a pure functional
language, I don't see how the execution of the config file could be
securely sandboxed.)

So, indeed, the documentation should stress that arbitrary code from
the config file will be executed by the library and so the programmer
should exercise care if the program can run with elevated privilege,
but generally this could be a very handy facility.


On Tue, Dec 21, 2010 at 6:43 PM, Justin du coeur <[hidden email]> wrote:

> Hmm.  The idea's quite neat, but the word that immediately springs to my
> mind is "security".  This being a library, it's intended to be used widely,
> probably sometimes naively, and I suspect that many programmers aren't going
> to think carefully enough about the risks of having a runtime-modifiable
> code file that the program depends upon.
> (The runtime-modifiable is the key thing here.  It being a config file, it's
> *intended* to be writeable on disc.  That puts a big bullseye on the file
> for hacking.  Might not be a problem, but I wouldn't take the question
> lightly.)
>
> All of this can probably be addressed (and I confess, I haven't read the
> library itself to see whether you're already tackling this), but it's the
> main thing I'd worry about.  This code needs to be carefully sandboxed, or
> the library needs some careful thought and documentation about the security
> implications...
>
> On Tue, Dec 21, 2010 at 9:20 PM, Erik Hetzner <[hidden email]> wrote:
>>
>> Hi,
>>
>> I have put together a small library for runtime configuration of scala
>> programs. It offers the following features:
>>
>> * type safety: e.g., if a config value expects an int, one cannot pass
>>  in a string
>> * flexibility: config files are written in scala, so they can utilize
>>  any scala concepts
>> * defaults: specify default values
>> * write-once: config values can be set only once
>> * dependencies: config values can use other config values to set their
>>  own values
>>
>> The project page is located at:
>>
>>  https://bitbucket.org/egh/ssconf
>>
>> It uses the scala compiler to read & process configuration files,
>> which look like:
>>
>>  configVal := 10
>>  anotherConfigVal := configVal + 1
>>  arrayVal := Array("hello", "world")
>>  mapVal := Map("hello" -> "world")
>>  objVal := new ComplexObject(1, 2, 3)
>>
>> I am looking for feedback, especially regarding the config file
>> format. Because the config files are valid scala, we are both free to
>> do many things and constrained at the same time. I think that the
>> method I have come up works well, but I am curious what others think.
>>
>> I am already using this library for a number of my projects where I
>> need runtime configuration of values, e.g. server names, number of
>> threads to use, etc. I am finding it easier to use than java
>> properties or other ad-hoc configuration systems. I hope you will also
>> find it useful.
>>
>> best, Erik Hetzner
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Feedback request: ssconf

Erik Hetzner
At Tue, 21 Dec 2010 20:09:14 -0800,
Jim Balter wrote:

>
> Someone who can edit a disk file can generally also compile and run
> it, so there's no security problem with disk files per se. The problem
> comes about when the program reading and processing (and compiling)
> the config file is more privileged than the level of write access to
> the config file. So, for instance, a program running with
> administrator privilege should check that the config file is not
> writable by non-administrators. For non-executable config files, a
> program only has to be well-behaved for all possible values of all
> config variables ... which still leaves plenty of room for security
> violations, but not nearly as much as when the config file is an
> arbitrary Turing Machine. (And, since Scala isn't a pure functional
> language, I don't see how the execution of the config file could be
> securely sandboxed.)
>
> So, indeed, the documentation should stress that arbitrary code from
> the config file will be executed by the library and so the programmer
> should exercise care if the program can run with elevated privilege,
> but generally this could be a very handy facility.

Hi,

Thanks to both of you for pointing this out. I have modified the
README file to note that a config file can execute arbitrary code.

While in many ways I consider this more of a feature than a bug, it
should certainly be stressed to users that they should not consider
their config files safe for modification by a different user than the
one who runs the executable.

best, Erik