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@xxxxxxxxxx
[mailto:fedora-selinux-list-
> bounces@xxxxxxxxxx] On Behalf Of Bill Nottingham
> Sent: Thursday, February 21, 2008 3:23 PM
> To: fedora-selinux-list@xxxxxxxxxx
> 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@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
