I have a project with multiple daemons (around 6) which share many common features (they access the network, create and maintain daemon specific files, access random numbers, etc...), though they each deal with a different set of tasks (monitoring network resources, providing network file sharing services, providing network authentication services, etc).
Is it okay to use the interface file to define a set of common properties for these daemons to avoid listing everything out for each daemon? If not the interface file, then how should a common set of patterns for these daemons be defined?
I found listing the rules for each daemon to be bug prone and tedious.
On 03/01/2010 06:46 PM, Scott Salley wrote:
I have a project with multiple daemons (around 6) which share many common features (they access the network, create and maintain daemon specific files, access random numbers, etc...), though they each deal with a different set of tasks (monitoring network resources, providing network file sharing services, providing network authentication services, etc).
Is it okay to use the interface file to define a set of common properties for these daemons to avoid listing everything out for each daemon? If not the interface file, then how should a common set of patterns for these daemons be defined?
I usually use attributes for that. For example let us assume you have a suite of apps to confine.
In that case you could assign an attribute mysuite_domains to each domain type.
Then you can write the policy that all of the apps in your suite have in common using the mysuite_domains attirbute instead of the individual types.
You can find some examples in my policy repository:
git://84.245.6.206/selinux-modules.git
And in particular the telepathy.te file.
######################################## # # Telepathy global personal policy. #
allow tp_domains self:process { getsched signal }; allow tp_domains self:fifo_file rw_fifo_file_perms;
.. etc, etc ..
I found listing the rules for each daemon to be bug prone and tedious.
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
On 03/01/2010 06:46 PM, Scott Salley wrote:
I have a project with multiple daemons (around 6) which share many common features (they access the network, create and maintain daemon specific files, access random numbers, etc...), though they each deal with a different set of tasks (monitoring network resources, providing network file sharing services, providing network authentication services, etc).
Is it okay to use the interface file to define a set of common properties for these daemons to avoid listing everything out for each daemon? If not the interface file, then how should a common set of patterns for these daemons be defined?
I found listing the rules for each daemon to be bug prone and tedious.
And you can also use attributes in interfaces.
For example (from telepathy.if):
######################################## ## <summary> ## Send DBus messages to and from ## all Telepathy domains. ## </summary> ## <param name="domain"> ## <summary> ## Domain allowed access. ## </summary> ## </param> # interface(`telepathy_dbus_chat', ` gen_require(` attribute tp_domains; class dbus send_msg; ')
allow $1 tp_domains:dbus send_msg; allow tp_domains $1:dbus send_msg; ')
(from telepathy.te):
optional_policy(` telepathy_dbus_chat(tp_domains) ')
Meaning each domain type that has the tp_domains attribute assigned can dbus chat to each domain type that has the tp_domains attribute assigned.
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
On 03/01/2010 12:46 PM, Scott Salley wrote:
I have a project with multiple daemons (around 6) which share many common features (they access the network, create and maintain daemon specific files, access random numbers, etc...), though they each deal with a different set of tasks (monitoring network resources, providing network file sharing services, providing network authentication services, etc).
Is it okay to use the interface file to define a set of common properties for these daemons to avoid listing everything out for each daemon? If not the interface file, then how should a common set of patterns for these daemons be defined?
I found listing the rules for each daemon to be bug prone and tedious.
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
Yes this is done with apache cgi scripts for example, nagios.
A lot of time these use templates to generate the types. Also lookinto using attributes to associate rules with the types
type $1_t, MYDOMAIN;
Then in the te file you add rules like
files_read_etc_files(MDOMAIN)
selinux@lists.fedoraproject.org