All of lore.kernel.org
 help / color / mirror / Atom feed
* Security Working Group - Wednesday May 13
@ 2020-05-12 17:58 Joseph Reynolds
  2020-05-13 22:03 ` Security Working Group - Wednesday May 13 - results Joseph Reynolds
  0 siblings, 1 reply; 2+ messages in thread
From: Joseph Reynolds @ 2020-05-12 17:58 UTC (permalink / raw)
  To: openbmc

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.

2. Discuss SELinux email use cases (email). 3. Experimental bmcweb 
prototype for authentication rate-limiting. 4. The security wiki now 
links to OpenBMC's threat models. 5. Are there security considerations 
in using the fwupd tool? 6. Do we have requirements for BMC admins to 
disable specific crypto ciphers?

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

* 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

end of thread, other threads:[~2020-05-13 22:04 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-12 17:58 Security Working Group - Wednesday May 13 Joseph Reynolds
2020-05-13 22:03 ` Security Working Group - Wednesday May 13 - results Joseph Reynolds

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.