[yocto] Security updates question

[Jon Szymaniak]

Hi Brian,

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

> Hi Brian
>
> On Fri, Sep 7, 2018 at 1:25 PM Brian Smucker <bds at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20180908/b1d5acb0/attachment.html>