This is used by cloud providers to set up VMs during deployment.
https://github.com/canonical/cloud-init
Signed-off-by: Chris PeBenito <Christopher.PeBenito@microsoft.com>
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>
In order to detect bugs like the one fixed by commit d938683bf47c
("drbd: fix pattern for /usr/lib/ocf/resource.d/linbit/drbd"), forbid
the use of \d in the policy. This was actually only used to match
/usr/share/apr-1/build/...
with
/usr/share/apr(-\d)?/build/[^/]+\.sh -- gen_context(system_u:object_r:bin_t,s0)
/usr/share/apr(-\d)?/build/libtool -- gen_context(system_u:object_r:bin_t,s0)
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
Debian's PAM configuration uses a patched pam_motd module that runs
files in /etc/update-motd.d/ in order to generate a dynamic Message Of
The Day (MOTD). By default, there is only one script:
$ cat /etc/update-motd.d/10-uname
#!/bin/sh
uname -snrvm
According to https://wiki.debian.org/motd, the script is executed
through run-parts:
if (!system("/usr/bin/env -i
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
run-parts --lsbsysinit /etc/update-motd.d >
/run/motd.dynamic.new"))
rename("/run/motd.dynamic.new", "/run/motd.dynamic");
This requires allowing pam_motd users to execute bin_t commands
(/usr/bin/env) and shells (/bin/sh), and to manage /run/motd.dynamic*
files.
Allow relevant accesses for Debian-based systems.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
In a pattern, a dot can match any character, including slash. It makes
sense when it is combined with ?, + or *, but makes little sense when
left alone.
Most of the time, the label was for file containing dots, where the dot
was not escaped. A few times, the dot was really intended to match any
character. In such case, [^/] better suits the intent.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
Label some shell scripts from bridge-utils correctly. Maybe have ifdef
distro_debian around this, not sure what upstream is doing.
systemd_nspawn_t needs to manage the /etc/localtime symlink if you have a
labeled chroot.
Another dontaudit for mon_local_test_t to stop it spamming the logs.
Support a .d directory for dnsmasq config files.
Commit 2e7553db63 ("Create / to /usr equivalence for bin, sbin, and
lib, from Russell Coker.") removed from corecommands.fc:
/usr/(.*/)?bin(/.*)? gen_context(system_u:object_r:bin_t,s0)
Consequently files like /usr/x86_64-w64-mingw32/bin/objdump get labeled
as usr_t:
$ matchpathcon /usr/x86_64-w64-mingw32/bin/objdump
/usr/x86_64-w64-mingw32/bin/objdump system_u:object_r:usr_t
Make such files labeled as bin_t again.
This patch adds three new file contexts for script executables
belonging to new Gnome applications (weather application and
sound recorder).
Signed-off-by: Guido Trentalancia <guido@trentalancia.net>
On systems such as Arch Linux, all programs which are usually located in
/bin, /sbin, /usr/bin and /usr/sbin are present in /usr/bin and the
other locations are symbolic links to this directory. With such a
configuration, the file contexts which define types for files in
/bin, /sbin and /usr/sbin need to be duplicated to provide definitions
for /usr/bin/...
As the "/bin vs. /usr/bin" part of the needed definitions has already
been done with the "usr merge" patches, the next step consists in
duplicating file contexts for /usr/sbin. This is what this patch does
for all modules which are not in contrib.
This is the second iteration of an idea I have previously posted on
http://oss.tresys.com/pipermail/refpolicy/2017-March/009176.html
When you merged the mon patch you removed the ability for mon_t to execute
lib_t files.
The following patch re-enables the ability to execute alert scripts.
Some policy modules define file contexts in /bin, /sbin and /lib without
defining similar file contexts in the same directory under /usr.
Add these missing file contexts when there are outside ifdef blocks.
/etc/sysconfig/libvirtd does not have the executable bit set, so it does
not make sense for it to be labelled bin_t. I can't seem to find the
reason it was set that way originally.
Signed-off-by: Garrett Holmstrom <gholms@devzero.com>
On Arch Linux, /usr/lib/gvfs directory contains both executable files
(gvfsd, gvfs-udisks2-volume-monitor...) and libraries (libgvfscommon.so
and libgvfsdaemon.so). As all executable files are prefixed with
"gfvs", so use this to distinguish them with the libraries.
This fixes the following AVC denials, reported from geoclue service
using a library wrongly labelled bin_t:
avc: denied { read } for pid=14872 comm="geoclue"
name="libgvfscommon.so" dev="dm-0" ino=3152594
scontext=system_u:system_r:geoclue_t
tcontext=system_u:object_r:bin_t tclass=file permissive=1
avc: denied { open } for pid=14872 comm="geoclue"
path="/usr/lib/gvfs/libgvfscommon.so" dev="dm-0" ino=3152594
scontext=system_u:system_r:geoclue_t
tcontext=system_u:object_r:bin_t tclass=file permissive=1
avc: denied { execute } for pid=14872 comm="geoclue"
path="/usr/lib/gvfs/libgvfscommon.so" dev="dm-0" ino=3152594
scontext=system_u:system_r:geoclue_t
tcontext=system_u:object_r:bin_t tclass=file permissive=1
It is used by system-config-printer, as shown by these AVC denials:
avc: denied { execute } for pid=1061 comm="system-config-p"
name="applet.py" dev="dm-0" ino=9568316
scontext=sysadm_u:sysadm_r:sysadm_t tcontext=system_u:object_r:usr_t
tclass=file permissive=1
avc: denied { execute_no_trans } for pid=1061
comm="system-config-p"
path="/usr/share/system-config-printer/applet.py" dev="dm-0"
ino=9568316 scontext=sysadm_u:sysadm_r:sysadm_t
tcontext=system_u:object_r:usr_t tclass=file permissive=1
On Arch Linux, OpenSSH installs these binary files in /usr/lib/ssh:
* sftp-server (labeled with ssh_keysign_exec_t type in refpolicy)
* ssh-askpass (symlink to x11-ssh-askpass)
* ssh-keysign
* ssh-pkcs11-helper
* x11-ssh-askpass (from x11-ssh-askpass package)
Label all these files but sftp-server as bin_t.
