I was writing policy today, and I couldn't help notice a lot of repetitiveness in our policy:
libs_use_ld_so(...) libs_use_shared_libs(...)
These are needed by, well, everything. Can't they be assumed-unless-denied?
Similarly, 99% of confined apps need:
miscfiles_read_localization() files_read_etc_files(.) pipes & stream sockets
Is there a way to streamline policy so there is a lot less repetition?
Bill
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Bill Nottingham wrote:
I was writing policy today, and I couldn't help notice a lot of repetitiveness in our policy:
libs_use_ld_so(...) libs_use_shared_libs(...)
These are needed by, well, everything. Can't they be assumed-unless-denied?
Similarly, 99% of confined apps need:
miscfiles_read_localization() files_read_etc_files(.) pipes & stream sockets
Is there a way to streamline policy so there is a lot less repetition?
Bill
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
We have talked about this in the past, and so far it has not gone anywhere. The original goal when refpolicy policy was first written was to allow more fine grained control then the example policy, which grouped large amounts of access rules within a single macro. (can_network) for example. So we wanted to avoid this, and perhaps the pendulum swung too far to the opposite degree.
Is there any possibility of writing bundles of policies that can be "imported" into other configurations? Such as defining a package for a set of policies like "shared-libs", and then when writing the policy putting "import shared-libs" or something like that? Is this too much complex to do?
Marcelo.
2008/2/22, Daniel J Walsh dwalsh@redhat.com:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Bill Nottingham wrote:
I was writing policy today, and I couldn't help notice a lot of repetitiveness in our policy:
libs_use_ld_so(...) libs_use_shared_libs(...)
These are needed by, well, everything. Can't they be
assumed-unless-denied?
Similarly, 99% of confined apps need:
miscfiles_read_localization() files_read_etc_files(.) pipes & stream sockets
Is there a way to streamline policy so there is a lot less repetition?
Bill
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
We have talked about this in the past, and so far it has not gone anywhere. The original goal when refpolicy policy was first written was to allow more fine grained control then the example policy, which grouped large amounts of access rules within a single macro. (can_network) for example. So we wanted to avoid this, and perhaps the pendulum swung too far to the opposite degree.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAke+0oIACgkQrlYvE4MpobPd5gCfYpoWTHLDhsCf1Ae1oTQFv4dA AukAn0voXayQTmjDZm+AvEWoFyU2n/Rz =sl9z -----END PGP SIGNATURE-----
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Marcelo Klein wrote:
Is there any possibility of writing bundles of policies that can be "imported" into other configurations? Such as defining a package for a set of policies like "shared-libs", and then when writing the policy putting "import shared-libs" or something like that? Is this too much complex to do?
Marcelo.
No, this is what interfaces do, although they are more like functions calls.
We have two ways of grouping access to a domain, either directory though allow rules, or by adding an attribute.
For example
type httpd_t, domain; allow domain self:file read;
or
allow httpd_t self:file read;
Both generate the same policy.
In refpolicy we have a interface domain_type() which adds the domain attribute.
So we could move all
libs_use_ld_so(domain) libs_use_shared_libs(domain)
And eliminate these rules from all te files.
The question is what granularity do you do this at.
Almost every confined domain needs to read etc_t so if we added files_read_etc_files(domain)
We could remove those, but now if someone wanted to write a confined domain without access to etc_t, his policy is a lot harder to write.
2008/2/22, Daniel J Walsh dwalsh@redhat.com:
Bill Nottingham wrote:
I was writing policy today, and I couldn't help notice a lot of repetitiveness in our policy:
libs_use_ld_so(...) libs_use_shared_libs(...)
These are needed by, well, everything. Can't they be
assumed-unless-denied?
Similarly, 99% of confined apps need:
miscfiles_read_localization() files_read_etc_files(.) pipes & stream sockets
Is there a way to streamline policy so there is a lot less repetition?
Bill
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
We have talked about this in the past, and so far it has not gone anywhere. The original goal when refpolicy policy was first written was to allow more fine grained control then the example policy, which grouped large amounts of access rules within a single macro. (can_network) for example. So we wanted to avoid this, and perhaps the pendulum swung too far to the opposite degree.
- -- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
You can always create your own interface to eliminate the repetition that you're seeing. That's what I did. I created a basic_app module with a template that takes care of the basic stuff that I found nearly all of my policy modules needed. Here is what my interface looks like:
################################################ ## <summary> ## Call this template for basic functionality necessary for most ## application domains ## </summary> ## <desc> ## <p> ## This template creates derived domains for applications ## </p> ## <param name="domain_prefix"> ## The prefix for domain name. For example: somedomain ## This will result in the creation of the following types: ## somedomain_t ## somedomain_exec_t ## </param ## <param name="userdomain_prefix"> ## The prefix of the user domain (for example, user if the prefix for user_t), ## which will be running the client/server. NOTE: This must be an unprivileged ## user, such as user_t or staff_t. It will NOT work for a privileged user such ## as sysadm_t or secadm_t. ## </param> template(`basic_app_unpriv_template',` ################################ # Declarations
type $1_t; domain_type($1_t)
## Access to shared libraries libs_use_ld_so($1_t) libs_use_shared_libs($1_t)
miscfiles_read_localization($1_t)
## Type of the exec, which is the entrypoint into the domain type $1_exec_t; files_type($1_exec_t) domain_entry_file($1_t, $1_exec_t)
## allow transitions from unprivileged user to this domain gen_require(` type $2_t; ') userdom_entry_spec_domtrans_unpriv_users($1_t) domain_auto_trans($2_t, $1_exec_t, $1_t)
## allow this domain to use sshd file descriptors ssh_use_fd($1_t)
## Allow this domain to use newrole file descriptors. Needed ## if we newrole to a new shell before running seutil_use_newrole_fds($1_t)
## allow this domain to use the correct devpts_t (tty) type userdom_use_user_terminals($2, $1_t)
## allow this domain to send a SIGCHLD signal back to the shell process ## to notify the shell that the child process has ended allow $1_t $2_t:process sigchld;
## need this to allow ps to see the process running in this domain, ## which is listed in the /proc dir ##allow $2_t $1_t:dir search_dir_perms; ##allow $2_t $1_t:file read_file_perms; allow_unpriv_ps_access($1_t)
fs_search_auto_mountpoints($1_t) files_read_etc_files($1_t) files_search_home($1_t) fs_search_nfs($1_t) files_search_usr($1_t) files_list_tmp($1_t)
')
-----Original Message----- From: fedora-selinux-list-bounces@redhat.com
[mailto:fedora-selinux-list-
bounces@redhat.com] On Behalf Of Bill Nottingham Sent: Thursday, February 21, 2008 3:23 PM To: fedora-selinux-list@redhat.com Subject: excessively verbose policy
I was writing policy today, and I couldn't help notice a lot of repetitiveness in our policy:
libs_use_ld_so(...) libs_use_shared_libs(...)
These are needed by, well, everything. Can't they be assumed-unless- denied?
Similarly, 99% of confined apps need:
miscfiles_read_localization() files_read_etc_files(.) pipes & stream sockets
Is there a way to streamline policy so there is a lot less repetition?
Bill
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
selinux@lists.fedoraproject.org