This is better than the current status quo of running nginx under
initrc_t, a lot of other webservers are already under the apache policy
(e.g. lighttpd) and this requires no additional permissions.
See also the discussion from March 2013 on the selinux-refpolicy mailing
list: https://lore.kernel.org/selinux-refpolicy/20110318110259.GA25236@localhost.localdomain/
Signed-off-by: bauen1 <j2468h@gmail.com>
a require was fixed back in 2011, so using corenet_tcp_bind_stunnel_port
would be an option now, but stunnel_t already has
corenet_tcp_bind_all_ports, so this access is redundant.
Signed-off-by: Daniel Burgener <Daniel.Burgener@Microsoft.com>
I have been working to support IMA/EVM on a system. It
requires having keys added to the kernel keyring. Keys
added with keyctl and evmctl. I am creating keys in the
ima_key_t type. Once the keys are created, many domains
then need search permission on the type of the key. The
following changes are needed to get things to work.
Need to add keys to the kernel keyring (keyctl).
type=AVC msg=audit(1585420717.704:1868): avc: denied { write } for pid=8622 comm="keyctl" scontext=system_u:system_r:cleanup_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=key permissive=1
Allow all domains to search key
type=AVC msg=audit(1587936822.802:556): avc: denied { search } for pid=5963 comm="kworker/u16:6" scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:ima_key_t:s0 tclass=key permissive=1
type=AVC msg=audit(1587936822.804:559): avc: denied { search } for pid=5963 comm="systemd-cgroups" scontext=system_u:system_r:systemd_cgroups_t:s0 tcontext=system_u:object_r:ima_key_t:s0 tclass=key permissive=1
type=AVC msg=audit(1587936822.809:560): avc: denied { search } for pid=5964 comm="(sysctl)" scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:ima_key_t:s0 tclass=key permissive=1
type=AVC msg=audit(1587936822.813:562): avc: denied { search } for pid=5964 comm="sysctl" scontext=system_u:system_r:initrc_t:s0 tcontext=system_u:object_r:ima_key_t:s0 tclass=key permissive=1
type=AVC msg=audit(1587936823.149:604): avc: denied { search } for pid=5987 comm="setsebool" scontext=system_u:system_r:semanage_t:s0 tcontext=system_u:object_r:ima_key_t:s0 tclass=key permissive=1
Signed-off-by: Dave Sugar <dsugar@tresys.com>
Add EFI bootloaders rEFInd and systemd-boot. Boot tools which manage
bootloader files in UEFI (DOS) partition need also to manage UEFI boot
variables in efivarfs. Bootctl (systemd-boot tool) verifies the type
of EFI file system and needs to mmap() the files.
Signed-off-by: Topi Miettinen <toiwoton@gmail.com>
Add KWin to list of window managers and allow it to mmap wm_tmpfs_t
files to avoid a crash. Related audit event:
type=AVC msg=audit(04/24/2020 15:39:25.287:679) : avc: denied { map } for pid=1309 comm=kwin_x11 path=/memfd:JSVMStack:/lib/x86_64-linux-gnu/libQt5Qml.so.5 (deleted) dev="tmpfs" ino=45261 scontext=user_u:user_r:user_wm_t:s0 tcontext=user_u:object_r:wm_tmpfs_t:s0 tclass=file permissive=0
Signed-off-by: Topi Miettinen <toiwoton@gmail.com>
Allow systemd-networkd to send and receive ICMPv6 Router Solicitation
and Router Advertisement packets (in reality all ICMP/ICMPv6 packets)
and DHCP client packets.
Signed-off-by: Topi Miettinen <toiwoton@gmail.com>
In many cases, this won't result in a change in the actual policy generated, but if the definitions of macros are changed going forward, the mismatches could cause issues.
Signed-off-by: Daniel Burgener <Daniel.Burgener@microsoft.com>
When using network namespaces with `ip netns`, command `ip` creates
files in `/run/netns` that are mountpoints for `nsfs`. For example:
$ ip netns add VPN
$ ls -Z /run/netns/VPN
system_u:object_r:nsfs_t /run/netns/VPN
$ findmnt /run/netns/VPN
TARGET SOURCE FSTYPE OPTIONS
/run/netns/VPN nsfs[net:[4026532371]] nsfs rw
/run/netns/VPN nsfs[net:[4026532371]] nsfs rw
From a shell CLI, it is possible to retrieve the name of the current
network namespace:
$ ip netns exec VPN bash
$ ip netns identify $$
VPN
This requires reading `/proc/$PID/ns/net`, which is labelled as a user
domain. Allow this access using `userdom_read_all_users_state()`.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
`sysdig` is a tool that enables introspecting the system, debugging it,
etc. It uses a driver that creates `/dev/sysdig0`. Define a specific
label in order to be able to allow using it.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
On Debian 10, ``systemd --user`` runs some generators in
/usr/lib/systemd/user-environment-generators when a user session starts.
Here is what is logged in audit.log for a sysadm user.
type=AVC msg=audit(1586962888.516:65): avc: denied { getattr } for
pid=309 comm="(sd-executor)"
path="/usr/lib/systemd/user-environment-generators/90gpg-agent"
dev="vda1" ino=662897 scontext=sysadm_u:sysadm_r:sysadm_systemd_t
tcontext=system_u:object_r:systemd_generator_exec_t tclass=file
permissive=1
type=AVC msg=audit(1586962888.516:66): avc: denied { map } for
pid=310 comm="30-systemd-envi"
path="/usr/lib/systemd/user-environment-generators/30-systemd-environment-d-generator"
dev="vda1" ino=655822 scontext=sysadm_u:sysadm_r:sysadm_systemd_t
tcontext=system_u:object_r:systemd_generator_exec_t tclass=file
permissive=1
type=AVC msg=audit(1586962888.516:66): avc: denied
{ execute_no_trans } for pid=310 comm="(direxec)"
path="/usr/lib/systemd/user-environment-generators/30-systemd-environment-d-generator"
dev="vda1" ino=655822 scontext=sysadm_u:sysadm_r:sysadm_systemd_t
tcontext=system_u:object_r:systemd_generator_exec_t tclass=file
permissive=1
Run these program without domain transition.
This follows a discussion that took place in
https://github.com/SELinuxProject/refpolicy/pull/224
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
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>
