where to store application json

[William Kennington]

I think it's pretty straightforward, immutable data is stored in
/etc/<appname> and mutable data in /var/lib/<appname>

On Tue, Aug 20, 2019 at 8:23 AM Andrew Geissler <geissonator at gmail.com> wrote:
>
> 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
> > >
> >