From: domg472@gmail.com (Dominick Grift) Date: Thu, 13 Jan 2011 21:30:19 +0100 Subject: [refpolicy] Policy modules design guidelines? In-Reply-To: <4D2F57EA.4060203@tresys.com> References: <20110112204642.GA9459@siphos.be> <4D2F57EA.4060203@tresys.com> Message-ID: <4D2F60DB.4020506@gmail.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/13/2011 08:52 PM, Christopher J. PeBenito wrote: > 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 _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. My opinion on this is different and the mozilla example is a good example as to why my opinion is different. My opinion is that it is preferred to use the per role template with the role prefixes, as this does not hurt and it offers flexibility for cases that may not have been foreseen. Like mozilla, in refpolicy mozilla is not prefixed. For this reason i had to redo mozilla policy in my policy that is built on reference policy. I think refpolicy should be as general as possible. With that i mean it should be usable whichever way you want to go with you customized policy. Back to mozilla, i have confined thunderbird as well. As you may know thunderbird can run firefox (click a URL in a mail messages) and firefox can run thunderbird (send link..) So firefox needs to transition to thunderbird and vice versa. But in a confined user space you will may want to want different firefox policy depending on who runs it. Therefore you need to prefix the firefox and thunderbird domains. examples: user_mozilla_t -> thunderbird_exec_t -> user_thunderbird_t staff_thunderbird_t -> mozilla_exec_t -> staff_mozilla_t This is why i prefer the prefix domains. It does not hurt to use them and who knows, you may need it later (and my experience says that many user apps are able to run other agents) my two cents >> - 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. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk0vYNsACgkQMlxVo39jgT+Q5ACeLkC3LlIrEjzrZdVQ4VpqmFW7 cxEAoLwvKRO5FfU7FWn7G21A5WC7HzGO =LVdN -----END PGP SIGNATURE-----