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>
With the introduction of the freedesktop XDG location support in the
policy, end users need to be allowed to manage these locations from their
main user domain.
The necessary privileges are added to the xserver_role() interface, which is
in use by the unconfined user domain as well as the main other user domains
(like user, sysadm and staff).
The necessary file transitions for the directories are added as well.
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
Introduce various freedesktop locations, based on the base directory
specification [1]. The new locations are introduced as a separate module
to keep the rules related to these specifications isolated from the main
user domain (which is already one of the biggest modules code-wise).
Right now, two distinct location groups are provided, one being the set
of locations that will have domain-specific types, and one that remains
generic for end users.
The first set of types are:
- XDG Cache location, meant for non-essential cached data. The base type
here is xdg_cache_t, which is generally at $HOME/.cache
- XDG Data location, for user-specific data. The base type here is
xdg_data_t, which is generally at $HOME/.local
- XDG Config location, for user-specific configuration files. The base
type here is xdg_config_t, which is generally at $HOME/.config
The idea here is to provide support for domain-specific files as well.
For instance, Chromium has its user-specific configuration files in
~/.config/chromium, which is then marked as chromium_xdg_config_t.
This allows for isolation of potentially sensitive information from
regular user application domains. Firefox for instance should not be
able to read user configuration data from unrelated applications.
The second set of types are:
- User documents, with xdg_documents_t as the type. This is
generally for the ~/Documents location.
- User downloads, with xdg_downloads_t as the type. This is
generally for the ~/Downloads location.
- User music, with xdg_music_t as the type. This is generally for
the ~/Music location.
- User pictures, with xdg_pictures_t as the type. This is generally
for the ~/Pictures location.
- User videos, with xdg_videos_t as the type. This is generally for
the ~/Videos location.
Alongside the type definitions, a number of access interfaces are
defined to support the use of these types, and for the first set to
enable the necessary file transitions.
[1] https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
Update the Makefile to first build the template files (template code
definitions) and then have all segenxml calls use these files.
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
The segenxml tool is used to generate documentation regarding the policy
definitions. Its output is an XML file that contains the in-line
comments associated with boolean generation as well as interface
definitions.
With booleans also generated inside templates, this information was
(until now) ignored. Templates such as apache's apache_content_template
which created new booleans were not properly documented, as the
in-template comments were ignored.
In this patch, we will go over module code first and seek template
calls. When a template call is matched, the module code is updated
(expanded) with the template content (while substituting the arguments
to get a proper code listing). Only after all templates have been
expanded we seek the necessary boolean definitions.
Changes since v2:
- Fix BOOLEAN statements to match backtick (`) and tick (') usages as
well
- Fix match for arguments to also include multiple entries ( { ... } )
Changes since v1:
- Also apply the regexp on BOOLEAN to allow generating templated
boolean/tunable documentation
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
Some of the templates in the reference policy generate new booleans and
tunables, based on the $1, $2, ... parameters passed on. To allow
segenxml, which generates the necessary documentation on booleans, to
keep track of template-generated booleans as well, we need to allow it
to substitute template calls with the actual template content.
The gentemplates.sh script is a helper script that will extract template
code and store it as files (one file per template). These files are then
later on used by the segenxml tool.
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>