Security updates question

Security updates question

[Brian Smucker]

Hello all,

We have a device whose image is built using an older yocto image. It is 
based on yocto Danny, if I recall correctly.

How do users of yocto handle the need occasionally to update one or more 
component packages to deal with security vulnerabilities?

I am not a yocto expert and I was hoping there would be a clear way 
forward here.

Migrating all our recipes to the latest version of yocto probably should 
be done, but it would involve weeks of pain. I know, I started to do it 
sometime back.

So that is one option, but a very unattractive one at the moment.

When we jumped into using Yocto, I was hoping that there would be a 
clear answer to this, but I have been frustrated. Perhaps there is a 
clear answer, but it's outside of what I know.

What are my options and the tradeoffs of each?

Thanks

Brian

Re: Security updates question

[Khem Raj]

Hi Brian

On Fri, Sep 7, 2018 at 1:25 PM Brian Smucker <bds@bsmucker.eu.org> wrote:
>
> Hello all,
>
> We have a device whose image is built using an older yocto image. It is
> based on yocto Danny, if I recall correctly.
>
> How do users of yocto handle the need occasionally to update one or more
> component packages to deal with security vulnerabilities?
>
> I am not a yocto expert and I was hoping there would be a clear way
> forward here.
>
> Migrating all our recipes to the latest version of yocto probably should
> be done, but it would involve weeks of pain. I know, I started to do it
> sometime back.
>
> So that is one option, but a very unattractive one at the moment.
>
> When we jumped into using Yocto, I was hoping that there would be a
> clear answer to this, but I have been frustrated. Perhaps there is a
> clear answer, but it's outside of what I know.
>
> What are my options and the tradeoffs of each?

yocto project provided infra to build distributions. so you would have
either built your own distribution or procured it from someone else e.g.
OSVs, if its third party the they generally have security update schedules
that you can work with.

If you build your own distro then you have freedom to make changes
and patch the security vulnerability and deploy it.
community maintains releases for quite some time and you can just
cherry-pick the point releases which primarily get security fixes.
danny is an old release and is not currently supported in community

https://wiki.yoctoproject.org/wiki/Releases

so you can still check if needed fixes are there in danny and build it.
you can also work with some OE/yocto consultants to get this done
for danny

There are also binary feed based distributions like angstrom which can
provide prebuilt packages ( ipks) but they also have support schedule
and I am sure for angstrom danny based feeds are not updated.

Thanks
-Khem


>
> Thanks
>
> Brian
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: Security updates question

[Jon Szymaniak]

[-- Attachment #1: Type: text/plain, Size: 5619 bytes --]

Hi Brian,

On Fri, Sep 7, 2018 at 3:36 PM Khem Raj <raj.khem@gmail.com> wrote:

> Hi Brian
>
> On Fri, Sep 7, 2018 at 1:25 PM Brian Smucker <bds@bsmucker.eu.org> wrote:
> >
> > Hello all,
> >
> > We have a device whose image is built using an older yocto image. It is
> > based on yocto Danny, if I recall correctly.
> >
> > How do users of yocto handle the need occasionally to update one or more
> > component packages to deal with security vulnerabilities?
> >
> > I am not a yocto expert and I was hoping there would be a clear way
> > forward here.
> >
> > Migrating all our recipes to the latest version of yocto probably should
> > be done, but it would involve weeks of pain. I know, I started to do it
> > sometime back.
> >
> > So that is one option, but a very unattractive one at the moment.
> >
> > When we jumped into using Yocto, I was hoping that there would be a
> > clear answer to this, but I have been frustrated. Perhaps there is a
> > clear answer, but it's outside of what I know.
> >
> > What are my options and the tradeoffs of each?
>
> yocto project provided infra to build distributions. so you would have
> either built your own distribution or procured it from someone else e.g.
> OSVs, if its third party the they generally have security update schedules
> that you can work with.
>
> If you build your own distro then you have freedom to make changes
> and patch the security vulnerability and deploy it.
> community maintains releases for quite some time and you can just
> cherry-pick the point releases which primarily get security fixes.
> danny is an old release and is not currently supported in community
>
> https://wiki.yoctoproject.org/wiki/Releases
>
> so you can still check if needed fixes are there in danny and build it.
> you can also work with some OE/yocto consultants to get this done
> for danny
>
> There are also binary feed based distributions like angstrom which can
> provide prebuilt packages ( ipks) but they also have support schedule
> and I am sure for angstrom danny based feeds are not updated.
>
> Thanks
> -Khem
>

To further expand on Khem's thoughts -- you can find some system update
options compared/contrasted here:

https://wiki.yoctoproject.org/wiki/System_Update

In general, if you track changes made to a supported release branch, the
commit logs tend to make it quite clear which changesets are addressing one
or more CVEs.  The Build History feature [1] can help you make sense of
everything that's in your image, and the cve-check BitBake class [2] can
help supplement whatever processes you use to track relevant CVEs.

[1]
https://www.yoctoproject.org/docs/2.5.1/dev-manual/dev-manual.html#maintaining-build-output-quality
[2]
https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/classes/cve-check.bbclass

If you’re designing your own update mechanism, or even evaluating some
options, there are plenty of important factors to consider. Each of these
may involve a number of critical design decisions, which must consider the
constraints, operating
environment, and needs of your specific product.

For example, a mechanism supporting over-the-air updates to a fleet of
maritime vessels over a low-data-rate wireless connection will likely
differ from one that is intended for IoT devices in the home.

Just a few important factors to consider include:

- Authenticity: How do you ensure that someone has not maliciously tampered
with an update? Typically, this is implemented using a digital signature
computed using an asymmetric cryptographic algorithm. This signature must
be verified prior to parsing or otherwise processing the contents of an
update. Devices would need to have a priori knowledge of the public portion
of the signing key, or that of a certificate authority that will have
signed any newly supplied signing certificates. I’m certainly biased, but
strongly believe that this is the sort of thing you’ll want to have
reviewed by a third party, as there are plenty of potential pitfalls.

- Rollback Protection: How can you prevent an attacker from reverting a
device to an earlier, vulnerable state? If you have a  business case for
allowing customers to downgrade firmware, is it possible to maintain a
whitelisted set of downgrade options?

- Fault Tolerance: What happens if a failure (e.g. loss of power) occurs
during an update?  How can the system detect whether or not an update has
been successfully applied, and recover from a failure?  For devices with
ample storage media, a popular option seems to be an A/B partition layout,
in which an inactive system partition is updated and then switched to on
reboot, after the update is determined to have been applied successfully.
Any ability to track repeated boot failures could be leveraged to boot a
recovery image, which of course should enforce the authenticity & rollback
restrictions outlined above.

While I certainly understand your frustration, I think one thing to
recognize is how challenging of a task it would be to have a
one-size-fits-all solution maintained by the Yocto Project.  Instead, it
seems more practical (to me) to look toward application-domain specific
projects like https://mender.io, which themselves use Yocto-built images.
(Granted, I haven't really looked into Mender much -- so take this note
with a healthy does of skepticism.)

I realize I probably just gave you more questions than answers... but
hopefully in my rambling I've provided at lease some useful food for
thought.

Best regards,
Jon

[-- Attachment #2: Type: text/html, Size: 7109 bytes --]

Re: Security updates question

[Jon Szymaniak]

[-- Attachment #1: Type: text/plain, Size: 2632 bytes --]

Hi Brian,

On Sat, Sep 8, 2018 at 6:20 PM Brian Smucker <bds@bsmucker.eu.org> wrote:

> Jon,
>
> I do appreciate your insights and I am aware of some of the update
> mechanisms that are out there. At the moment we don't have a need for
> that. The need at this time is a totally new image, identical to the
> working image we have been using, except with an updated web server
> package. For the present we will use our manual update mechanism to
> update select devices  on an as-needed basis.
>
> So I am not implying by my question that I think that Yocto should have
> a way to do that kind of updating. I agree that it is out of the scope
> of the Yocto build system. And the update mechanism itself was in no
> case what prompted the question in the first place.
>
> The question was: How do people/companies deal with the problem of
> needing a new version of an existing package in a working image based on
> an old version of Yocto?
>
> Thanks again for your reply.
>
> Brian
>
>
My sincere apologies for completely misunderstanding your question.  I've
CC'd the mailing list in this response, just in an attempt to help steer
further discussion back on course, after I wandered off. :)

Here's my attempt at more useful questions and comments, at least.

1) How have the maintainers of the upstream software in question resolved
the vulnerability?
  1a) Is there a single patch, or a manageable number of patches, that you
could apply to address the vulnerability? If so, perhaps you could use a
.bbappend file [1] in your layer to append patches to SRC_URI.
  1b) Take a look at how patches are backported in release branches (e.g.
[2]) for some inspiration.

2) In the case where the version you're on does not have an easily applied
patch available, is it possible to simply pull in a recipe from a newer
version of Yocto into your own layer(s)?
  2a) Depending on the software, this might lead you down a dependency
rabbit hole, and might not be viable.
  2b) If this is possible, I wonder if it would be sane to maintain your
own layer of updated recipes you're transitioning to, as not to clutter
whatever layer(s) you use for your organization. Ideally, once you reach a
point where you could fully switch to a newer Yocto release, you could just
drop this temporary layer from your bblayers.conf and track a maintained
release.

[1]
https://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#using-bbappend-files
[2]
https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=rocko&id=b33d89d5ea8604657a59b83a30c3374079c34fd2

Best regards,
Jon

[-- Attachment #2: Type: text/html, Size: 3440 bytes --]