From: dwalsh@redhat.com (Daniel J Walsh) Date: Thu, 13 Jan 2011 15:37:51 -0500 Subject: [refpolicy] Policy modules design guidelines? In-Reply-To: <4D2F60DB.4020506@gmail.com> References: <20110112204642.GA9459@siphos.be> <4D2F57EA.4060203@tresys.com> <4D2F60DB.4020506@gmail.com> Message-ID: <4D2F629F.2090401@redhat.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/13/2011 03:30 PM, Dominick Grift wrote: > 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. > > _______________________________________________ refpolicy mailing list refpolicy at oss.tresys.com http://oss.tresys.com/mailman/listinfo/refpolicy If we only had a write policy that does an isa. A third option would be to write the policy using attributes, with the basics of what a web browser is, web_browser_domain, and then define types for the contents. Then you could say something like type mozilla_t, web_browser_domain; allow mozilla_t .... Or type $1_mozilla_t, web_browser_domain; ... And both use cases are happy. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk0vYp8ACgkQrlYvE4MpobP2WgCdEfeIm8w0w46TQ4/VbSenrZHI wtsAn0PjNK+pk5vSYuWdfNhFLR8Lua5r =P6+W -----END PGP SIGNATURE-----