libselinux behavior in permissive mode wrt invalid domains

libselinux behavior in permissive mode wrt invalid domains

[Colin Walters]

Hi,

I'd like broader input on:
http://bugs.freedesktop.org/show_bug.cgi?id=21072

Is this something we can do inside libselinux itself?  Or are we
planning similar patches around avc_has_perm calls for the X server,
libvirt and other userspace programs?

--
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.

Re: libselinux behavior in permissive mode wrt invalid domains

[Daniel J Walsh]

On 04/14/2009 02:42 PM, Colin Walters wrote:
> Hi,
>
> I'd like broader input on:
> http://bugs.freedesktop.org/show_bug.cgi?id=21072
>
> Is this something we can do inside libselinux itself?  Or are we
> planning similar patches around avc_has_perm calls for the X server,
> libvirt and other userspace programs?
>
> --
> 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.

So the question is whether the API should return allowed when in 
permissive mode rather then denied and make every App server code up 
permissive mode check.


We have had several bugs where tools have not checked whether the 
machine is in permissive mode when doing an access check.  One 
possibility would be to generate the AVC in the check code when in 
permissive mode or always generat the AVC, there an return allowed.

If you look at the calling apps point of view it is asking if the user 
should be allowed the access and in permissive mode he should be allowed 
the access.

--
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.

Re: libselinux behavior in permissive mode wrt invalid domains

[Stephen Smalley]

On Wed, 2009-04-15 at 08:15 -0400, Daniel J Walsh wrote:
> On 04/14/2009 02:42 PM, Colin Walters wrote:
> > Hi,
> >
> > I'd like broader input on:
> > http://bugs.freedesktop.org/show_bug.cgi?id=21072
> >
> > Is this something we can do inside libselinux itself?  Or are we
> > planning similar patches around avc_has_perm calls for the X server,
> > libvirt and other userspace programs?
> >
> > --
> > 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.
> 
> So the question is whether the API should return allowed when in 
> permissive mode rather then denied and make every App server code up 
> permissive mode check.
> 
> 
> We have had several bugs where tools have not checked whether the 
> machine is in permissive mode when doing an access check.  One 
> possibility would be to generate the AVC in the check code when in 
> permissive mode or always generat the AVC, there an return allowed.
> 
> If you look at the calling apps point of view it is asking if the user 
> should be allowed the access and in permissive mode he should be allowed 
> the access.

avc_has_perm() already checks for permissive mode internally, unlike
security_compute_av().  However, in this case, the problem is not that
permission was denied but rather that one of the security contexts is no
longer valid.

-- 
Stephen Smalley
National Security Agency


--
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.

Re: libselinux behavior in permissive mode wrt invalid domains

[Eamon Walsh]

Stephen Smalley wrote:
> On Wed, 2009-04-15 at 08:15 -0400, Daniel J Walsh wrote:
>   
>> On 04/14/2009 02:42 PM, Colin Walters wrote:
>>     
>>> Hi,
>>>
>>> I'd like broader input on:
>>> http://bugs.freedesktop.org/show_bug.cgi?id=21072
>>>
>>> Is this something we can do inside libselinux itself?  Or are we
>>> planning similar patches around avc_has_perm calls for the X server,
>>> libvirt and other userspace programs?
>>>
>>> --
>>> 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.
>>>       
>> So the question is whether the API should return allowed when in 
>> permissive mode rather then denied and make every App server code up 
>> permissive mode check.
>>
>>
>> We have had several bugs where tools have not checked whether the 
>> machine is in permissive mode when doing an access check.  One 
>> possibility would be to generate the AVC in the check code when in 
>> permissive mode or always generat the AVC, there an return allowed.
>>
>> If you look at the calling apps point of view it is asking if the user 
>> should be allowed the access and in permissive mode he should be allowed 
>> the access.
>>     
>
> avc_has_perm() already checks for permissive mode internally, unlike
> security_compute_av().  However, in this case, the problem is not that
> permission was denied but rather that one of the security contexts is no
> longer valid.
>
>   

To elaborate, a return value of -1 from avc_has_perm() does not mean
"denied."  It is errno being EACCES that means denied.  EINVAL means bad
context or other argument.  And there are other possibilities, like
ENOMEM.  So at the very least, the D-Bus code should log a different
message ("SELinux denying due to invalid context") when errno is EINVAL.

I'd like to see this problem solved in the kernel.  The compute_av call
should map invalid contexts to the unlabeled sid instead of erroring out
with EINVAL in permissive mode.

I reviewed ss/services.c briefly and came up with the following
pseudo-patch which modifies the behavior of string_to_context_struct(). 
Some potential issues are that:
 -- string_to_context_struct() is called from convert_context() as well
as security_context_to_sid_core().
 -- Mutating the context struct into the unlabeled context might
interact badly with the "force == 1" logic in
security_context_to_sid_core().



diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
index deeec6c..bf49ecc 100644
--- a/security/selinux/ss/services.c
+++ b/security/selinux/ss/services.c
@@ -900,6 +900,28 @@ int security_sid_to_context_force(u32 sid, char **scontext, u32 *scontext_len)
 	return security_sid_to_context_core(sid, scontext, scontext_len, 1);
 }
 
+static inline int string_to_context_struct_handle_invalid_context(struct context *context)
+{
+	int rc = 0;
+
+	if (selinux_enforcing) {
+		rc = -EINVAL;
+	} else {
+		char *s;
+		u32 len;
+
+		if (!context_struct_to_string(context, &s, &len)) {
+			printk(KERN_WARNING
+		       "SELinux:  Context %s would be invalid if enforcing\n",
+			       s);
+			kfree(s);
+		}
+
+		magically_turn_context_into_the_unlabeled_sid(ctx);
+	}
+	return rc;
+}
+
 /*
  * Caveat:  Mutates scontext.
  */
@@ -978,8 +1000,9 @@ static int string_to_context_struct(struct policydb *pol,
 
 	/* Check the validity of the new context. */
 	if (!policydb_context_isvalid(pol, ctx)) {
-		rc = -EINVAL;
-		goto out;
+		rc = string_to_context_struct_handle_invalid_context(ctx);
+		if (rc)
+			goto out;
 	}
 	rc = 0;
 out:



-- 
Eamon Walsh <ewalsh@tycho.nsa.gov>
National Security Agency


--
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.

Re: libselinux behavior in permissive mode wrt invalid domains

[Stephen Smalley]

On Thu, 2009-04-16 at 20:47 -0400, Eamon Walsh wrote:
> Stephen Smalley wrote:
> > On Wed, 2009-04-15 at 08:15 -0400, Daniel J Walsh wrote:
> >   
> >> On 04/14/2009 02:42 PM, Colin Walters wrote:
> >>     
> >>> Hi,
> >>>
> >>> I'd like broader input on:
> >>> http://bugs.freedesktop.org/show_bug.cgi?id=21072
> >>>
> >>> Is this something we can do inside libselinux itself?  Or are we
> >>> planning similar patches around avc_has_perm calls for the X server,
> >>> libvirt and other userspace programs?
> >>>
> >>> --
> >>> 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.
> >>>       
> >> So the question is whether the API should return allowed when in 
> >> permissive mode rather then denied and make every App server code up 
> >> permissive mode check.
> >>
> >>
> >> We have had several bugs where tools have not checked whether the 
> >> machine is in permissive mode when doing an access check.  One 
> >> possibility would be to generate the AVC in the check code when in 
> >> permissive mode or always generat the AVC, there an return allowed.
> >>
> >> If you look at the calling apps point of view it is asking if the user 
> >> should be allowed the access and in permissive mode he should be allowed 
> >> the access.
> >>     
> >
> > avc_has_perm() already checks for permissive mode internally, unlike
> > security_compute_av().  However, in this case, the problem is not that
> > permission was denied but rather that one of the security contexts is no
> > longer valid.
> >
> >   
> 
> To elaborate, a return value of -1 from avc_has_perm() does not mean
> "denied."  It is errno being EACCES that means denied.  EINVAL means bad
> context or other argument.  And there are other possibilities, like
> ENOMEM.  So at the very least, the D-Bus code should log a different
> message ("SELinux denying due to invalid context") when errno is EINVAL.
> 
> I'd like to see this problem solved in the kernel.  The compute_av call
> should map invalid contexts to the unlabeled sid instead of erroring out
> with EINVAL in permissive mode.
> 
> I reviewed ss/services.c briefly and came up with the following
> pseudo-patch which modifies the behavior of string_to_context_struct(). 
> Some potential issues are that:
>  -- string_to_context_struct() is called from convert_context() as well
> as security_context_to_sid_core().
>  -- Mutating the context struct into the unlabeled context might
> interact badly with the "force == 1" logic in
> security_context_to_sid_core().
> 
> 
> 
> diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
> index deeec6c..bf49ecc 100644
> --- a/security/selinux/ss/services.c
> +++ b/security/selinux/ss/services.c
> @@ -900,6 +900,28 @@ int security_sid_to_context_force(u32 sid, char **scontext, u32 *scontext_len)
>  	return security_sid_to_context_core(sid, scontext, scontext_len, 1);
>  }
>  
> +static inline int string_to_context_struct_handle_invalid_context(struct context *context)
> +{
> +	int rc = 0;
> +
> +	if (selinux_enforcing) {
> +		rc = -EINVAL;
> +	} else {
> +		char *s;
> +		u32 len;
> +
> +		if (!context_struct_to_string(context, &s, &len)) {
> +			printk(KERN_WARNING
> +		       "SELinux:  Context %s would be invalid if enforcing\n",
> +			       s);
> +			kfree(s);
> +		}
> +
> +		magically_turn_context_into_the_unlabeled_sid(ctx);
> +	}
> +	return rc;
> +}
> +
>  /*
>   * Caveat:  Mutates scontext.
>   */
> @@ -978,8 +1000,9 @@ static int string_to_context_struct(struct policydb *pol,
>  
>  	/* Check the validity of the new context. */
>  	if (!policydb_context_isvalid(pol, ctx)) {
> -		rc = -EINVAL;
> -		goto out;
> +		rc = string_to_context_struct_handle_invalid_context(ctx);
> +		if (rc)
> +			goto out;
>  	}
>  	rc = 0;
>  out:

No, I don't want to change the behavior upon context_to_sid calls in
general, as we otherwise lose all context validity checking in
permissive mode.

I think I'd rather change compute_sid behavior to preclude the situation
from arising in the first place, possibly altering the behavior in
permissive mode upon an invalid context to fall back on the ssid
(process) or the tsid (object).  But I'm not entirely convinced any
change is required here.

-- 
Stephen Smalley
National Security Agency


--
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.

Re: libselinux behavior in permissive mode wrt invalid domains

[Joshua Brindle]

Stephen Smalley wrote:
> On Thu, 2009-04-16 at 20:47 -0400, Eamon Walsh wrote:
>> Stephen Smalley wrote:
<snip>

> 
> No, I don't want to change the behavior upon context_to_sid calls in
> general, as we otherwise lose all context validity checking in
> permissive mode.
> 
> I think I'd rather change compute_sid behavior to preclude the situation
> from arising in the first place, possibly altering the behavior in
> permissive mode upon an invalid context to fall back on the ssid
> (process) or the tsid (object).  But I'm not entirely convinced any
> change is required here.
> 

I just want to follow up to make sure we are all on the same page here. Was the 
suggestion to change avc_has_perm in libselinux or context_to_sid in the kernel 
or leave the code as is and fix the callers of avc_has_perm to correctly handle 
error codes?

I prefer the last approach because of Eamon's explanation, EINVAL is already 
passed in errno to specify the context was invalid (and if object managers 
aren't handling that correctly now there is a good chance they aren't handling 
the ENOMEM case either).

--
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.

Re: libselinux behavior in permissive mode wrt invalid domains

[Stephen Smalley]

On Tue, 2009-04-21 at 16:32 -0400, Joshua Brindle wrote:
> Stephen Smalley wrote:
> > On Thu, 2009-04-16 at 20:47 -0400, Eamon Walsh wrote:
> >> Stephen Smalley wrote:
> <snip>
> 
> > 
> > No, I don't want to change the behavior upon context_to_sid calls in
> > general, as we otherwise lose all context validity checking in
> > permissive mode.
> > 
> > I think I'd rather change compute_sid behavior to preclude the situation
> > from arising in the first place, possibly altering the behavior in
> > permissive mode upon an invalid context to fall back on the ssid
> > (process) or the tsid (object).  But I'm not entirely convinced any
> > change is required here.
> > 
> 
> I just want to follow up to make sure we are all on the same page here. Was the 
> suggestion to change avc_has_perm in libselinux or context_to_sid in the kernel 
> or leave the code as is and fix the callers of avc_has_perm to correctly handle 
> error codes?
> 
> I prefer the last approach because of Eamon's explanation, EINVAL is already 
> passed in errno to specify the context was invalid (and if object managers 
> aren't handling that correctly now there is a good chance they aren't handling 
> the ENOMEM case either).

I'd be inclined to change compute_sid (not context_to_sid) in the kernel
to prevent invalid contexts from being formed even in permissive mode
(scenario is a type transition where role is not authorized for the new
type).  That was originally to allow the system to boot in permissive
mode.  But an alternative would be to just stay in the caller's context
(ssid) in that situation.

Changing the callers of avc_has_perm() to handle EINVAL and/or ENOMEM
may make sense, but that logic should not depend on enforcing vs.
permissive mode.
 
-- 
Stephen Smalley
National Security Agency


--
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.

Re: libselinux behavior in permissive mode wrt invalid domains

[Eamon Walsh]

Stephen Smalley wrote:
> On Tue, 2009-04-21 at 16:32 -0400, Joshua Brindle wrote:
>   
>> Stephen Smalley wrote:
>>     
>>> On Thu, 2009-04-16 at 20:47 -0400, Eamon Walsh wrote:
>>>       
>>>> Stephen Smalley wrote:
>>>>         
>> <snip>
>>
>>     
>>> No, I don't want to change the behavior upon context_to_sid calls in
>>> general, as we otherwise lose all context validity checking in
>>> permissive mode.
>>>
>>> I think I'd rather change compute_sid behavior to preclude the situation
>>> from arising in the first place, possibly altering the behavior in
>>> permissive mode upon an invalid context to fall back on the ssid
>>> (process) or the tsid (object).  But I'm not entirely convinced any
>>> change is required here.
>>>
>>>       
>> I just want to follow up to make sure we are all on the same page here. Was the 
>> suggestion to change avc_has_perm in libselinux or context_to_sid in the kernel 
>> or leave the code as is and fix the callers of avc_has_perm to correctly handle 
>> error codes?
>>
>> I prefer the last approach because of Eamon's explanation, EINVAL is already 
>> passed in errno to specify the context was invalid (and if object managers 
>> aren't handling that correctly now there is a good chance they aren't handling 
>> the ENOMEM case either).
>>     
>
> I'd be inclined to change compute_sid (not context_to_sid) in the kernel
> to prevent invalid contexts from being formed even in permissive mode
> (scenario is a type transition where role is not authorized for the new
> type).  That was originally to allow the system to boot in permissive
> mode.  But an alternative would be to just stay in the caller's context
> (ssid) in that situation.
>
> Changing the callers of avc_has_perm() to handle EINVAL and/or ENOMEM
> may make sense, but that logic should not depend on enforcing vs.
> permissive mode.
>  
>   


FWIW, the following patch to D-Bus should help:


bfo21072 - Log SELinux denials better by checking errno for the cause
    
    Note that this does not fully address the bug report since
    EINVAL can still be returned in permissive mode.  However the log
    messages will now reflect the proper cause of the denial.
    
Signed-off-by: Eamon Walsh <ewalsh@tycho.nsa.gov>

diff --git a/bus/selinux.c b/bus/selinux.c
index c0f6f4d..46a18a9 100644
--- a/bus/selinux.c
+++ b/bus/selinux.c
@@ -433,8 +433,18 @@ bus_selinux_check (BusSELinuxID        *sender_sid,
                     SELINUX_SID_FROM_BUS (bus_sid), 
                     target_class, requested, &aeref, auxdata) < 0)
     {
-      _dbus_verbose ("SELinux denying due to security policy.\n");
-      return FALSE;
+    switch (errno)
+      {
+      case EACCES:
+        _dbus_verbose ("SELinux denying due to security policy.\n");
+        return FALSE;
+      case EINVAL:
+        _dbus_verbose ("SELinux denying due to invalid security context.\n");
+        return FALSE;
+      default:
+        _dbus_verbose ("SELinux denying due to: %s\n", _dbus_strerror (errno));
+        return FALSE;
+      }
     }
   else
     return TRUE;


-- 
Eamon Walsh <ewalsh@tycho.nsa.gov>
National Security Agency


--
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.

Re: libselinux behavior in permissive mode wrt invalid domains

[Colin Walters]

On Tue, Apr 21, 2009 at 7:11 PM, Eamon Walsh <ewalsh@tycho.nsa.gov> wrote:
>
> FWIW, the following patch to D-Bus should help:
>
>
> bfo21072 - Log SELinux denials better by checking errno for the cause
>
>    Note that this does not fully address the bug report since
>    EINVAL can still be returned in permissive mode.  However the log
>    messages will now reflect the proper cause of the denial.

Applied, thank you!


--
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.

Re: libselinux behavior in permissive mode wrt invalid domains

[Stephen Smalley]

On Tue, 2009-04-14 at 14:42 -0400, Colin Walters wrote:
> Hi,
> 
> I'd like broader input on:
> http://bugs.freedesktop.org/show_bug.cgi?id=21072
> 
> Is this something we can do inside libselinux itself?  Or are we
> planning similar patches around avc_has_perm calls for the X server,
> libvirt and other userspace programs?

I agree with you - this should be handled within libselinux if it gets
handled at all, not in the callers of avc_has_perm().

-- 
Stephen Smalley
National Security Agency


--
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.