Configuration Format

[Soft]

Today, Nitro's back ends rely on libvmi configuration files being present. The configuration file paths are not specified explicitly but instead the config file is found by checking a list of predetermined locations dictated by libvmi's code base. I think there are certain problems with this approach.

First of, if you think Nitro as a library, it can lead to surprising results. Whether or not your Nitro-based application will work depends on some external config files being present in the file system. For a library, I think it makes more sense to be programmatically configurable. Maybe we could allow passing the libvmi configuration as a dictionary to the Nitro object or something. The libvmi API's allow this we just do not make use of them currently.

Second, for Nitro as an command line application, I think having the user to create a config file, not for Nitro but one of Nitro's dependencies is maybe not the most user friendly thing. Basically, we are extending Nitro's user interface to some of our (somewhat internal) dependencies. Maybe this is mostly a cosmetic thing since we would still require the same information. Additionally, I think it would be nice if the command line application allowed specifying the configuration file to be used explicitly (a --conf argument or something). I think having this around would create less confusion about which config file is used.

Third, we currently do not have nice way for configuring back ends in general. The back end factory automatically initializes back end objects. I think it would be nice if it could pass them some arbitrary back end dependent configuration data. For example, back ends could use these custom initialization parameters to disable some of the extractors.

So what I am proposing is:

1. Make Nitro not use libvmi's global configuration files. Have back end factory provide programmatic interface for libvmi's initialization. This could be something as simple as having get_backend take another dict that contained the data required by libvmi.
2. Make the command line interface support specifying a Nitro specific config file. Data-wise, this config file could be superset of libvmi's configuration. It would include all the data required by libvmi + some additional back end dependent configuration. I think having the ability to configure back ends for specific use cases would make them more flexible and lessen the need to find the right balance on what to extract.

I think this would not be huge change nor that much work. What do you think? Should I implement something like this?