Security Working Group - Wednesday May 13 - results

[Joseph Reynolds <jrey@linux.ibm.com>]

On 5/12/20 12:58 PM, Joseph Reynolds wrote:
> This is a reminder of the OpenBMC Security Working Group meeting 
> scheduled for this Wednesday May 13 at 10:00am PDT.
>
> We'll discuss current development items, and anything else that comes up.
>
> The current topics:
>
> 1. Note: concurrent OCP virtual summit.
Decided to hold the security working group meeting regardless of 
concurrent OCP virtual summit.
>
> 2. Discuss SELinux email use cases (email). 
Discuss SELinux email use cases - 
https://lists.ozlabs.org/pipermail/openbmc/2020-April/021477.html

Manoj led us through SELinux email use-cases.  SELinux can help control 
access so we (OpenBMC contributors) restrict access to those processes 
that should have access:


(Joseph disclaimer): I tried to summarize the use cases as Manoj walked 
through them.  This is a summary only.  Please refer to the email chain.

Use cases:

2-1 NBD (network block device) is used to offload dumps on POWER 
systems.  It reads from PLDM source and writes to NBD device.  Control 
who has write access to the NBD device.

2-2 All processes running root can write to config files under the /etc 
directory.

2-3 All processes can control use of systemctl command.

2-4 All processes can write to the journal (journald).

2-5 All processes can use network tcp and udp ports - port-based 
firewall capability.

2-6 D-Bus service names (paths under /xyz/openbmc_project/*)

2-7 D-Bus message passing - hardening D-Bus communication

2-8 Map existing roles (Administrator, Operator, etc.) to SELinux.  
Assign SELinux label based on ingress vector (serial line vs SSH vs REST 
login).  Uses PAM-selinux config files.

2-9 System calls. For example, disable ptrace.

2-10 Run user executing capabilities.  executables only from specific 
paths, for example, don’t allow running programs from /tmp


Next steps: Compare AppArmor vs SELinux.  Consider Cost/benefit.

- Prioritize the benefits (as listed above).

- Consider costs including: developer time (person-months), BMC 
resources (flash size and memory requirements, BMC performance).

- Also consider the cost of future development, for example consider the 
complications for a developer who is not skilled in security practice: 
adding a security-relevant function (or entirely new service) or 
adapting a service for different use cases.  They can either struggle 
with getting the security controls correct, or accidentally create a 
security hole.


U-Boot focus: Interaction between SELinux and U-Boot (commands like 
fw_setenv)?  For example: functions for factory reset and select BMC 
boot source (such as for BMC firmware update) use the fw_setenv command 
(or underlying mechanism).  Are these functions the only ones who should 
be allowed to access the fw_setenv function?

Related side topic: Protect unattended BMC boot.  Can we harden U-Boot 
itself?


Anton is considering an alternative to apparmor and selinux: KRSI: 
Kernel Runtime Security Instrumentation


Next steps: prioritize which benefits we want.  Followup in email.

> 3. Experimental bmcweb prototype for authentication rate-limiting. 

https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/31841

Joseph briefly walked through the review and talked about Linux-PAM 
issues and alternatives like pam_abl.

Feedback was: Looks right.

> 4. The security wiki now links to OpenBMC's threat models. 

No discussion.


> 5. Are there security considerations in using the fwupd tool? 

No discussion.

> 6. Do we have requirements for BMC admins to disable specific crypto 
> ciphers?
That is, allowing the BMC admin to disable ciphers 
https://lists.ozlabs.org/pipermail/openbmc/2020-May/021619.htmlThis 
seems useful, but nobody jumped up to do it.

Drawbacks: implementation cost.  For example: do we try to prevent the 
admin from removing all supported algorithms so that are none left to 
connect to?


BONUS AGENDA ITEMS:

7 Requirements for security audit log - 
https://lists.ozlabs.org/pipermail/openbmc/2020-May/021640.html

Joseph walked through the email.


8 (Bonus topic) We need a better meeting time for India, Zurich, and others.

Joseph revived the email thread 
https://lists.ozlabs.org/pipermail/openbmc/2020-May/021641.html

Next step is for two people to agree on a meeting time.

- Joseph

>
> Access, agenda, and notes are in the wiki:
>
> https://github.com/openbmc/openbmc/wiki/Security-working-group
>
> - Joseph