Jacques Thomas wrote: > KaiGai Kohei wrote: >>>>> I also think we have one other a rough option. >>>>> It simply applies type boundaries on only sources to restrict its privileges, >>>>> and it does not apply any restrictions on target types. >>>>> >>>>> >>>>> >>>> Unless there is a clear use for bounds on targets, I would favor this >>>> option. (The "rough" one :-) ) >>>> I see mostly room for confusion with the bounds on target types, because >>>> of the contravariance issue. >>>> >>>> >>> I can write and submit a patch along these lines. The patch is >>> straightforward: I just have to remove the "dead" code. >>> >> Note that libsepol has an option which test type-boundary violations >> in usermode just before policy load. >> Also check check_avtab_hierarchy_callback() in libsepol/src/hierarchy.c. >> (It is called when ) >> >> Historically, this code delivered from hierarchy namespace support by >> Joshua Brindle. I'd like to ask him what about this change. >> >> MEMO: The hierarchy namespace support implicitly set up type-boundary >> on a couple of types. For example, if we defined httpd_t.cgi type, >> it is implicitly bounded by httpd_t type without TYPEBOUNDS. >> >> I also have not seen any case example which restrict target types by >> the hierarchy namespace support. So, it seems to me we have no matter >> to remove the "dead" code. >> >> Joshua, what's your opinion? I agree. The purpose of the type hierarchy was to confine children domains to a subset of their parents (or a subset of the parent domain -> parent target). For example, this is allowed: allow subject object: file read; allow subject.child object.child: file read; This was so that the parent didn't specifically have to have access to the child, but could allow children to access it based on the fact that the targets parent was accessible by the subjects parent. This was mostly for 'container' types where a subject isn't really used on the system and is only used as a container. We thought about adding a container keyword to remove those container types from the policy before it was built but after the hierarchy checks were done but that wouldn't work anymore due to the hierarchy checks in the kernel. >> >> >> >>> However, could someone please indicate me how I am supposed to test the >>> patch ? In other words, is there a standardized testing procedure that I >>> am unaware of ? >>> >> http://ltp.sourceforge.net/ >> >> It also contains SELinux testcases including type boundary, but it also >> does not contains a case of type boundary on target types. >> > > Kaigai, thank you for you detailed answer. > > Joshua, I am waiting for your opinion. > > Thank you both, > Jacques > > -- 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.
