selinux: Permit transitions under NO_NEW_PRIVS or NOSUID under certain, circumstances.

From 731c593d0813128eb6d3a62658038681b6e1cf9a Mon Sep 17 00:00:00 2001

From c1fa21950c5c3eb0dd97ae5145fa3d3f04adc5c4 Mon Sep 17 00:00:00 2001

From 66e8681c88a4cb0e3d84ed92f59e9812ba4a3003 Mon Sep 17 00:00:00 2001

v2 - fix patch description to match the code.

From c1fa21950c5c3eb0dd97ae5145fa3d3f04adc5c4 Mon Sep 17 00:00:00 2001

Quoted 1 line · Stephen Smalley

v2 - fix patch description to match the code.

Okay Stephen, I suppose you should get some special consideration, but is posting your patches inline really that hard :)

---
From c1fa21950c5c3eb0dd97ae5145fa3d3f04adc5c4 Mon Sep 17 00:00:00 2001
From: Stephen Smalley <[email protected]>
Date: Thu, 12 Jun 2014 08:17:48 -0400
Subject: [PATCH] selinux: Permit exec transitions under NO_NEW_PRIVS or
NOSUID under certain circumstances.

If the callee SID is bounded by the caller SID or if the caller SID is allowed to perform a dynamic transition (setcon) to the callee SID, then allowing the transition to occur poses no risk of privilege escalation and we can therefore safely allow the transition to occur. Add these two exemptions for both the case where a transition was explicitly requested by the application and the case where an automatic transition is defined in policy.

Signed-off-by Stephen Smalley <[email protected]>

Acked-by Andy Lutomirski <[email protected]>

security/selinux/hooks.c +7 -0

index 83d06db..d5e8dc5 100644
@@ -2086,6 +2086,36 @@ static int selinux_vm_enough_memory(struct mm_struct
 *mm, long pages)
 
 /* binprm security operations */
 
+static int check_nnp_nosuid(const struct linux_binprm *bprm,
+			    const struct task_security_struct *old_tsec,
+			    const struct task_security_struct *new_tsec)
+{
+	int nnp = (bprm->unsafe & LSM_UNSAFE_NO_NEW_PRIVS);
+	int nosuid = (bprm->file->f_path.mnt->mnt_flags & MNT_NOSUID);
+	int rc;

Quoted 21 lines · Paul Moore

Quoted 1 line · Stephen Smalley

v2 - fix patch description to match the code.

Okay Stephen, I suppose you should get some special consideration, but is posting your patches inline really that hard :)

---
From c1fa21950c5c3eb0dd97ae5145fa3d3f04adc5c4 Mon Sep 17 00:00:00 2001
From: Stephen Smalley <[email protected]>
Date: Thu, 12 Jun 2014 08:17:48 -0400
Subject: [PATCH] selinux: Permit exec transitions under NO_NEW_PRIVS or
NOSUID under certain circumstances.

If the callee SID is bounded by the caller SID or if the caller SID is allowed to perform a dynamic transition (setcon) to the callee SID, then allowing the transition to occur poses no risk of privilege escalation and we can therefore safely allow the transition to occur. Add these two exemptions for both the case where a transition was explicitly requested by the application and the case where an automatic transition is defined in policy.

Quoted 2 lines

Signed-off-by Stephen Smalley <[email protected]>

Acked-by Andy Lutomirski <[email protected]>

Comments below ...

Quoted 16 lines

security/selinux/hooks.c +7 -0

index 83d06db..d5e8dc5 100644
@@ -2086,6 +2086,36 @@ static int selinux_vm_enough_memory(struct mm_struct
 *mm, long pages)
 
 /* binprm security operations */
 
+static int check_nnp_nosuid(const struct linux_binprm *bprm,
+			    const struct task_security_struct *old_tsec,
+			    const struct task_security_struct *new_tsec)
+{
+	int nnp = (bprm->unsafe & LSM_UNSAFE_NO_NEW_PRIVS);
+	int nosuid = (bprm->file->f_path.mnt->mnt_flags & MNT_NOSUID);
+	int rc;

security/selinux/hooks.c static int selinux_vm_enough_memory(struct mm_struct · line 2106

Quoted 10 lines

security/selinux/hooks.c +10 -0

+
+	if (!nnp && !nosuid)
+		return 0; /* neither NNP nor nosuid */
+
+	if (new_tsec->sid == old_tsec->sid)
+		return 0; /* No change in credentials */
+
+	rc = security_bounded_transition(old_tsec->sid, new_tsec->sid);
+	if (rc == 0)
+		return 0; /* allowed via bounded transition */

I think there might be an audit issue here; security_bounded_transition() will generate an audit record on failure which probably isn't what we want in this case.

Other than that, this seems reasonable, even in the face of NNP, and as others point out, standard DAC capabilities do something similar.

security/selinux/hooks.c static int selinux_vm_enough_memory(struct mm_struct · line 2116

Quoted 10 lines

security/selinux/hooks.c +10 -0

+	/* Only allow if dyntransition permission aka setcon() is allowed. */
+	rc = avc_has_perm(old_tsec->sid, new_tsec->sid, SECCLASS_PROCESS,
+			  PROCESS__DYNTRANSITION, NULL);
+	if (rc) {
+		if (nnp)
+			return -EPERM;
+		else
+			return -EACCES;
+	}
+	return 0;

I know this dyntransition/NNP/NOSUID interaction has been discussed quite a bit off-list (mostly while I was away, my apologies), but I haven't seen a lot on-list and while the descriptions hints at it the code itself doesn't elaborate on why this is "OK". I'd like to see some comments about why it is okay to allow the transition, regardless of NNP/NOSUID, if the dyntransition is allowed. I'd also like to see a quick comment about why we return -EPERM/- EACCES.

There was a lot of discussion around these points and I want to make sure the ideas aren't lost.

Quoted 80 lines · Paul Moore

Quoted 21 lines · Paul Moore

Quoted 1 line · Stephen Smalley

v2 - fix patch description to match the code.

Okay Stephen, I suppose you should get some special consideration, but is posting your patches inline really that hard :)

---
From c1fa21950c5c3eb0dd97ae5145fa3d3f04adc5c4 Mon Sep 17 00:00:00 2001
From: Stephen Smalley <[email protected]>
Date: Thu, 12 Jun 2014 08:17:48 -0400
Subject: [PATCH] selinux: Permit exec transitions under NO_NEW_PRIVS or
NOSUID under certain circumstances.

If the callee SID is bounded by the caller SID or if the caller SID is allowed to perform a dynamic transition (setcon) to the callee SID, then allowing the transition to occur poses no risk of privilege escalation and we can therefore safely allow the transition to occur. Add these two exemptions for both the case where a transition was explicitly requested by the application and the case where an automatic transition is defined in policy.

Quoted 2 lines

Signed-off-by Stephen Smalley <[email protected]>

Acked-by Andy Lutomirski <[email protected]>

Comments below ...

Quoted 16 lines

security/selinux/hooks.c +7 -0

index 83d06db..d5e8dc5 100644
@@ -2086,6 +2086,36 @@ static int selinux_vm_enough_memory(struct mm_struct
 *mm, long pages)
 
 /* binprm security operations */
 
+static int check_nnp_nosuid(const struct linux_binprm *bprm,
+                        const struct task_security_struct *old_tsec,
+                        const struct task_security_struct *new_tsec)
+{
+    int nnp = (bprm->unsafe & LSM_UNSAFE_NO_NEW_PRIVS);
+    int nosuid = (bprm->file->f_path.mnt->mnt_flags & MNT_NOSUID);
+    int rc;

security/selinux/hooks.c static int selinux_vm_enough_memory(struct mm_struct · line 2106

Quoted 10 lines

security/selinux/hooks.c +10 -0

+
+    if (!nnp && !nosuid)
+            return 0; /* neither NNP nor nosuid */
+
+    if (new_tsec->sid == old_tsec->sid)
+            return 0; /* No change in credentials */
+
+    rc = security_bounded_transition(old_tsec->sid, new_tsec->sid);
+    if (rc == 0)
+            return 0; /* allowed via bounded transition */

I think there might be an audit issue here; security_bounded_transition() will generate an audit record on failure which probably isn't what we want in this case.

Other than that, this seems reasonable, even in the face of NNP, and as others point out, standard DAC capabilities do something similar.

security/selinux/hooks.c static int selinux_vm_enough_memory(struct mm_struct · line 2116

Quoted 10 lines

security/selinux/hooks.c +10 -0

+    /* Only allow if dyntransition permission aka setcon() is allowed. */
+    rc = avc_has_perm(old_tsec->sid, new_tsec->sid, SECCLASS_PROCESS,
+                      PROCESS__DYNTRANSITION, NULL);
+    if (rc) {
+            if (nnp)
+                    return -EPERM;
+            else
+                    return -EACCES;
+    }
+    return 0;

I know this dyntransition/NNP/NOSUID interaction has been discussed quite a bit off-list (mostly while I was away, my apologies), but I haven't seen a lot on-list and while the descriptions hints at it the code itself doesn't elaborate on why this is "OK". I'd like to see some comments about why it is okay to allow the transition, regardless of NNP/NOSUID, if the dyntransition is allowed. I'd also like to see a quick comment about why we return -EPERM/- EACCES.

Quoted 2 lines

There was a lot of discussion around these points and I want to make sure the ideas aren't lost.

The claim was that dyntransition is sufficient since it would allow the caller to setcon() to the new domain directly and therefore perform any action in that domain. Thus, allowing it to transition to that domain upon exec under NNP or on a file in a nosuid mount does not enable it to do anything it could not already do directly.

However, this presumes that the policy writer does not merely add dyntransition to the caller domain upon encountering the avc denial in this situation without thinking about the implications and deciding whether to truly trust the caller domain in this way. Which is likely a dangerous assumption, especially for people who write policy via audit2allow.

At least with the bounded transition, you have to explicitly declare that the new domain is bounded by the caller domain and the kernel will then enforce the restriction that the new domain is not granted any permission not allowed to the caller domain.

I'm also unclear as to whether this in fact solves the actual problem for sandbox -X.

So I'd drop this patch for now at least.

Quoted 92 lines · Stephen Smalley

Quoted 76 lines · Paul Moore

Quoted 20 lines · Paul Moore

Quoted 1 line · Stephen Smalley

v2 - fix patch description to match the code.

Okay Stephen, I suppose you should get some special consideration, but is posting your patches inline really that hard :)

---
From c1fa21950c5c3eb0dd97ae5145fa3d3f04adc5c4 Mon Sep 17 00:00:00 2001
From: Stephen Smalley <[email protected]>
Date: Thu, 12 Jun 2014 08:17:48 -0400
Subject: [PATCH] selinux: Permit exec transitions under NO_NEW_PRIVS or
NOSUID under certain circumstances.

If the callee SID is bounded by the caller SID or if the caller SID is allowed to perform a dynamic transition (setcon) to the callee SID, then allowing the transition to occur poses no risk of privilege escalation and we can therefore safely allow the transition to occur. Add these two exemptions for both the case where a transition was explicitly requested by the application and the case where an automatic transition is defined in policy.

Quoted 2 lines

Signed-off-by Stephen Smalley <[email protected]>

Acked-by Andy Lutomirski <[email protected]>

Comments below ...

Quoted 16 lines

security/selinux/hooks.c +7 -0

index 83d06db..d5e8dc5 100644
@@ -2086,6 +2086,36 @@ static int selinux_vm_enough_memory(struct mm_struct
 *mm, long pages)
 
 /* binprm security operations */
 
+static int check_nnp_nosuid(const struct linux_binprm *bprm,
+                        const struct task_security_struct *old_tsec,
+                        const struct task_security_struct *new_tsec)
+{
+    int nnp = (bprm->unsafe & LSM_UNSAFE_NO_NEW_PRIVS);
+    int nosuid = (bprm->file->f_path.mnt->mnt_flags & MNT_NOSUID);
+    int rc;

security/selinux/hooks.c static int selinux_vm_enough_memory(struct mm_struct · line 2106

Quoted 10 lines

security/selinux/hooks.c +10 -0

+
+    if (!nnp && !nosuid)
+            return 0; /* neither NNP nor nosuid */
+
+    if (new_tsec->sid == old_tsec->sid)
+            return 0; /* No change in credentials */
+
+    rc = security_bounded_transition(old_tsec->sid, new_tsec->sid);
+    if (rc == 0)
+            return 0; /* allowed via bounded transition */

I think there might be an audit issue here; security_bounded_transition() will generate an audit record on failure which probably isn't what we want in this case.

Other than that, this seems reasonable, even in the face of NNP, and as others point out, standard DAC capabilities do something similar.

security/selinux/hooks.c static int selinux_vm_enough_memory(struct mm_struct · line 2116

Quoted 10 lines

security/selinux/hooks.c +10 -0

+    /* Only allow if dyntransition permission aka setcon() is allowed. */
+    rc = avc_has_perm(old_tsec->sid, new_tsec->sid, SECCLASS_PROCESS,
+                      PROCESS__DYNTRANSITION, NULL);
+    if (rc) {
+            if (nnp)
+                    return -EPERM;
+            else
+                    return -EACCES;
+    }
+    return 0;

I know this dyntransition/NNP/NOSUID interaction has been discussed quite a bit off-list (mostly while I was away, my apologies), but I haven't seen a lot on-list and while the descriptions hints at it the code itself doesn't elaborate on why this is "OK". I'd like to see some comments about why it is okay to allow the transition, regardless of NNP/NOSUID, if the dyntransition is allowed. I'd also like to see a quick comment about why we return -EPERM/- EACCES.

Quoted 2 lines

There was a lot of discussion around these points and I want to make sure the ideas aren't lost.

The claim was that dyntransition is sufficient since it would allow the caller to setcon() to the new domain directly and therefore perform any action in that domain. Thus, allowing it to transition to that domain upon exec under NNP or on a file in a nosuid mount does not enable it to do anything it could not already do directly.

However, this presumes that the policy writer does not merely add dyntransition to the caller domain upon encountering the avc denial in this situation without thinking about the implications and deciding whether to truly trust the caller domain in this way. Which is likely a dangerous assumption, especially for people who write policy via audit2allow.

Quoted 5 lines

At least with the bounded transition, you have to explicitly declare that the new domain is bounded by the caller domain and the kernel will then enforce the restriction that the new domain is not granted any permission not allowed to the caller domain.

How about making the change just for bounded transitions, then? No one will write the policy if the kernel doesn't support it.

Quoted 2 lines

I'm also unclear as to whether this in fact solves the actual problem for sandbox -X.

Dunno. dwalsh, does it?

Quoted 1 line

So I'd drop this patch for now at least.

--Andy
_______________________________________________
Selinux mailing list
[email protected]
To unsubscribe, send email to [email protected].
To get help, send an email containing "help" to [email protected].

We can use it to fix sandbox.

sandbox -X xterm can do the following

unconfined_t -> seunshare_t -> sandbox_x_t Then I allow sandbox_x_t to setcur to sandbox_x_client_t. sandbox_x_t can run the xserver, and the confined app will run as sandbox_x_client_t. If I am allowed to transition to a tighter domain, I can get the scripts to work.

Quoted 114 lines · Stephen Smalley

Quoted 92 lines · Paul Moore

Quoted 76 lines · Paul Moore

Quoted 20 lines · Stephen Smalley

Quoted 1 line

v2 - fix patch description to match the code.

Okay Stephen, I suppose you should get some special consideration, but is posting your patches inline really that hard :)

---
From c1fa21950c5c3eb0dd97ae5145fa3d3f04adc5c4 Mon Sep 17 00:00:00 2001
From: Stephen Smalley <[email protected]>
Date: Thu, 12 Jun 2014 08:17:48 -0400
Subject: [PATCH] selinux: Permit exec transitions under NO_NEW_PRIVS or
NOSUID under certain circumstances.

If the callee SID is bounded by the caller SID or if the caller SID is allowed to perform a dynamic transition (setcon) to the callee SID, then allowing the transition to occur poses no risk of privilege escalation and we can therefore safely allow the transition to occur. Add these two exemptions for both the case where a transition was explicitly requested by the application and the case where an automatic transition is defined in policy.

Quoted 2 lines

Signed-off-by Stephen Smalley <[email protected]>

Acked-by Andy Lutomirski <[email protected]>

Comments below ...

Quoted 16 lines

security/selinux/hooks.c +7 -0

index 83d06db..d5e8dc5 100644
@@ -2086,6 +2086,36 @@ static int selinux_vm_enough_memory(struct mm_struct
 *mm, long pages)
 
 /* binprm security operations */
 
+static int check_nnp_nosuid(const struct linux_binprm *bprm,
+                        const struct task_security_struct *old_tsec,
+                        const struct task_security_struct *new_tsec)
+{
+    int nnp = (bprm->unsafe & LSM_UNSAFE_NO_NEW_PRIVS);
+    int nosuid = (bprm->file->f_path.mnt->mnt_flags & MNT_NOSUID);
+    int rc;

security/selinux/hooks.c static int selinux_vm_enough_memory(struct mm_struct · line 2106

Quoted 10 lines

security/selinux/hooks.c +10 -0

+
+    if (!nnp && !nosuid)
+            return 0; /* neither NNP nor nosuid */
+
+    if (new_tsec->sid == old_tsec->sid)
+            return 0; /* No change in credentials */
+
+    rc = security_bounded_transition(old_tsec->sid, new_tsec->sid);
+    if (rc == 0)
+            return 0; /* allowed via bounded transition */

I think there might be an audit issue here; security_bounded_transition() will generate an audit record on failure which probably isn't what we want in this case.

Other than that, this seems reasonable, even in the face of NNP, and as others point out, standard DAC capabilities do something similar.

security/selinux/hooks.c static int selinux_vm_enough_memory(struct mm_struct · line 2116

Quoted 10 lines

security/selinux/hooks.c +10 -0

+    /* Only allow if dyntransition permission aka setcon() is allowed. */
+    rc = avc_has_perm(old_tsec->sid, new_tsec->sid, SECCLASS_PROCESS,
+                      PROCESS__DYNTRANSITION, NULL);
+    if (rc) {
+            if (nnp)
+                    return -EPERM;
+            else
+                    return -EACCES;
+    }
+    return 0;

I know this dyntransition/NNP/NOSUID interaction has been discussed quite a bit off-list (mostly while I was away, my apologies), but I haven't seen a lot on-list and while the descriptions hints at it the code itself doesn't elaborate on why this is "OK". I'd like to see some comments about why it is okay to allow the transition, regardless of NNP/NOSUID, if the dyntransition is allowed. I'd also like to see a quick comment about why we return -EPERM/- EACCES.

Quoted 2 lines

There was a lot of discussion around these points and I want to make sure the ideas aren't lost.

The claim was that dyntransition is sufficient since it would allow the caller to setcon() to the new domain directly and therefore perform any action in that domain. Thus, allowing it to transition to that domain upon exec under NNP or on a file in a nosuid mount does not enable it to do anything it could not already do directly.

However, this presumes that the policy writer does not merely add dyntransition to the caller domain upon encountering the avc denial in this situation without thinking about the implications and deciding whether to truly trust the caller domain in this way. Which is likely a dangerous assumption, especially for people who write policy via audit2allow.

Quoted 5 lines

At least with the bounded transition, you have to explicitly declare that the new domain is bounded by the caller domain and the kernel will then enforce the restriction that the new domain is not granted any permission not allowed to the caller domain.

How about making the change just for bounded transitions, then? No one will write the policy if the kernel doesn't support it.

Quoted 2 lines

I'm also unclear as to whether this in fact solves the actual problem for sandbox -X.

Dunno. dwalsh, does it?

Quoted 1 line

So I'd drop this patch for now at least.

--Andy
_______________________________________________
Selinux mailing list
[email protected]
To unsubscribe, send email to [email protected].
To get help, send an email containing "help" to [email protected].

Quoted 8 lines · Daniel J Walsh

We can use it to fix sandbox.

sandbox -X xterm can do the following

unconfined_t -> seunshare_t -> sandbox_x_t Then I allow sandbox_x_t to setcur to sandbox_x_client_t. sandbox_x_t can run the xserver, and the confined app will run as sandbox_x_client_t. If I am allowed to transition to a tighter domain, I can get the scripts to work.

Which of those transitions are on exec and which ones are via explicit setcon() call?

Would it work if you couldn't allow it via dyntransition but had to specify typebounds <callingdomain> <newdomain>;
instead?

Quoted 107 lines · Andy Lutomirski

Quoted 106 lines · Stephen Smalley

Quoted 92 lines · Paul Moore

Quoted 76 lines · Paul Moore

Quoted 20 lines · Stephen Smalley

Quoted 1 line

v2 - fix patch description to match the code.

Okay Stephen, I suppose you should get some special consideration, but is posting your patches inline really that hard :)

---
From c1fa21950c5c3eb0dd97ae5145fa3d3f04adc5c4 Mon Sep 17 00:00:00 2001
From: Stephen Smalley <[email protected]>
Date: Thu, 12 Jun 2014 08:17:48 -0400
Subject: [PATCH] selinux: Permit exec transitions under NO_NEW_PRIVS or
NOSUID under certain circumstances.

If the callee SID is bounded by the caller SID or if the caller SID is allowed to perform a dynamic transition (setcon) to the callee SID, then allowing the transition to occur poses no risk of privilege escalation and we can therefore safely allow the transition to occur. Add these two exemptions for both the case where a transition was explicitly requested by the application and the case where an automatic transition is defined in policy.

Quoted 2 lines

Signed-off-by Stephen Smalley <[email protected]>

Acked-by Andy Lutomirski <[email protected]>

Comments below ...

Quoted 16 lines

security/selinux/hooks.c +7 -0

index 83d06db..d5e8dc5 100644
@@ -2086,6 +2086,36 @@ static int selinux_vm_enough_memory(struct mm_struct
 *mm, long pages)
 
 /* binprm security operations */
 
+static int check_nnp_nosuid(const struct linux_binprm *bprm,
+                        const struct task_security_struct *old_tsec,
+                        const struct task_security_struct *new_tsec)
+{
+    int nnp = (bprm->unsafe & LSM_UNSAFE_NO_NEW_PRIVS);
+    int nosuid = (bprm->file->f_path.mnt->mnt_flags & MNT_NOSUID);
+    int rc;

security/selinux/hooks.c static int selinux_vm_enough_memory(struct mm_struct · line 2106

Quoted 10 lines

security/selinux/hooks.c +10 -0

+
+    if (!nnp && !nosuid)
+            return 0; /* neither NNP nor nosuid */
+
+    if (new_tsec->sid == old_tsec->sid)
+            return 0; /* No change in credentials */
+
+    rc = security_bounded_transition(old_tsec->sid, new_tsec->sid);
+    if (rc == 0)
+            return 0; /* allowed via bounded transition */

I think there might be an audit issue here; security_bounded_transition() will generate an audit record on failure which probably isn't what we want in this case.

Other than that, this seems reasonable, even in the face of NNP, and as others point out, standard DAC capabilities do something similar.

security/selinux/hooks.c static int selinux_vm_enough_memory(struct mm_struct · line 2116

Quoted 10 lines

security/selinux/hooks.c +10 -0

+    /* Only allow if dyntransition permission aka setcon() is allowed. */
+    rc = avc_has_perm(old_tsec->sid, new_tsec->sid, SECCLASS_PROCESS,
+                      PROCESS__DYNTRANSITION, NULL);
+    if (rc) {
+            if (nnp)
+                    return -EPERM;
+            else
+                    return -EACCES;
+    }
+    return 0;

I know this dyntransition/NNP/NOSUID interaction has been discussed quite a bit off-list (mostly while I was away, my apologies), but I haven't seen a lot on-list and while the descriptions hints at it the code itself doesn't elaborate on why this is "OK". I'd like to see some comments about why it is okay to allow the transition, regardless of NNP/NOSUID, if the dyntransition is allowed. I'd also like to see a quick comment about why we return -EPERM/- EACCES.

Quoted 2 lines

There was a lot of discussion around these points and I want to make sure the ideas aren't lost.

The claim was that dyntransition is sufficient since it would allow the caller to setcon() to the new domain directly and therefore perform any action in that domain. Thus, allowing it to transition to that domain upon exec under NNP or on a file in a nosuid mount does not enable it to do anything it could not already do directly.

However, this presumes that the policy writer does not merely add dyntransition to the caller domain upon encountering the avc denial in this situation without thinking about the implications and deciding whether to truly trust the caller domain in this way. Which is likely a dangerous assumption, especially for people who write policy via audit2allow.

Quoted 5 lines

At least with the bounded transition, you have to explicitly declare that the new domain is bounded by the caller domain and the kernel will then enforce the restriction that the new domain is not granted any permission not allowed to the caller domain.

How about making the change just for bounded transitions, then? No one will write the policy if the kernel doesn't support it.

Quoted 2 lines

I'm also unclear as to whether this in fact solves the actual problem for sandbox -X.

Dunno. dwalsh, does it?

Quoted 1 line

So I'd drop this patch for now at least.

Quoted 9 lines

Quoted 8 lines

--Andy
_______________________________________________
Selinux mailing list
[email protected]
To unsubscribe, send email to [email protected].
To get help, send an email containing "help" to [email protected].

_______________________________________________
Selinux mailing list
[email protected]
To unsubscribe, send email to [email protected].
To get help, send an email containing "help" to [email protected].