KaiGai Kohei wrote: > (2010/03/05 23:31), Joshua Brindle wrote: >> >> Stephen Smalley wrote: >>> On Fri, 2010-03-05 at 09:19 -0500, Joshua Brindle wrote: >>>> KaiGai Kohei wrote: >>>>> (2010/03/05 1:01), Joshua Brindle wrote: >>>>>> KaiGai Kohei wrote: >>>>>>> (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. :( ) >>>>>>> >>>>>> The original hierarchy specified that if httpd_t had e.g., write >>>>>> access >>>>>> to httpd_sys_content_t then webapp_t could be given write access to >>>>>> webapp_content_t without httpd_t having direct access to >>>>>> webapp_content_t. >>>>>> >>>>>> This was done so that, in policy access controls, parents could be >>>>>> decoupled from children while still allowing child subjects to access >>>>>> child objects. One application of this was to have parents that, >>>>>> themselves, did not have access to children objects (or were not >>>>>> active >>>>>> at all). >>>>> Is this behavior really preferable? >>>>> >>>>> If my_app_t domain is allowed to access httpd_sys_content_t, and >>>>> your_app_t >>>>> domain allowed to access webapp_content_t, it looks like here is no >>>>> data >>>>> flows between two domains. However, in this example, webapp_t shares >>>>> its >>>>> process local memory with httpd_t, the content of >>>>> httpd_sys_content_t will >>>>> be visible webapp_t and vice versa. >>>>> In other words, all webapp_t domain can do are also allowed to httpd_t. >>>>> >>>>> my_app_t<-----> httpd_sys_content_t<-----> httpd_t .... >>>>> r/w r/w : process >>>>> : local memory >>>>> your_app_t<-----> webapp_content_t<-----> webapp_t ......: >>>>> r/w r/w >>>>> >>>>> We shouldn't have reused idea of the type hierarchy when we implemented >>>>> type boundary and multi-threading support? >>>>> >>>>> Or, is it really necessary for the policy management server the parent >>>>> types to be decoupled from the children? >>>>> >>>>>>>> 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. >>>>>>> >>>>>> The original paper talking about type hierarchies is at: >>>>>> >>>>>> http://selinux-symposium.org/2006/papers/01-policy-management-server.pdf >>>>>> >>>>>> >>>>>> section 2.3.1 >>>>> In this example, if we provide apache.content that is accessable >>>>> from apache.cgi, >>>>> the policy writer can allow apache.cgi.user to access >>>>> apache.content.user. >>>>> When he writes the policy between apache.cgi and apache.content, he >>>>> does not need >>>>> to know rest of the upcoming child policies. >>>>> At least, it also seems to me reasonable. >>>>> >>>>> If apache.cgi could access apache.content.user and >>>>> apache.content.main being >>>>> children of the apache.content automatically, such as attribute, we >>>>> don't need >>>>> to worry about this behavior.... :( >>>>> >>>> Well, we certainly didn't want an inherit permissions kind of system for >>>> the type hierarchy. It was an implicit constraint system so that >>>> permissions got smaller and smaller as you went down. The purpose of the >>>> type hierarchy was to protect the policy intent. >>>> >>>> The new behavior wrt threads and hierarchy allows extra permissions >>>> (namely, access to the parent domains memory) that were never present >>>> before so policy analysis will likely have to assume that they are >>>> combined domains, unfortunately. >>>> >>>> Is a dyntrans rule still required for threads to setcon to a child >>>> domain? >>> Yes. And dyntransition already implies that you are trusting the >>> program to maintain any desired separation between the two security >>> contexts, as already documented in the setcon(3) man page. >>> >> If dyntrans is still required then I don't see any change in behavior here. > > Unlike setcon(3) in a single-thread-process, a worker thread can see its > process local memory which can contain the information to be invisible > imported by other thread after setcon(3). > Is there any fundamental differences? > > It seems me here is no fundamental differences, but I may miss something. > Correct, there is no fundamental difference. It sounds like the hierarchy behavior is how we intended it originally. -- 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.
