diff mbox series

bitbake-worker: skipping disable network when unprivileged userns is restricted

Message ID 20240708081034.1474312-1-changqing.li@windriver.com
State New
Headers show
Series bitbake-worker: skipping disable network when unprivileged userns is restricted | expand

Commit Message

Changqing Li July 8, 2024, 8:10 a.m. UTC
From: Chen Qi <Qi.Chen@windriver.com>

From ubuntu24.04, apparmor is enabled by default, and unprivileged
userns is restricted, which causes following error when bitbake-worker
try to disable network:
Traceback (most recent call last):
  File "/poky/bitbake/bin/bitbake-worker", line 278, in child
    bb.utils.disable_network(uid, gid)
  File "/poky/bitbake/lib/bb/utils.py", line 1696, in disable_network
    with open("/proc/self/uid_map", "w") as f:
PermissionError: [Errno 1] Operation not permitted

Like what we have done for non local uid, skip disable network in above
condition to avoid have to disable profile unprivileged_userns for the
host or have to config a profile per project

[1] https://lists.yoctoproject.org/g/yocto/topic/workaround_for_uid_map_error/106192359

Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Changqing Li <changqing.li@windriver.com>
---
 bitbake/bin/bitbake-worker | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

Comments

Alexander Kanavin July 8, 2024, 8:36 a.m. UTC | #1
Should we rather direct users to disable the apparmor restriction? I
don't think an important QA constraint in the bitbake build process
should be automatically disabled this way.

Wasn't there also an upstream discussion/ticket with ubuntu? I'd
rather have this resolved upstream. Disabling the network check
instead isn't going to help that.

Alex

On Mon, 8 Jul 2024 at 10:10, Changqing Li via lists.openembedded.org
<changqing.li=windriver.com@lists.openembedded.org> wrote:
>
> From: Chen Qi <Qi.Chen@windriver.com>
>
> From ubuntu24.04, apparmor is enabled by default, and unprivileged
> userns is restricted, which causes following error when bitbake-worker
> try to disable network:
> Traceback (most recent call last):
>   File "/poky/bitbake/bin/bitbake-worker", line 278, in child
>     bb.utils.disable_network(uid, gid)
>   File "/poky/bitbake/lib/bb/utils.py", line 1696, in disable_network
>     with open("/proc/self/uid_map", "w") as f:
> PermissionError: [Errno 1] Operation not permitted
>
> Like what we have done for non local uid, skip disable network in above
> condition to avoid have to disable profile unprivileged_userns for the
> host or have to config a profile per project
>
> [1] https://lists.yoctoproject.org/g/yocto/topic/workaround_for_uid_map_error/106192359
>
> Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
> Signed-off-by: Changqing Li <changqing.li@windriver.com>
> ---
>  bitbake/bin/bitbake-worker | 15 ++++++++++++---
>  1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/bitbake/bin/bitbake-worker b/bitbake/bin/bitbake-worker
> index e8073f2ac3..0a042fdc7c 100755
> --- a/bitbake/bin/bitbake-worker
> +++ b/bitbake/bin/bitbake-worker
> @@ -272,12 +272,21 @@ def fork_off_task(cfg, data, databuilder, workerdata, extraconfigdata, runtask):
>
>                  bb.utils.set_process_name("%s:%s" % (the_data.getVar("PN"), taskname.replace("do_", "")))
>
> +                def skip_disable_network(taskname, uid):
> +                    if not bb.utils.is_local_uid(uid):
> +                        logger.debug("Skipping disable network for %s since %s is not a local uid." % (taskname, uid))
> +                        return True
> +                    if os.path.exists("/proc/sys/kernel/apparmor_restrict_unprivileged_userns"):
> +                        with open("/proc/sys/kernel/apparmor_restrict_unprivileged_userns") as f:
> +                            if f.readline().strip() == "1":
> +                                logger.debug("Skipping disable network since sys.kernel.apparmor_restrict_unprivileged_userns is 1")
> +                                return True
> +                    return False
> +
>                  if not bb.utils.to_boolean(the_data.getVarFlag(taskname, 'network')):
> -                    if bb.utils.is_local_uid(uid):
> +                    if not skip_disable_network(taskname, uid):
>                          logger.debug("Attempting to disable network for %s" % taskname)
>                          bb.utils.disable_network(uid, gid)
> -                    else:
> -                        logger.debug("Skipping disable network for %s since %s is not a local uid." % (taskname, uid))
>
>                  # exported_vars() returns a generator which *cannot* be passed to os.environ.update()
>                  # successfully. We also need to unset anything from the environment which shouldn't be there
> --
> 2.25.1
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#16397): https://lists.openembedded.org/g/bitbake-devel/message/16397
> Mute This Topic: https://lists.openembedded.org/mt/107099079/1686489
> Group Owner: bitbake-devel+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/bitbake-devel/unsub [alex.kanavin@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
ChenQi July 8, 2024, 9:12 a.m. UTC | #2
On 7/8/24 16:36, Alexander Kanavin wrote:
> Should we rather direct users to disable the apparmor restriction?

How about an extra patch for the env init script to warn users about 
this situation?

There have already been some check there. e.g.,

py_v38_check=$(python3 -c 'import sys; print(sys.version_info >= (3,8,0))')

> I
> don't think an important QA constraint in the bitbake build process
> should be automatically disabled this way.
It's a best-to-have feature. It's not 100% necessary to have an image 
built out. There's already a is_local_uid check that skips network 
disabling.
> Wasn't there also an upstream discussion/ticket with ubuntu? I'd
> rather have this resolved upstream.
Frankly I'm not very optimistic about Ubuntu solving this problem. We're 
on our own.
>   Disabling the network check
> instead isn't going to help that.

Hopefully we can lower the barrier for people to use Yocto if possible, 
even if they use Ubuntu24 and know little about apparmor.

P.S.

This problem has reported to Ubuntu for 4 months. It was discussed on 
the Yocto mailing list. People seem to be waiting for Ubuntu. I'm not 
very optimistic about getting a solution from Ubuntu.

Regards,

Qi

>
> Alex
>
> On Mon, 8 Jul 2024 at 10:10, Changqing Li via lists.openembedded.org
> <changqing.li=windriver.com@lists.openembedded.org> wrote:
>> From: Chen Qi <Qi.Chen@windriver.com>
>>
>>  From ubuntu24.04, apparmor is enabled by default, and unprivileged
>> userns is restricted, which causes following error when bitbake-worker
>> try to disable network:
>> Traceback (most recent call last):
>>    File "/poky/bitbake/bin/bitbake-worker", line 278, in child
>>      bb.utils.disable_network(uid, gid)
>>    File "/poky/bitbake/lib/bb/utils.py", line 1696, in disable_network
>>      with open("/proc/self/uid_map", "w") as f:
>> PermissionError: [Errno 1] Operation not permitted
>>
>> Like what we have done for non local uid, skip disable network in above
>> condition to avoid have to disable profile unprivileged_userns for the
>> host or have to config a profile per project
>>
>> [1] https://lists.yoctoproject.org/g/yocto/topic/workaround_for_uid_map_error/106192359
>>
>> Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
>> Signed-off-by: Changqing Li <changqing.li@windriver.com>
>> ---
>>   bitbake/bin/bitbake-worker | 15 ++++++++++++---
>>   1 file changed, 12 insertions(+), 3 deletions(-)
>>
>> diff --git a/bitbake/bin/bitbake-worker b/bitbake/bin/bitbake-worker
>> index e8073f2ac3..0a042fdc7c 100755
>> --- a/bitbake/bin/bitbake-worker
>> +++ b/bitbake/bin/bitbake-worker
>> @@ -272,12 +272,21 @@ def fork_off_task(cfg, data, databuilder, workerdata, extraconfigdata, runtask):
>>
>>                   bb.utils.set_process_name("%s:%s" % (the_data.getVar("PN"), taskname.replace("do_", "")))
>>
>> +                def skip_disable_network(taskname, uid):
>> +                    if not bb.utils.is_local_uid(uid):
>> +                        logger.debug("Skipping disable network for %s since %s is not a local uid." % (taskname, uid))
>> +                        return True
>> +                    if os.path.exists("/proc/sys/kernel/apparmor_restrict_unprivileged_userns"):
>> +                        with open("/proc/sys/kernel/apparmor_restrict_unprivileged_userns") as f:
>> +                            if f.readline().strip() == "1":
>> +                                logger.debug("Skipping disable network since sys.kernel.apparmor_restrict_unprivileged_userns is 1")
>> +                                return True
>> +                    return False
>> +
>>                   if not bb.utils.to_boolean(the_data.getVarFlag(taskname, 'network')):
>> -                    if bb.utils.is_local_uid(uid):
>> +                    if not skip_disable_network(taskname, uid):
>>                           logger.debug("Attempting to disable network for %s" % taskname)
>>                           bb.utils.disable_network(uid, gid)
>> -                    else:
>> -                        logger.debug("Skipping disable network for %s since %s is not a local uid." % (taskname, uid))
>>
>>                   # exported_vars() returns a generator which *cannot* be passed to os.environ.update()
>>                   # successfully. We also need to unset anything from the environment which shouldn't be there
>> --
>> 2.25.1
>>
>>
>> -=-=-=-=-=-=-=-=-=-=-=-
>> Links: You receive all messages sent to this group.
>> View/Reply Online (#16397): https://lists.openembedded.org/g/bitbake-devel/message/16397
>> Mute This Topic: https://lists.openembedded.org/mt/107099079/1686489
>> Group Owner: bitbake-devel+owner@lists.openembedded.org
>> Unsubscribe: https://lists.openembedded.org/g/bitbake-devel/unsub [alex.kanavin@gmail.com]
>> -=-=-=-=-=-=-=-=-=-=-=-
>>
Alexander Kanavin July 8, 2024, 9:25 a.m. UTC | #3
On Mon, 8 Jul 2024 at 11:12, ChenQi <Qi.Chen@windriver.com> wrote:
> This problem has reported to Ubuntu for 4 months. It was discussed on
> the Yocto mailing list. People seem to be waiting for Ubuntu. I'm not
> very optimistic about getting a solution from Ubuntu.

I do not agree. The last comment  (#10, added two weeks ago) in
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2056555 shows
how to create an apparmor profile specifically for bitbake, so once
this is added to apparmor upstream and makes its way into Ubuntu the
problem will be solved. At that point the forced network disabling
will become unnecessary and damaging. Ubuntu release notes imply
they've done it for things like Chrome and Discord, but they expect
more to be added:

https://discourse.ubuntu.com/t/ubuntu-24-04-lts-noble-numbat-release-notes/39890#security-improvements

Alex
Changqing Li July 9, 2024, 2:41 a.m. UTC | #4
On 7/8/24 17:25, Alexander Kanavin wrote:
> CAUTION: This email comes from a non Wind River email account!
> Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
> On Mon, 8 Jul 2024 at 11:12, ChenQi<Qi.Chen@windriver.com>  wrote:
>> This problem has reported to Ubuntu for 4 months. It was discussed on
>> the Yocto mailing list. People seem to be waiting for Ubuntu. I'm not
>> very optimistic about getting a solution from Ubuntu.
> I do not agree. The last comment  (#10, added two weeks ago) in
> https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2056555  shows
> how to create an apparmor profile specifically for bitbake, so once
> this is added to apparmor upstream and makes its way into Ubuntu the
> problem will be solved. At that point the forced network disabling
> will become unnecessary and damaging. Ubuntu release notes imply
> they've done it for things like Chrome and Discord, but they expect
> more to be added:
>
> https://discourse.ubuntu.com/t/ubuntu-24-04-lts-noble-numbat-release-notes/39890#security-improvements

I think applications like Chrome, thunderbird etc are commonly used 
applications by user, so they are might in

ubuntu's package repo,  so they will support it and add profile for it 
by default.  But for bitbake,  it is mostly

for developer and and not support by ubuntu.  And considering there 
might be many other softwares meet this issue,

so I am not optimistic that ubuntu will add default profile for all 
these softwares.  so maybe we are still on our own.

One option is using this patch,  so users don't have to struggle on this 
problem, don't need sudo, don't need an apparmor profile etc,

but have the side effect that skip disable network,  we need to balance 
which to choose.

One option is document or  notice message in oe-init-build-env,  suggest 
user to disable unprivileged_userns or write a profile for bitbake.


Regards

Changqing

>
> Alex
Richard Purdie July 9, 2024, 10:58 a.m. UTC | #5
On Tue, 2024-07-09 at 10:41 +0800, Changqing Li via lists.openembedded.org wrote:
>  
> On 7/8/24 17:25, Alexander Kanavin wrote:
> > On Mon, 8 Jul 2024 at 11:12, ChenQi <Qi.Chen@windriver.com> wrote:
> > > 
> > > This problem has reported to Ubuntu for 4 months. It was discussed on
> > > the Yocto mailing list. People seem to be waiting for Ubuntu. I'm not
> > > very optimistic about getting a solution from Ubuntu.
> > > I do not agree. The last comment  (#10, added two weeks ago) in
> > https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2056555 shows
> > how to create an apparmor profile specifically for bitbake, so once
> > this is added to apparmor upstream and makes its way into Ubuntu the
> > problem will be solved. At that point the forced network disabling
> > will become unnecessary and damaging. Ubuntu release notes imply
> > they've done it for things like Chrome and Discord, but they expect
> > more to be added:
> > 
> > https://discourse.ubuntu.com/t/ubuntu-24-04-lts-noble-numbat-release-notes/39890#security-improvements
> > 
> I think applications like Chrome, thunderbird etc are commonly used applications by user, so they are might in
> ubuntu's package repo,  so they will support it and add profile for it by default.  But for bitbake,  it is mostly
> for developer and and not support by ubuntu.  And considering  there might be many other softwares meet this issue,
> so I am not optimistic that ubuntu will add default profile for all these softwares.  so maybe we are still on our own.
> One option is using this patch,  so users don't have to struggle on this problem, don't need sudo, don't need an apparmor profile etc, 
> but have the side effect that skip disable network,  we need to balance which to choose.
> One option is document or  notice message in oe-init-build-env,  suggest user to disable unprivileged_userns or write a profile for bitbake.

I do not want to just stop disabling the network silently so the patch
as written isn't an option.

I'm also not keen to make oe-init-build-env too complex, it is meant to
be just enough to get us into bitbake, nothing more. Adding sanity
checks there is the wrong place. This could happen in the normal
sanity.bbclass code but we need to make sure it triggers when a user
upgrades their existing distro.

I think we should open a new ticket with ubuntu specifically about
adding a profile for bitbake and see if we can get a definitive answer
on whether we can add a profile for it or not. I'd suggest a new ticket
so we don't get confused with the comments in the one linked above.

Cheers,

Richard
Alexander Kanavin July 9, 2024, 11:02 a.m. UTC | #6
On Tue, 9 Jul 2024 at 04:42, Changqing Li <changqing.li@windriver.com> wrote:

> I think applications like Chrome, thunderbird etc are commonly used applications by user, so they are might in
> ubuntu's package repo,  so they will support it and add profile for it by default.  But for bitbake,  it is mostly
> for developer and and not support by ubuntu.  And considering  there might be many other softwares meet this issue,
> so I am not optimistic that ubuntu will add default profile for all these softwares.  so maybe we are still on our own.
> One option is using this patch,  so users don't have to struggle on this problem, don't need sudo, don't need an apparmor profile etc,

Yes. Things will 'just work' on the surface. But you would also be
doing those users a disservice by quietly disabling an important check
behind their back, and not even letting them know that. Some users
will not be happy to learn that after the fact.

> but have the side effect that skip disable network,  we need to balance which to choose.
>
> One option is document or  notice message in oe-init-build-env,  suggest user to disable unprivileged_userns or write a profile for bitbake.

I wonder if we can wrap the actual /proc/self/... writing calls in
disable_network() (I think this is where things fail without system
tweaks?) with an exception handler pointing people to instructions
about installing an apparmor profile. It wouldn't be optimal (this
happens in a task execution, not in a build setup), but it would help.

Alex
Changqing Li July 10, 2024, 3:28 a.m. UTC | #7
On 7/9/24 18:58, Richard Purdie wrote:
> CAUTION: This email comes from a non Wind River email account!
> Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
> On Tue, 2024-07-09 at 10:41 +0800, Changqing Li via lists.openembedded.org wrote:
>> On 7/8/24 17:25, Alexander Kanavin wrote:
>>> On Mon, 8 Jul 2024 at 11:12, ChenQi<Qi.Chen@windriver.com>  wrote:
>>>> This problem has reported to Ubuntu for 4 months. It was discussed on
>>>> the Yocto mailing list. People seem to be waiting for Ubuntu. I'm not
>>>> very optimistic about getting a solution from Ubuntu.
>>>>   I do not agree. The last comment  (#10, added two weeks ago) in
>>> https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2056555  shows
>>> how to create an apparmor profile specifically for bitbake, so once
>>> this is added to apparmor upstream and makes its way into Ubuntu the
>>> problem will be solved. At that point the forced network disabling
>>> will become unnecessary and damaging. Ubuntu release notes imply
>>> they've done it for things like Chrome and Discord, but they expect
>>> more to be added:
>>>
>>> https://discourse.ubuntu.com/t/ubuntu-24-04-lts-noble-numbat-release-notes/39890#security-improvements
>>>
>> I think applications like Chrome, thunderbird etc are commonly used applications by user, so they are might in
>> ubuntu's package repo,  so they will support it and add profile for it by default.  But for bitbake,  it is mostly
>> for developer and and not support by ubuntu.  And considering  there might be many other softwares meet this issue,
>> so I am not optimistic that ubuntu will add default profile for all these softwares.  so maybe we are still on our own.
>> One option is using this patch,  so users don't have to struggle on this problem, don't need sudo, don't need an apparmor profile etc,
>> but have the side effect that skip disable network,  we need to balance which to choose.
>> One option is document or  notice message in oe-init-build-env,  suggest user to disable unprivileged_userns or write a profile for bitbake.
> I do not want to just stop disabling the network silently so the patch
> as written isn't an option.
>
> I'm also not keen to make oe-init-build-env too complex, it is meant to
> be just enough to get us into bitbake, nothing more. Adding sanity
> checks there is the wrong place. This could happen in the normal
> sanity.bbclass code but we need to make sure it triggers when a user
> upgrades their existing distro.
>
> I think we should open a new ticket with ubuntu specifically about
> adding a profile for bitbake and see if we can get a definitive answer
> on whether we can add a profile for it or not. I'd suggest a new ticket
> so we don't get confused with the comments in the one linked above.

file a new ticket 
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2072615

let's wait to see if the recommended profile can be acceptted.

Regards

Changqing

>
> Cheers,
>
> Richard
>
>
>
Changqing Li July 11, 2024, 1:39 a.m. UTC | #8
On 7/10/24 11:28, Changqing Li via lists.openembedded.org wrote:
>
>
> On 7/9/24 18:58, Richard Purdie wrote:
>> CAUTION: This email comes from a non Wind River email account!
>> Do not click links or open attachments unless you recognize the sender and know the content is safe.
>>
>> On Tue, 2024-07-09 at 10:41 +0800, Changqing Li via lists.openembedded.org wrote:
>>> On 7/8/24 17:25, Alexander Kanavin wrote:
>>>> On Mon, 8 Jul 2024 at 11:12, ChenQi<Qi.Chen@windriver.com>  wrote:
>>>>> This problem has reported to Ubuntu for 4 months. It was discussed on
>>>>> the Yocto mailing list. People seem to be waiting for Ubuntu. I'm not
>>>>> very optimistic about getting a solution from Ubuntu.
>>>>>   I do not agree. The last comment  (#10, added two weeks ago) in
>>>> https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2056555  shows
>>>> how to create an apparmor profile specifically for bitbake, so once
>>>> this is added to apparmor upstream and makes its way into Ubuntu the
>>>> problem will be solved. At that point the forced network disabling
>>>> will become unnecessary and damaging. Ubuntu release notes imply
>>>> they've done it for things like Chrome and Discord, but they expect
>>>> more to be added:
>>>>
>>>> https://discourse.ubuntu.com/t/ubuntu-24-04-lts-noble-numbat-release-notes/39890#security-improvements
>>>>
>>> I think applications like Chrome, thunderbird etc are commonly used applications by user, so they are might in
>>> ubuntu's package repo,  so they will support it and add profile for it by default.  But for bitbake,  it is mostly
>>> for developer and and not support by ubuntu.  And considering  there might be many other softwares meet this issue,
>>> so I am not optimistic that ubuntu will add default profile for all these softwares.  so maybe we are still on our own.
>>> One option is using this patch,  so users don't have to struggle on this problem, don't need sudo, don't need an apparmor profile etc,
>>> but have the side effect that skip disable network,  we need to balance which to choose.
>>> One option is document or  notice message in oe-init-build-env,  suggest user to disable unprivileged_userns or write a profile for bitbake.
>> I do not want to just stop disabling the network silently so the patch
>> as written isn't an option.
>>
>> I'm also not keen to make oe-init-build-env too complex, it is meant to
>> be just enough to get us into bitbake, nothing more. Adding sanity
>> checks there is the wrong place. This could happen in the normal
>> sanity.bbclass code but we need to make sure it triggers when a user
>> upgrades their existing distro.
>>
>> I think we should open a new ticket with ubuntu specifically about
>> adding a profile for bitbake and see if we can get a definitive answer
>> on whether we can add a profile for it or not. I'd suggest a new ticket
>> so we don't get confused with the comments in the one linked above.
>
> file a new ticket 
> https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2072615
>
> let's wait to see if the recommended profile can be acceptted.
>
Hi,

The request is rejected as following comments:

Unfortunately, as John has stated in this comment:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2063976/comments/3 
<https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2063976/comments/3>
We are not able to ship a profile for bitbake running in a writable 
location of an unprivileged user because it could be used to bypass the 
restriction.

Regards

Changqing

> Regards
>
> Changqing
>
>> Cheers,
>>
>> Richard
>>
>>
>>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#16414):https://lists.openembedded.org/g/bitbake-devel/message/16414
> Mute This Topic:https://lists.openembedded.org/mt/107099079/3616873
> Group Owner:bitbake-devel+owner@lists.openembedded.org
> Unsubscribe:https://lists.openembedded.org/g/bitbake-devel/unsub  [changqing.li@windriver.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
Richard Purdie July 11, 2024, 4:56 p.m. UTC | #9
On Thu, 2024-07-11 at 09:39 +0800, Changqing Li via
lists.openembedded.org wrote:
> The request is rejected as following comments:
>  
> Unfortunately, as John has stated in this comment:
>  
> https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2063976/commen
> ts/3
>  We are not able to ship a profile for bitbake running in a writable
> location of an unprivileged user because it could be used to bypass
> the restriction.
>  

Sad but I can see why.

In that case we should put a sanity check into sanity.bbclass to detect
the permissions issue and point the user at docs on how to make things
work if the issue is present.

Cheers,

Richard
diff mbox series

Patch

diff --git a/bitbake/bin/bitbake-worker b/bitbake/bin/bitbake-worker
index e8073f2ac3..0a042fdc7c 100755
--- a/bitbake/bin/bitbake-worker
+++ b/bitbake/bin/bitbake-worker
@@ -272,12 +272,21 @@  def fork_off_task(cfg, data, databuilder, workerdata, extraconfigdata, runtask):
 
                 bb.utils.set_process_name("%s:%s" % (the_data.getVar("PN"), taskname.replace("do_", "")))
 
+                def skip_disable_network(taskname, uid):
+                    if not bb.utils.is_local_uid(uid):
+                        logger.debug("Skipping disable network for %s since %s is not a local uid." % (taskname, uid))
+                        return True
+                    if os.path.exists("/proc/sys/kernel/apparmor_restrict_unprivileged_userns"):
+                        with open("/proc/sys/kernel/apparmor_restrict_unprivileged_userns") as f:
+                            if f.readline().strip() == "1":
+                                logger.debug("Skipping disable network since sys.kernel.apparmor_restrict_unprivileged_userns is 1")
+                                return True
+                    return False
+
                 if not bb.utils.to_boolean(the_data.getVarFlag(taskname, 'network')):
-                    if bb.utils.is_local_uid(uid):
+                    if not skip_disable_network(taskname, uid):
                         logger.debug("Attempting to disable network for %s" % taskname)
                         bb.utils.disable_network(uid, gid)
-                    else:
-                        logger.debug("Skipping disable network for %s since %s is not a local uid." % (taskname, uid))
 
                 # exported_vars() returns a generator which *cannot* be passed to os.environ.update() 
                 # successfully. We also need to unset anything from the environment which shouldn't be there