overlayFS security concern

[Milton Miller II]

On Feb 22, Lei Yu wrote:
>On Sun, Feb 21, 2021 at 12:56 AM Patrick Williams <patrick at stwcx.xyz>
>wrote:
>> On Sat, Feb 20, 2021 at 11:46:08AM +1030, Andrew Jeffery wrote:
>> > On Sat, 20 Feb 2021, at 11:01, Kun Zhao wrote:
>> > > 2. don’t use overlayFS (but it’s really useful for debugging
>during
>> > > develop, and configuration management)
>> >
>> > Possibly, but it's probably worth looking at IMA instead:
>>
>> IMA (or similar) is likely a good option.
>>
>> There is also work going on to remove 'root' from many users and
>> daemons so it should be harder to overwrite executables.  If you
>> have root I'm pretty sure you can always subvert even something
>like
>> IMA.
>>


>> A protection we could do which would make attacks slightly harder
>> than they are today would be to change how we mount OverlayFS.
>Right
>> now we mount it on top of root, but we could be more explicit about
>> mounting it only on top of places we expect to be read-write.
>`/etc`
>> and `/var` are the two that come to mind but I'm sure there are
>others.
>> This shouldn't be very difficult to implement for someone wanting
>to
>> take the initiative.
>

I've offered before and the offer still stands.

As the author of the original system layout including the init 
and update scripts in the base layout and havng provided design 
input to all 3 of the base, ubi, and mmc layouts I'm happy to 
work on migrating the base layout to also transition from full 
filesystem overlay to the direct mount of var with etc overlay 
that exists on the other two layouts.

However, I don't have the access needed to test and regress the 
transition from the current layout.  I need the assistance of 
someone that is using the current layout and willing to test and 
provide feedback on the transition.

[ Openbmc developent is not my primary work and I don't have 
access to a system using the static layout that I can get 
reflashed for recovery ]


Once this is done we can work as a community to seperate out the 
overload of defaults and configuration that is in etc, probably 
by a combination of moving openbmc content to /var/lib, and 
perhaps by making /etc distributed empty via the system empty 
init support (where /etc would be a plain writable filesystem 
of pure configuration vs distribution defaults).

Only after that can overlayfs be removed from the kernel.

>Yup, as far as I remember, the "ubi layout" distro feature only mount
>specific directories instead of root.
>Checking the code, it enables the `read-only-rootfs`
>IMAGE_FEATURES[1], and use a different init script to mount only /etc
>by `preinit-mounts.bb`[2]
>The same for `phosphor-mmc` as well.
>
>@anoo should know this well :)
>

And I also know it, having been involved in all three layouts.

>[1]:
>https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openb
>mc_openbmc_blob_master_meta-2Dphosphor_recipes-2Dphosphor_images_obmc
>-2Dphosphor-2Dimage.bb-23L35&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=bvv7
>AJEECoRKBU02rcu4F5DWd-EwX8As2xrXeO9ZSo4&m=Lykl2abBxWlXUeD9IOsaSRujrlt
>BLI3LARBleKpfHMA&s=R_DHDXjMbd3D6V1ycREvdpSYQpPPGmYQdRctW3JRnHU&e= 
>[2]:
>https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openb
>mc_openbmc_blob_master_meta-2Dphosphor_recipes-2Dphosphor_preinit-2Dm
>ounts_preinit-2Dmounts_init&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=bvv7A
>JEECoRKBU02rcu4F5DWd-EwX8As2xrXeO9ZSo4&m=Lykl2abBxWlXUeD9IOsaSRujrltB
>LI3LARBleKpfHMA&s=DSsCadWHqoLFHZ2JIx0c6psN1joBzjxI-je9q6is13I&e= 
>
>-- 
>BRs,
>Lei YU


milton