where to store application json

[Joseph Reynolds]

On 8/18/19 7:15 PM, Andrew Jeffery wrote:
>
> On Sat, 17 Aug 2019, at 02:24, Joseph Reynolds wrote:
>> On 8/16/19 8:31 AM, Matt Spinler wrote:
>>> On 8/15/2019 6:59 PM, Andrew Jeffery wrote:
>>>> On Fri, 16 Aug 2019, at 07:01, Andrew Geissler wrote:
>>>>> As we start moving more and more of our applications to using
>>>>> runtime parsed
>>>>> json files, it seems like a good time to come up with a standard
>>>>> location to put
>>>>> the json files. I think a requirement is they be in a writeable
>>>>> filesystem
>>>>> (although that may bring security concerns) so that you can edit and
>>>>> restart
>>>>> services that use them on the fly for bringup and debug.
>>>>>
>>>>> /etc seems like the right spot. But if so, where in /etc
>>> While convenient to the developer for testing, to me it doesn't sound
>>> like good practice to put read
>>> only, critical files into a writeable spot?  How could we even trust
>>> data that comes back to us from
>>> the field when a user that can get into their BMC can just change
>>> these?  Or accidentally
>>> delete a file?
>>>
>> One security concern is that config files offer a good way for hackers
>> to get persistent access to the system.  That is, if they are able to
>> get root access to the BMC one time, they may be able to persist their
>> hack across BMC reboots by modifying some config files.  IMHO, to make
>> it harder for them, as much as possible of the file system should be
>> read-only, and read-write config files should not offer the above
>> mentioned service to hackers.
> What are some concrete examples of what you're concerned about here?

I was thinking about config files that specify which plugins to load, 
for example, by absolute pathname.  In this scenario, the hacker would 
write a plugin, and the first time they compromise the BMC, they copy 
the plugin to the BMC's file system, and modify the config file to 
active it.  In this way, their code re-activates even if they lose access.

>
> Are you suggesting hackers are exploiting flaws in the config file parsers?
> Because in that case we should just fix the parsers. Or perhaps configuring
> the system in an unsafe way?

No, but that's a good point.  We can begin to address those 
vulnerabilities with static and dynamic code scans and config file 
fuzzing, and with good design and documentation about config files.

>
> Anyway, having any writable storage provides a place to drop payloads
> and generally wreak havoc, but having an unconfigurable BMC is not a
> direction I think we should go, it seems pretty restrictive. We do need
> to be careful about how we treat the content though, as it can't really
> be authenticated.

Agreed.

>
> Andrew
>