RE: excessively verbose policy

[Clarkson, Mike R (US SSA)]

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