When invoking tcpdump, the application creates a netlink_socket and then chroots
into /var/lib/tcpdump.
Without the right to create a netlink_socket:
tcpdump: Can't open netlink socket 13:Permission denied
Without the right on dac_read_search and sys_chroot:
tcpdump: Couldn't chroot/chdir to '/var/lib/tcpdump': Permission denied
See also https://bugs.gentoo.org/show_bug.cgi?id=443624
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
Now that we have file_contexts.subs_dist, translations that were put in the file context definition files can now be
cleaned up.
Differences from v1:
- removes a few duplicate entries in the libraries.fc file, and
- removes the contrib references
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
When using sudo with SELinux integrated support, the sudo domains need to be able to create user keys. Without this
privilege, any command invoked like "sudo /etc/init.d/local status" will run within the sudo domain (sysadm_sudo_t)
instead of the sysadm_t domain (or whatever domain is mentioned in the sudoers file).
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
By default, any role attribute should be able to type their "own" types
that share the same prefix and used in the run interface. For example,
role newrole_roles types newrole_t;
so that the calling domain of the seutil_run_newrole() interface could
properly tansition into newrole_t. Without above role rule, the caller's
role won't be associated with newrole_t.
Other role attributes such as useradd_roles, groupadd_roles, chfn_roles
and run_init_roles should be fixed in the same way.
Many users use portage from within cron (for instance to update the
portage tree or even automatically update their system). As such, we
allow to run portage from the (system) cronjob domains.
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
We allow portage to call gpg. However, this requires that the location
where the trustdb is stored is marked as a read/write type. The default
location used within Gentoo is /etc/portage/gpg, which would lead to
portage_conf_t. However, this type should remain a read-only type.
As such, we introduce a type called portage_gpg_t for this location and
grant portage_fetch_t the necessary rights on this type.
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
Enhance portage_fetch_t from an application type to a domain. Introduce
the proper portage_fetch_exec_t and add the necessary privileges to the
domain definition to allow portage_fetch_t to be used by Portage
management utilities like layman and emerge-webrsync.
We enhance portage_domtrans() to include portage_fetch_t support.
Providing a different interface (portage_fetch_domtrans) is possible
too, but since every application and role that needs to deal with
portage needs to deal with the fetching as well, and vice versa, we keep
this in portage_domtrans.
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
The gcc-config application uses some functions (from
/etc/init.d/functions.sh) which are simple wrappers on top of
/sbin/rc. Since this script is sourced and the functions executed
from within gcc_config_t, we allow gcc-config to execute /sbin/rc
without transitioning.
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
Portage supports the use of proxy systems (which usually run on port 8080)
for the fetching of software archives.
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
Portage supports the notion of "live ebuilds", which are packages that, when
installed, update a repository checkout on a specific location. This means
that a few portage-related domains need to have manage_* privileges on that
location whereas they usually have much more limited rights (when live
ebuilds aren't used).
To support live ebuilds, we introduce another label called portage_srcrepo_t
for those specific locations where the "higher" privileges are needed for,
and grant the proper permissions on the compile domains (like
portage_sandbox_t) to manage the checkouts.
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
When users want to use NFS mounted portage tree, distfiles, packages and
other locations, they need to use the proper context= mount option. However,
in the majority of cases, the users use a single NFS mount. In such
situation, context= cannot be used properly since it puts a label on the
entire mount (whereas we would then need other labels depending on
subdirectories).
Introducing a boolean "portage_use_nfs" which, when set (default off),
allows the necessary portage-related domains to manage files and directories
with the nfs_t label.
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
