Flatpak does seccomp syscall filtering like Docker containers does on Linux

"Move all seccomp filters to xdg-seccomp-filters project" https://github.com/flatpak/flatpak/issues/4466
- Is there a limited set of syscalls for bin/python in general use?
- A given application which uses Python only needs certain syscalls, and there's no way to specify which in the python packaging ecosystem yet; so, tools that dynamically trace syscalls at runtime (while running integration tests of the complete application, or tests of  packages or modules or callables) are useful for generating and manually cleaning up an allow list of access control rules.

The stopdisablingselinux.com talk has a walkthrough of audit2allow, which tails dmesg (journalctl --dmesg) and generates candidate SELinux Policies.

"WIP: Add an all-syscalls feature which disables seccomp filtering" :
"Performance impact of seccomp filter in games"  https://github.com/flatpak/flatpak/issues/4187#issuecomment-1075512546
- list of reasons to not run flatpaks without seccomp

Seccomp syscall filter rules are Linux only, though; so
A more abstract permission set similar to Android's list of strings for package manifest.xml files
 which is *verifiably* implemented as {e.g. seccomp, AppArmor, SELinux Policies, and MacOS and Windows equivalents} 
 prior to cryptographically-signing the package manifests
 (and uploading to e.g. PyPI where what's uploaded will be TUF-signed)
 would be necessary.

Potential development workflow changes:

1. Update setup.py: add os-portable permission strings and/or os-specific rules to package's' setup.py's and meta.yml's, modules, and/or callables
2.
3. Generate {setup.py console_script package entrypoint scripts with syscall filtering, flatpak packages with syscall filtering, AppArmor scripts, SELinux Policies, and  OCI container seccomp config ,} without having to again trace syscalls while running tests
4. 
5. Generate config dicts for IDK subprocess.safe_Popen(security_opts=)  ?

  (Given each package's os-portable permission strings and/or os-specific rules)

6. Determine whether plain Python code even needs WASI system access when run in a WASM runtime (which can be imported from CPython with e.g. emscripten-forge/pyjs-code-runner,  (which doesn't itself do seccomp syscall filtering))


On Wed, Mar 1, 2023, 11:09 PM Wes Turner <wes.turner@gmail.com> wrote:
There must  be capabilities/permissions specified in wheel package manifests:

OCI Open Container Interface specs are implemented in e.g. Podman and buildah but not yet in Docker (moby engine) or BuildKit, fwiu. Like Docker, Podman works on Linux//Mac/Windows.

The OCI specs do not specify how or whether to AppArmor and/or SELinux within the container and/or on the host; but they do specify setcap and dropcap capabilities that 

The OCI specs: https://opencontainers.org/about/overview/ :

> The OCI currently contains three specifications: the Runtime Specification (runtime-spec), the Image Specification (image-spec) and the Distribution Specification (distribution-spec). The Runtime Specification outlines how to run a “filesystem bundle” that is unpacked on disk. At a high-level an OCI implementation would download an OCI Image then unpack that image into an OCI Runtime filesystem bundle. At this point the OCI Runtime Bundle would be run by an OCI Runtime.

https://github.com/opencontainers/image-spec/blob/main/spec.md
- https://github.com/opencontainers/image-spec/blob/main/config.md#example




For example:
- AppArmor
  https://wiki.archlinux.org/title/AppArmor#Understanding_profiles

- SELinux Policies
  https://wiki.archlinux.org/title/SELinux#Concepts:_Mandatory_Access_Controls
  https://github.com/fedora-selinux/selinux-policy/blob/rawhide/policy/modules/contrib/pyzor.fc
  https://github.com/fedora-selinux/selinux-policy/blob/rawhide/policy/modules/contrib/pyzor.te
  https://github.com/fedora-selinux/selinux-policy/blob/rawhide/policy/modules/contrib/pyzor.if
  https://github.com/k3s-io/k3s/issues/1372#issuecomment-581797716

- Android APK permissions
  https://developer.android.com/reference/android/Manifest.permission
  https://developer.android.com/guide/topics/permissions/overview

- containers

- WebExtensions 
  https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/permissions

> Extensions need permissions to access more powerful WebExtension APIs. They can ask for permissions at install time, by including the permissions they need in the `permissions` manifest.json key. The main advantages of asking for permissions at install time are:
> - The user is only asked once, so it's less disruptive for them, and a simpler decision.
> - The extension can rely on the access to the APIs it needs, because if already running, the permissions have been granted.
>
> In most major browsers, users can see if their installed extensions request advanced permissions through the browser's extensions manager.

$ pip freeze
$ conda env export --from-history
$ docker sbom

> With the permissions API, an extension can ask for additional permissions at runtime. These permissions need to be listed in the `optional_permissions` manifest.json key. 

Terms: 
- DAC: Discretionary Access Control
- MAC: Mandatory Access Control


Things that could enforce the conjunctive sum of the access control policies for each package and c extension module in a given set of paths in sys.path:

- ~~Python runtime itself~~
- a process spawner that wraps systemd-nspawn and similar for other OSes
  - Flatpak (Linux)
    $ flatpak run "$flatpakname"
  - $ firejail --appimage=
    https://github.com/netblue30/firejail
- Containers / VMs: virtual machines
  - Gvisor
  - Firecracker
  - https://github.com/containers/oci-seccomp-bpf-hook
    - https://github.com/falcosecurity/falco



On Wed, Mar 1, 2023, 4:50 PM Paul Bryan <pbryan@anode.ca> wrote:
I'm of the opinion that trying to sandbox an otherwise unaltered runtime and standard library will run into the same walls as previous attempts. My sense of this is if the Python community had the appetite for effective fine-grained access control policies, it would require embedding enforcement into the stdlib modules themselves. Pretty much a refactor across the board.
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/2S7WBMIHFF5O2POQG2MON7THP3GVZCBT/
Code of Conduct: http://python.org/psf/codeofconduct/