aboutgitcodebugslistschat
path: root/contrib
Commit message (Collapse)AuthorAgeFilesLines
* apparmor: Fix comments after PID file and AF_UNIX socket creation refactoring2024_05_23.765eb0bStefano Brivio2024-05-233-7/+13
| | | | | | | | | | | | Now: - we don't open the PID file in main() anymore - PID file and AF_UNIX socket are opened by pidfile_open() and tap_sock_unix_open() - write_pidfile() becomes pidfile_write() Reported-by: Richard W.M. Jones <rjones@redhat.com> Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Acked-by: Richard W.M. Jones <rjones@redhat.com>
* apparmor: Fix passt abstractionMaxime Bélair2024-05-221-1/+1
| | | | | | | | | | | | | | | | | | | Commit b686afa2 introduced the invalid apparmor rule `mount options=(rw, runbindable) /,` since runbindable mount rules cannot have a source. Therefore running aa-logprof/aa-genprof will trigger errors (see https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2065685) $ sudo aa-logprof ERROR: Operation {'runbindable'} cannot have a source. Source = AARE('/') This patch fixes it to the intended behavior. Link: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2065685 Fixes: b686afa23e85 ("apparmor: Explicitly pass options we use while remounting root filesystem") Signed-off-by: Maxime Bélair <maxime.belair@canonical.com> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* apparmor: allow netns paths on /tmpPaul Holzinger2024-05-131-1/+1
| | | | | | | | | | | | | | | For some unknown reason "owner" makes it impossible to open bind mounted netns references as apparmor denies it. In the kernel denied log entry we see ouid=0 but it is not clear why that is as the actual file is owned by the real (rootless) user id. In abstractions/pasta there is already `@{run}/user/@{uid}/**` without owner set for the same reason as this path contains the netns path by default when running under Podman. Fixes: 72884484b00d ("apparmor: allow read access on /tmp for pasta") Signed-off-by: Paul Holzinger <pholzing@redhat.com> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* apparmor: allow read access on /tmp for pasta2024_05_10.7288448Paul Holzinger2024-05-101-2/+3
| | | | | | | | | | The podman CI on debian runs tests based on /tmp but pasta is failing there because it is unable to open the netns path as the open for read access is denied. Link: https://github.com/containers/podman/issues/22625 Signed-off-by: Paul Holzinger <pholzing@redhat.com> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* apparmor: Fix access to procfs namespace entries in pasta's abstractionDanish Prakash2024-04-051-0/+3
| | | | | | | | | | | | | | | | | | | | | From an original patch by Danish Prakash. With commit ff22a78d7b52 ("pasta: Don't try to watch namespaces in procfs with inotify, use timer instead"), if a filesystem-bound target namespace is passed on the command line, we'll grab a handle on its parent directory. That commit, however, didn't introduce a matching AppArmor rule. Add it here. To access a network namespace procfs entry, we also need a 'ptrace' rule. See commit 594dce66d3bb ("isolation: keep CAP_SYS_PTRACE when required") for details as to when we need this -- essentially, it's about operation with Buildah. Reported-by: Jörg Sonnenberger <joerg@bec.de> Link: https://github.com/containers/buildah/issues/5440 Link: https://bugzilla.suse.com/show_bug.cgi?id=1221840 Fixes: ff22a78d7b52 ("pasta: Don't try to watch namespaces in procfs with inotify, use timer instead") Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* apparmor: Expand scope of @{run}/user access, allow writing PID files tooStefano Brivio2024-04-051-1/+1
| | | | | | | | | | | | | | | With Podman's custom networks, pasta will typically need to open the target network namespace at /run/user/<UID>/containers/networks: grant access to anything under /run/user/<UID> instead of limiting it to some subpath. Note that in this case, Podman will need pasta to write out a PID file, so we need write access, for similar locations, too. Reported-by: Jörg Sonnenberger <joerg@bec.de> Link: https://github.com/containers/buildah/issues/5440 Link: https://bugzilla.suse.com/show_bug.cgi?id=1221840 Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* apparmor: Add mount rule with explicit, empty source in passt abstractionStefano Brivio2024-04-051-0/+1
| | | | | | | | | | | | | For the policy to work as expected across either AppArmor commit 9d3f8c6cc05d ("parser: fix parsing of source as mount point for propagation type flags") and commit 300889c3a4b7 ("parser: fix option flag processing for single conditional rules"), we need one mount rule with matching mount options as "source" (that is, without source), and one without mount options and an explicit, empty source. Link: https://github.com/containers/buildah/issues/5440 Link: https://bugzilla.suse.com/show_bug.cgi?id=1221840 Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* fedora: Switch license identifier to SPDX2024_03_18.615d370Dan Čermák2024-03-181-1/+1
| | | | | | | | The spec file patch by Dan Čermák was originally contributed at: https://src.fedoraproject.org/rpms/passt/pull-request/1 Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
* selinux: Allow pasta to remount procfs2024_02_16.08344daStefano Brivio2024-02-161-0/+2
| | | | | | | | | | | Partially equivalent to commit abf5ef6c22d2 ("apparmor: Allow pasta to remount /proc, access entries under its own copy"): we should allow pasta to remount /proc. It still works otherwise, but further UID remapping in nested user namespaces (e.g. pasta in pasta) won't. Reported-by: Laurent Jacquot <jk@lutty.net> Link: https://bugs.passt.top/show_bug.cgi?id=79#c3 Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* Revert "selinux: Drop user_namespace class rules for Fedora 37"2023_11_07.56d9f6dStefano Brivio2023-11-072-0/+4
| | | | | | | | This reverts commit 3fb3f0f7a59498bdea1d199eecfdbae6c608f78f: it was meant as a patch for Fedora 37 (and no later versions), not something I should have merged upstream. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* selinux: Allow passt to talk over unconfined_t UNIX domain socket for --fd2023_11_07.74e6f48Stefano Brivio2023-11-071-0/+1
| | | | | | | | | | | | | | | If passt is started with --fd to talk over a pre-opened UNIX domain socket, we don't really know what label might be associated to it, but at least for an unconfined_t socket, this bit of policy wouldn't belong to anywhere else: enable that here. This is rather loose, of course, but on the other hand passt will sandbox itself into an empty filesystem, so we're not really adding much to the attack surface except for what --fd is supposed to do. Reported-by: Matej Hrica <mhrica@redhat.com> Link: https://bugzilla.redhat.com/show_bug.cgi?id=2247221 Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* selinux: Drop user_namespace class rules for Fedora 37Stefano Brivio2023-11-072-4/+0
| | | | | | | | | | | | | With current selinux-policy-37.22-1.fc37.noarch, and presumably any future update for Fedora 37, the user_namespace class is not available, so statements using it prevent the policy from being loaded. If a class is not defined in the base policy, any related permission is assumed to be enabled, so we can safely drop those. Link: https://bugzilla.redhat.com/show_bug.cgi?id=2237996 Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* fedora: Replace pasta hard links by separate buildsStefano Brivio2023-09-071-6/+16
| | | | | | | | | | | | | | | | | | | | | | | | | The hard link trick didn't actually fix the issue with SELinux file contexts properly: as opposed to symbolic links, SELinux now correctly associates types to the labels that are set -- except that those labels are now shared, so we can end up (depending on how rpm(8) extracts the archives) with /usr/bin/passt having a pasta_exec_t context. This got rather confusing as running restorecon(8) seemed to fix up labels -- but that's simply toggling between passt_exec_t and pasta_exec_t for both links, because each invocation will just "fix" the file with the mismatching context. Replace the hard links with two separate builds of the binary, as suggested by David. The build is reproducible, so we pass "-pasta" in the VERSION for pasta's build. This is wasteful but better than the alternative. Just copying the binary over would otherwise cause issues with debuginfo packages due to duplicate Build-IDs -- and rpmbuild(8) also warns about them. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* apparmor: Add pasta's own profileStefano Brivio2023-09-073-10/+31
| | | | | | | | | | | | | | | | | | | If pasta and pasta.avx2 are hard links to passt and passt.avx2, AppArmor will attach their own profiles on execution, and we can restrict passt's profile to what it actually needs. Note that pasta needs to access all the resources that passt needs, so the pasta abstraction still includes passt's one. I plan to push the adaptation required for the Debian package in commit 5bb812e79143 ("debian/rules: Override pasta symbolic links with hard links"), on Salsa. If other distributions need to support AppArmor profiles they can follow a similar approach. The profile itself will be installed, there, via dh_apparmor, in a separate commit, b52557fedcb1 ("debian/rules: Install new pasta profile using dh_apparmor"). Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* apparmor: Allow pasta to remount /proc, access entries under its own copyStefano Brivio2023-09-071-0/+7
| | | | | | | | | | Since commit b0e450aa8500 ("pasta: Detach mount namespace, (re)mount procfs before spawning command"), we need to explicitly permit mount of /proc, and access to entries under /proc/PID/net (after remount, that's what AppArmor sees as path). Fixes: b0e450aa8500 ("pasta: Detach mount namespace, (re)mount procfs before spawning command") Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* apparmor: Allow read-only access to uid_mapStefano Brivio2023-09-071-0/+2
| | | | | | | | | | | | | | Starting with commit 770d1a4502dd ("isolation: Initially Keep CAP_SETFCAP if running as UID 0 in non-init"), the lack of this rule became more apparent as pasta needs to access uid_map in procfs even as non-root. However, both passt and pasta needs this, in case they are started as root, so add this directly to passt's abstraction (which is sourced by pasta's profile too). Fixes: 770d1a4502dd ("isolation: Initially Keep CAP_SETFCAP if running as UID 0 in non-init") Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* apparmor: Explicitly pass options we use while remounting root filesystemStefano Brivio2023-09-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | As a result of AppArmor commit d4b0fef10a4a ("parser: fix rule flag generation change_mount type rules"), we can't expect anymore to get permission to mount() / read-write, with MS_REC | MS_UNBINDABLE ("runbindable", in AppArmor terms), if we don't explicitly pass those flags as options. It used to work by mistake. Now, the reasonable expectation would be that we could just change the existing rule into: mount options=(rw, runbindable) "" -> /, ...but this now fails to load too, I think as a result of AppArmor commit 9d3f8c6cc05d ("parser: fix parsing of source as mount point for propagation type flags"). It works with 'rw' alone, but 'runbindable' is indeed a propagation type flag. Skip the source specification, it doesn't add anything meaningful to the rule anyway. Reported-by: Paul Holzinger <pholzing@redhat.com> Link: https://github.com/containers/podman/pull/19751 Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* apparmor: Use abstractions/nameservice to deal with symlinked resolv.confStefano Brivio2023-09-061-2/+1
| | | | | | | | | | | | | While abstractions/nameservice appeared too broad and overkill for our simple need (read-only resolv.conf access), it properly deals with symlinked resolv.conf files generated by systemd-resolved, NetworkManager or suchlike. If we just grant read-only access to /etc/resolv.conf, we'll fail to read nameserver information in rather common configurations, because AppArmor won't follow the symlink. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* selinux: Fix domain transitions for typical commands pasta might run2023_08_18.0af928eStefano Brivio2023-08-181-1/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ...now it gets ugly. If we use pasta without an existing target namespace, and run commands directly or spawn a shell, and keep the pasta_t domain when we do, they won't be able to do much: a shell might even start, but it's not going to be usable, or to even display a prompt. Ideally, pasta should behave like a shell when it spawns a command: start as unconfined_t and automatically transition to whatever domain is associated in the specific policy for that command. But we can't run as unconfined_t, of course. It would seem natural to switch to unconfined_t "just before", so that the default transitions happen. But transitions can only happen when we execvp(), and that's one single transition -- not two. That is, this approach would work for: pasta -- sh -c 'ip address show' but not for: pasta -- ip address show If we configure a transition to unconfined_t when we run ip(8), we'll really try to start that as unconfined_t -- but unconfined_t isn't allowed as entrypoint for ip(8) itself, and execvp() will fail. However, there aren't many different types of binaries pasta might commonly run -- for example, we're unlikely to see pasta used to run a mount(8) command. Explicitly set up domain transition for common stuff -- switching to unconfined_t for bin_t and shells works just fine, ip(8), ping(8), arping(8) and similar need a different treatment. While at it, allow commands we spawn to inherit resource limits and signal masks, because that's what happens by default, and don't require AT_SECURE sanitisation of the environment (because that won't happen by default). Slightly unrelated: we also need to explicitly allow pasta_t to use TTYs, not just PTYs, otherwise we can't keep stdin and stdout open for shells. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* selinux: Allow pasta_t to read nsfs entriesStefano Brivio2023-08-181-0/+2
| | | | | | | | | This is needed to monitor filesystem-bound namespaces and quit when they're gone -- this feature never really worked with SELinux. Fixes: 745a9ba4284c ("pasta: By default, quit if filesystem-bound net namespace goes away") Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Acked-by: Richard W.M. Jones <rjones@redhat.com>
* selinux: Add rules for sysctl and /proc/net accessesStefano Brivio2023-08-182-0/+4
| | | | | | | | | That's what we actually need to check networking-related sysctls, to scan for bound ports, and to manipulate bits of network configuration inside pasta's target namespaces. Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Acked-by: Richard W.M. Jones <rjones@redhat.com>
* selinux: Update policy to fix user/group settingsStefano Brivio2023-08-182-4/+13
| | | | | | | | | Somehow most of this used to work on older kernels, but now we need to explicitly permit setuid, setgid, and setcap capabilities, as well as read-only access to passwd (as we support running under a given login name) and sssd library facilities. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* selinux: Fix user namespace creation after breaking kernel changeStefano Brivio2023-08-182-0/+4
| | | | | | | | | | | | | | | | | Kernel commit ed5d44d42c95 ("selinux: Implement userns_create hook") seems to just introduce a new functionality, but given that SELinux implements a form of mandatory access control, introducing the new permission breaks any application (shipping with SELinux policies) that needs to create user namespaces, such as passt and pasta for sandboxing purposes. Add the new 'allow' rules. They appear to be backward compatible, kernel-wise, and the policy now requires the new 'user_namespace' class to build, but that's something distributions already ship. Reported-by: Richard W.M. Jones <rjones@redhat.com> Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: Richard W.M. Jones <rjones@redhat.com>
* selinux: Use explicit paths for binaries in file contextStefano Brivio2023-08-182-2/+4
| | | | | | | | | There's no reason to use wildcards, and we don't want any similarly-named binary (not that I'm aware of any) to risk being associated to passt_exec_t and pasta_exec_t by accident. Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: Richard W.M. Jones <rjones@redhat.com>
* fedora: Install pasta as hard link to ensure SELinux file context matchStefano Brivio2023-08-181-0/+7
| | | | | | | | | | | | | | The Makefile installs symbolic links by default, which actually worked at some point (not by design) with SELinux, but at least on recent kernel versions it doesn't anymore: override pasta (and pasta.avx2) with hard links. Otherwise, even if the links are labeled as pasta_exec_t, SELinux will "resolve" them to passt_exec_t, and we'll have pasta running as passt_t instead of pasta_t. Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Acked-by: Richard W.M. Jones <rjones@redhat.com>
* passt: Relicense to GPL 2.0, or any later versionStefano Brivio2023-04-0611-12/+12
| | | | | | | | | | | | | | | | | | | In practical terms, passt doesn't benefit from the additional protection offered by the AGPL over the GPL, because it's not suitable to be executed over a computer network. Further, restricting the distribution under the version 3 of the GPL wouldn't provide any practical advantage either, as long as the passt codebase is concerned, and might cause unnecessary compatibility dilemmas. Change licensing terms to the GNU General Public License Version 2, or any later version, with written permission from all current and past contributors, namely: myself, David Gibson, Laine Stump, Andrea Bolognani, Paul Holzinger, Richard W.M. Jones, Chris Kuhn, Florian Weimer, Giuseppe Scrivano, Stefan Hajnoczi, and Vasiliy Ulyanov. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* fedora: Adjust path for SELinux policy and interface file to latest guidelines2023_03_29.b10b983Stefano Brivio2023-03-291-9/+8
| | | | | | | | | | | | | | | | | | | Forget about: https://fedoraproject.org/wiki/SELinux_Policy_Modules_Packaging_Draft and: https://fedoraproject.org/wiki/PackagingDrafts/SELinux_Independent_Policy The guidelines to follow are: https://fedoraproject.org/wiki/SELinux/IndependentPolicy Start from fixing the most pressing issue, that is, a path conflict with policy-selinux-devel about passt.if, and, while at it, adjust the installation paths for policy files too. Reported-by: Xose Vazquez Perez <xose.vazquez@gmail.com> Link: https://bugzilla.redhat.com/show_bug.cgi?id=2182476 Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* fedora: Don't install useless SELinux interface file for pastaStefano Brivio2023-03-291-2/+0
| | | | | | | | | | That was meant to be an example, and I just dropped it in the previous commit -- passt.if should be more than enough as a possible example. Reported-by: Carl G. <carlg@fedoraproject.org> Link: https://bugzilla.redhat.com/show_bug.cgi?id=2182145 Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* selinux: Drop useless interface file for pastaStefano Brivio2023-03-291-25/+0
| | | | | | | | | This was meant to be an example, but I managed to add syntax errors to it. Drop it altogether. Reported-by: Carl G. <carlg@fedoraproject.org> Link: https://bugzilla.redhat.com/show_bug.cgi?id=2182145 Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* fedora: Refresh SELinux labels in scriptlets, require -selinux package2023_03_17.dd23496Stefano Brivio2023-03-171-5/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | Instead of: https://fedoraproject.org/wiki/SELinux_Policy_Modules_Packaging_Draft follow this: https://fedoraproject.org/wiki/PackagingDrafts/SELinux_Independent_Policy which seems to make more sense and fixes the issue that, on a fresh install, without a reboot, the file contexts for the binaries are not actually updated. In detail: - labels are refreshed using the selinux_relabel_pre and selinux_relabel_post on install, upgrade, and uninstall - use the selinux_modules_install and selinux_modules_uninstall macros, instead of calling 'semodule' directly (no functional changes in our case) - require the -selinux package on SELinux-enabled environments and if the current system policy is "targeted" Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* fedora: Install SELinux interface files to shared include directory2023_03_10.70c0765Stefano Brivio2023-03-101-0/+4
| | | | | Link: https://github.com/fedora-selinux/selinux-policy/pull/1613 Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* contrib/selinux: Split interfaces into smaller bitsStefano Brivio2023-03-101-10/+61
| | | | | | | ...to fit accepted Fedora practices. Link: https://github.com/fedora-selinux/selinux-policy/pull/1613 Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* contrib/selinux: Drop unused passt_read_data() interfaceStefano Brivio2023-03-101-8/+0
| | | | Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* contrib/selinux: Drop "example" from headers: this is the actual policyStefano Brivio2023-03-106-6/+6
| | | | Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* contrib: Drop libvirt out-of-tree patch, integration mostly works in 9.1.0Stefano Brivio2023-03-091-427/+0
| | | | | | | | ...and in any case, this patch doesn't offer any advantage over the current upstream integration. Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
* contrib: Drop QEMU out-of-tree patchesStefano Brivio2023-03-092-208/+0
| | | | | | | Native support was introduced with commit 13c6be96618c, QEMU 7.2. Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
* contrib: Drop Podman out-of-tree patch, integration is upstream nowStefano Brivio2023-03-091-605/+0
| | | | | | | | See https://github.com/containers/podman/pull/16141, shipped in Podman 4.4. Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
* contrib/selinux: Let interface users set paths for log, PID, socket filesStefano Brivio2023-03-091-1/+25
| | | | | | | | | | | | | | | | Even libvirt itself will configure passt to write log, PID and socket files to different locations depending on whether the domain is started as root (/var/log/libvirt/...) or as a regular user (/var/log/<PID>/libvirt/...), and user_tmp_t would only cover the latter. Create interfaces for log and PID files, so that callers can specify different file contexts for those, and modify the interface for the UNIX socket file to allow different paths as well. Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Tested-by: Laine Stump <laine@redhat.com> Reviewed-by: Laine Stump <laine@redhat.com>
* contrib/selinux: Allow binding and connecting to all UDP and TCP portsStefano Brivio2023-03-091-12/+15
| | | | | | | | | | | | | | | | | | | | | Laine reports that with a simple: <portForward proto='tcp'> <range start='2022' to='22'/> </portForward> in libvirt's domain XML, passt won't start as it fails to bind arbitrary ports. That was actually the intention behind passt_port_t: the user or system administrator should have explicitly configured allowed ports on a given machine. But it's probably not realistic, so just allow any port to be bound and forwarded. Also fix up some missing operations on sockets. Reported-by: Laine Stump <laine@redhat.com> Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Tested-by: Laine Stump <laine@redhat.com> Reviewed-by: Laine Stump <laine@redhat.com>
* contrib/selinux: Let passt write to stdout and stderr when it startsStefano Brivio2023-03-091-0/+1
| | | | | | | | | | Otherwise, it's unusable as stand-alone tool, or in foreground mode, and it's also impossible to get output from --help or --version, because for SELinux it's just a daemon. Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Tested-by: Laine Stump <laine@redhat.com> Reviewed-by: Laine Stump <laine@redhat.com>
* contrib/selinux: Drop duplicate init_daemon_domain() ruleStefano Brivio2023-03-091-1/+0
| | | | | | Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Tested-by: Laine Stump <laine@redhat.com> Reviewed-by: Laine Stump <laine@redhat.com>
* contrib/apparmor: Split profile into abstractions, use themStefano Brivio2023-02-273-60/+89
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | One day, libvirt might actually support running passt to provide guest connectivity. Should libvirtd (or virtqemud) start passt, it will need to access socket and PID files in specific locations, and passt needs to accept SIGTERM in case QEMU fails to start after passt is already started. To make this more convenient, split the current profile into two abstractions, for passt and for pasta, so that external programmes can include the bits they need (and especially not include the pasta abstraction if they only need to start passt), plus whatever specific adaptation is needed. For stand-alone usage of passt and pasta, the 'passt' profile simply includes both abstractions, plus rules to create and access PID and capture files in default or reasonable ($HOME) locations. Tested on Debian with libvirt 9.0.0 together with a local fix to start passt as intended, namely libvirt commit c0efdbdb9f66 ("qemu_passt: Avoid double daemonizing passt"). This is an example of how the libvirtd profile (or virtqemud abstraction, or virtqemud profile) can use this: # support for passt network back-end /usr/bin/passt Cx -> passt, profile passt { /usr/bin/passt r, owner @{run}/user/[0-9]*/libvirt/qemu/run/passt/* rw, signal (receive) set=("term") peer=/usr/sbin/libvirtd, signal (receive) set=("term") peer=libvirtd, include if exists <abstractions/passt> } translated: - when executing /usr/bin/passt, switch to the subprofile "passt" (not the "discrete", i.e. stand-alone profile), described below. Scrub the environment (e.g. LD_PRELOAD is dropped) - in the "passt" subprofile: - allow reading the binary - allow read and write access to PID and socket files - make passt accept SIGTERM from /usr/sbin/libvirtd, and libvirtd peer names - include anything else that's needed by passt itself Suggested-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* selinux/passt.te: Allow setting socket option on routing netlink socketStefano Brivio2023-02-211-1/+1
| | | | Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* selinux/passt.te: Allow /etc/resolv.conf symlinks to be followedStefano Brivio2023-02-211-0/+1
| | | | Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* selinux/passt.te: Allow setcap on the process itselfStefano Brivio2023-02-211-0/+1
| | | | | | | This is needed by the new functions in isolate.c, add the corresponding rule. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* selinux: Switch to a more reasonable model for PID and socket filesStefano Brivio2023-02-212-5/+7
| | | | | | | | Instead of restricting PID files to /var/run/passt.pid, which is a single file and unlikely to be used, use the user_tmp_t type which should cover any reasonable need. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* selinux: Define interfaces for libvirt and similar frameworksStefano Brivio2023-02-212-0/+27
| | | | | | | | | | Services running passt will commonly need to transition to its domain, terminate it, connect and write to its socket. The init_daemon_domain() macro now defines the default transition to the passt_t domain, using the passt_exec_t type. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* selinux/passt.if: Fix typo in passt_read_data interface definitionStefano Brivio2023-02-211-1/+1
| | | | | | | | | This is an example interface, currently unused, so it went undetected: m4 macros need a backtick at the beginning of a block instead of a single quote. Fixes: 1f4b7fa0d75d ("passt, pasta: Add examples of SELinux policy modules") Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* Remove contrib/debian, Debian package development now happens on SalsaStefano Brivio2022-11-166-63/+0
| | | | | | | | | The development of the Debian package is now at: https://salsa.debian.org/sbrivio/passt Drop contrib/debian, it's finally obsolete. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* contrib/apparmor: Merge pasta and passt profiles, update rulesStefano Brivio2022-11-162-88/+51
| | | | | | | | | | | | | AppArmor resolves executable links before profile attachment rules are evaluated, so, as long as pasta is installed as a link to passt, there's no way to differentiate the two cases. Merge the two profiles and leave a TODO note behind, explaining two possible ways forward. Update the rules so that passt and pasta are actually usable, once the profile is installed. Most required changes are related to isolation and sandboxing features. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-05 05:43:12 +0000