From: cpebenito@tresys.com (Christopher J. PeBenito) Date: Mon, 17 Jan 2011 14:17:04 -0500 Subject: [refpolicy] Policy modules design guidelines? In-Reply-To: <4D345B2C.10302@gmail.com> References: <20110112204642.GA9459@siphos.be> <4D2F57EA.4060203@tresys.com> <4D2F60DB.4020506@gmail.com> <20110115210302.GA16861@siphos.be> <4D3455DA.4060608@tresys.com> <4D345B2C.10302@gmail.com> Message-ID: <4D3495B0.8070109@tresys.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 1/17/2011 10:07 AM, Dominick Grift wrote: > On 01/17/2011 03:44 PM, Christopher J. PeBenito wrote: >> On 1/15/2011 4:03 PM, Sven Vermeulen wrote: >>> On Thu, Jan 13, 2011 at 09:30:19PM +0100, Dominick Grift wrote: >>>> 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 >>> >>> What I'm thinking about was how domains can influence each other. Most >>> application domains (like mozilla_t) have some permissions for feedback >>> (such as sigchld/signull sending, fd usage, ...) towards the "caller" >>> domain. I would expect that this is quite harmless, but I can imagine that >>> a well-versed malicious person is able to "influence" a more privileged >>> domain through this. >>> >>> Let me explain with the following example: a staff_u mapped user runs by >>> default in the staff_t domain and launches firefox (transitioning to >>> mozilla_t). He also (in a different terminal) switches role to sysadm_r to >>> perform some administrative tasks. >>> >>> Now, permission-wise, the policy allows the same privileges from mozilla_t >>> to sysadm_t and staff_t. In my imagination, I would see a malicious user >>> influencing the running firefox through whatever exploit available and >>> having the permissions to manipulate some aspects within the sysadm_t >>> domain. Not much and far fetched most likely, but I leave that to the >>> experts in the field. >>> >>> +---------+ +-----------+ >>> | staff_t |<------------>| mozilla_t | >>> +---------+ +-----------+ >>> ^ >>> | >>> +----------+ | >>> | sysadm_t |<-----------------/ >>> +----------+ >>> >>> When using the templates, there would be no SELinux permission whatsoever >>> from the prefixed mozilla domain to the sysadm_t domain: >>> >>> +---------+ +-----------------+ >>> | staff_t |<------------->| staff_mozilla_t | >>> +---------+ +-----------------+ >> >> This is how it used to be; the role was encoded in the types. It was >> decided that this slim reduction of flexibility was worth the huge >> reduction of complexity in the policy. > > As i recall it this was more aimed towards derived object types, and not > so much derived domain types. No. It was aimed at _all_ role-derived types. > I do agree that derived domain types add flexibility/complexity but i do > not see how rbac can replace some of the functionality that prefixed > domains and type enforcement provides (e.g. enforce policy for a > application based on who runs the application (role prefix) Of course it can't replace all possible uses, but it does replace all upstream instances, save the ones where there are execution path issues like su, sudo, and screen. For example, the mozilla policy was exactly the same for all roles, except each only accessed the role-specific home dir, X window, etc. If all objects in the system have an appropriate role in their context, each instance of mozilla can be cleanly separated by role. > Any gui user application should be prefixed in my view because they can > all be run from nautilus and or gpanel (launchers). And if you confine > either gpanel or nautilus there is no way to tell selinux who runs the > application (other then nautilus or gpanel), and we cannot make any > distinction. > > On top of that the prefixed type gives me the flexibility to create > prefixed booleans. It allows me to customize a userdomain by just > toggling a few booleans. > > currently for me role prefixes for domain types proves to be invaluable > in my pursuit to confine the user space. Of course people can still do this for their custom policies. However, upstream is pragmatic with its usage. The actual security gains by the complexity you suggest tends to be dubious. As long as that is the case, we'll chose simpler policy. -- Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com