passt: Relicense to GPL 2.0, or any later version
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>
2023-04-05 20:11:44 +02:00
|
|
|
# SPDX-License-Identifier: GPL-2.0-or-later
|
contrib/apparmor: Split profile into abstractions, use them
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>
2023-02-27 17:24:40 +01:00
|
|
|
#
|
|
|
|
|
# PASST - Plug A Simple Socket Transport
|
|
|
|
|
# for qemu/UNIX domain socket mode
|
|
|
|
|
#
|
|
|
|
|
# PASTA - Pack A Subtle Tap Abstraction
|
|
|
|
|
# for network namespace/tap device mode
|
|
|
|
|
#
|
|
|
|
|
# contrib/apparmor/abstractions/passt - Abstraction for passt(1)
|
|
|
|
|
#
|
|
|
|
|
# Copyright (c) 2022 Red Hat GmbH
|
|
|
|
|
# Author: Stefano Brivio <sbrivio@redhat.com>
|
|
|
|
|
|
|
|
|
|
abi <abi/3.0>,
|
|
|
|
|
|
|
|
|
|
include <abstractions/base>
|
|
|
|
|
|
2023-09-06 20:39:12 +02:00
|
|
|
include <abstractions/nameservice> # get_dns(), conf.c
|
contrib/apparmor: Split profile into abstractions, use them
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>
2023-02-27 17:24:40 +01:00
|
|
|
|
|
|
|
|
capability net_bind_service, # isolation.c, conf.c
|
|
|
|
|
capability setuid,
|
|
|
|
|
capability setgid,
|
|
|
|
|
capability sys_admin,
|
|
|
|
|
capability setpcap,
|
|
|
|
|
capability net_admin,
|
|
|
|
|
capability sys_ptrace,
|
|
|
|
|
|
|
|
|
|
/ r, # isolate_prefork(), isolation.c
|
apparmor: Explicitly pass options we use while remounting root filesystem
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>
2023-09-06 20:54:52 +02:00
|
|
|
mount options=(rw, runbindable) /,
|
2024-04-03 19:57:34 +02:00
|
|
|
mount "" -> "/",
|
contrib/apparmor: Split profile into abstractions, use them
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>
2023-02-27 17:24:40 +01:00
|
|
|
mount "" -> "/tmp/",
|
|
|
|
|
pivot_root "/tmp/" -> "/tmp/",
|
|
|
|
|
umount "/",
|
|
|
|
|
|
2023-09-06 21:09:47 +02:00
|
|
|
owner @{PROC}/@{pid}/uid_map r, # conf_ugid()
|
|
|
|
|
|
contrib/apparmor: Split profile into abstractions, use them
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>
2023-02-27 17:24:40 +01:00
|
|
|
network netlink raw, # nl_sock_init_do(), netlink.c
|
|
|
|
|
|
|
|
|
|
network inet stream, # tcp.c
|
|
|
|
|
network inet6 stream,
|
|
|
|
|
|
|
|
|
|
network inet dgram, # udp.c
|
|
|
|
|
network inet6 dgram,
|
|
|
|
|
|
|
|
|
|
network unix stream, # tap.c
|
|
|
|
|
|
|
|
|
|
network unix dgram, # __openlog(), log.c
|
|
|
|
|
|
|
|
|
|
/usr/bin/passt.avx2 ix, # arch_avx2_exec(), arch.c
|