(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. >> However, it also seems to me it is right manner to allow them explicitly >> in the security policy, although I sent a patch to revert the changes. >> >> In the original logic, when httpd_t domain is allowed to access httpd_t >> type, webapp_t domain is also allowed to access webapp_t type, although >> httpd_t domain is not allowed to access webapp_t type. >> It seems to me it is a case when child domain has permissions which are >> not allowed to the parent domain. >> >> I reconsidered that it is a case when we should write security policy >> explicitly. What do you think about it? > -- 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.
