[cip-dev] Package Proposal #1 (Security packages), rev03

[cip-dev] Package Proposal #1 (Security packages), rev03

[Kento Yoshida]

Hello CIP core group members,

I'd formally like to propose to add security packages as revision 3.
I've already the description sheet before, but I'll share all files for this review again in this mail.

Contents:
 proposal_SecurityWG_rev03.yml: the full flat proposal file including all source and binary sets with reason, security tag information and so on
 Requirements_for_proposal_SecurityWG_rev03.xlsx: the same file which I've already sent before to explain the requirement in the standard
 2_src-bin_sort_SecurityWG.txt: the 95 proposed package lists simplified with source and binary names
 2_src-bin_sort_all.txt: the 179 package lists consisted of the 95 lists for this proposal and the 84 lists already approved by CIP core as a minimal base shown in brackets

I'd like to set the due date for reviewing this proposal by February 21, Friday.
It would be very helpful if I can get your feedback, concerning or question in this week due to resolve by the due date.

@kazuhiro3.hayashi at toshiba.co.jp,
Could you proceed this proposal? Thank you for many cooperation.

Thank you all for considering my request,
Kent

>-----Original Message-----
>From: cip-dev <cip-dev-bounces@lists.cip-project.org> On Behalf Of Kento Yoshida
>Sent: Friday, February 7, 2020 5:58 PM
>To: Punit Agrawal <punit1.agrawal@toshiba.co.jp>;
>kazuhiro3.hayashi at toshiba.co.jp
>Cc: cip-security at lists.cip-project.org; cip-dev at lists.cip-project.org
>Subject: Re: [cip-dev] RESUME REQUEST: [cip-core] Package Proposal #1 (Security
>packages)
>
>Hello reviews,
>
>Thank you for your supporting against our proposal.
>I'd like to share you the description sheet for our proposal of security packages.
>Please consider my attachment and the following note.
>
>Note:
>1. Added "fail2ban" as the alternative "pam-shield" because "pam-shield" is not
>well-maintained and replace with "fail2ban"
>2. There are 3 packages in bottom that are under discussion to add. They are out of
>scope for this review but I'd like to explain them, so let me know your ideas if you
>have.
>3. The requirements for hardware functions are out of scope for this review, but
>tpm2 is concrete example mentioned in the standard, so I'd like to add some
>packages related tpm2. However, they are options for only using tpm2, so let me
>know your comments against adding the packages for a specific use case.
>
>BTW,
>
>@kazuhiro3.hayashi at toshiba.co.jp,
>
>I'd like to create new proposal to add "fail2ban", but the script for generating
>proposal shows the following error, and I could not generate it.
>
>-------------------------------
>Source package name:
>Binary packages:
>
>any>
>Traceback (most recent call last):
>  File "./generate-proposal.py", line 218, in <module>
>    generate_proposal(common.PDPProposal.ProposalInfo())
>  File "./generate-proposal.py", line 176, in generate_proposal
>    deb_src_pkg_info = prepare_src_pkg_info(apt, cve, dep_src_pkg,
>dep_pkg_info.keys())
>  File "./generate-proposal.py", line 51, in prepare_src_pkg_info
>    dp_list_final = gpd.get_pkg_depends(pkg, apt)
>  File "/home/yoshidak/cip-pkglist/get_pkg_depends.py", line 102, in
>get_pkg_depends
>    dp_list, dp_vir_pkg_dict = apt.apt_cache_get_depends_list(pkg_name)
>  File "/home/yoshidak/cip-pkglist/common.py", line 222, in
>apt_cache_get_depends_list
>    dp_info=c[pkg_name]
>  File "/usr/lib/python2.7/dist-packages/apt/cache.py", line 238, in __getitem__
>    raise KeyError('The cache has no package named %r' % key)
>KeyError: "The cache has no package named 'any>'"
>-------------------------------
>
>I think that the reason is below. When I enter the information of "fail2ban", the
>script get the dependency for it as <python3:any>.
>
>-------------------------------
>Enter the source package name: fail2ban
>Choose the required binary packages:
>        1: fail2ban
> Input the numbers in comma separated (eg: 1,3,4): 1
>
>fail2ban
> Choose one of the virtual package provider: <python3:any>
>        1: python3
> Input the number: 1
>        -<python3:any>:python3
>        -lsb-base
> Are any of the binary packages used in target rootfs?
>        1: True
>        2: False
>-------------------------------
>
>Would you confirm this issue?
>
>Best regards,
>Kent
>
>>-----Original Message-----
>>From: Punit Agrawal <punit1.agrawal@toshiba.co.jp>
>>Sent: Thursday, January 23, 2020 4:35 PM
>>To: Kento Yoshida <kento.yoshida.wz@renesas.com>
>>Cc: cip-dev at lists.cip-project.org; cip-security at lists.cip-project.org
>>Subject: Re: [cip-dev] RESUME REQUEST: [cip-core] Package Proposal #1
>>(Security
>>packages)
>>
>>Thank you for your comments, Yoshida-san. Follow up comments inline.
>>
>>Kento Yoshida <kento.yoshida.wz@renesas.com> writes:
>>
>>> Hello and thank you for your comment, Punit,
>>>
>>>>-----Original Message-----
>>>>From: Punit Agrawal <punit1.agrawal@toshiba.co.jp>
>>>>Sent: Monday, January 20, 2020 7:29 PM
>>>>To: Kento Yoshida <kento.yoshida.wz@renesas.com>
>>>>Cc: cip-dev at lists.cip-project.org; kazuhiro3.hayashi at toshiba.co.jp;
>>>>cip-security at lists.cip-project.org
>>>>Subject: Re: [cip-dev] RESUME REQUEST: [cip-core] Package Proposal #1
>>>>(Security
>>>>packages)
>>>>
>>>>Hello Yoshida-san,
>>>>
>>>>Kento Yoshida <kento.yoshida.wz@renesas.com> writes:
>>>>
>>>>> Hello,
>>>>>
>>>>> I would like to resume our proposal from security working group.
>>>>> As you know, Kazu has modified the script to generate a proposal
>>>>> and posted the
>>>>minimum base system proposal, and then I created the new proposal.
>>>>>
>>>>> The difference from the original (rev01) proposal is below:
>>>>> 1. We remove 'duplicity', 'google-authenticator', 'pam-shield' and
>>>>> 'suricata' in the
>>>>new proposal because they have an issue such as non-well maintained,
>>>>python version, too much dependencies and so on. We'll separately
>>>>propose them after solved these issues.
>>>>> 2. The new proposal shows all source package as flat. Thanks to the
>>>>> new script,
>>>>Kazu!
>>>>> 3. Actually several packages overlap with the proposed packages for
>>>>> minimum
>>>>base system in Debian, so I added comment them like that.
>>>>>
>>>>> @kazuhiro3.hayashi at toshiba.co.jp,
>>>>> Would you check this proposal and set the due date to review it?
>>>>>
>>>>> Please reply if you have any comments or questions.
>>>>
>>>>I have a comment about packages in the proposal that depend on
>>>>hardware / system features -
>>>>
>>>>* Some packages in the proposal depend on special purpose hardware to
>>>>  provide their functionality. e.g., TPM.
>>>>
>>>>  In systems, where TPM is not present (or similar functionality is
>>>> provided by alternate mechanisms), the TPM related packages will not
>>>> be useful. e.g., the non-x86 platforms in the CIP reference hardware
>>>> list.
>>>>
>>>>* Similarly, some packages require the system to be connected to the
>>>>  network.
>>>>
>>>>In both of these situations, I am wondering what is the impact on
>>>>compliance? Is there a need to also define minimal set of hardware
>>>>features expected from reference hardware to be able to meet
>>>>compliance
>>requirements?
>>>>
>>>
>>> How each reference hardware satisfies the requirements should be
>>> considered by each reference hardware provider.
>>
>>Agreed.
>>
>>But without an explicit statement of the requirement, how can a
>>hardware vendor wanting to develop system for CIP users know what
>>features to enable in their system?
>>
>>> If we provide hardware mechanisms similar with TPM to protect
>>> credentials and authentications, we can meet compliance requirements.
>>
>>TPM2 specification is more than 2000 pages long with many features and
>>functions. I believe the IEC standard requires a subset of this
>>functionality. The Security WG maybe intimately familiar with the
>>required features but for the reviewers on this list, there isn't any criteria to use
>for evaluation.
>>
>>Stating these functional requirements explicitly will serve the dual
>>purpose of -
>>
>>* Provide an objective criteria for evaluating the package proposal
>>(and
>>  discuss alternatives)
>>
>>* Give hardware / system vendors the features / functions needed by CIP
>>  users.
>>
>>What do you think?
>>
>>> TPM related packages are options in only systems where TPM is
>>> implemented as you said. If supporting these packages require too
>>> much costs, the necessity of them will diminish.  Actually the
>>> standard lists TPM as a typical example, so we thought it will be
>>> useful to maintain TPM related packages for many users, but their
>>> necessities depend on supporting cost.
>>
>>I see - thanks for the background of the TPM-related packages in the proposal.
>>
>>>
>>>>To help review the package list (and also discuss alternatives), it
>>>>would help to define the underlying functionality that is required in
>>>>more detail, e.g., secure key storage, verified boot, etc. It'll make
>>>>it possible review the proposal more concretely.
>>
>>[...]

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Requirements_for_proposal_SecurityWG_rev03.xlsx
Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Size: 17780 bytes
Desc: Requirements_for_proposal_SecurityWG_rev03.xlsx
URL: <http://lists.cip-project.org/pipermail/cip-dev/attachments/20200212/4eee4f99/attachment-0001.xlsx>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: proposal_SecurityWG_rev03.yml
Type: application/octet-stream
Size: 25733 bytes
Desc: proposal_SecurityWG_rev03.yml
URL: <http://lists.cip-project.org/pipermail/cip-dev/attachments/20200212/4eee4f99/attachment-0001.obj>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 2_src-bin_sort_all.txt
URL: <http://lists.cip-project.org/pipermail/cip-dev/attachments/20200212/4eee4f99/attachment-0002.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 2_src-bin_sort_SecurityWG.txt
URL: <http://lists.cip-project.org/pipermail/cip-dev/attachments/20200212/4eee4f99/attachment-0003.txt>

[cip-dev] Package Proposal #1 (Security packages), rev03

[kazuhiro3.hayashi at toshiba.co.jp]

Hello Kent,

Thank you for updating the proposal.

Dear reviewers,

First, please confirm the attachment in Kent's mail, especially
the "Proposal description" sheet in "Requirements_for_proposal_SecurityWG_rev03.xlsx",
which includes "detail description" of top level security packages (18 packages).
After that, we can check more details in .yml file (like dependencies)
based on our agreements about the 18 packages.

Due date: February 21, Friday

I think this duration might be short to check all information in .yml file,
but it's enough to confirm the information in "Proposal description" in .xlsx
or just to start the discussion about them.

Best regards,
Kazu

> Could you proceed this proposal? Thank you for many cooperation.

> 
> Hello CIP core group members,
> 
> I'd formally like to propose to add security packages as revision 3.
> I've already the description sheet before, but I'll share all files for this review again in this mail.
> 
> Contents:
>  proposal_SecurityWG_rev03.yml: the full flat proposal file including all source and binary sets with reason, security
> tag information and so on
>  Requirements_for_proposal_SecurityWG_rev03.xlsx: the same file which I've already sent before to explain the requirement
> in the standard
>  2_src-bin_sort_SecurityWG.txt: the 95 proposed package lists simplified with source and binary names
>  2_src-bin_sort_all.txt: the 179 package lists consisted of the 95 lists for this proposal and the 84 lists already approved
> by CIP core as a minimal base shown in brackets
> 
> I'd like to set the due date for reviewing this proposal by February 21, Friday.
> It would be very helpful if I can get your feedback, concerning or question in this week due to resolve by the due date.
> 
> @kazuhiro3.hayashi at toshiba.co.jp,
> Could you proceed this proposal? Thank you for many cooperation.
> 
> Thank you all for considering my request,
> Kent
> 
> >-----Original Message-----
> >From: cip-dev <cip-dev-bounces@lists.cip-project.org> On Behalf Of Kento Yoshida
> >Sent: Friday, February 7, 2020 5:58 PM
> >To: Punit Agrawal <punit1.agrawal@toshiba.co.jp>;
> >kazuhiro3.hayashi at toshiba.co.jp
> >Cc: cip-security at lists.cip-project.org; cip-dev at lists.cip-project.org
> >Subject: Re: [cip-dev] RESUME REQUEST: [cip-core] Package Proposal #1 (Security
> >packages)
> >
> >Hello reviews,
> >
> >Thank you for your supporting against our proposal.
> >I'd like to share you the description sheet for our proposal of security packages.
> >Please consider my attachment and the following note.
> >
> >Note:
> >1. Added "fail2ban" as the alternative "pam-shield" because "pam-shield" is not
> >well-maintained and replace with "fail2ban"
> >2. There are 3 packages in bottom that are under discussion to add. They are out of
> >scope for this review but I'd like to explain them, so let me know your ideas if you
> >have.
> >3. The requirements for hardware functions are out of scope for this review, but
> >tpm2 is concrete example mentioned in the standard, so I'd like to add some
> >packages related tpm2. However, they are options for only using tpm2, so let me
> >know your comments against adding the packages for a specific use case.
> >
> >BTW,
> >
> >@kazuhiro3.hayashi at toshiba.co.jp,
> >
> >I'd like to create new proposal to add "fail2ban", but the script for generating
> >proposal shows the following error, and I could not generate it.
> >
> >-------------------------------
> >Source package name:
> >Binary packages:
> >
> >any>
> >Traceback (most recent call last):
> >  File "./generate-proposal.py", line 218, in <module>
> >    generate_proposal(common.PDPProposal.ProposalInfo())
> >  File "./generate-proposal.py", line 176, in generate_proposal
> >    deb_src_pkg_info = prepare_src_pkg_info(apt, cve, dep_src_pkg,
> >dep_pkg_info.keys())
> >  File "./generate-proposal.py", line 51, in prepare_src_pkg_info
> >    dp_list_final = gpd.get_pkg_depends(pkg, apt)
> >  File "/home/yoshidak/cip-pkglist/get_pkg_depends.py", line 102, in
> >get_pkg_depends
> >    dp_list, dp_vir_pkg_dict = apt.apt_cache_get_depends_list(pkg_name)
> >  File "/home/yoshidak/cip-pkglist/common.py", line 222, in
> >apt_cache_get_depends_list
> >    dp_info=c[pkg_name]
> >  File "/usr/lib/python2.7/dist-packages/apt/cache.py", line 238, in __getitem__
> >    raise KeyError('The cache has no package named %r' % key)
> >KeyError: "The cache has no package named 'any>'"
> >-------------------------------
> >
> >I think that the reason is below. When I enter the information of "fail2ban", the
> >script get the dependency for it as <python3:any>.
> >
> >-------------------------------
> >Enter the source package name: fail2ban
> >Choose the required binary packages:
> >        1: fail2ban
> > Input the numbers in comma separated (eg: 1,3,4): 1
> >
> >fail2ban
> > Choose one of the virtual package provider: <python3:any>
> >        1: python3
> > Input the number: 1
> >        -<python3:any>:python3
> >        -lsb-base
> > Are any of the binary packages used in target rootfs?
> >        1: True
> >        2: False
> >-------------------------------
> >
> >Would you confirm this issue?
> >
> >Best regards,
> >Kent
> >
> >>-----Original Message-----
> >>From: Punit Agrawal <punit1.agrawal@toshiba.co.jp>
> >>Sent: Thursday, January 23, 2020 4:35 PM
> >>To: Kento Yoshida <kento.yoshida.wz@renesas.com>
> >>Cc: cip-dev at lists.cip-project.org; cip-security at lists.cip-project.org
> >>Subject: Re: [cip-dev] RESUME REQUEST: [cip-core] Package Proposal #1
> >>(Security
> >>packages)
> >>
> >>Thank you for your comments, Yoshida-san. Follow up comments inline.
> >>
> >>Kento Yoshida <kento.yoshida.wz@renesas.com> writes:
> >>
> >>> Hello and thank you for your comment, Punit,
> >>>
> >>>>-----Original Message-----
> >>>>From: Punit Agrawal <punit1.agrawal@toshiba.co.jp>
> >>>>Sent: Monday, January 20, 2020 7:29 PM
> >>>>To: Kento Yoshida <kento.yoshida.wz@renesas.com>
> >>>>Cc: cip-dev at lists.cip-project.org; kazuhiro3.hayashi at toshiba.co.jp;
> >>>>cip-security at lists.cip-project.org
> >>>>Subject: Re: [cip-dev] RESUME REQUEST: [cip-core] Package Proposal #1
> >>>>(Security
> >>>>packages)
> >>>>
> >>>>Hello Yoshida-san,
> >>>>
> >>>>Kento Yoshida <kento.yoshida.wz@renesas.com> writes:
> >>>>
> >>>>> Hello,
> >>>>>
> >>>>> I would like to resume our proposal from security working group.
> >>>>> As you know, Kazu has modified the script to generate a proposal
> >>>>> and posted the
> >>>>minimum base system proposal, and then I created the new proposal.
> >>>>>
> >>>>> The difference from the original (rev01) proposal is below:
> >>>>> 1. We remove 'duplicity', 'google-authenticator', 'pam-shield' and
> >>>>> 'suricata' in the
> >>>>new proposal because they have an issue such as non-well maintained,
> >>>>python version, too much dependencies and so on. We'll separately
> >>>>propose them after solved these issues.
> >>>>> 2. The new proposal shows all source package as flat. Thanks to the
> >>>>> new script,
> >>>>Kazu!
> >>>>> 3. Actually several packages overlap with the proposed packages for
> >>>>> minimum
> >>>>base system in Debian, so I added comment them like that.
> >>>>>
> >>>>> @kazuhiro3.hayashi at toshiba.co.jp,
> >>>>> Would you check this proposal and set the due date to review it?
> >>>>>
> >>>>> Please reply if you have any comments or questions.
> >>>>
> >>>>I have a comment about packages in the proposal that depend on
> >>>>hardware / system features -
> >>>>
> >>>>* Some packages in the proposal depend on special purpose hardware to
> >>>>  provide their functionality. e.g., TPM.
> >>>>
> >>>>  In systems, where TPM is not present (or similar functionality is
> >>>> provided by alternate mechanisms), the TPM related packages will not
> >>>> be useful. e.g., the non-x86 platforms in the CIP reference hardware
> >>>> list.
> >>>>
> >>>>* Similarly, some packages require the system to be connected to the
> >>>>  network.
> >>>>
> >>>>In both of these situations, I am wondering what is the impact on
> >>>>compliance? Is there a need to also define minimal set of hardware
> >>>>features expected from reference hardware to be able to meet
> >>>>compliance
> >>requirements?
> >>>>
> >>>
> >>> How each reference hardware satisfies the requirements should be
> >>> considered by each reference hardware provider.
> >>
> >>Agreed.
> >>
> >>But without an explicit statement of the requirement, how can a
> >>hardware vendor wanting to develop system for CIP users know what
> >>features to enable in their system?
> >>
> >>> If we provide hardware mechanisms similar with TPM to protect
> >>> credentials and authentications, we can meet compliance requirements.
> >>
> >>TPM2 specification is more than 2000 pages long with many features and
> >>functions. I believe the IEC standard requires a subset of this
> >>functionality. The Security WG maybe intimately familiar with the
> >>required features but for the reviewers on this list, there isn't any criteria to use
> >for evaluation.
> >>
> >>Stating these functional requirements explicitly will serve the dual
> >>purpose of -
> >>
> >>* Provide an objective criteria for evaluating the package proposal
> >>(and
> >>  discuss alternatives)
> >>
> >>* Give hardware / system vendors the features / functions needed by CIP
> >>  users.
> >>
> >>What do you think?
> >>
> >>> TPM related packages are options in only systems where TPM is
> >>> implemented as you said. If supporting these packages require too
> >>> much costs, the necessity of them will diminish.  Actually the
> >>> standard lists TPM as a typical example, so we thought it will be
> >>> useful to maintain TPM related packages for many users, but their
> >>> necessities depend on supporting cost.
> >>
> >>I see - thanks for the background of the TPM-related packages in the proposal.
> >>
> >>>
> >>>>To help review the package list (and also discuss alternatives), it
> >>>>would help to define the underlying functionality that is required in
> >>>>more detail, e.g., secure key storage, verified boot, etc. It'll make
> >>>>it possible review the proposal more concretely.
> >>
> >>[...]

Re: [cip-dev] Package Proposal #1 (Security packages), rev03

[kazuhiro3.hayashi]

Hello all,

We discussed with security WG members yesterday then
decided to SUSPEND this proposal process for a while.

The reasons of the suspending is that CIP (reviewers) need more information
to understand the required security features (and functional relations with the packages).
In order to get the information, we are planning to follow the steps below:

1. CIP Core provides "sample" images including the proposed packages (+ more if required)
   so that CIP members (mainly security WG) can "evaluate" the required security features
   using the actual run-time environment.
2. CIP Security confirm whether the packages can satisfy the security requirements
   (by testing manually or creating test cases), one by one
3. Based on the result in 2, CIP Security refine this package proposal if needed
   and resume the package proposal

CIP Core has started to create the sample image for the evaluation.
This activity will be discussed in another thread.

Best regards,
Kazu

> -----Original Message-----
> From: Cip-security [mailto:cip-security-bounces@lists.cip-project.org] On Behalf Of kazuhiro3.hayashi@toshiba.co.jp
> Sent: Friday, February 14, 2020 11:05 AM
> To: kento.yoshida.wz@renesas.com; cip-dev@lists.cip-project.org
> Cc: cip-security@lists.cip-project.org
> Subject: Re: [Cip-security] Package Proposal #1 (Security packages), rev03
> 
> Hello Kent,
> 
> Thank you for updating the proposal.
> 
> Dear reviewers,
> 
> First, please confirm the attachment in Kent's mail, especially
> the "Proposal description" sheet in "Requirements_for_proposal_SecurityWG_rev03.xlsx",
> which includes "detail description" of top level security packages (18 packages).
> After that, we can check more details in .yml file (like dependencies)
> based on our agreements about the 18 packages.
> 
> Due date: February 21, Friday
> 
> I think this duration might be short to check all information in .yml file,
> but it's enough to confirm the information in "Proposal description" in .xlsx
> or just to start the discussion about them.
> 
> Best regards,
> Kazu
> 
> > Could you proceed this proposal? Thank you for many cooperation.
> 
> >
> > Hello CIP core group members,
> >
> > I'd formally like to propose to add security packages as revision 3.
> > I've already the description sheet before, but I'll share all files for this review again in this mail.
> >
> > Contents:
> >  proposal_SecurityWG_rev03.yml: the full flat proposal file including all source and binary sets with reason, security
> > tag information and so on
> >  Requirements_for_proposal_SecurityWG_rev03.xlsx: the same file which I've already sent before to explain the requirement
> > in the standard
> >  2_src-bin_sort_SecurityWG.txt: the 95 proposed package lists simplified with source and binary names
> >  2_src-bin_sort_all.txt: the 179 package lists consisted of the 95 lists for this proposal and the 84 lists already
> approved
> > by CIP core as a minimal base shown in brackets
> >
> > I'd like to set the due date for reviewing this proposal by February 21, Friday.
> > It would be very helpful if I can get your feedback, concerning or question in this week due to resolve by the due date.
> >
> > @kazuhiro3.hayashi@toshiba.co.jp,
> > Could you proceed this proposal? Thank you for many cooperation.
> >
> > Thank you all for considering my request,
> > Kent
> >
> > >-----Original Message-----
> > >From: cip-dev <cip-dev-bounces@lists.cip-project.org> On Behalf Of Kento Yoshida
> > >Sent: Friday, February 7, 2020 5:58 PM
> > >To: Punit Agrawal <punit1.agrawal@toshiba.co.jp>;
> > >kazuhiro3.hayashi@toshiba.co.jp
> > >Cc: cip-security@lists.cip-project.org; cip-dev@lists.cip-project.org
> > >Subject: Re: [cip-dev] RESUME REQUEST: [cip-core] Package Proposal #1 (Security
> > >packages)
> > >
> > >Hello reviews,
> > >
> > >Thank you for your supporting against our proposal.
> > >I'd like to share you the description sheet for our proposal of security packages.
> > >Please consider my attachment and the following note.
> > >
> > >Note:
> > >1. Added "fail2ban" as the alternative "pam-shield" because "pam-shield" is not
> > >well-maintained and replace with "fail2ban"
> > >2. There are 3 packages in bottom that are under discussion to add. They are out of
> > >scope for this review but I'd like to explain them, so let me know your ideas if you
> > >have.
> > >3. The requirements for hardware functions are out of scope for this review, but
> > >tpm2 is concrete example mentioned in the standard, so I'd like to add some
> > >packages related tpm2. However, they are options for only using tpm2, so let me
> > >know your comments against adding the packages for a specific use case.
> > >
> > >BTW,
> > >
> > >@kazuhiro3.hayashi@toshiba.co.jp,
> > >
> > >I'd like to create new proposal to add "fail2ban", but the script for generating
> > >proposal shows the following error, and I could not generate it.
> > >
> > >-------------------------------
> > >Source package name:
> > >Binary packages:
> > >
> > >any>
> > >Traceback (most recent call last):
> > >  File "./generate-proposal.py", line 218, in <module>
> > >    generate_proposal(common.PDPProposal.ProposalInfo())
> > >  File "./generate-proposal.py", line 176, in generate_proposal
> > >    deb_src_pkg_info = prepare_src_pkg_info(apt, cve, dep_src_pkg,
> > >dep_pkg_info.keys())
> > >  File "./generate-proposal.py", line 51, in prepare_src_pkg_info
> > >    dp_list_final = gpd.get_pkg_depends(pkg, apt)
> > >  File "/home/yoshidak/cip-pkglist/get_pkg_depends.py", line 102, in
> > >get_pkg_depends
> > >    dp_list, dp_vir_pkg_dict = apt.apt_cache_get_depends_list(pkg_name)
> > >  File "/home/yoshidak/cip-pkglist/common.py", line 222, in
> > >apt_cache_get_depends_list
> > >    dp_info=c[pkg_name]
> > >  File "/usr/lib/python2.7/dist-packages/apt/cache.py", line 238, in __getitem__
> > >    raise KeyError('The cache has no package named %r' % key)
> > >KeyError: "The cache has no package named 'any>'"
> > >-------------------------------
> > >
> > >I think that the reason is below. When I enter the information of "fail2ban", the
> > >script get the dependency for it as <python3:any>.
> > >
> > >-------------------------------
> > >Enter the source package name: fail2ban
> > >Choose the required binary packages:
> > >        1: fail2ban
> > > Input the numbers in comma separated (eg: 1,3,4): 1
> > >
> > >fail2ban
> > > Choose one of the virtual package provider: <python3:any>
> > >        1: python3
> > > Input the number: 1
> > >        -<python3:any>:python3
> > >        -lsb-base
> > > Are any of the binary packages used in target rootfs?
> > >        1: True
> > >        2: False
> > >-------------------------------
> > >
> > >Would you confirm this issue?
> > >
> > >Best regards,
> > >Kent
> > >
> > >>-----Original Message-----
> > >>From: Punit Agrawal <punit1.agrawal@toshiba.co.jp>
> > >>Sent: Thursday, January 23, 2020 4:35 PM
> > >>To: Kento Yoshida <kento.yoshida.wz@renesas.com>
> > >>Cc: cip-dev@lists.cip-project.org; cip-security@lists.cip-project.org
> > >>Subject: Re: [cip-dev] RESUME REQUEST: [cip-core] Package Proposal #1
> > >>(Security
> > >>packages)
> > >>
> > >>Thank you for your comments, Yoshida-san. Follow up comments inline.
> > >>
> > >>Kento Yoshida <kento.yoshida.wz@renesas.com> writes:
> > >>
> > >>> Hello and thank you for your comment, Punit,
> > >>>
> > >>>>-----Original Message-----
> > >>>>From: Punit Agrawal <punit1.agrawal@toshiba.co.jp>
> > >>>>Sent: Monday, January 20, 2020 7:29 PM
> > >>>>To: Kento Yoshida <kento.yoshida.wz@renesas.com>
> > >>>>Cc: cip-dev@lists.cip-project.org; kazuhiro3.hayashi@toshiba.co.jp;
> > >>>>cip-security@lists.cip-project.org
> > >>>>Subject: Re: [cip-dev] RESUME REQUEST: [cip-core] Package Proposal #1
> > >>>>(Security
> > >>>>packages)
> > >>>>
> > >>>>Hello Yoshida-san,
> > >>>>
> > >>>>Kento Yoshida <kento.yoshida.wz@renesas.com> writes:
> > >>>>
> > >>>>> Hello,
> > >>>>>
> > >>>>> I would like to resume our proposal from security working group.
> > >>>>> As you know, Kazu has modified the script to generate a proposal
> > >>>>> and posted the
> > >>>>minimum base system proposal, and then I created the new proposal.
> > >>>>>
> > >>>>> The difference from the original (rev01) proposal is below:
> > >>>>> 1. We remove 'duplicity', 'google-authenticator', 'pam-shield' and
> > >>>>> 'suricata' in the
> > >>>>new proposal because they have an issue such as non-well maintained,
> > >>>>python version, too much dependencies and so on. We'll separately
> > >>>>propose them after solved these issues.
> > >>>>> 2. The new proposal shows all source package as flat. Thanks to the
> > >>>>> new script,
> > >>>>Kazu!
> > >>>>> 3. Actually several packages overlap with the proposed packages for
> > >>>>> minimum
> > >>>>base system in Debian, so I added comment them like that.
> > >>>>>
> > >>>>> @kazuhiro3.hayashi@toshiba.co.jp,
> > >>>>> Would you check this proposal and set the due date to review it?
> > >>>>>
> > >>>>> Please reply if you have any comments or questions.
> > >>>>
> > >>>>I have a comment about packages in the proposal that depend on
> > >>>>hardware / system features -
> > >>>>
> > >>>>* Some packages in the proposal depend on special purpose hardware to
> > >>>>  provide their functionality. e.g., TPM.
> > >>>>
> > >>>>  In systems, where TPM is not present (or similar functionality is
> > >>>> provided by alternate mechanisms), the TPM related packages will not
> > >>>> be useful. e.g., the non-x86 platforms in the CIP reference hardware
> > >>>> list.
> > >>>>
> > >>>>* Similarly, some packages require the system to be connected to the
> > >>>>  network.
> > >>>>
> > >>>>In both of these situations, I am wondering what is the impact on
> > >>>>compliance? Is there a need to also define minimal set of hardware
> > >>>>features expected from reference hardware to be able to meet
> > >>>>compliance
> > >>requirements?
> > >>>>
> > >>>
> > >>> How each reference hardware satisfies the requirements should be
> > >>> considered by each reference hardware provider.
> > >>
> > >>Agreed.
> > >>
> > >>But without an explicit statement of the requirement, how can a
> > >>hardware vendor wanting to develop system for CIP users know what
> > >>features to enable in their system?
> > >>
> > >>> If we provide hardware mechanisms similar with TPM to protect
> > >>> credentials and authentications, we can meet compliance requirements.
> > >>
> > >>TPM2 specification is more than 2000 pages long with many features and
> > >>functions. I believe the IEC standard requires a subset of this
> > >>functionality. The Security WG maybe intimately familiar with the
> > >>required features but for the reviewers on this list, there isn't any criteria to use
> > >for evaluation.
> > >>
> > >>Stating these functional requirements explicitly will serve the dual
> > >>purpose of -
> > >>
> > >>* Provide an objective criteria for evaluating the package proposal
> > >>(and
> > >>  discuss alternatives)
> > >>
> > >>* Give hardware / system vendors the features / functions needed by CIP
> > >>  users.
> > >>
> > >>What do you think?
> > >>
> > >>> TPM related packages are options in only systems where TPM is
> > >>> implemented as you said. If supporting these packages require too
> > >>> much costs, the necessity of them will diminish.  Actually the
> > >>> standard lists TPM as a typical example, so we thought it will be
> > >>> useful to maintain TPM related packages for many users, but their
> > >>> necessities depend on supporting cost.
> > >>
> > >>I see - thanks for the background of the TPM-related packages in the proposal.
> > >>
> > >>>
> > >>>>To help review the package list (and also discuss alternatives), it
> > >>>>would help to define the underlying functionality that is required in
> > >>>>more detail, e.g., secure key storage, verified boot, etc. It'll make
> > >>>>it possible review the proposal more concretely.
> > >>
> > >>[...]
> 
> _______________________________________________
> Cip-security mailing list
> Cip-security@lists.cip-project.org
> https://lists.cip-project.org/mailman/listinfo/cip-security
_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev

Re: [cip-dev] Package Proposal #1 (Security packages), rev03

[Punit Agrawal]

Hi,

As mentioned earlier, I had some questions / queries regarding the
requirements for the proposed packages. Sending them here for
discussion.

Kento Yoshida <kento.yoshida.wz@renesas.com> writes:

>  Requirements_for_proposal_SecurityWG_rev03.xlsx: the same file which I've already sent before to explain the requirement in the standard

* sudo-ldap

Is there a specific requirement to include sudo-ldap in favour of plain
sudo? IIUC, sudo is a minimal dependency version while ldap requires
additional packages to be available.


* openssh

Based on the listed requierments, it is not clear why ftp and ssh
clients are needed. Can you please clarify the requirements' text to
motivate inclusion of the client binaries as well.


* pam-pkcs11

From my understanding, the package enables login  using public / private
keys. But the requirements talk about enforcing the strength of
passwords -

    "A minimum strength of used passwords needs to be enforced."

Possibly a mixup of package and requirements?


* tpm2*

I think libtss2-esys0 is mistakenly included as explicit requirement. It
seems to be a dependency of tpm2-abrmd and will get pulled in
automatically as per my understanding.


* uuid-runtime

It’s not clear how the package is related to the requirement -

    "Account Identifier shall be unique on a component or system wide
    level. Protection of relevant information in rest and transit shall
    be supported."

Can you add more details to the requirement to clarify this?
---


Thanks,
Punit
_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev

Re: [cip-dev] Package Proposal #1 (Security packages), rev03

[Kento Yoshida]

Thank you for your comments, Punit.

I'll reply to your queries, see the followings.

>* sudo-ldap
>
>Is there a specific requirement to include sudo-ldap in favour of plain sudo? IIUC,
>sudo is a minimal dependency version while ldap requires additional packages to
>be available.
>
We considered and decided to adopt only sudo binary. As the result, sudo source code includes both sudo and sudo-ldap binaries, but we only need sudo.
LDAP is just example in the requirement and will be needed only specific case. At least, nobody in security working group members want that.

>* openssh
>
>Based on the listed requierments, it is not clear why ftp and ssh clients are needed.
>Can you please clarify the requirements' text to motivate inclusion of the client
>binaries as well.
>
SSH client is needed as just a run-time dependency for SSH server.

>* pam-pkcs11
>
>From my understanding, the package enables login  using public / private keys.
>But the requirements talk about enforcing the strength of passwords -
>
>    "A minimum strength of used passwords needs to be enforced."
>
>Possibly a mixup of package and requirements?
>
Indeed, the package functionality and the requirement do not match.
In addition, pam-pkcs11 is only required for CR 1.7, it's mean "A minimum strength of used passwords needs to be enforced.", so we should consider again whether we need pam-pkcs11 or not.
Thank you for pointing out this.

>* tpm2*
>
>I think libtss2-esys0 is mistakenly included as explicit requirement. It seems to be a
>dependency of tpm2-abrmd and will get pulled in automatically as per my
>understanding.
>
Yes. libtss2-esys0 is a dependency tpm2-abrmd and tpm2-tools.
But, it is not just a mistake. The TSS and TCTI libraries located in libtss2-esys0 is important to meet the requirement shown in the description for tpm2*.
So, I expressly include libtss2-esys0 as a required binary not just a dependency.

>* uuid-runtime
>
>It’s not clear how the package is related to the requirement -
>
>    "Account Identifier shall be unique on a component or system wide
>    level. Protection of relevant information in rest and transit shall
>    be supported."
>
>Can you add more details to the requirement to clarify this?
>
As is, identifier shall be unique, so we need universally unique identifier generator.
Sorry but I don't know what you don't know. This is very simple requirement.

>-----Original Message-----
>From: Punit Agrawal <punit1.agrawal@toshiba.co.jp>
>Sent: Monday, March 9, 2020 7:31 PM
>To: Kento Yoshida <kento.yoshida.wz@renesas.com>
>Cc: cip-dev@lists.cip-project.org; cip-security@lists.cip-project.org
>Subject: Re: [cip-dev] Package Proposal #1 (Security packages), rev03
>
>Hi,
>
>As mentioned earlier, I had some questions / queries regarding the requirements
>for the proposed packages. Sending them here for discussion.
>
>Kento Yoshida <kento.yoshida.wz@renesas.com> writes:
>
>>  Requirements_for_proposal_SecurityWG_rev03.xlsx: the same file which
>> I've already sent before to explain the requirement in the standard
>
>* sudo-ldap
>
>Is there a specific requirement to include sudo-ldap in favour of plain sudo? IIUC,
>sudo is a minimal dependency version while ldap requires additional packages to
>be available.
>
>
>* openssh
>
>Based on the listed requierments, it is not clear why ftp and ssh clients are needed.
>Can you please clarify the requirements' text to motivate inclusion of the client
>binaries as well.
>
>
>* pam-pkcs11
>
>From my understanding, the package enables login  using public / private keys.
>But the requirements talk about enforcing the strength of passwords -
>
>    "A minimum strength of used passwords needs to be enforced."
>
>Possibly a mixup of package and requirements?
>
>
>* tpm2*
>
>I think libtss2-esys0 is mistakenly included as explicit requirement. It seems to be a
>dependency of tpm2-abrmd and will get pulled in automatically as per my
>understanding.
>
>
>* uuid-runtime
>
>It’s not clear how the package is related to the requirement -
>
>    "Account Identifier shall be unique on a component or system wide
>    level. Protection of relevant information in rest and transit shall
>    be supported."
>
>Can you add more details to the requirement to clarify this?
>---
>
>
>Thanks,
>Punit
_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev

Re: [cip-dev] Package Proposal #1 (Security packages), rev03

[Punit Agrawal]

Hi Yoshida-san,

Thanks for the clarifications. Where applicable please include them in
the requirements text and / or comments for the relevant packages for
the next update.

One additional comment below -

Kento Yoshida <kento.yoshida.wz@renesas.com> writes:

[...]

>>* uuid-runtime
>>
>>It’s not clear how the package is related to the requirement -
>>
>>    "Account Identifier shall be unique on a component or system wide
>>    level. Protection of relevant information in rest and transit shall
>>    be supported."
>>
>>Can you add more details to the requirement to clarify this?
>>
> As is, identifier shall be unique, so we need universally unique identifier generator.
> Sorry but I don't know what you don't know. This is very simple
> requirement.

I understand the requirement for having ’unique account identifier’
(usernames) but using uuidgen to achieve this seems quite impractical.

For reference, I checked the output of uuidgen included in the package -

    $ uuidgen
    b865c278-4230-4d5a-b7de-0ee528910095

It generates a 37 character long string of what seems like random hex
values. Are you recommending that we have these kind of strings for
usernames?

Thanks,
Punit

>
>>-----Original Message-----
>>From: Punit Agrawal <punit1.agrawal@toshiba.co.jp>
>>Sent: Monday, March 9, 2020 7:31 PM
>>To: Kento Yoshida <kento.yoshida.wz@renesas.com>
>>Cc: cip-dev@lists.cip-project.org; cip-security@lists.cip-project.org
>>Subject: Re: [cip-dev] Package Proposal #1 (Security packages), rev03
>>
>>Hi,
>>
>>As mentioned earlier, I had some questions / queries regarding the requirements
>>for the proposed packages. Sending them here for discussion.
>>
>>Kento Yoshida <kento.yoshida.wz@renesas.com> writes:
>>
>>>  Requirements_for_proposal_SecurityWG_rev03.xlsx: the same file which
>>> I've already sent before to explain the requirement in the standard
>>
>>* sudo-ldap
>>
>>Is there a specific requirement to include sudo-ldap in favour of plain sudo? IIUC,
>>sudo is a minimal dependency version while ldap requires additional packages to
>>be available.
>>
>>
>>* openssh
>>
>>Based on the listed requierments, it is not clear why ftp and ssh clients are needed.
>>Can you please clarify the requirements' text to motivate inclusion of the client
>>binaries as well.
>>
>>
>>* pam-pkcs11
>>
>>From my understanding, the package enables login  using public / private keys.
>>But the requirements talk about enforcing the strength of passwords -
>>
>>    "A minimum strength of used passwords needs to be enforced."
>>
>>Possibly a mixup of package and requirements?
>>
>>
>>* tpm2*
>>
>>I think libtss2-esys0 is mistakenly included as explicit requirement. It seems to be a
>>dependency of tpm2-abrmd and will get pulled in automatically as per my
>>understanding.
>>
>>
>>* uuid-runtime
>>
>>It’s not clear how the package is related to the requirement -
>>
>>    "Account Identifier shall be unique on a component or system wide
>>    level. Protection of relevant information in rest and transit shall
>>    be supported."
>>
>>Can you add more details to the requirement to clarify this?
>>---
>>
>>
>>Thanks,
>>Punit
_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev