OpenSSL 1.1 always opens both /dev/urandom and /dev/random, which
generates spurious denial messages for ssh_t, ssh_keygen_t and probably
various other domains too.
The code only uses /dev/random as a fallback and can cope with an open()
failure just fine, so I'm dontauditing the access. However, I don't have
strong feelings about this -- if someone would prefer to allow these
accesses instead, I'd be okay with that too.
Some distros configure logrotate to put its status file somewhere else
than the default /var/lib/logrotate.status. Debian puts it in
/var/lib/logrotate/, and Gentoo uses /var/lib/misc/.
mcstransd never implemented this permission. To keep permission indices
lined up, replace the permission with "unused_perm" to make it clear that
it has no effect.
Currently, sepolgen-ifgen fails with the following error:
/usr/share/selinux/refpolicy/include/support/obj_perm_sets.spt: Syntax error on line 157 ` [type=TICK]
error parsing headers
error parsing file /usr/share/selinux/refpolicy/include/support/obj_perm_sets.spt: could not parse text: "/usr/share/selinux/refpolicy/include/support/obj_perm_sets.spt: Syntax error on line 157 ` [type=TICK]"
Applications can optionally map fonts and fontconfig caches into memory.
miscfiles_read_fonts() already grants those perms, but it seems
xserver_use_user_fonts() was forgotten.
e2fsprogs 1.44.3 installs e2mmpstatus as a hard link to dumpe2fs. This
makes "restorecon -Rv /usr/bin" relabels this file with conflicting
contexts:
Relabeled /usr/bin/e2mmpstatus from system_u:object_r:fsadm_exec_t to system_u:object_r:bin_t
Relabeled /usr/bin/dumpe2fs from system_u:object_r:bin_t to system_u:object_r:fsadm_exec_t
Fix this by labelling e2mmpstatus like dumpe2fs.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
When using libreswan, pluto needs permissions for building the
Security Association Database and for setting contexts on IPSec
policy and SAs.
Signed-off-by: Yuli Khodorkovskiy <yuli@crunchydata.com>
In domain_transition_pattern there is rule:
allow $1 $2:file { getattr open read execute };
map permission is missing here, which is generating lot of AVC.
Replacing permissions with mmap_exec_file_perms set.
SELinux 2.8 is stricter with duplicate filetrans and these rules cause
problems if a domain needs more than one xdg dir.
Domains should call xdg_generic_user_home_dir_filetrans_data directly if
needed.
To simplify policy management on the various application domains with
respect to user content access, a template is introduced which generates
four tunable_policy() blocks.
- The *_read_generic_user_content boolean will enable the application
domain to read generic user resources (labeled with user_home_t).
- The *_read_all_user_content boolean does the same, but for all user
resources (those associated with the user_home_content_type attribute).
- The *_manage_generic_user_content boolean enables the application to
manage generic user resources (labeled with user_home_t)
- The *_manage_all_user_content boolean does the same, but for all user
reosurces (those associated with the user_home_content_type attribute).
Although it would be even better to generate the booleans themselves as
well (which is what Gentoo does with this template), it would result in
booleans without proper documentation. Calls such as "semanage boolean
-l" would fail to properly show a description on the boolean - something
Gentoo resolves by keeping this documentation separate in a
doc/gentoo_tunables.xml file.
In this patch, we assume that the calling modules will define the
booleans themselves (with appropriate documentation). The template
checks for the existence of the booleans. This approach is more in
line with how domain-specific booleans are managed up to now.
Changes since v2:
- Fix typo in gen_require (had a closing : instead of ;)
Changes since v1:
- Use in-line XML comment and tunable definition
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
To facilitate handling user home content (through the
user_home_content_type attribute) the following interfaces are provided:
- userdom_read_all_user_home_content
- userdom_manage_all_user_home_content
Domains that are granted these privileges are able to read (or manage)
all user home content, so not only the generic one (user_home_t) but all
types that have been assigned the user_home_content_type attribute. This
is more than just user_home_t and the XDG types, so the use should not
be granted automatically.
As part of the larger XDG patch set, these interfaces are called through
the *_read_all_user_content and *_manage_all_user_content booleans which
are by default not enabled.
Changes since v2:
- Fix typo in pattern call
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
Luis Ressel
David Sugar
Chris PeBenito
Laurent Bigonville
Nicolas Iooss
Yuli Khodorkovskiy
Lukas Vrabec
Jagannathan Raman
Jason Zaman
Sven Vermeulen