Closed jagiella closed 18 hours ago
A workaround that solves that problem is tinkering with apparmor: https://github.com/DevToys-app/DevToys/issues/1198#issuecomment-2161540748
But this should not be a prerequist for the launcher to work, right?
this will always be a requirement on ubuntu due to Ubuntu developers deciding to use Apparmor to restrict the creation of user namespaces: https://ubuntu.com/blog/ubuntu-23-10-restricted-unprivileged-user-namespaces
it may be possible to package an apparmor profile as part of the deb, something we need to look into
apparmor profile added https://github.com/Open-Wine-Components/umu-launcher/pull/218
As @darix has commented on #218, please don't create an "unconfined" profile for bwrap. This completely bypasses the unprivileged user namespace creation restriction and makes the machine exploitable by attacks that use it.
A profile for scripts/programs that call bwrap should be created instead. Please contact the AppArmor community if you need any assistance.
AppArmor upstream has created a profile for bwrap that does not make your machine vulnerable. You can find the profile here. It is not enabled by default on Ubuntu, but you can enable it by either copying the file from gitlab, installing it on /etc/apparmor.d/, and load it using sudo apparmor_parser /etc/apparmor.d/bwrap-userns-restrict
.
You can also use the version shipped by the apparmor-profile package, and create a symbolic link from the extra-profiles directory to /etc/apparmor.d/
sudo ln -s /usr/share/apparmor/extra-profiles/bwrap-userns-restrict /etc/apparmor.d/
and load it
sudo apparmor_parser /etc/apparmor.d/bwrap-userns-restrict
.
well jjohansen commented that the userns-restrict breaks flatpak. which isnt ideal either. the approach from cboltz would confine what bwrap does to the subprofile of an umu-launcher profile.
I would be happy to help with that. I already did a complete profile set for @GloriousEggroll 's wine build in the past :)
from my understanding of all of this, based on gegarcia's comment we just need to remove our current bwrap profile and use bwrap-userns-restrict instead, just rename it so it's umu-specific and so we can add/remove it with the package without interfering with other pre-existing profiles, is that correct? (ex package and ship bwrap-usrns-restrict-umu)
also we need to somehow modify it so it's specific to umu and does not interfere with flatpak -- is that right?
naw.
you would do something like
profile umu-launcher /path/to/script/that/calls/bwrap {
/usr/bin/bwrap cx -> bwrap,
profile bwrap {
}
}
that way you have a scoped profile for bwrap.
@darix the bwrap profile was missing the "mediate_deleted" flag but that's fixed upstream. we didn't get any other reports of it breaking flatpak (although testing has been limited since the majority is not enabling the profile anymore).
aha. well great to know we dont have to go through profiling the umu-launcher scripts :)
@GloriousEggroll is bwrap called indirectly via pressure-vessel or so?
@GloriousEggroll is bwrap called indirectly via pressure-vessel or so?
yes
@darix the bwrap profile was missing the "mediate_deleted" flag but that's fixed upstream. we didn't get any other reports of it breaking flatpak (although testing has been limited since the majority is not enabling the profile anymore).
great so then this should be sufficient hopefully?:
https://github.com/Open-Wine-Components/umu-launcher/commit/f21c7e651bf8dcaab391e614f3bb15fc3557c94b
good lord that would have been a profile chain ... or well we could have just profiled pressure-vessel and dont have to start at the umu scripts.
great so then this should be sufficient hopefully?:
for the opensuse rpm i just did ln -s
https://build.opensuse.org/projects/games/packages/umu-launcher/files/umu-launcher.spec?expand=1
although I suppose I could even just use the same filename and make it a symlink
great so then this should be sufficient hopefully?: f21c7e6
for the opensuse rpm i just did
ln -s
https://build.opensuse.org/projects/games/packages/umu-launcher/files/umu-launcher.spec?expand=1
yeah i just want to make the name different from the default so that it can be easily added/removed without interfering with other existing files (or in the event that something else already created the symlink or copied the file)
yeah that's why i kept the non upstream name for the symlink. i just had to through a lot of profiles and rename them after upstream introduced same profiles with just an empty block to handle userns :)
alright here we go, this looks better i think:
https://github.com/Open-Wine-Components/umu-launcher/commit/0b4b9dc81c0633babd69243b2d44ed6954a7e8e3
@GloriousEggroll is umu using a system copy of pressure-vessel or the one from steam? i dont see a requires in the rpm spec
alright here we go, this looks better i think:
why do that in post(rm) scripts instead of in the install section like we would do in rpms?
@GloriousEggroll is umu using a system copy of pressure-vessel or the one from steam? i dont see a requires in the rpm spec
it automatically downloads the steam version
alright here we go, this looks better i think: 0b4b9dc
why do that in post(rm) scripts instead of in the install section like we would do in rpms?
no reason really, just saw it as an easy way to do it rather than packaging a static symlink
there now its a shipped symlink and should link back to the package when checking the file package ownership
https://github.com/Open-Wine-Components/umu-launcher/commit/418c5d2aab3a5ceb5d57661d50f780a2cf3960d7
I install umu-launcher deb packages on ubuntu 24.04.
Running the launcher always ends up with an permission error: