Haveged by itself requires a few additional privileges (create a unix socket
and write access to some proc/sys/kernel files (like
/proc/sys/kernel/random/write_wakeup_threshold).
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
Introduce a tunable called "entropyd_use_audio". This boolean triggers the
privileges that are specific for audio support (both device access as well
as the alsa-specific ones).
The idea to use a boolean is to support other entropy management
applications/daemons which use different sources (like haveged using the
HAVEGE algorithm).
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>
Create the rpc_tcp_rw_nfs_sockets() interface, allowing for the calling
domain to access the tcp_sockets managed by nfsd_t.
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
This is intended to label /run/udev, but I am assuming that everyone
will use file_contexts.subs(_dist)? to substitute /var/run for /run,
since there are currently no other fcs for /run in refpolicy.
The label is udev_tbl_t instead of udev_var_run_t, because /run/udev
contains the data which used to be in /dev/.udev.
Add read_lnk_file_perms to all interfaces giving access to var_run_t and
var_lock_t.
This is needed as on Debian /var/run and /var/lock are now symlinks to
/run and /run/lock.
When mozilla_role interface is called, 1st argument is the caller's
role and 2nd argument is the caller's domain, such as:
mozilla_role(staff_r, staff_t)
When mozilla_role calls mozilla_run_plugin, the passed 2nd argument
should be the caller's role rather than its domain, so $1 not $2 should
be used.
Signed-off-by: Harry Ciao <qingtao.cao@windriver.com>
The zabbix agent is responsible for collecting the system state and other
monitorable aspects. This include
- information from /proc
- read attributes of various files (tamper detection)
- connect to the ssh service (check if it is reachable)
- get file system information
- read login information
- ...
It should be noted that the agent can do a lot more, depending on the target
system (what is being monitored) and the running services. The allowed
privileges here will in the future expand more as more templates are
checked.
Update: follow styleguide
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
The zabbix server also connects to the agents (this is called "active
monitoring" in the zabbix terms). So we create a zabbix_agent_tcp_connect
interface, use it for the zabbix_t domain and, since zabbix can use
hostname-based connections, allow DNS resolving for the zabbix server.
Update: Follow styleguide
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
The zabbix agent has its own dedicated port (10050) on which it needs to
bind/listen.
Also, the agent connects to the server so we add the zabbix_tcp_connect
interface (shamelessly copied from mysql_tcp_connect) and use it for the
zabbix_agent_t domain.
Update: structure interface calls more closely to styleguide
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
The zabbix agent should be confined within its own domain. We start with the
definition of a small(er) skeleton to work from. This includes proper file
context definitions, standard interdomain privileges (which are quite
similar to those of the server) and the proper log- and pid access
privileges.
Update: attempt to follow styleguide more closely
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
The zabbix server uses a dedicated port (10051). We define it and allow the
zabbix server to bind/listen on it.
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
On Mon, Jun 13, 2011 at 10:28:15AM +0200, Sven Vermeulen wrote:
> Zabbix servers use shared memory to keep common information and structures.
> This is implemented on tmpfs. We support this by introducing a
> zabbix_tmpfs_t type and allow the server proper access to it.
After a small discussion and a few more tests, drop the "dir" in
fs_tmpfs_filetrans.
For posterity's sake, this is the denial one gets when no tmpfs_t related
privileges are given:
Jun 13 11:24:06 build kernel: [ 213.054230] type=1400
audit(1307957046.001:106): avc: denied { read write } for pid=3162
comm="zabbix_agentd" path=2F535953563663303132323534202864656C6574656429
dev=tmpfs ino=32768 scontext=system_u:system_r:zabbix_agent_t
tcontext=system_u:object_r:tmpfs_t tclass=file
With fs_tmpfs_filetrans(..., file) the same denial is given, but as
tcontext=zabbix_tmpfs_t. Hence the rw_files_pattern() enhancement.
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
The zabbix server process is a multi-process system.
In order to, for instance, shut it down, signalling within the domain is
necessary. Otherwise, the processes remain running.
Also, since there are multiple processes trying to use the same log file,
the zabbix server uses semaphores to ensure proper access to the log files
(concurrency).
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
Chris PeBenito
Sven Vermeulen
Matthew Ife
Harry Ciao