Security Working Group - Wednesday April 1

[Anton Kachalov]

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 at 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 at 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 at 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 at 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
>>>> >
>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200421/33d62201/attachment.htm>