where to store application json

[Andrew Jeffery]

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?

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?

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.

Andrew