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>
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>
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>
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>
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>
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>
...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>
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>
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>
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>
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>
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>
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>
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>
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: 1f4b7fa0d7 ("passt, pasta: Add examples of SELinux policy modules")
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
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>
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>
fedora-review says:
Note: Directories without known owners:
/usr/share/selinux/packages/passt, /usr/share/doc/passt,
/usr/share/selinux, /usr/share/selinux/packages
and selinux-policy owns those two last ones.
While at it, split Requires: tags also for post and preun actions
onto different lines, for consistency.
Reported-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
fedora-review says:
Note: No known owner of /usr/share/selinux/packages/passt,
/usr/share/doc/passt
While at it, replace "passt" by "%{name}" in a few places for
consistency.
Reported-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
...instead of PATH. This seems to be the only change needed in
existing pasta integrations after patch:
Use explicit --netns option rather than multiplexing with PID
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Fedora's parameters currently match the ones from the Makefile (which
is based on GNU recommendations), but that's not necessarily
guaranteed.
This should make the OpenSUSE Tumbleweed override for docdir
unnecessary: drop it.
Suggested-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
...as it's used twice. The short version, however, appears hardcoded
only once in the output, and it comes straight from the rpkg macro
building the version string -- leave that macro as it is.
Suggested-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
...which makes it fall under MIT licensing terms. Daniel reports that
it's very unusual for spec files to contain explicit licensing terms
and might cause minor inconveniences later on, on mass changes to
spec files.
I originally added licensing information using SPDX identifiers to
make the project fully compliant with the REUSE Specification 3.0
(https://reuse.software/spec/), but there are anyway a few more files
not including explicit licensing information. It might be worth to
fix that later on, in any case.
Suggested-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
It turns out that, while on most distributions "docdir" would be
/usr/share/doc, it's /usr/share/doc/packages/ on OpenSUSE Tumbleweed.
Use an explicit docdir as shown in:
https://en.opensuse.org/openSUSE:Build_Service_cross_distribution_howto
and don't unnecessarily hardcode directory variables in the Makefile.
Otherwise, RPM builds for OpenSUSE will fail now that we have a README
there.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
If the man pages are not compressed, the current wildcards wouldn't
match them. Drop the trailing '.' from them.
Reported-by: Artur Frenszek-Iwicki <fedora@svgames.pl>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
This will also set any distribution-specific LDFLAGS. It's not needed
anymore starting from Fedora 36, but the package might be built on
other versions and distributions too (including e.g. CentOS Stream 8).
Reported-by: Artur Frenszek-Iwicki <fedora@svgames.pl>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Otherwise, passt-selinux will be built separately for each supported
architecture.
Suggested-by: Artur Frenszek-Iwicki <fedora@svgames.pl>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
This is required as Fedora doesn't accept a temporary pointer to
a source URL.
Reported-by: Ralf Corsepius <rc040203@freenet.de>
Reported-by: Artur Frenszek-Iwicki <fedora@svgames.pl>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
It seems to be exposed by Koji (https://pagure.io/koji/issue/2541),
but it's not actually in use, so we have to drop that. The website
the URL tag points to reports all the needed information anyway.
Reported-by: Artur Frenszek-Iwicki <fedora@svgames.pl>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
git_dir_changelog is useful in theory, but it requires pairs of
annotated tags, which should be generated by rpkg itself to make any
sense, implying a relatively heavyweight interaction whenever I want
to push a new package version.
Also, the default content of the changelog entries include the full
list of changes, but the Fedora Packaging Guidelines specifically
mention that:
[t]hey must never simply contain an entire copy of the source
CHANGELOG entries.
We don't have a CHANGELOG file, but the full git history is
conceptually equivalent for this purpose, I guess.
Introduce our own passt_git_changelog() rpkg macro, building
changelog entries, using tags in the form DATE-SHA, where DATE
is an ISO 8601 date representation, and SHA is a short (7-digits)
form of the head commit at a given moment (git push).
These changelog entries mention, specifically, changes to the
packaging information itself (entries under contrib/fedora), and
simply report a link to cgit for the ranges between tags.
Reported-by: Benson Muite <benson_muite@emailplus.org>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Given that a three-way git merge was enough to cope with context
changes in man pages, it's probably a good idea to enable that for
'git am' in the demo too.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
