Re: [bitbake-devel] [PATCH [RFC] 1/2] utils: Add landlock_restrict_network function

David Nyström <[email protected]> Fri, 17 Jul 2026 20:11:11 +0200 (CEST)
Newsgroups org.openembedded.lists.bitbake-devel
Message-ID <[email protected]>
--83233296248056541784311871881947
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE



On Mon, 15 Jun 2026, Paul Barker wrote:

> On Fri, 2026-06-12 at 13:38 +0200, David Nystr=C3=B6m wrote:
>> Add landlock_restrict_network() which blocks TCP bind/connect using
>> Landlock LSM (ABI v4+, kernel 6.7+). Designed to stack with the
>> existing disable_network() namespace isolation, covering the case
>> where disable_network() is skipped for non-local UIDs.
>>
>> Gracefully returns False on older kernels (ABI < 4).
>>
>> Signed-off-by: David Nystr=C3=B6m <[email protected]>
>
> Hi David,
>
> I think adding this is a good idea, but the code needs a few changes to
> ensure it is maintainable.

Thanks for the review, and good comments.
My comments below.

>> ---
>>  lib/bb/utils.py | 26 ++++++++++++++++++++++++++
>>  1 file changed, 26 insertions(+)
>>
>> diff --git a/lib/bb/utils.py b/lib/bb/utils.py
>> index 181082c95..1347c29d0 100644
>> --- a/lib/bb/utils.py
>> +++ b/lib/bb/utils.py
>> @@ -2054,6 +2054,32 @@ def disable_network(uid=3DNone, gid=3DNone):
>>      with open("/proc/self/gid_map", "w") as f:
>>          f.write("%s %s 1" % (gid, gid))
>>
>> +def landlock_restrict_network():
>> +    """Block TCP bind/connect using Landlock LSM (ABI v4+, kernel 6.7+)=
.
>> +    Gracefully skipped on older kernels. Stacks with disable_network().=
"""
>> +
>> +    NR_CREATE =3D 444  # landlock_create_ruleset
>> +    NR_SELF   =3D 446  # landlock_restrict_self
>> +    NET_TCP   =3D 0x3  # BIND_TCP | CONNECT_TCP
>
> We should base these on the names used in the Linux kernel so it's easy
> to search for things and compare with example C code in the docs. So,
>
>    NR_landlock_create_ruleset =3D 444
>    NR_landlock_add_rule =3D 445
>
>    LANDLOCK_ACCESS_NET_BIND_TCP =3D 0x1
>    LANDLOCK_ACCESS_NET_CONNECT_TCP =3D 0x2
>
>    LANDLOCK_CREATE_RULESET_VERSION =3D 1

+1.

>> +
>> +    libc =3D ctypes.CDLL('libc.so.6')
>> +
>> +    abi =3D libc.syscall(NR_CREATE, 0, 0, 1)
>> +    if abi < 4:
>> +        return False
>
>    # Check that landlock is enabled and supports network access
>    # restriction (added in ABI version 4)
>    abi =3D libc.syscall(NR_landlock_create_ruleset,
>                       0, 0,
>                       LANDLOCK_CREATE_RULESET_VERSION)
>    if abi < 4:
>        logger.debug("System doesn't support disabling network via landloc=
k")
>        return False
>
> That's a litte more verbose, but much clearer.

Good point.

>> +
>> +    attr =3D struct.pack("QQ", 0, NET_TCP)
>> +    buf =3D ctypes.create_string_buffer(attr)
>> +    fd =3D libc.syscall(NR_CREATE, buf, len(attr), 0)
>> +    if fd < 0:
>> +        return False
>
> We probably also want a logger.debug() call to log the failure here as
> well.
>
>> +
>> +    libc.prctl(38, 1, 0, 0, 0)  # PR_SET_NO_NEW_PRIVS
>
> The commit message only describes use of landlock, not no_new_privs. We
> need constants for this call as well.

Also a very good point, setuid/gid and setcap:ed binaries will=20
silently run without privs, which should be documented also in the commit m=
essage.
This is a landlock requirement for unpriv use, and the main source of=20
potential sideeffects I would expect from this approach.
Since there is no way do disable it, without setting the=20
"network" flag on a failing task, I'd really want to gain more=20
confidence about the potential sideeffects of no_new_privs on=20
various edge cases before I send a non-RFC patch.
Testing is ongoing with your comments addressed, but I will not be able to=
=20
finish before my vacation starts(tomorrow). If considered urgent,
feel free to use idea only.

>> +    r =3D libc.syscall(NR_SELF, fd, 0)
>> +    os.close(fd)
>> +    return r =3D=3D 0
>> +
>> +
>>  def export_proxies(d):
>>      from bb.fetch2 import get_fetcher_environment
>>      """ export common proxies variables from datastore to environment "=
""
>
> Thanks,
>
> --=20
> Paul Barker
>
>
>=

--83233296248056541784311871881947--