excessively verbose policy

[Bill Nottingham]

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

[Daniel J Walsh]

-----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(a)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-----

[Marcelo Klein]

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(a)redhat.com&gt;:
>  -----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(a)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(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>

[Daniel J Walsh]

-----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(a)redhat.com&gt;:
>  
>  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(a)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(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
> > 
> ------------------------------------------------------------------------ 
>  --
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iEYEARECAAYFAke+/vYACgkQrlYvE4MpobODXgCgqIz5SV2TRH9LIt3LFePsQkXa
> tjsAoNACxe2ftqUHZhxRyDo70/c3Oa4Q
> =MJG/
> -----END PGP SIGNATURE-----

[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