where to store application json

where to store application json

[Andrew Geissler]

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?

Adriana pointed me to the FSH guidelines[1] in a review which has the following:
"It is recommended that files be stored in subdirectories of /etc rather than
directly in /etc.".

/etc/opt ?
/etc/opt/phosphor/ ?
/etc/opt/phosphor/<repository name>/ ?

Our use of /var/lib/ for persistent data uses a /var/lib/<repository name>
type directory syntax so staying consistent with that seems to make sense
leading me to think /etc/opt/<repository name>/ would be our best bet.

Thoughts?
Andrew

[1]: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s07.html

Re: where to store application json

[Andrew Jeffery]

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?
> 
> Adriana pointed me to the FSH guidelines[1] in a review which has the following:
> "It is recommended that files be stored in subdirectories of /etc rather than
> directly in /etc.".
> 
> /etc/opt ?
> /etc/opt/phosphor/ ?
> /etc/opt/phosphor/<repository name>/ ?

Where did the "/opt/" bit come from? Please lets drop that.

IMO we should be using /etc/<application name>. Be mindful that one repository
can produce multiple applications, but what application sits in which repository
is a code organisation problem and not something that we should tie into system
configuration.

Andrew

Re: where to store application json

[Matt Spinler]

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?



>> ?
>>
>> Adriana pointed me to the FSH guidelines[1] in a review which has the following:
>> "It is recommended that files be stored in subdirectories of /etc rather than
>> directly in /etc.".
>>
>> /etc/opt ?
>> /etc/opt/phosphor/ ?
>> /etc/opt/phosphor/<repository name>/ ?
> Where did the "/opt/" bit come from? Please lets drop that.
>
> IMO we should be using /etc/<application name>. Be mindful that one repository
> can produce multiple applications, but what application sits in which repository
> is a code organisation problem and not something that we should tie into system
> configuration.
>
> Andrew

Re: where to store application json

[Patrick Venture]

On Fri, Aug 16, 2019 at 6:33 AM Matt Spinler <mspinler@linux.ibm.com> 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?
>
>
>
> >> ?
> >>
> >> Adriana pointed me to the FSH guidelines[1] in a review which has the following:
> >> "It is recommended that files be stored in subdirectories of /etc rather than
> >> directly in /etc.".
> >>
> >> /etc/opt ?
> >> /etc/opt/phosphor/ ?
> >> /etc/opt/phosphor/<repository name>/ ?
> > Where did the "/opt/" bit come from? Please lets drop that.
> >
> > IMO we should be using /etc/<application name>. Be mindful that one repository
> > can produce multiple applications, but what application sits in which repository
> > is a code organisation problem and not something that we should tie into system
> > configuration.
> >
> > Andrew

A lot of stuff is in /usr/share -- but I think /etc is a reasonable place too.

>

Re: where to store application json

[Joseph Reynolds]

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.

My 2 cents,
- Joseph

>
>
>>> ?
>>>
>>> Adriana pointed me to the FSH guidelines[1] in a review which has 
>>> the following:
>>> "It is recommended that files be stored in subdirectories of /etc 
>>> rather than
>>> directly in /etc.".
>>>
>>> /etc/opt ?
>>> /etc/opt/phosphor/ ?
>>> /etc/opt/phosphor/<repository name>/ ?
>> Where did the "/opt/" bit come from? Please lets drop that.
>>
>> IMO we should be using /etc/<application name>. Be mindful that one 
>> repository
>> can produce multiple applications, but what application sits in which 
>> repository
>> is a code organisation problem and not something that we should tie 
>> into system
>> configuration.
>>
>> Andrew
>

Re: 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

Re: 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
>

Re: 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@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
> >
>

Re: 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@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@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
> > >
> >