From: sven.vermeulen@siphos.be (Sven Vermeulen)
Date: Wed, 12 Jan 2011 21:46:42 +0100
Subject: [refpolicy] Policy modules design guidelines?
Message-ID: <20110112204642.GA9459@siphos.be>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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)

- 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 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?

- 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)?

- 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)?

Wkr,
	Sven Vermeulen