On Mon, Apr 28, 2008 at 5:39 PM, Eamon Walsh <ewalsh@xxxxxxxxxxxxx> wrote:
Seems to me that paste mlsconstrain should be (l1 eq l2) and should be a mlsconstrain for paste_after_confirm which is (l1 domby l2).Christopher J. PeBenito wrote:Here is a revised patch. I support including this in refpolicy as it's generally useful for supporting selection managers.
On Fri, 2008-04-25 at 08:07 -0500, Xavier Toth wrote:
Here's a patch I'm using with an MLS version of glipper to give the
capability to check for dominance between copy and paste data
contexts. Hopefully some version of this can be upstreamed.
Note that the access_vectors definition is at the end of the file in this patch. Not sure if the ordering matters in that file, if it doesn't you can move this to coincide with the other X classes.
Signed-off-by: Eamon Walsh <ewalsh@xxxxxxxxxxxxx>
---
Index: policy/flask/security_classes
===================================================================
--- policy/flask/security_classes (revision 2667)
+++ policy/flask/security_classes (working copy)Index: policy/flask/access_vectors
@@ -114,5 +114,6 @@
class x_resource # userspace
class x_event # userspace
class x_synthetic_event # userspace
+class x_application_data # userspace
# FLASK
===================================================================
--- policy/flask/access_vectors (revision 2667)
+++ policy/flask/access_vectors (working copy)
@@ -775,3 +775,10 @@+ paste_after_confirm
{
recv
}
+
+class x_application_data
+{
+ paste
+ copy
+}
Index: policy/mls
===================================================================
--- policy/mls (revision 2667)
+++ policy/mls (working copy)
@@ -568,7 +568,13 @@
( t1 == mlsxwinwrite ));
+#
+# MLS policy for the x_application_data class
+#
+mlsconstrain x_application_data { paste }+ ( l1 domby l2 );
+
#
# MLS policy for the pax class