* Security Working Group - Wednesday May 13 - results
2020-05-12 17:58 Security Working Group - Wednesday May 13 Joseph Reynolds
@ 2020-05-13 22:03 ` Joseph Reynolds
0 siblings, 0 replies; 2+ messages in thread
From: Joseph Reynolds @ 2020-05-13 22:03 UTC (permalink / raw)
To: openbmc
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
^ permalink raw reply [flat|nested] 2+ messages in thread