Re: [bitbake-devel] [PATCH RFC 0/2] bitbake: Add basic landlock support

["David Nyström" <david.nystrom@est.tech>]

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



On Wed, 9 Sep 2026, Richard Purdie wrote:

> Hi David,
>
> On Thu, 2026-07-16 at 17:50 +0200, David Nyström wrote:
>> On Thu, 16 Jul 2026, Richard Purdie wrote:
>>> On Fri, 2026-06-12 at 13:38 +0200, David Nyström via lists.openembedded.org wrote:
>>>> When current implementation runs in an unprivileged docker container,
>>>> basic networking will be allowed by default in all steps, ignoring the
>>>> network varflags intention.
>>>> Introduce support for landlock blocking of bind and connect, providing
>>>> basic support for blocking TCP.
>>>> UDP is corrently beeing worked on upstream, but not yet supported.
>>>>
>>>> Landlock requires PR_SET_NO_NEW_PRIVS to prevent escape,
>>>> which is also attempted, this prevents privilege escalation from child.
>>>> devshell and related are already tagged with network varflag and
>>>> can sudo at will.
>>>>
>>>> syscall ABI is asm-generic, 5.13+ for all archs except alpha.
>>>> On alpha, we leak 2 fd:s in the childs context before graceful exit,
>>>> which is cleaned up at child termination.
>>>> Don't have an alpha target, so this is not tested, evaluated via
>>>> static analysis only.
>>>>
>>>> Landlock also provides a future possibility for filesystem
>>>> limitations with the purpose of catching bugs, and preventing
>>>> persistance of supply chain releated payloads. writes to f.ex.
>>>> .bashrc and friends.
>>>>
>>>> Signed-off-by: David Nyström <david.nystrom@est.tech>
>>>> ---
>>>> David Nyström (2):
>>>>       utils: Add landlock_restrict_network function
>>>>       bitbake-worker: Call landlock_restrict_network for tasks without network
>>>>
>>>>  bin/bitbake-worker |  2 ++
>>>>  lib/bb/utils.py    | 26 ++++++++++++++++++++++++++
>>>>  2 files changed, 28 insertions(+)
>>>
>>> I think this has generally has positive comments, we just need to take
>>> Paul's review comments into account about the magic numbers. Would you
>>> be able to send a version with those tweaks?
>>
>> Yes, thanks for the review, and sorry for the late reply.
>> Will reroll with comments.
>
> These still are in the queue and desired, do you think you'll get a
> chance to look at them?

I did a v2, but have been hesitating to send a non-RFC, since the 
test-scope for this is bit overwhelming.

This due to the change of default task behaviour in regards
to no_new_privs. I'm not too worried at about
LSMs running beeing parent to bitbake, but there will likely be 
unintended fallout for sublayer tasks, where I've managed to test only a 
tiny subset of them.

Problematic tasks can of course be flagged with "network", to avoid 
no_new_privs, but that seems a bit wrong, but I failed to find a better 
solution. f.ex. The only reason the tap setup still works for do_testimage 
is due to its "network" tag.

Adding Bruce to CC, since I found some fusermount usage in 
vrunner(meta-virtualization) 
when probing through sub-layers, which usually is setcap:ed.
There are likely other cases downstream.

Whats scope was tested during its time in master-next ?

> Cheers,
>
> Richard
>