Security Working Group - Wednesday April 1

Security Working Group - Wednesday April 1

[Joseph Reynolds]

This is a reminder of the OpenBMC Security Working Group meeting 
scheduled for this Wednesday April 1 at 10:00am PDT.

We'll discuss current development items, and anything else that comes up.

The current topics:

1. SELinux or AppArmor plans

Access, agenda, and notes are in the wiki:

https://github.com/openbmc/openbmc/wiki/Security-working-group

- Joseph

Re: Security Working Group - Wednesday April 1

[Ratan Gupta]

Hi Joseph,

We did some POC around selinux, will share the detailed use-cases with 
selinux which can be useful in openbmc stack.

selinux is taking around 18MB space on flash, Is it a concern?

Regards

Ratan

On 3/31/20 9:51 PM, Joseph Reynolds wrote:
> This is a reminder of the OpenBMC Security Working Group meeting 
> scheduled for this Wednesday April 1 at 10:00am PDT.
>
> We'll discuss current development items, and anything else that comes up.
>
> The current topics:
>
> 1. SELinux or AppArmor plans
>
> Access, agenda, and notes are in the wiki:
>
> https://github.com/openbmc/openbmc/wiki/Security-working-group
>
> - Joseph
>

Re: Security Working Group - Wednesday April 1 - highlights

[Joseph Reynolds]

On 3/31/20 11:21 AM, Joseph Reynolds wrote:
> This is a reminder of the OpenBMC Security Working Group meeting 
> scheduled for this Wednesday April 1 at 10:00am PDT.
>
> We'll discuss current development items, and anything else that comes up.
>
> The current topics:
>
> 1. SELinux or AppArmor plans

Topic 1 has three points:
1a. We would also want to move away from all processes running as root. 
https://github.com/openbmc/openbmc/issues/3383  Next step is create 
issue for each repo.
1b. A next step is to determine criteria for selecting SELinux or 
AppArmor.  What direction should the project go?
1c. There is continued interest, but no active work on this.  Next step: 
Followup with email.


Topic 2 was added:  Admin-controlled security settings -- Discuss plans 
for BMC admin-controlled security settings.  Access per NIC. Disable 
ipmi cipher 3.
This topic was discussed recently by the Web design who have access to 
user feedback.

See IBM’s plans here: https://github.com/ibm-openbmc/dev/issues/612.
- Issue 612 does not quite cover all the items.  There are a few changes 
and clarifications from issue 612
.

The group discussed how a BMC admin can control access to the BMC via 
its network in terms of the following areas.
More details are in the minutes (link below).

1. The admin can control each NIC individually.  Example: data-center 
wide network, vs, private management network.  
  The admin can control 
which network interface the BMC brings up.

2. We would like to be able to control which services are available on a 
per-NIC basis.  For example, REST APIs to directly model if service X is 
accessible from network Y.
  Then we can, for example, provide IPMI 
RMCP+ service to a private network but not to the data-center-wide network.
We don't have this mechanism, but individual services may be able to 
discriminate based on ingress network.
I this the direction toward a solution remains open.
For the near team (this year), we’ll work on allowing the admin to 
disable and enable services.  For example, the admin can disable SSH and 
IPMI RMCP+, but will not have the capability offer RMCP+ to a network A 
but not network B.

3. We would like to allow the admin to enable or disable bridges like 
KCS or BT, and also protocols over thosse bridges such as IPMB.
(However, my understanding this this area is very limited.  Please 
contribute your understanding.)

4. We want to allow the admin to be able to disable RMCP+ cipher suite 
3, leaving only 17.  Is there an IPMI command to do that?  And is that 
command implemented in OpenBMC?

Note that after the meeting, a patch was created to remove suite 3: 
https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-net-ipmid/+/30814

Note the BMC's IPMI function has two very different access vectors:
- via RMCP+ out-of-band or network
- via in-band IPMI via host connections

Enabling these should be separately controllable.


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

- Joseph

Re: Security Working Group - Wednesday April 1 - highlights

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 845 bytes --]

On Thu, Apr 02, 2020 at 01:44:45PM -0500, Joseph Reynolds wrote:
> On 3/31/20 11:21 AM, Joseph Reynolds wrote:
> > This is a reminder of the OpenBMC Security Working Group meeting 
> > scheduled for this Wednesday April 1 at 10:00am PDT.
> >
> > We'll discuss current development items, and anything else that comes up.
> >
> > The current topics:
> >
> > 1. SELinux or AppArmor plans
> 
> Topic 1 has three points:
> 1a. We would also want to move away from all processes running as root. 
> https://github.com/openbmc/openbmc/issues/3383  Next step is create 
> issue for each repo.

Have the technical issues all been worked out on that issue?  Is there a
design documented of what "each repo" is suppose to do?  It seems like
kind of a leap to ask each repo to just not run as root at this point.

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Security Working Group - Wednesday April 1 - highlights

[Joseph Reynolds]

On 4/2/20 1:52 PM, Patrick Williams wrote:
> On Thu, Apr 02, 2020 at 01:44:45PM -0500, Joseph Reynolds wrote:
>> On 3/31/20 11:21 AM, Joseph Reynolds wrote:
>>> This is a reminder of the OpenBMC Security Working Group meeting
>>> scheduled for this Wednesday April 1 at 10:00am PDT.
>>>
>>> We'll discuss current development items, and anything else that comes up.
>>>
>>> The current topics:
>>>
>>> 1. SELinux or AppArmor plans
>> Topic 1 has three points:
>> 1a. We would also want to move away from all processes running as root.
>> https://github.com/openbmc/openbmc/issues/3383  Next step is create
>> issue for each repo.
> Have the technical issues all been worked out on that issue?  Is there a
> design documented of what "each repo" is suppose to do?  It seems like
> kind of a leap to ask each repo to just not run as root at this point.
>

Patrick,

Thanks for asking.  There are technical issues to be worked out (ref: 
issue 3383).

Correction to 1a. Work out technical issues, then ask all daemons to 
move away from running as root.

- Joseph

Re: Security Working Group - Wednesday April 1 - highlights

[Joseph Reynolds]

On 4/2/20 1:44 PM, Joseph Reynolds wrote:
> On 3/31/20 11:21 AM, Joseph Reynolds wrote:
>> This is a reminder of the OpenBMC Security Working Group meeting 
>> scheduled for this Wednesday April 1 at 10:00am PDT.
>>
> ...snip...
> For the near team (this year), we’ll work on allowing the admin to 
> disable and enable services.  For example, the admin can disable SSH 
> and IPMI RMCP+, but will not have the capability offer RMCP+ to a 
> network A but not network B.
> ...snip...

Does anyone have a requirement to allow the BMC admin to enable/disable 
the SSH access to its [host serial console][]?

It seems to me this provides access equivalent to [IPKVM][], so if we 
can disable IPKVM, we ought be be able to disable this.
I've asked Redfish to [Add SoL via SSH to ManagerNetworkProtocol][].  At 
least one other Redfish user wants this feature.

- Joseph

[host serial console]: 
https://github.com/openbmc/docs/blob/master/security/network-security-considerations.md#tcp-port-2200
[IPKVM]: https://github.com/openbmc/obmc-ikvm/blob/master/README.md
[Add SoL via SSH to ManagerNetworkProtocol]: 
https://redfishforum.com/thread/268/add-sol-ssh-managernetworkprotocol

Re: Security Working Group - Wednesday April 1

[Anton Kachalov]

[-- Attachment #1: Type: text/plain, Size: 940 bytes --]

Hello, Ratan.

Would you mind breaking down the estimation, curious about what brought up
18MB when enabling SELinux.
Precompiled rules in Android took 3MB on average.

On Wed, 1 Apr 2020 at 16:22, Ratan Gupta <ratagupt@linux.vnet.ibm.com>
wrote:

> Hi Joseph,
>
> We did some POC around selinux, will share the detailed use-cases with
> selinux which can be useful in openbmc stack.
>
> selinux is taking around 18MB space on flash, Is it a concern?
>
> Regards
>
> Ratan
>
> On 3/31/20 9:51 PM, Joseph Reynolds wrote:
> > This is a reminder of the OpenBMC Security Working Group meeting
> > scheduled for this Wednesday April 1 at 10:00am PDT.
> >
> > We'll discuss current development items, and anything else that comes up.
> >
> > The current topics:
> >
> > 1. SELinux or AppArmor plans
> >
> > Access, agenda, and notes are in the wiki:
> >
> > https://github.com/openbmc/openbmc/wiki/Security-working-group
> >
> > - Joseph
> >
>
>

[-- Attachment #2: Type: text/html, Size: 1510 bytes --]

Re: Security Working Group - Wednesday April 1

[Ratan Gupta]

[-- Attachment #1: Type: text/plain, Size: 2134 bytes --]

Hi Anton,

I brought  the meta-selinux layer, that enables the selinux framework on 
obmc-phosphor-image and it increases the size of the image by 18MB.

This layer enables the linux kernel support for selinux framework and 
brings in a lot of tools and scripts.
Just to name a few,layer comes with binaries like

- getenforce
- setenforce
- semange
- sestatus
- audit2why
- audit2allow
- restorecon
- chcon

It also brings in various scripts that would help to label the entire 
system during the first boot.

While lot of these binaries may be only required by the developer during 
the inital phase if selinux enablement and not to the end customer.

I need to spend a little more time to see what can we remove form the 
layer.

My suggestion is  we can defer this size work for later and start 
working on how selinux can help in openBMC security.

We would be publishing the se-linux use cases in a week.

Manoj is working with me on bringing down the size of se-linux layer.

Regards

Ratan

On 4/5/20 6:58 PM, Anton Kachalov wrote:
> Hello, Ratan.
>
> Would you mind breaking down the estimation, curious about what 
> brought up 18MB when enabling SELinux.
> Precompiled rules in Android took 3MB on average.
>
> On Wed, 1 Apr 2020 at 16:22, Ratan Gupta <ratagupt@linux.vnet.ibm.com 
> <mailto:ratagupt@linux.vnet.ibm.com>> wrote:
>
>     Hi Joseph,
>
>     We did some POC around selinux, will share the detailed use-cases
>     with
>     selinux which can be useful in openbmc stack.
>
>     selinux is taking around 18MB space on flash, Is it a concern?
>
>     Regards
>
>     Ratan
>
>     On 3/31/20 9:51 PM, Joseph Reynolds wrote:
>     > This is a reminder of the OpenBMC Security Working Group meeting
>     > scheduled for this Wednesday April 1 at 10:00am PDT.
>     >
>     > We'll discuss current development items, and anything else that
>     comes up.
>     >
>     > The current topics:
>     >
>     > 1. SELinux or AppArmor plans
>     >
>     > Access, agenda, and notes are in the wiki:
>     >
>     > https://github.com/openbmc/openbmc/wiki/Security-working-group
>     >
>     > - Joseph
>     >
>

[-- Attachment #2: Type: text/html, Size: 3722 bytes --]

Re: Security Working Group - Wednesday April 1

[Anton Kachalov]

[-- Attachment #1: Type: text/plain, Size: 2296 bytes --]

Thanks you for clarifying, Ratan.

Meanwhile I would try to check what will give us AppArmor in terms of
firmware's size growth.

On Mon, 6 Apr 2020 at 13:24, Ratan Gupta <ratagupt@linux.vnet.ibm.com>
wrote:

> Hi Anton,
>
> I brought  the meta-selinux layer, that enables the selinux framework on
> obmc-phosphor-image and it increases the size of the image by 18MB.
>
> This layer enables the linux kernel support for selinux framework and
> brings in a lot of tools and scripts.
> Just to name a few,layer comes with binaries like
>
> - getenforce
> - setenforce
> - semange
> - sestatus
> - audit2why
> - audit2allow
> - restorecon
> - chcon
>
> It also brings in various scripts that would help to label the entire
> system during the first boot.
>
> While lot of these binaries may be only required by the developer during
> the inital phase if selinux enablement and not to the end customer.
>
> I need to spend a little more time to see what can we remove form the
> layer.
>
> My suggestion is  we can defer this size work for later and start working
> on how selinux can help in openBMC security.
>
> We would be publishing the se-linux use cases in a week.
>
> Manoj is working with me on bringing down the size of se-linux layer.
>
> Regards
>
> Ratan
> On 4/5/20 6:58 PM, Anton Kachalov wrote:
>
> Hello, Ratan.
>
> Would you mind breaking down the estimation, curious about what brought up
> 18MB when enabling SELinux.
> Precompiled rules in Android took 3MB on average.
>
> On Wed, 1 Apr 2020 at 16:22, Ratan Gupta <ratagupt@linux.vnet.ibm.com>
> wrote:
>
>> Hi Joseph,
>>
>> We did some POC around selinux, will share the detailed use-cases with
>> selinux which can be useful in openbmc stack.
>>
>> selinux is taking around 18MB space on flash, Is it a concern?
>>
>> Regards
>>
>> Ratan
>>
>> On 3/31/20 9:51 PM, Joseph Reynolds wrote:
>> > This is a reminder of the OpenBMC Security Working Group meeting
>> > scheduled for this Wednesday April 1 at 10:00am PDT.
>> >
>> > We'll discuss current development items, and anything else that comes
>> up.
>> >
>> > The current topics:
>> >
>> > 1. SELinux or AppArmor plans
>> >
>> > Access, agenda, and notes are in the wiki:
>> >
>> > https://github.com/openbmc/openbmc/wiki/Security-working-group
>> >
>> > - Joseph
>> >
>>
>>

[-- Attachment #2: Type: text/html, Size: 4003 bytes --]

Re: Security Working Group - Wednesday April 1

[Anton Kachalov]

[-- Attachment #1: Type: text/plain, Size: 2902 bytes --]

Looks like an increase of image size for 18MB came from the dependencies
such as Python e.g. audit2allow that we can get rid of from the prod image.

I've tried to build AppArmor for OpenBMC. By default, it's being built with
Python and Perl as well, which also adds an extra 14MB of image size or
68MB -> 126MB unpacked rootfs increase.

Once such dependencies were dropped, I got a working AppArmor-enabled
system with only a 2MB increase.

On Mon, 6 Apr 2020 at 15:20, Anton Kachalov <rnouse@google.com> wrote:

> Thanks you for clarifying, Ratan.
>
> Meanwhile I would try to check what will give us AppArmor in terms of
> firmware's size growth.
>
> On Mon, 6 Apr 2020 at 13:24, Ratan Gupta <ratagupt@linux.vnet.ibm.com>
> wrote:
>
>> Hi Anton,
>>
>> I brought  the meta-selinux layer, that enables the selinux framework on
>> obmc-phosphor-image and it increases the size of the image by 18MB.
>>
>> This layer enables the linux kernel support for selinux framework and
>> brings in a lot of tools and scripts.
>> Just to name a few,layer comes with binaries like
>>
>> - getenforce
>> - setenforce
>> - semange
>> - sestatus
>> - audit2why
>> - audit2allow
>> - restorecon
>> - chcon
>>
>> It also brings in various scripts that would help to label the entire
>> system during the first boot.
>>
>> While lot of these binaries may be only required by the developer during
>> the inital phase if selinux enablement and not to the end customer.
>>
>> I need to spend a little more time to see what can we remove form the
>> layer.
>>
>> My suggestion is  we can defer this size work for later and start working
>> on how selinux can help in openBMC security.
>>
>> We would be publishing the se-linux use cases in a week.
>>
>> Manoj is working with me on bringing down the size of se-linux layer.
>>
>> Regards
>>
>> Ratan
>> On 4/5/20 6:58 PM, Anton Kachalov wrote:
>>
>> Hello, Ratan.
>>
>> Would you mind breaking down the estimation, curious about what brought
>> up 18MB when enabling SELinux.
>> Precompiled rules in Android took 3MB on average.
>>
>> On Wed, 1 Apr 2020 at 16:22, Ratan Gupta <ratagupt@linux.vnet.ibm.com>
>> wrote:
>>
>>> Hi Joseph,
>>>
>>> We did some POC around selinux, will share the detailed use-cases with
>>> selinux which can be useful in openbmc stack.
>>>
>>> selinux is taking around 18MB space on flash, Is it a concern?
>>>
>>> Regards
>>>
>>> Ratan
>>>
>>> On 3/31/20 9:51 PM, Joseph Reynolds wrote:
>>> > This is a reminder of the OpenBMC Security Working Group meeting
>>> > scheduled for this Wednesday April 1 at 10:00am PDT.
>>> >
>>> > We'll discuss current development items, and anything else that comes
>>> up.
>>> >
>>> > The current topics:
>>> >
>>> > 1. SELinux or AppArmor plans
>>> >
>>> > Access, agenda, and notes are in the wiki:
>>> >
>>> > https://github.com/openbmc/openbmc/wiki/Security-working-group
>>> >
>>> > - Joseph
>>> >
>>>
>>>

[-- Attachment #2: Type: text/html, Size: 4907 bytes --]

Re: Security Working Group - Wednesday April 1

[Anton Kachalov]

[-- Attachment #1: Type: text/plain, Size: 3588 bytes --]

So far there is an issue with D-Bus:

https://github.com/freedesktop/dbus/blob/master/bus/apparmor.c#L126

John Johansen has confirmed that the mainline kernel will not have
the apparmorfs/features/dbus/mask file until the mainline kernel
has AppArmor getpeersec support.

If I'm not mistaken, we do not run dbus daemons, only dbus-broker that is
clearly lack of AppArmor support:

https://github.com/bus1/dbus-broker/issues/169

https://github.com/bus1/dbus-broker/blob/master/src/launch/launcher.c#L1327

On Tue, 21 Apr 2020 at 11:57, Anton Kachalov <rnouse@google.com> wrote:

> Looks like an increase of image size for 18MB came from the dependencies
> such as Python e.g. audit2allow that we can get rid of from the prod image.
>
> I've tried to build AppArmor for OpenBMC. By default, it's being built
> with Python and Perl as well, which also adds an extra 14MB of image size
> or 68MB -> 126MB unpacked rootfs increase.
>
> Once such dependencies were dropped, I got a working AppArmor-enabled
> system with only a 2MB increase.
>
> On Mon, 6 Apr 2020 at 15:20, Anton Kachalov <rnouse@google.com> wrote:
>
>> Thanks you for clarifying, Ratan.
>>
>> Meanwhile I would try to check what will give us AppArmor in terms of
>> firmware's size growth.
>>
>> On Mon, 6 Apr 2020 at 13:24, Ratan Gupta <ratagupt@linux.vnet.ibm.com>
>> wrote:
>>
>>> Hi Anton,
>>>
>>> I brought  the meta-selinux layer, that enables the selinux framework on
>>> obmc-phosphor-image and it increases the size of the image by 18MB.
>>>
>>> This layer enables the linux kernel support for selinux framework and
>>> brings in a lot of tools and scripts.
>>> Just to name a few,layer comes with binaries like
>>>
>>> - getenforce
>>> - setenforce
>>> - semange
>>> - sestatus
>>> - audit2why
>>> - audit2allow
>>> - restorecon
>>> - chcon
>>>
>>> It also brings in various scripts that would help to label the entire
>>> system during the first boot.
>>>
>>> While lot of these binaries may be only required by the developer during
>>> the inital phase if selinux enablement and not to the end customer.
>>>
>>> I need to spend a little more time to see what can we remove form the
>>> layer.
>>>
>>> My suggestion is  we can defer this size work for later and start
>>> working on how selinux can help in openBMC security.
>>>
>>> We would be publishing the se-linux use cases in a week.
>>>
>>> Manoj is working with me on bringing down the size of se-linux layer.
>>>
>>> Regards
>>>
>>> Ratan
>>> On 4/5/20 6:58 PM, Anton Kachalov wrote:
>>>
>>> Hello, Ratan.
>>>
>>> Would you mind breaking down the estimation, curious about what brought
>>> up 18MB when enabling SELinux.
>>> Precompiled rules in Android took 3MB on average.
>>>
>>> On Wed, 1 Apr 2020 at 16:22, Ratan Gupta <ratagupt@linux.vnet.ibm.com>
>>> wrote:
>>>
>>>> Hi Joseph,
>>>>
>>>> We did some POC around selinux, will share the detailed use-cases with
>>>> selinux which can be useful in openbmc stack.
>>>>
>>>> selinux is taking around 18MB space on flash, Is it a concern?
>>>>
>>>> Regards
>>>>
>>>> Ratan
>>>>
>>>> On 3/31/20 9:51 PM, Joseph Reynolds wrote:
>>>> > This is a reminder of the OpenBMC Security Working Group meeting
>>>> > scheduled for this Wednesday April 1 at 10:00am PDT.
>>>> >
>>>> > We'll discuss current development items, and anything else that comes
>>>> up.
>>>> >
>>>> > The current topics:
>>>> >
>>>> > 1. SELinux or AppArmor plans
>>>> >
>>>> > Access, agenda, and notes are in the wiki:
>>>> >
>>>> > https://github.com/openbmc/openbmc/wiki/Security-working-group
>>>> >
>>>> > - Joseph
>>>> >
>>>>
>>>>

[-- Attachment #2: Type: text/html, Size: 6237 bytes --]

Re: Security Working Group - Wednesday April 1

[Brad Bishop]

at 5:57 AM, Anton Kachalov <rnouse@google.com> wrote:

> Once such dependencies were dropped, I got a working AppArmor-enabled  
> system with only a 2MB increase.

Hi Anton!

General question about AppArmor - would it require kernel patches to deploy  
it in OpenBMC?

thx - brad

Re: Security Working Group - Wednesday April 1

[Anton Kachalov]

[-- Attachment #1: Type: text/plain, Size: 1631 bytes --]

Hi, Brad.

AppArmor is upstreamed. I just enabled apparmor config for aspeed kernel.

Furthermore, Ubuntu's kernel has additional not upstreamed patches for
AppArmor. E.g. patch from:
https://launchpad.net/ubuntu/+archive/primary/+sourcefiles/linux/5.4.0-26.30/linux_5.4.0-26.30.diff.gz

is adding new routines like:
 -- apparmor_unix_stream_connect to check perms before making unix domain
connection
 -- apparmor_unix_may_send to check perms before conn or sending unix dgrams

and various new hooks for LSM.

Without those patches we wouldn't have all the benefits for DBus hardening.
Plus, the dbus-broker doesn't support all that stuff and needs to have
features to be ported from Freedesktop/DBus.

I'm also looking into 3rd LSM alternative: KRSI

https://lkml.org/lkml/2019/12/20/641

Nevertheless which LSM we're going to use at the end, we can define rules
in phosphor-dbus-interfaces:

https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/Control/Host.interface.yaml

to white list daemons / processes that might talk to specific methods or
query specific properties and so on.

Those definitions will be used to generate appropriate rules for underlying
LSM (besides general system-wide rules) at build time.

On Wed, 22 Apr 2020 at 14:33, Brad Bishop <bradleyb@fuzziesquirrel.com>
wrote:

> at 5:57 AM, Anton Kachalov <rnouse@google.com> wrote:
>
> > Once such dependencies were dropped, I got a working AppArmor-enabled
> > system with only a 2MB increase.
>
> Hi Anton!
>
> General question about AppArmor - would it require kernel patches to
> deploy
> it in OpenBMC?
>
> thx - brad
>

[-- Attachment #2: Type: text/html, Size: 2680 bytes --]

Re: Security Working Group - Wednesday April 1

[Brad Bishop]

at 8:10 AM, Anton Kachalov <rnouse@google.com> wrote:

> Hi, Brad.
>
> AppArmor is upstreamed. I just enabled apparmor config for aspeed kernel.
>
> Furthermore, Ubuntu's kernel has additional not upstreamed patches for  
> AppArmor. E.g. patch from:
> https://launchpad.net/ubuntu/+archive/primary/+sourcefiles/linux/5.4.0-26.30/linux_5.4.0-26.30.diff.gz
>
> is adding new routines like:
>  -- apparmor_unix_stream_connect to check perms before making unix domain connection
>  -- apparmor_unix_may_send to check perms before conn or sending unix dgrams
>
> and various new hooks for LSM.
>
> Without those patches we wouldn't have all the benefits for DBus  
> hardening. Plus, the dbus-broker doesn't support all that stuff and needs  
> to have features to be ported from Freedesktop/DBus.

Ok.  I just wanted to suggest that when we weigh the pros and cons of the  
different LSMs, that upstream support is taken into consideration.  Thanks  
for the detailed reply!

-brad