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
Extensions need permissions to access more powerful WebExtension APIs. They can ask for permissions at install time, by including the permissions
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/ : 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... https://github.com/fedora-selinux/selinux-policy/blob/rawhide/policy/modules... https://github.com/fedora-selinux/selinux-policy/blob/rawhide/policy/modules... 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/p... 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/2S7WBM... Code of Conduct: http://python.org/psf/codeofconduct/