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>
On Wed, Mar 23, 2011 at 09:10:37AM -0400, Christopher J. PeBenito wrote:
> > userdom_use_user_ptys(mozilla_t)
> > +userdom_manage_user_tmp_files(mozilla_t)
> > +userdom_manage_user_tmp_sockets(mozilla_t)
>
> Do you have more info on these? Such as what files and sockets are
> being managed?
Not anymore apparently. Been running now for quite some time without these
privileges and I get no problems with it. Retry:
Mozilla/Firefox creates temporary files for its plugin support (for instance
while viewing flc streams), like /tmp/plugtmp/plugin-crossdomain.xml.
Update policy to allow it to create its own tmp type and perform a file
transition when creating a file or directory in a tmp_t location (like
/tmp).
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
On Tue, Mar 22, 2011 at 08:44:49AM -0400, Christopher J. PeBenito wrote:
> > +manage_dirs_pattern(courier_authdaemon_t, courier_var_lib_t, courier_var_lib_t)
>
> It sounds like this should be create_dirs_pattern instead.
Indeed, create_dirs_pattern is sufficient here. Retry ;-)
During startup, authdaemon creates /var/lib/courier/authdaemon and creates a
socket for communication with courier imapd and pop3d daemons.
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
After a quick discussion with dominique, new attempt due to two issues:
1. No need (or even forbidden) to have "role $1 types foo_exec_t"
2. Suggestion to use the raid_run_mdadm name instead of raid_mdadm_role. The
idea here is to use raid_mdadm_role for prefixed domains (cfr. screen)
whereas raid_run_mdadm is to transition and run into a specific domain
Without wanting to (re?)start any discussion on prefixed versus non-prefixed
domains, such a naming convention could help us to keep the reference policy
cleaner (and naming conventions easy).
Also, refpolicy InterfaceNaming document only talks about run, not role.
So, without much further ado... ;-)
The system administrator (sysadm_r role) needs to use mdadm, but is not
allowed to use the mdadm_t type.
Rather than extend raid_domtrans_mdadm to allow this as well, use a
raid_mdadm_role (a bit more conform other role usages).
The other users of raid_domtrans_mdadm are all domains that run in system_r
role, which does have this type allowed (as per the system/raid.te
definition), so it wouldn't hurt to use raid_domtrans_mdadm for this.
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
During the installation of for instance java-config, Portage wants to set
its default file creation context to root:object_r:portage_tmp_t which isn't
allowed:
creating /var/tmp/portage/dev-java/java-config-2.1.11-r3/temp/images/3.1/etc/revdep-rebuild
copying src/revdep-rebuild/60-java -> /var/tmp/portage/dev-java/java-config-2.1.11-r3/temp/images/3.1/etc/revdep-rebuild/
running install_egg_info
Writing /var/tmp/portage/dev-java/java-config-2.1.11-r3/temp/images/3.1/usr/lib64/python3.1/site-packages/java_config-2.1.11-py3.1.egg-info
cp: failed to set default file creation context to `root:object_r:portage_tmp_t': Permission denied
cp: failed to set default file creation context to `root:object_r:portage_tmp_t': Permission denied
cp: failed to set default file creation context to `root:object_r:portage_tmp_t': Permission denied
cp: failed to set default file creation context to `root:object_r:portage_tmp_t': Permission denied
...
ERROR: dev-java/java-config-2.1.11-r3 failed:
Merging of intermediate installation image for Python ABI '2.6 into installation image failed
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
During installation of system packages like python, ustr, ... the
portage_sandbox_t domain requires ptrace capabilities.
If not allowed, the following error is returned:
/sbin/ldconfig -n /var/tmp/portage/dev-libs/ustr-1.0.4-r1/image//usr/lib64
ISE:_do_ptrace ^[[0mptrace(PTRACE_TRACEME, ..., 0x0000000000000000, 0x0000000000000000): Permission denied
/usr/lib/libsandbox.so(+0x3812)[0x7535af0ca812]
/usr/lib/libsandbox.so(+0x38a3)[0x7535af0ca8a3]
/usr/lib/libsandbox.so(+0x5595)[0x7535af0cc595]
/usr/lib/libsandbox.so(+0x5a87)[0x7535af0cca87]
/usr/lib/libsandbox.so(+0x68de)[0x7535af0cd8de]
/usr/lib/libsandbox.so(execvp+0x6c)[0x7535af0ceb3c]
make(+0x1159e)[0x337b918159e]
make(+0x11eec)[0x337b9181eec]
make(+0x12b34)[0x337b9182b34]
make(+0x1e759)[0x337b918e759]
/proc/5977/cmdline: make -j4 install
DESTDIR=/var/tmp/portage/dev-libs/ustr-1.0.4-r1/image/ HIDE=
libdir=/usr/lib64 mandir=/usr/share/man SHRDIR=/usr/share/doc/ustr-1.0.4-r1
DOCSHRDIR=/usr/share/doc/ustr-1.0.4-r1
This seems to be during a standard "make install" of the package but part of
Portage' sandbox usage (above error for ustr, but packages like python exhibit
the same problem.)
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
The installation of the wireshark package (and perhaps others) requires
portage setting file capabilities (through the setcap binary).
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
The attached patch allows postgresql_t domain to read selabel definition files
(such as /etc/selinux/targeted/contexts/sepgsql_contexts).
The upcoming version (v9.1) uses selabel_lookup(3) to assign initial security context
of database objects, we need to allow this reference.
Thanks,
--
NEC Europe Ltd, SAP Global Competence Center
KaiGai Kohei <kohei.kaigai@eu.nec.com>
