(2010/03/01 23:34), Stephen Smalley wrote: > On Mon, 2010-03-01 at 11:43 +0900, KaiGai Kohei wrote: >> (2010/02/20 0:20), Stephen Smalley wrote: >>> On Fri, 2010-02-19 at 16:33 +0900, KaiGai Kohei wrote: >>>> (2010/02/17 22:51), Stephen Smalley wrote: >>>>> On Wed, 2010-02-17 at 08:49 +0900, KaiGai Kohei wrote: >>>>>>> I'd say we revert the changeset and restore the prior behavior. >>>>>>> I don't think we should impose the latter convention on policy writers. >>>>>> >>>>>> OK, fair enough for me. >>>>>> >>>>>> This patch revert the commit of 7d52a155e38d5a165759dbbee656455861bf7801 >>>>>> which removed a part of type_attribute_bounds_av as a dead code. >>>>>> However, at that time, we didn't find out the target side boundary allows >>>>>> to handle some of pseudo /proc/<pid>/* entries with its process's security >>>>>> context well. >>>>> >>>>> Does Jacques' original concern about the code still hold true? >>>>> http://marc.info/?l=selinux&m=125770868309928&w=2 >>>>> http://marc.info/?l=selinux&m=125851264424682&w=2 >>>> >>>> This patch just tries to revert the changes by previous my patch, >>>> and returns to the start point, so it also reverts the Jacques' >>>> original concern. >>>> >>>> At that time, IIRC, Jacques concerned about the logic being unclear. >>>> Then, I introduced two options. The one is rough; that removes boundary >>>> checks in the target side. The other option tried to mask union bits of >>>> both of violated permissions on subject and target side boundaries (*1). >>>> >>>> (*1) type_attribute_bounds_av(Sc,Tc, ...) >>>> { >>>> masked = 0; >>>> >>>> if (Sc has its bounds) >>>> masked |= P(Sc,Tc)& ~P(Sp,Tc); >>>> >>>> if (Tc has its bounds) >>>> masked |= P(Sc,Tc)& ~P(Sc,Tp); >>>> >>>> avd->allowed&= ~masked; >>>> } >>>> >>>> However, the later option also requires policy writers special treatments >>>> to handle pseudo file entries labeled with parent's domain. >>>> >>>> For example, when web server (httpd_t) launches a thread and assign an >>>> individual bounded security context (webapp_t), we don't need to take >>>> a special treatment to access pseudo files labeled as webapp_t in the >>>> original logic. >>>> >>>> If we adopt the logic introduced at (*1), when we write webapp_t's policy, >>>> we have to allow webapp_t domain to access files labeled as httpd_t, not >>>> only webapp_t, because permissions between webapp_t and webapp_t will be >>>> eventually masked by one's between httpd_t domain and webapp_t type or >>>> webapp_t domain and httpd_t type. >>> >>> That seems wrong to me - we don't want webapp_t to be able to access >>> the /proc/pid entries of other tasks running in httpd_t. We only want >>> it to be able to access its own /proc/pid entries in webapp_t. Yes? >>> >> >> Sorry for the late replying, because I've been unavailable last week. >> >> Yes, I also think it is unnatural to require webapp_t to have access >> rights to /proc/pid entries labeled as httpd_t, if and when we adopt >> the above logic. >> >> However, it does not solve the matter that Jacques pointed out the >> meaning of the original logic is unclear. >> >> In addition, I pointed out the original logic can allow webapp_t >> domain some permissions on the webapp_t type without permissions >> of httpd_t which bounds webapp_t. >> >> Example) >> allow httpd_t httpd_t : file { read }; >> allow webapp_t webapp_t : file { read }; >> >> In this case, webapp_t can read from files labeled as webapp_t, and >> it is not masked because httpd_t also has same permissions on itself. >> >> It seems to me httpd_t should have permissions on webapp_t types from >> the perspective of the definition of type boundary, even if we need to >> modify existing security policy a bit. >> (BTW, existing refpolicy does not use boundary right now.) >> >> I think we want webapp_t to have access rights (except for ones allowed >> explicitly) on the httpd_t, but it is not unnatural that httpd_t have >> access rights on webapp_t types. It performs boundary of the webapp_t's >> permissions as literal. > > I think I need to revisit the original design of the hierarchical types > support, and how it compares with the extension policy logic that > inspired it (described in Section 4.2.2.3.2 on page 39 of: > http://www.cs.utah.edu/flux/fluke/html/ftls.ps.gz ) It seems to me this article does not mention about a case when source and target SIDs are in different parent-child-trees individually. For example, when webapp_t being a child of httpd_t tries to access files labeled as webapp_content_t being a child of httpd_sys_content_t, it was unclear for me what is an expected behavior. (Perhaps, other part of the article may introduce it, but the volume of the article is a bit large. :( ) > Perhaps Joshua has a design tech note available on the hierarchical > types design? If not available, it is good idea to make clear what is the expected behavior explicitly, on the wikipage for instance. Thanks, -- KaiGai Kohei <kaigai@xxxxxxxxxxxxx> -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
