Optionally generate Netfilter NFT tables. Sample output:
```#!/usr/sbin/nft -f
flush ruleset
table inet security {
secmark default_input_packet {
"system_u:object_r:server_packet_t:s0"
}
secmark default_output_packet {
"system_u:object_r:client_packet_t:s0"
}
secmark afs_bos_input {
"system_u:object_r:afs_bos_server_packet_t:s0"
}
secmark afs_bos_output {
"system_u:object_r:afs_bos_client_packet_t:s0"
}
...
chain INPUT {
type filter hook input priority 0; policy accept;
ct state new meta secmark set "default_input_packet"
ct state new udp dport 7007 meta secmark set "afs_bos_input"
...
ct state new ct secmark set meta secmark
ct state established,related meta secmark set ct secmark
}
chain FORWARD {
type filter hook forward priority 0; policy accept;
}
chain OUTPUT {
type filter hook output priority 0; policy accept;
ct state new meta secmark set "default_output_packet"
ct state new udp dport 7007 meta secmark set "afs_bos_output"
...
ct state new ct secmark set meta secmark
ct state established,related meta secmark set ct secmark
}
}
```
The labels are applied to TCP and/or UDP as needed. MCS and MLS are
not really handled.
Signed-off-by: Topi Miettinen <toiwoton@gmail.com>
The various /bin/tpm2_* binaries use dbus to communicate
with tpm2-abrmd and also can directly access /dev/tpmrm0. This
seems like a way to help limit access to the TPM by running the
tpm_* binaries in their own domain.
I setup this domain because I have a process that needs to use
tpm2_hmac to encode something, but didn't want that domain to
have direct access to the TPM. I did some basic testing to verify
that the other tpm2_* binaries have basically the same access needs.
But it wasn't through testing of all the tpm2_* binaries.
Signed-off-by: Dave Sugar <dsugar@tresys.com>
When testing issues in older versions of refpolicy (for example when
git-bisecting a regression), the newer policy modules are kept in
/usr/share/selinux/refpolicy/ and trigger errors when they fail to be
loaded by "semodule -s refpolicy -i /usr/share/selinux/refpolicy/*.pp".
Avoid this situation by removed old modules from
/usr/share/selinux/refpolicy/ before running "make install".
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
Use a separate directory for files generated my 'make conf', so the clean targets from Rules.* do not remove them.
Signed-off-by: Christian Göttsche <cgzones@googlemail.com>
Yes mmap is the standard way of accessing the mail spool.
Removed spamd_gpg_t because there's no point to it, the separation doesn't
provide an actual benefit.
Made the other requested changes.
Signed-off-by: Russell Coker <russell@coker.com.au>
Init, init scripts and udisks don't need to be able to create regular
files in /dev.
Thanks to Jarkko Sakkinen for the idea.
Signed-off-by: Topi Miettinen <toiwoton@gmail.com>
D-Bus services wanting to pass file descriptors for
tun/tap devices need to read/write privileges to /dev/tun.
Without this privilege the following denial will happen:
type=AVC msg=audit(1582227542.557:3045): avc: denied { read write } for pid=1741 comm="dbus-daemon" path="/dev/net/tun" dev="devtmpfs" ino=486 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tun_tap_device_t:s0 tclass=chr_file permissive=0
This is needed by OpenVPN 3 Linux, where an unprivileged
process (openvpn3-service-client) requests a tun device
from a privileged service (openvpn3-service-netcfg) over
the D-Bus system bus.
GitHub-Issue: #190
Signed-off-by: David Sommerseth <davids@openvpn.net>
I'm seeing problems on RHEL7 with lvm2-activation-generator that are
coming from recent changes to put systemd-fstab-generator into it's
own domain. I resolved the issues by creaing this generator attribute
to grant common generator permissions and move all generators into
a single systemd_generator_t domain.
Then setup specific types for the following generators:
lvm2-activation-generator - needs to read lvm2 config
systemd-sysv-generator - needs to read stuff in init_t that other generators don't.
systemd-efi-boot-generator - needs to read stuff on the EFI boot partition labeled boot_t
For fstab generator allow it to write /sys
[ 19.482951] type=1400 audit(1584548691.268:7): avc: denied { write } for pid=1638 comm="systemd-fstab-g" name="/" dev="sysfs" ino=1 Allow scontext=system_u:system_r:systemd_fstab_generator_t:s0 tcontext=system_u:object_r:sysfs_t:s0 tclass=dir permissive=1
audit(1585500099.139:6): avc: denied { read } for pid=1635 comm="systemd-cryptse" path="/run/systemd/generator/dev-mapper-luks\x2d6a613af0\x2d0a61\x2d462f\x2d8679\x2d1b0d964fbc88.device.d/.#90-device-timeout.confsOskdU" dev="tmpfs" ino=12243 scontext=system_u:system_r:systemd_generator_t:s0 tcontext=system_u:object_r:init_runtime_t:s0 tclass=file permissive=1
audit(1585500099.139:7): avc: denied { setattr } for pid=1635 comm="systemd-cryptse" name=".#90-device-timeout.confsOskdU" dev="tmpfs" ino=12243 scontext=system_u:system_r:systemd_generator_t:s0 tcontext=system_u:object_r:init_runtime_t:s0 tclass=file permissive=1
audit(1585500099.139:8): avc: denied { rename } for pid=1635 comm="systemd-cryptse" name=".#90-device-timeout.confsOskdU" dev="tmpfs" ino=12243 scontext=system_u:system_r:systemd_generator_t:s0 tcontext=system_u:object_r:init_runtime_t:s0 tclass=file permissive=1
Signed-off-by: Dave Sugar <dsugar@tresys.com>