Wine-based snap, logos9, can't start child process(es)

n8marti · November 26, 2021, 12:16pm

I’m trying to make the wine-based snap package logos9 work under strict confinement. It works fine in devmode, but then seems to fail to start child process(es) when run in jailmode. Here’s the specific error I see in the winedebug output:

System.ComponentModel.Win32Exception: Accès refusé
   at System.Diagnostics.NtProcessManager.GetModuleInfos(Int32 processId, Boolea
n firstModuleOnly)
   at System.Diagnostics.NtProcessManager.GetFirstModuleInfo(Int32 processId)
   at System.Diagnostics.Process.get_MainModule()
   at LDLS4.OurApp.Main(String[] astrArgs)
wine: Unhandled exception 0xe0434352 in thread 120 at address 000000007B0118AD (thread 0120), starting debugger...
0130:err:unwind:install_bpf Unexpected status 0xffffffff, errno 1.
Can't attach process 011c: error 5

I’m not well-versed in AppArmor and Seccomp, but it seems like this is the relevant Seccomp violation:

= Seccomp =
Time: Nov 26 12:32:01
Log: auid=1000 uid=1000 gid=1000 ses=3 subj=snap.logos9.logos9 pid=1179452 comm="wineserver" exe="/snap/logos9/11/wine-platform/wine-staging/bin/wineserver" sig=0 arch=c000003e 101(ptrace) compat=0 ip=0x7f5af431c71f code=0x50000
Syscall: ptrace

But I’ve already enabled process-control, system-observe, and system-trace plugs, thinking at least one of those would fix the problem:

$ snap connections logos9
Interface                 Connecteur                      Prise                               Notes
# [...]
process-control           logos9:process-control          :process-control                    manual
system-observe            logos9:system-observe           :system-observe                     manual
system-trace              logos9:system-trace             :system-trace                       manual
# [...]

Here’s part of the snapcraft.yaml:

name: logos9

grade: devel # must be 'stable' to release into candidate/stable channels
confinement: devmode # use 'strict' once you have the right plugs and slots
architectures:
  - amd64

environment:
  TRICKS: "dotnet48 corefonts ddr=gdi fontsmooth=rgb"
  WINEDLLOVERRIDES: "mscoree,mshtml=" # Prevent pop-ups about Wine Mono and Wine Gecko

apps:
  logos9:
    extensions: [gnome-3-28]
    command: bin/sommelier run-exe
    environment:
      RUN_EXE: "C:/users/$USER/AppData/Local/Logos/Logos.exe"
      # RUN_EXE: "C:/users/$USER/AppData/Local/Logos/System/Logos.exe"
      INSTALL_URL: https://downloads.logoscdn.com/LBS9/Installer/9.9.0.0011/Logos-x64.msi
      # INSTALL_FLAGS: /silent # optional commandline flags to pass to the installer
    plugs:
      - audio-playback
      - home
      - network
      - network-manager-observe
      - process-control
      - system-observe
      - system-trace
      - udisks2

Any suggestions on how I can move forward on this? The snap is available from the Snap Store on the edge channel:

snap install logos9 --edge --jailmode # or --devmode

Reference:

n8marti · December 6, 2021, 5:24pm

Has nobody run into this before? I’ve tried filtering and understanding the winedebug output while running the app, but it’s all new territory for me and I don’t understand Windows function calls at all (yet!).

Did I even identify the correct Seccomp violation? It would be helpful to know if I’m at least on the right track.

n8marti · May 3, 2022, 2:21pm

It turns out that the problem is related to how dotnet tries to modify a child process. It uses a system call that could modify any process, since it takes an arbitrary PID as the first argument. This is a snap no-no, although supposedly there’s a workaround using a manually-connected process-control plug (but it’s not working for me). But this manual CLI step would still be a pain for normal users.

Further info at these links:

github.com/dotnet/runtime

Comment by jdstrand - PAL: Update CreateThread

dotnet:master ← lucyllewy:issue-1634

Unfortunately there are limitations in the sandbox mediation for this API. Speci…fically, while we can mediate `sched_setaffinity` via the syscall filter, we are not able to say 'allow this for child pids'/etc; this is a limitation of the kernel. We do allow `sched_setaffinity(0, ...)` in the default policy. We could allow a bare `sched_setaffinity` rule (which is what process control does), but that would allow specifying arbitrary pids as the first argument. AppArmor allows us to mediate CAP_SYS_NICE (which we allow in process-control) which is needed to set the affinity for processes with a differing euid/ruid than the current euid, but even without CAP_SYS_NICE, allowing arbitrary use of `sched_setaffinity` would allow setting the affinity for any process within the user's session and would allow snap daemons (which may run as root) to set the affinity for any root process on the system. The `process-control` interface is the current means to grant access to this API to snaps. Unfortunately, since it allows influencing other snaps and the system (for this API and more), it is manually connected. In terms of future enhancements, the seccomp implementation in the kernel is called at a point where it doesn't have the context to know if the target pid is a child or not. Perhaps AppArmor could grow fine-grained mediation for this to allow setting the affinity for childen, but this is likely challenging to do in a performant manner (and would not be something that would be useful for a long time even if it were implemented today). AFAIK, there is no cgroup facility that could be employed that would limit the use of `sched_setaffinity` to as certain set of pids (we can only limit the CPUs). While we can evaluate each request to grant snaps access to `process-control`, a more developer-friendly mechanism for consumers of dotnet runtime is preferred. Perhaps dotnet runtime can shuffle this code around a bit to have the child call `sched_setaffinity(0, ...)`?

soarc · May 3, 2022, 2:42pm

I believe this was fixed in .net5 dotnet core 3.1 self-contained snap · Issue #1634 · dotnet/runtime · GitHub

Change new thread’s affinity after thread starts, from the same thread, as a workaround for Snap by kouvel · Pull Request #40205 · dotnet/runtime · GitHub

n8marti · May 3, 2022, 2:44pm

I’ve seen that, thanks. However, this app uses dotnet 4.8, and I don’t know of any way to proceed in that case.

ezzep · May 28, 2022, 12:47am

Hey! Fellow Logos user! Typical response on these things huh? So, there’s a thing called Darling that lets you use Mac OS apps. I’m stuck at getting a kernel module installed for it, but if that works, then we could use the Mac OS app and ditch wine. The problem? I’m a Fedora user, not a Debian/Ubuntu, and they made a deb package for the module. Hope that helps you not get bogged down.