Allow setting noexec flag for newly created filesystems

[Maryse47]

On systems which strictly use noexec flag for filesystems, creating new, arbitrary ones with exec flag means apps in sandbox will have more privileges than they would have on host.

This won't cover interpreted code but blocking execution of such code is work in progress: https://patchwork.kernel.org/patch/11135563/ and if it's completed then it will hit by the same issue with lack of noexec flag on new tmpfs filesystems.

Moreover on such restricted systems there could be no interpreters available in executable paths in container which again may be bypassed by putting interpreter to newly created executable path and run it from it.

This is follow-up from https://github.com/containers/bubblewrap/pull/345

[Maryse47]

Relevant comment from @alexlarsson in mentioned ticket:

So, there are two issues here, one is that you might want to create a bwrap container that has a no-exec tmpfs. I think this should be an option independent on the host state, and its actually similar to #346 in that we want ways to set more permissions on the files/dirs/mounts bwrap creates.

The other issue is that you're setting up a system (be it a real host or some other form of container) where the user has access to the bwrap command, but doesn't have access to any writable executable location. In this case giving access to the bwrap commands would let you escape the noexec limitation. I think this should be handled by bwrap detecting this case and automatically setting noexec, in that particular case.

So, if all mounts in the current namespace are read-only or noexec, then we should make all new tmpfs:es automatically noexec. I guess this isn't 100% correct, as you might have a situation where you have access to a read-write executable mount but file permissions makes it impossible to write anything there. That seems like an unsafe thing to rely on though, and if you want to grant bwrap access it would be better to make such mounts read-only.