>> The interface additions would be ok, but upon closer examination of
>> the constraints, why are the reads traditional BLP
>> (l1 dom l2), but the writes aren't (l1 eq l2 for { file lnk_file
>> fifo_file }, and (l1 dom l2 and l1 domby h2) for { dir chr_file
>> blk_file sock_file })?  In fact, the (l1 dom l2 and l1 domby h2)
>> doesn't look correct to me; (l1 domby l2) seems right.  It appears
>> the write constraints are being used for integrity (at least for
>> file, lnk_file and fifo_file), but we already have TE for this
>> purpose. 

I don't want to re-open my debate from a year ago about the value and desirability of write up in MLS systems and the ability to have untrusted MLS aware applications (i.e., I disagree with Chad's comment above :-) Perhaps the correct answer is to have primitive interfaces that implement the true BLP "no write down, no read up" rules and an added interface that encapsulates "no write down" with "only write equal" so that if others want to use the (IMHO highly desirable) write up ability, they can do so within the reference policy framework.

To be honest I'm not even sure how interfaces work for constraints, but I would still suggest using lower level primitive interfaces and build up to "write equal only". Too bad constraints don't work inside of conditional policies! Frank

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.