Add a milter_port_t for use with inet sockets for communication
between milters and MTAs.
There are no defined ports with this type: admins are expected
to use semanage to specify the ports being used for milters.
The unconfined user is currently not allowed to call portage-related
functions. However, in a targeted system (with unconfined domains
enabled), users (including administrators) should be allowed to
transition to the portage domain.
We position the portage-related calls outside the "ifdef(distro_gentoo)"
as other distributions support Portage as well.
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
The system administrator (in sysadm_t) is the only "user" domain that is
allowed to call portage-related services. So it also gains the privilege
to execute portage tree management functions (and as such transition to
portage_fetch_t).
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
The semanage application supports a "semanage permissive" feature,
allowing certain domains to be marked for running permissive (rather
than the entire system).
To support this feature, we introduce a semanage_var_lib_t type for the
location where semanage will keep its permissive_<domain>.* files, and
allow semanage_t to work with fifo_files (needed for the command to
work).
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
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>
Some applications might want to execute gpg without requiring a
transition. A possible use case is to allow applications to validate
signatures (made by GnuPG). As long as the application doesn't need to
generate signatures itself and its trustdb is not marked as
gpg_secret_t, it suffices to grant it gpg_exec().
Note that it does require the application to have read/write rights in
the directory where the trustdb is stored (as gpg tries to generate lock
files where the trustdb file is located).
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 /sbin/rc binary is used by the system administrator to manage
runlevels (add/delete), check runlevel state, etc. all which do not
require a transition to occur. Hence the /sbin/rc (now labeled
rc_exec_t) is allowed to be executed without transitioning.
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
When an init script is launched, Gentoo's integrated run_init support
will re-execute /sbin/rc (an all-in-one binary) for various functions.
The run_init_t domain here should not be allowed to transition yet, so
we allow it to execute /sbin/rc without transitioning.
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>
Within Gentoo, the init system (openrc) uses a single binary (/sbin/rc)
for all its functions, be it executing init scripts, managing runlevels,
checking state, etc. This binary is not allowed to be labeled
initrc_exec_t as that would trigger domain transitions where this isn't
necessary (or even allowed).
A suggested solution is to use a separate type declaration for /sbin/rc
(rc_exec_t) which transitions where necessary.
This patch includes support for the /sbin/rc rc_exec_t type and declares
the init_rc_exec() interface which allows domains to execute the binary
without transitioning.
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
Puppet is a management utility to manage several dozens or even hundreds of
systems through a single application. Part of its job is to ensure that the
configuration and state of a system is as expected. Part of this is to ensure
that the proper mounts are available and, if not, mount them (or umount them).
This patch allows puppet_t to call mount.
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
During build and eventual activation of the base policy, the load_policy_t
domain attempts to use a portage file descriptor. However, this serves no
purpose (the loading is done correctly and everything is logged
appropriately).
Hence, we dontaudit this use.
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
Systems that use LDAPS (LDAP over SSL/TLS) for their sysnet_* activities
currently fail since these domains do not allow proper access to the random
devices (needed for SSL/TLS). This patch adds this privilege to
sysnet_use_ldap.
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
The courier-imapd daemon is part of the courier package (and already supported
by the courier module in refpolicy), but uses a different location for its
configuration files (/etc/courier-imap) and persistent data
(/var/lib/courier-imap).
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
