Security Enhanced Linux
What's New
Frequently Asked Questions
Background
Documents
License
Download
Participating
Mail List
Archives
Remaining Work
Contributors
Related Work
Press Releases
Information Assurance Research
NIARL In-house Research Areas
Mathematical Sciences Program
Sabbaticals
Computer & Information Sciences Research
Technology Transfer
Advanced Computing
Advanced Mathematics
Communications & Networking
Information Processing
Microelectronics
Other Technologies
Technology Fact Sheets
Publications
Related Links
|
SELinux Mailing ListRE: [PATCH] MLS interface update
From: Frank Mayer <mayerf_at_tresys.com>
Date: Tue, 14 Mar 2006 09:52:04 -0500
>> 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. > > The MLS BLP write policy has been modified to write equality, instead > of allowing unrestricted writeup. Unrestricted writeup is usually not > desired and is not even allowed by DCID 6/3. DCID 6/3 requires at > least write limitation to the user's clearance. We have the *toclr > attributes to achieve the clearance restrictions if desired. The { > dir chr_file blk_file sock_file } case is to handle ranged objects > whereas { file lnk_file fifo_file } have constraints to disallow them > from being ranged. 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.Received on Tue 14 Mar 2006 - 09:52:36 EST |
|
Date Posted: Jan 15, 2009 | Last Modified: Jan 15, 2009 | Last Reviewed: Jan 15, 2009 |