where to store application json

[Andrew Geissler]

Thanks for all the good discussion. It seems like in summary the
consensus is what
Andrew Jeffery proposed:

/etc/<application name>/

There are security concerns with this but there are a lot of files in /etc/
that could cause security concerns if people get the correct access
to modify them. For my use case, the json is simply something that
tells the application when to log errors. If people find they need data
files which could have significant security concerns, they may want
to revisit the location for their config file.

Andrew

On Mon, Aug 19, 2019 at 12:15 PM Joseph Reynolds <jrey at linux.ibm.com> wrote:
>
>
> 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
> >
>