[refpolicy] Policy modules design guidelines?

[cpebenito@tresys.com (Christopher J. PeBenito)]

On 01/12/11 15:46, Sven Vermeulen wrote:
> Hi list
> 
> I'm slowly writing modules for applications that I cannot find modules for
> in the reference policy or elsewhere. My main goal is to have policies for
> all applications that have some network connectivity or work with data
> received by untrusted parties (such as an e-mail client).
> 
> During the development I've found it difficult to know what the proper
> approach is concerning a few setups. From the #selinux mailinglist I gather
> that many of these approaches are mainly depending on the author (no wrong
> or right approach) but before submitting modules to the mailinglist for
> review (and potential inclusion) I thought of asking the following questions
> first ;-)
> 
> - In case of application-specific modules (mozilla, pan, mutt, ...) is there
>   a preferred method for handling the definitions? There are modules (such
>   as for mozilla) that have the majority of the AV rules in the .te file and
>   a somewhat straightforward role interface in .if, whereas others like
>   screen have a straightforward .te file (more of a definition) whereas the
>   .if file has a template (allowing for the generation of <role>_screen_t
>   domains)

There is a key difference between these two sets of modules.  In most
cases, you want it like mozilla, where nearly all the rules are in the
.te and the role interface is simple.  The few apps like screen have a
different problem.  They have a transition into the app, and then back
out to the user domain (e.g. a shell running in the user's domain exec's
screen which exec's a new shell in the user's domain).  For that to work
right, either you need a SELinux-aware app, or per-role application domains.

> - When writing policies on one system, chances are very high that this
>   policy is not sufficient on other systems (especially other
>   distributions). Is it okay to present the policy when tested on a single
>   platform (so that others can check it and perhaps update it) or would you
>   rather see the request for inclusion only after a distribution (or two)
>   have included it in their releases?

One distro test is fine.  The other distro maintainers can tweak it as
necessary.  The use of distro build options is also preferred: where
possible (and reasonable) distro-specific behaviors should be separated
out into the distro_* build options.

> - One module I'm working on (Skype) has shown me that Skype likes reading
>   things in the users' mozilla/firefox files (~/.mozilla/.../sec8.db and
>   prefs.js), most likely to check if the Skype plugin is installed. I
>   personally would not want to have this allowed, but I can imagine that the
>   reference policy doesn't want to prevent activities that are normal
>   behavior. Is that correct?

It depends on why this is happening.  If you have clicked a link in a
Skype IM chat and firefox is running in the wrong domain (in skype_t or
whatever), then we definitely want to fix that, not add access for
skype_t.  If Skype is just accessing the files, then justification for
the access would need to be provided, since on the surface it looks like
inappropriate access.

> - How much in-line documentation would reference policy suggestions have?
>   Does it make sense to document (as comments) reasons why certain
>   interfaces are called in the .te description? I noticed that not that many
>   modules have much comments beyond the structural separation (to split the
>   policy in related blocks)?

We're happy to have additional documentation, as long as its useful, and
most of all, correct.  Obviously comments like this would not be useful:

# do dns lookups
sysnet_dns_name_resolve(my_app_t)

> - If an application really requires a permission to be granted (say execmem)
>   but a more global boolean exists (allow_execmem) does reference policy
>   want the module to honor the boolean, or should this only be when both
>   states of the boolean still offer (some) functionality (like allow_dmesg)?

If the app intrinsically requires execmem, then just allow it
unconditionally.  An example is java.  If you want to use java app, you
have to accept the risk of having execmem.

The conditionals/tunables follow the logic of the code.  In your
allow_dmesg example, its up to the admin to decide if users can run
dmesg.  It won't break user domains if they can't dmesg.  So it makes
sense to have this security-relevant decision exposed in the policy via
a tunable.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com