aboutgitcodebugslistschat
path: root/contrib/selinux/passt.te
Commit message (Collapse)AuthorAgeFilesLines
* selinux: Drop user_namespace class rules for Fedora 37Stefano Brivio2023-11-071-2/+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>
* selinux: Add rules for sysctl and /proc/net accessesStefano Brivio2023-08-181-0/+1
| | | | | | | | | 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-181-2/+7
| | | | | | | | | 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-181-0/+2
| | | | | | | | | | | | | | | | | 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>
* passt: Relicense to GPL 2.0, or any later versionStefano Brivio2023-04-061-1/+1
| | | | | | | | | | | | | | | | | | | 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>
* contrib/selinux: Drop "example" from headers: this is the actual policyStefano Brivio2023-03-101-1/+1
| | | | Signed-off-by: Stefano Brivio <sbrivio@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>
* 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-211-4/+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-211-0/+1
| | | | | | | | | | 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>
* passt, pasta: Add examples of SELinux policy modulesStefano Brivio2022-03-291-0/+111
These should cover any reasonably common use case in distributions. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>