Thanks, we don't have an issue with bitbake, the issue comes down to running code out of a user writable location.
1. The location of bitbake will vary by user. Making any profile we could ship only functional for a subset of bitbak users. For the others it would require a privileged action to enable.
2. Enabling unprivileged user namespaces in a user writable location (an unprivileged action) allows an exploit to by-pass the restriction by writing that locations, as part of its setup. Doing this at a distro level advertises that location is available to all users, making it easy for exploits to be able to detect and adapt to this. When a user chooses to do it locally, it greatly reduces the risk compared to the distro level enablement.
Unfortunately atm this forces the user to understand what is going on and manually enable a profile for the application. We are working on a GUI method that users will be able to use, making this task easier. Unfortunately this also comes with the risk of users just click yes/enable without understanding the risk, but there is no way around that problem.
@kanavin:
Thanks, we don't have an issue with bitbake, the issue comes down to running code out of a user writable location.
1. The location of bitbake will vary by user. Making any profile we could ship only functional for a subset of bitbak users. For the others it would require a privileged action to enable.
2. Enabling unprivileged user namespaces in a user writable location (an unprivileged action) allows an exploit to by-pass the restriction by writing that locations, as part of its setup. Doing this at a distro level advertises that location is available to all users, making it easy for exploits to be able to detect and adapt to this. When a user chooses to do it locally, it greatly reduces the risk compared to the distro level enablement.
Unfortunately atm this forces the user to understand what is going on and manually enable a profile for the application. We are working on a GUI method that users will be able to use, making this task easier. Unfortunately this also comes with the risk of users just click yes/enable without understanding the risk, but there is no way around that problem.