[cip-dev] Maintenance policies and early considerations III

[cip-dev] Maintenance policies and early considerations III

[Agustin Benito Bethencourt]

Hi,

the below considerations were discussed during the Members meeting. 
There is no conclusion yet about how to proceed.

++ Security fixes

+++ Out-of-tree drivers

The embedded systems that CIP will be used in will also often require 
out-of-tree drivers and will sometimes include other changes of unknown 
quality to their kernel.  It needs to be made clear to members that 
these modifications are unsupported, and that when they want the CIP 
core team to address a bug found in such a modified kernel they must 
first demonstrate that it exists in the CIP source release.

+++ Security updates

Commercial Linux based distributions like RHEL/SLE typically has 
security updates available for the most serious issues (such as 
privilege escalation) within a few days of them being publicly known, if 
not on the first day.

CIP may be able to achieve this with its source releases but its members 
may take much longer to release and deploy binary updates, maybe due to 
valid concerns about the risk of regression or limited opportunities to 
deploy updates.   In the worst case, they may use CIP as an 
advertising/compliance point but rarely bother to update.  For this 
reason Ben H. thinks it's important to draw on the work of the Kernel 
Self-Protection Project to add mitigations against common types of 
vulnerability.  That work is slowly filtering into mainline and at least 
some of it could be backported.

+++ Request to members from maintainer

During the meeting Ben requested CIP members to provide him some 
guidelines or policies currently followed to choose security patches. 
This information will hopefully provide some light that help maintainers 
to define some basic policies for choosing security fixes. This policies 
need to be tested over time.

Due to the length of the maintenance period, it is unlikely that the 
same person/team maintain the kernel for the entire life cycle so the 
main policies at least need to be left written.

Best Regards
-- 
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito at codethink.co.uk

[cip-dev] Maintenance policies and early considerations III

[Daniel Sangorrin]

Hi Agustin,

Sorry for the late reply.

> +++ Request to members from maintainer
> 
> During the meeting Ben requested CIP members to provide him some
> guidelines or policies currently followed to choose security patches.
> This information will hopefully provide some light that help maintainers
> to define some basic policies for choosing security fixes. This policies
> need to be tested over time.
> 
> Due to the length of the maintenance period, it is unlikely that the
> same person/team maintain the kernel for the entire life cycle so the
> main policies at least need to be left written.

I think that one possible guideline for backporting security patches to the CIP kernel
is to look at kernel CVEs [1]. A table (probably only accessible by members) 
indicating whether a CIP kernel is vulnerable or not to a CVE would be of great help.

Another source of bug/security fixes will be the PREEMPT RT patch. We will probably
need to check whether bugs found in new versions are properly backported to our
CIP kernels. 
# I see that Ben is already doing this! [2]

Finally, we may need to decide how to disclosure bugs that we may find ourselves 
while testing the CIP kernels. I guess we will need to make sure that all members are
ready for the disclosure.

Best regards
Daniel

[1] http://www.cvedetails.com/product/47/Linux-Linux-Kernel.html?vendor_id=33
[2] https://lkml.org/lkml/2016/9/29/473

[cip-dev] Maintenance policies and early considerations III

[Hidehiro Kawai]

Hi,

(2016/09/22 21:56), Agustin Benito Bethencourt wrote:
> Hi,
> 
> the below considerations were discussed during the Members meeting. 
> There is no conclusion yet about how to proceed.
> 
> ++ Security fixes
> 
> +++ Out-of-tree drivers
> 
> The embedded systems that CIP will be used in will also often require 
> out-of-tree drivers and will sometimes include other changes of unknown 
> quality to their kernel.  It needs to be made clear to members that 
> these modifications are unsupported, and that when they want the CIP 
> core team to address a bug found in such a modified kernel they must 
> first demonstrate that it exists in the CIP source release.

I agree on that.  CIP don't need to care about out-of-tree drivers.

> +++ Security updates
> 
> Commercial Linux based distributions like RHEL/SLE typically has 
> security updates available for the most serious issues (such as 
> privilege escalation) within a few days of them being publicly known, if 
> not on the first day.
> 
> CIP may be able to achieve this with its source releases but its members 
> may take much longer to release and deploy binary updates, maybe due to 
> valid concerns about the risk of regression or limited opportunities to 
> deploy updates.   In the worst case, they may use CIP as an 
> advertising/compliance point but rarely bother to update.  For this 
> reason Ben H. thinks it's important to draw on the work of the Kernel 
> Self-Protection Project to add mitigations against common types of 
> vulnerability.  That work is slowly filtering into mainline and at least 
> some of it could be backported.

I think it is important to prepare for zero-day attacks, and the Kernel
Self-Protection Project would help it.  If it could be backported,
doing it is preferred.  But does it make the long-term maintenance difficult?

> +++ Request to members from maintainer
> 
> During the meeting Ben requested CIP members to provide him some 
> guidelines or policies currently followed to choose security patches. 
> This information will hopefully provide some light that help maintainers 
> to define some basic policies for choosing security fixes. This policies 
> need to be tested over time.
> 
> Due to the length of the maintenance period, it is unlikely that the 
> same person/team maintain the kernel for the entire life cycle so the 
> main policies at least need to be left written.

Basically, I expect CIP supports all CVEs which are related to supported
features by CIP.  But human resources are limited, so CIP members might
need to prioritize them depending on their impact.

Best regards,

Hidehiro Kawai
Hitachi, Ltd. Research & Development Group