typebounds lookup from userspace

typebounds lookup from userspace

[Joshua Brindle]

For symbol labeling purposes for policy access control we need to be able to look up symbol hierarchy relationships. I expect we'll do this by exporting the symbol hierarchy via selinuxfs. Does anyone have suggestions on what that should look like? Do we want to export additional information on the symbols at the same time?

--
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: typebounds lookup from userspace

[Stephen Smalley]

On Fri, 2008-09-19 at 10:07 -0400, Joshua Brindle wrote:
> For symbol labeling purposes for policy access control we need to be
> able to look up symbol hierarchy relationships. I expect we'll do this
> by exporting the symbol hierarchy via selinuxfs. Does anyone have
> suggestions on what that should look like? Do we want to export
> additional information on the symbols at the same time?

I would have thought that the policy server would have its own internal
policydb that it could consult to check hierarchy relationships?

In any event, if we were to export such info via selinuxfs, then yes,
we'd want to also export other information about the symbols, such as
the user role and level authorizations, so that that information could
be used by libselinux and we could ultimately deprecate /selinux/user
aka security_compute_user().

-- 
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: typebounds lookup from userspace

[Joshua Brindle]

Stephen Smalley wrote:
> On Fri, 2008-09-19 at 10:07 -0400, Joshua Brindle wrote:
>> For symbol labeling purposes for policy access control we need to be
>> able to look up symbol hierarchy relationships. I expect we'll do this
>> by exporting the symbol hierarchy via selinuxfs. Does anyone have
>> suggestions on what that should look like? Do we want to export
>> additional information on the symbols at the same time?
> 
> I would have thought that the policy server would have its own internal
> policydb that it could consult to check hierarchy relationships?
> 

We want to avoid loading more policydb's since RAM usage and performance were issues with the expand-based access control.

> In any event, if we were to export such info via selinuxfs, then yes,
> we'd want to also export other information about the symbols, such as
> the user role and level authorizations, so that that information could
> be used by libselinux and we could ultimately deprecate /selinux/user
> aka security_compute_user().
> 

So, something like
/selinux/symbols/types/httpd_cgi_t
bounds: httpd_t

/selinux/symbols/users/user_u
bounds: staff_u
roles: user_r 
levels: s0-s0:c0.c128

?

or maybe

/selinux/symbols/users/user_u/roles
user_r

/selinux/symbols/users/user_u/bounds
staff_u

?

--
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: typebounds lookup from userspace

[Stephen Smalley]

On Fri, 2008-09-19 at 10:32 -0400, Joshua Brindle wrote:
> Stephen Smalley wrote:
> > On Fri, 2008-09-19 at 10:07 -0400, Joshua Brindle wrote:
> >> For symbol labeling purposes for policy access control we need to be
> >> able to look up symbol hierarchy relationships. I expect we'll do this
> >> by exporting the symbol hierarchy via selinuxfs. Does anyone have
> >> suggestions on what that should look like? Do we want to export
> >> additional information on the symbols at the same time?
> > 
> > I would have thought that the policy server would have its own internal
> > policydb that it could consult to check hierarchy relationships?
> > 
> 
> We want to avoid loading more policydb's since RAM usage and
> performance were issues with the expand-based access control.

libsemanage already has to load the policydb into memory for its
transactions.  Will this change in the future?  If not, then it seems
that you could simply leverage that.

> > In any event, if we were to export such info via selinuxfs, then yes,
> > we'd want to also export other information about the symbols, such as
> > the user role and level authorizations, so that that information could
> > be used by libselinux and we could ultimately deprecate /selinux/user
> > aka security_compute_user().
> > 
> 
> So, something like
> /selinux/symbols/types/httpd_cgi_t
> bounds: httpd_t
> 
> /selinux/symbols/users/user_u
> bounds: staff_u
> roles: user_r 
> levels: s0-s0:c0.c128
> 
> ?
> 
> or maybe
> 
> /selinux/symbols/users/user_u/roles
> user_r
> 
> /selinux/symbols/users/user_u/bounds
> staff_u

I know that at one point the trend was toward one value per file, but
that carries a cost of course, and I'm not sure the /selinux/class
interface turned out to be ideal.  Maybe others have opinions.

-- 
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: typebounds lookup from userspace

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 844 bytes --]

On Fri, 19 Sep 2008 11:07:22 EDT, Stephen Smalley said:

> I know that at one point the trend was toward one value per file, but
> that carries a cost of course, and I'm not sure the /selinux/class
> interface turned out to be ideal.  Maybe others have opinions.

That's true for sysfs.  The selinuxfs is a different beast and can make its
own choices.   The biggest gotcha is that you need to remain backwards-combatabl;e,
so anything that's there *now* has to remain there for a rather extensive
deprecation period.  Keep in mind that Andrew Morton just this week had an
issue with /proc/net that turned out to be because he had an FC5 policy loaded,
and that ancient policy didn't know that /proc/net is now a symlink...

What info would *ideally* be available for userspace?  Let's figure that out
first, and work backwards from there...



[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: typebounds lookup from userspace

[Joshua Brindle]

Stephen Smalley wrote:
> On Fri, 2008-09-19 at 10:32 -0400, Joshua Brindle wrote:
>> Stephen Smalley wrote:
>>> On Fri, 2008-09-19 at 10:07 -0400, Joshua Brindle wrote:
>>>> For symbol labeling purposes for policy access control we need to be
>>>> able to look up symbol hierarchy relationships. I expect we'll do this
>>>> by exporting the symbol hierarchy via selinuxfs. Does anyone have
>>>> suggestions on what that should look like? Do we want to export
>>>> additional information on the symbols at the same time?
>>> I would have thought that the policy server would have its own internal
>>> policydb that it could consult to check hierarchy relationships?
>>>
>> We want to avoid loading more policydb's since RAM usage and
>> performance were issues with the expand-based access control.
> 
> libsemanage already has to load the policydb into memory for its
> transactions.  Will this change in the future?  If not, then it seems
> that you could simply leverage that.
> 

True, though that is currently only done when not building a policy. For access control we will be building a policy but hope to do access control far before that happens (thus saving time if it is going to fail anyway). The rebuild code path doesn't currently open the old policy so adding that would double the ram usage.

>>> In any event, if we were to export such info via selinuxfs, then yes,
>>> we'd want to also export other information about the symbols, such as
>>> the user role and level authorizations, so that that information could
>>> be used by libselinux and we could ultimately deprecate /selinux/user
>>> aka security_compute_user().
>>>
>> So, something like
>> /selinux/symbols/types/httpd_cgi_t
>> bounds: httpd_t
>>
>> /selinux/symbols/users/user_u
>> bounds: staff_u
>> roles: user_r 
>> levels: s0-s0:c0.c128
>>
>> ?
>>
>> or maybe
>>
>> /selinux/symbols/users/user_u/roles
>> user_r
>>
>> /selinux/symbols/users/user_u/bounds
>> staff_u
> 
> I know that at one point the trend was toward one value per file, but
> that carries a cost of course, and I'm not sure the /selinux/class
> interface turned out to be ideal.  Maybe others have opinions.
> 

was there anything specific about the class interface you didn't like? I like it in the sense that once the tree is built the policydb never has to be consulted. I don't think that is an option for this case though.

I like one value per file but we are talking about a large namespace for types. 

--
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: typebounds lookup from userspace

[Stephen Smalley]

On Fri, 2008-09-19 at 11:47 -0400, Joshua Brindle wrote:
> Stephen Smalley wrote:
> > On Fri, 2008-09-19 at 10:32 -0400, Joshua Brindle wrote:
> >> Stephen Smalley wrote:
> >>> On Fri, 2008-09-19 at 10:07 -0400, Joshua Brindle wrote:
> >>>> For symbol labeling purposes for policy access control we need to be
> >>>> able to look up symbol hierarchy relationships. I expect we'll do this
> >>>> by exporting the symbol hierarchy via selinuxfs. Does anyone have
> >>>> suggestions on what that should look like? Do we want to export
> >>>> additional information on the symbols at the same time?
> >>> I would have thought that the policy server would have its own internal
> >>> policydb that it could consult to check hierarchy relationships?
> >>>
> >> We want to avoid loading more policydb's since RAM usage and
> >> performance were issues with the expand-based access control.
> > 
> > libsemanage already has to load the policydb into memory for its
> > transactions.  Will this change in the future?  If not, then it seems
> > that you could simply leverage that.
> > 
> 
> True, though that is currently only done when not building a policy.

What?  It constructs a policydb in memory when building a policy and
then writes it out.  There is always an in-memory policydb, whether it
is just loaded from the existing policy file (via Dan's enhancement) or
generated via expand/link + merge local components.

>  For access control we will be building a policy but hope to do access
> control far before that happens (thus saving time if it is going to
> fail anyway). The rebuild code path doesn't currently open the old
> policy so adding that would double the ram usage.

Ok.

> > I know that at one point the trend was toward one value per file, but
> > that carries a cost of course, and I'm not sure the /selinux/class
> > interface turned out to be ideal.  Maybe others have opinions.
> > 
> 
> was there anything specific about the class interface you didn't like?
> I like it in the sense that once the tree is built the policydb never
> has to be consulted. I don't think that is an option for this case
> though.
> 
> I like one value per file but we are talking about a large namespace for types.

Yes, I'm a little concerned about eating up kernel memory for all of
those pseudo inodes, most of which will never be used by userspace.

-- 
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: typebounds lookup from userspace

[Joshua Brindle]

Stephen Smalley wrote:
> On Fri, 2008-09-19 at 11:47 -0400, Joshua Brindle wrote:
>> Stephen Smalley wrote:
>>> On Fri, 2008-09-19 at 10:32 -0400, Joshua Brindle wrote:
>>>> Stephen Smalley wrote:
>>>>> On Fri, 2008-09-19 at 10:07 -0400, Joshua Brindle wrote:
>>>>>> For symbol labeling purposes for policy access control we need to be
>>>>>> able to look up symbol hierarchy relationships. I expect we'll do this
>>>>>> by exporting the symbol hierarchy via selinuxfs. Does anyone have
>>>>>> suggestions on what that should look like? Do we want to export
>>>>>> additional information on the symbols at the same time?
>>>>> I would have thought that the policy server would have its own internal
>>>>> policydb that it could consult to check hierarchy relationships?
>>>>>
>>>> We want to avoid loading more policydb's since RAM usage and
>>>> performance were issues with the expand-based access control.
>>> libsemanage already has to load the policydb into memory for its
>>> transactions.  Will this change in the future?  If not, then it seems
>>> that you could simply leverage that.
>>>
>> True, though that is currently only done when not building a policy.
> 
> What?  It constructs a policydb in memory when building a policy and
> then writes it out.  There is always an in-memory policydb, whether it
> is just loaded from the existing policy file (via Dan's enhancement) or
> generated via expand/link + merge local components.
> 
>>  For access control we will be building a policy but hope to do access
>> control far before that happens (thus saving time if it is going to
>> fail anyway). The rebuild code path doesn't currently open the old
>> policy so adding that would double the ram usage.
> 
> Ok.
> 
>>> I know that at one point the trend was toward one value per file, but
>>> that carries a cost of course, and I'm not sure the /selinux/class
>>> interface turned out to be ideal.  Maybe others have opinions.
>>>
>> was there anything specific about the class interface you didn't like?
>> I like it in the sense that once the tree is built the policydb never
>> has to be consulted. I don't think that is an option for this case
>> though.
>>
>> I like one value per file but we are talking about a large namespace for types.
> 
> Yes, I'm a little concerned about eating up kernel memory for all of
> those pseudo inodes, most of which will never be used by userspace.
> 

So I guess an alternative is a query interface like the others. open /selinux/bounds, write a type and get back the bounds? 

--
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: typebounds lookup from userspace

[Joshua Brindle]

Stephen Smalley wrote:
> On Fri, 2008-09-19 at 11:47 -0400, Joshua Brindle wrote:
>> Stephen Smalley wrote:
>>> On Fri, 2008-09-19 at 10:32 -0400, Joshua Brindle wrote:
>>>> Stephen Smalley wrote:
>>>>> On Fri, 2008-09-19 at 10:07 -0400, Joshua Brindle wrote:
>>>>>> For symbol labeling purposes for policy access control we need to be
>>>>>> able to look up symbol hierarchy relationships. I expect we'll do this
>>>>>> by exporting the symbol hierarchy via selinuxfs. Does anyone have
>>>>>> suggestions on what that should look like? Do we want to export
>>>>>> additional information on the symbols at the same time?
>>>>> I would have thought that the policy server would have its own internal
>>>>> policydb that it could consult to check hierarchy relationships?
>>>>>
>>>> We want to avoid loading more policydb's since RAM usage and
>>>> performance were issues with the expand-based access control.
>>> libsemanage already has to load the policydb into memory for its
>>> transactions.  Will this change in the future?  If not, then it seems
>>> that you could simply leverage that.
>>>
>> True, though that is currently only done when not building a policy.
> 
> What?  It constructs a policydb in memory when building a policy and
> then writes it out.  There is always an in-memory policydb, whether it
> is just loaded from the existing policy file (via Dan's enhancement) or
> generated via expand/link + merge local components.
> 
>>  For access control we will be building a policy but hope to do access
>> control far before that happens (thus saving time if it is going to
>> fail anyway). The rebuild code path doesn't currently open the old
>> policy so adding that would double the ram usage.
> 
> Ok.
> 
>>> I know that at one point the trend was toward one value per file, but
>>> that carries a cost of course, and I'm not sure the /selinux/class
>>> interface turned out to be ideal.  Maybe others have opinions.
>>>
>> was there anything specific about the class interface you didn't like?
>> I like it in the sense that once the tree is built the policydb never
>> has to be consulted. I don't think that is an option for this case
>> though.
>>
>> I like one value per file but we are talking about a large namespace for types.
> 
> Yes, I'm a little concerned about eating up kernel memory for all of
> those pseudo inodes, most of which will never be used by userspace.
> 

Ok, after thinking about this we really need the entire picture as far as typebounds goes in order to do access control because the modules being added and removed may also have typebounds that we need to incorporate into the labeling process, so that a user can declare a type and bound it to another type. 

So the options are keep a typebounds cache in the libsemanage store or have a node in selinuxfs that exports all the typebounds at once. Do you have a preference of which way to do it?

--
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: typebounds lookup from userspace

[KaiGai Kohei]

Joshua Brindle wrote:
> For symbol labeling purposes for policy access control we need to be able
 > to look up symbol hierarchy relationships. I expect we'll do this by exporting
 > the symbol hierarchy via selinuxfs. Does anyone have suggestions on what that
 > should look like? Do we want to export additional information on the symbols
 > at the same time?

I noticed that userspace object manager also need an interface to get metadata
of types to support permissive domain. Currently, we don't have any interface
to know what domain should be handled as permissive domain.

If "/selinux/access" can return the 6th value to show whether the given query
should be handled as permissive domain or not, it helps userspace object managers.

It is undesirable for me to add a new interface to query whether the given domain
is permissive or not, because it cannot avoid atomicity matter.

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

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

permissive domain interface (Re: typebounds lookup from userspace)

[KaiGai Kohei]

[-- Attachment #1: Type: text/plain, Size: 1638 bytes --]

> If "/selinux/access" can return the 6th value to show whether the given 
> query should be handled as permissive domain or not, it helps userspace
 > object managers.

I tried to make a patch as a proof of concept, like:

[root@saba ~]# semanage permissive -a staff_t
[kaigai@saba php-5.2.6]$ ./sapi/cli/php -r    \
'$scontext = "staff_u:staff_r:staff_t";
  $tcontext = "system_u:object_r:etc_t";
  $tclass = selinux_string_to_class("file");

  $avd = selinux_compute_av($scontext, $tcontext, $tclass);
  var_dump($avd);'

array(6) {
   ["allowed"]=>
   int(139347)
   ["decided"]=>
   int(-1)
   ["auditallow"]=>
   int(0)
   ["auditdeny"]=>
   int(-17)
   ["seqno"]=>
   int(2)
   ["permissive"]=>
   bool(true)
}      ^^^^

[kaigai@saba php-5.2.6]$ ./sapi/cli/php -r    \
'$scontext = "user_u:user_r:user_t";
  $tcontext = "system_u:object_r:etc_t";
  $tclass = selinux_string_to_class("file");

  $avd = selinux_compute_av($scontext, $tcontext, $tclass);
  var_dump($avd);'
array(6) {
   ["allowed"]=>
   int(139347)
   ["decided"]=>
   int(-1)
   ["auditallow"]=>
   int(0)
   ["auditdeny"]=>
   int(-17)
   ["seqno"]=>
   int(2)
   ["permissive"]=>
   bool(false)
}      ^^^^^
----

This patch also improves atomicity between av_decision and "permissive domain"
property at avc_has_perm_noaudit(). It should be checked within same critical
section protected by policy_rwlock in strictly, but the current implementation
has a theoretical possibility that a new policy is loaded between
security_compute_av() and security_permissive_sid(). :-)

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

[-- Attachment #2: permissive-domain-interface-libselinux.1.patch --]
[-- Type: text/x-patch, Size: 1977 bytes --]

Index: libselinux/include/selinux/selinux.h
===================================================================
--- libselinux/include/selinux/selinux.h	(revision 2950)
+++ libselinux/include/selinux/selinux.h	(working copy)
@@ -130,8 +130,11 @@
 	access_vector_t auditallow;
 	access_vector_t auditdeny;
 	unsigned int seqno;
+	unsigned int flags;
 };
 
+#define SELINUX_AV_FLAGS_PERMISSIVE		0x0001
+
 /* Structure for passing options, used by AVC and label subsystems */
 struct selinux_opt {
 	int type;
Index: libselinux/src/avc.c
===================================================================
--- libselinux/src/avc.c	(revision 2950)
+++ libselinux/src/avc.c	(working copy)
@@ -855,11 +855,12 @@
 	denied = requested & ~(ae->avd.allowed);
 
 	if (!requested || denied) {
-		if (avc_enforcing) {
+		if (!avc_enforcing || (ae->avd.flags & SELINUX_AV_FLAGS_PERMISSIVE))
+			ae->avd.allowed |= requested;
+		else {
 			errno = EACCES;
 			rc = -1;
-		} else
-			ae->avd.allowed |= requested;
+		}
 	}
 
       out:
@@ -873,7 +874,7 @@
 		 security_class_t tclass, access_vector_t requested,
 		 struct avc_entry_ref *aeref, void *auditdata)
 {
-	struct av_decision avd = { 0, 0, 0, 0, 0 };
+	struct av_decision avd = { 0, 0, 0, 0, 0, 0 };
 	int errsave, rc;
 
 	rc = avc_has_perm_noaudit(ssid, tsid, tclass, requested, aeref, &avd);
Index: libselinux/src/compute_av.c
===================================================================
--- libselinux/src/compute_av.c	(revision 2950)
+++ libselinux/src/compute_av.c	(working copy)
@@ -49,9 +49,13 @@
 	if (ret < 0)
 		goto out2;
 
-	if (sscanf(buf, "%x %x %x %x %u", &avd->allowed,
-		   &avd->decided, &avd->auditallow, &avd->auditdeny,
-		   &avd->seqno) != 5) {
+	ret = sscanf(buf, "%x %x %x %x %u %x",
+		     &avd->allowed, &avd->decided,
+		     &avd->auditallow, &avd->auditdeny,
+		     &avd->seqno, &avd->flags);
+	if (ret == 5)
+		avd->flags = 0;
+	else if (ret < 5 || ret > 6) {
 		ret = -1;
 		goto out2;
 	}

[-- Attachment #3: permissive-domain-interface-kernel.1.patch --]
[-- Type: text/x-patch, Size: 3245 bytes --]

 security/selinux/avc.c              |    2 +-
 security/selinux/include/security.h |    3 ++-
 security/selinux/selinuxfs.c        |    4 ++--
 security/selinux/ss/services.c      |   30 +++++-------------------------
 4 files changed, 10 insertions(+), 29 deletions(-)

diff --git a/security/selinux/avc.c b/security/selinux/avc.c
index cb30c7e..0a8e3e1 100644
--- a/security/selinux/avc.c
+++ b/security/selinux/avc.c
@@ -904,7 +904,7 @@ int avc_has_perm_noaudit(u32 ssid, u32 tsid,
 	if (denied) {
 		if (flags & AVC_STRICT)
 			rc = -EACCES;
-		else if (!selinux_enforcing || security_permissive_sid(ssid))
+		else if (!selinux_enforcing || (p_ae->avd.flags & AV_FLAGS_PERMISSIVE))
 			avc_update_node(AVC_CALLBACK_GRANT, requested, ssid,
 					tsid, tclass);
 		else
diff --git a/security/selinux/include/security.h b/security/selinux/include/security.h
index 7244737..3f3ebd2 100644
--- a/security/selinux/include/security.h
+++ b/security/selinux/include/security.h
@@ -84,9 +84,10 @@ struct av_decision {
 	u32 auditallow;
 	u32 auditdeny;
 	u32 seqno;
+	u32 flags;
 };
 
-int security_permissive_sid(u32 sid);
+#define AV_FLAGS_PERMISSIVE	0x0001
 
 int security_compute_av(u32 ssid, u32 tsid,
 	u16 tclass, u32 requested,
diff --git a/security/selinux/selinuxfs.c b/security/selinux/selinuxfs.c
index 69c9dcc..17360c9 100644
--- a/security/selinux/selinuxfs.c
+++ b/security/selinux/selinuxfs.c
@@ -589,10 +589,10 @@ static ssize_t sel_write_access(struct file *file, char *buf, size_t size)
 		goto out2;
 
 	length = scnprintf(buf, SIMPLE_TRANSACTION_LIMIT,
-			  "%x %x %x %x %u",
+			  "%x %x %x %x %u %x",
 			  avd.allowed, avd.decided,
 			  avd.auditallow, avd.auditdeny,
-			  avd.seqno);
+			  avd.seqno, avd.flags);
 out2:
 	kfree(tcon);
 out:
diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
index ab0cc0c..a815cfa 100644
--- a/security/selinux/ss/services.c
+++ b/security/selinux/ss/services.c
@@ -411,6 +411,7 @@ static int context_struct_compute_av(struct context *scontext,
 	avd->auditallow = 0;
 	avd->auditdeny = 0xffffffff;
 	avd->seqno = latest_granting;
+	avd->flags = 0;
 
 	/*
 	 * Check for all the invalid cases.
@@ -529,31 +530,6 @@ inval_class:
 	return 0;
 }
 
-/*
- * Given a sid find if the type has the permissive flag set
- */
-int security_permissive_sid(u32 sid)
-{
-	struct context *context;
-	u32 type;
-	int rc;
-
-	read_lock(&policy_rwlock);
-
-	context = sidtab_search(&sidtab, sid);
-	BUG_ON(!context);
-
-	type = context->type;
-	/*
-	 * we are intentionally using type here, not type-1, the 0th bit may
-	 * someday indicate that we are globally setting permissive in policy.
-	 */
-	rc = ebitmap_get_bit(&policydb.permissive_map, type);
-
-	read_unlock(&policy_rwlock);
-	return rc;
-}
-
 static int security_validtrans_handle_fail(struct context *ocontext,
 					   struct context *ncontext,
 					   struct context *tcontext,
@@ -769,6 +745,10 @@ int security_compute_av(u32 ssid,
 
 	rc = context_struct_compute_av(scontext, tcontext, tclass,
 				       requested, avd);
+
+	/* check permissive domain */
+	if (ebitmap_get_bit(&policydb.permissive_map, scontext->type))
+		avd->flags |= AV_FLAGS_PERMISSIVE;
 out:
 	read_unlock(&policy_rwlock);
 	return rc;

Re: typebounds lookup from userspace

[Eamon Walsh]

KaiGai Kohei wrote:
> Joshua Brindle wrote:
>   
>> For symbol labeling purposes for policy access control we need to be able
>>     
>  > to look up symbol hierarchy relationships. I expect we'll do this by exporting
>  > the symbol hierarchy via selinuxfs. Does anyone have suggestions on what that
>  > should look like? Do we want to export additional information on the symbols
>  > at the same time?
>
> I noticed that userspace object manager also need an interface to get metadata
> of types to support permissive domain. Currently, we don't have any interface
> to know what domain should be handled as permissive domain.
>
> If "/selinux/access" can return the 6th value to show whether the given query
> should be handled as permissive domain or not, it helps userspace object managers.
>   

Why does a userspace object manager need to know if a domain is marked
permissive?  That should be hidden behind security_compute_av().


> It is undesirable for me to add a new interface to query whether the given domain
> is permissive or not, because it cannot avoid atomicity matter.
>
> Thanks,
>   


-- 
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: typebounds lookup from userspace

[Stephen Smalley]

On Tue, 2008-10-07 at 13:24 -0400, Eamon Walsh wrote:
> KaiGai Kohei wrote:
> > Joshua Brindle wrote:
> >   
> >> For symbol labeling purposes for policy access control we need to be able
> >>     
> >  > to look up symbol hierarchy relationships. I expect we'll do this by exporting
> >  > the symbol hierarchy via selinuxfs. Does anyone have suggestions on what that
> >  > should look like? Do we want to export additional information on the symbols
> >  > at the same time?
> >
> > I noticed that userspace object manager also need an interface to get metadata
> > of types to support permissive domain. Currently, we don't have any interface
> > to know what domain should be handled as permissive domain.
> >
> > If "/selinux/access" can return the 6th value to show whether the given query
> > should be handled as permissive domain or not, it helps userspace object managers.
> >   
> 
> Why does a userspace object manager need to know if a domain is marked
> permissive?  That should be hidden behind security_compute_av().

It would be hidden behind avc_has_perm() but not behind
security_compute_av().  And as SE-PostgreSQL implements its own variant
of the AVC, it would need that information.
> 
> 
> > It is undesirable for me to add a new interface to query whether the given domain
> > is permissive or not, because it cannot avoid atomicity matter.
> >
> > Thanks,
> >   
> 
> 
-- 
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: typebounds lookup from userspace

[Eamon Walsh]

Eamon Walsh wrote:
> KaiGai Kohei wrote:
>   
>> Joshua Brindle wrote:
>>   
>>     
>>> For symbol labeling purposes for policy access control we need to be able
>>>     
>>>       
>>  > to look up symbol hierarchy relationships. I expect we'll do this by exporting
>>  > the symbol hierarchy via selinuxfs. Does anyone have suggestions on what that
>>  > should look like? Do we want to export additional information on the symbols
>>  > at the same time?
>>
>> I noticed that userspace object manager also need an interface to get metadata
>> of types to support permissive domain. Currently, we don't have any interface
>> to know what domain should be handled as permissive domain.
>>
>> If "/selinux/access" can return the 6th value to show whether the given query
>> should be handled as permissive domain or not, it helps userspace object managers.
>>   
>>     
>
> Why does a userspace object manager need to know if a domain is marked
> permissive?  That should be hidden behind security_compute_av().
>   

Whoops, nevermind.

I looked at the patches and they seem reasonable, but there may be a
compatibility issue with the extra flags thing.  What happens if
libselinux expects it but it's not there?

Also minor nit, making the flags structure field into a bitmap would
eliminate the need for a #define, i.e.   "unsigned long permissive:1"


>   
>> It is undesirable for me to add a new interface to query whether the given domain
>> is permissive or not, because it cannot avoid atomicity matter.
>>
>> Thanks,
>>   
>>     
>
>
>   


-- 
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: typebounds lookup from userspace

[KaiGai Kohei]

Eamon Walsh wrote:
> Eamon Walsh wrote:
>> KaiGai Kohei wrote:
>>   
>>> Joshua Brindle wrote:
>>>   
>>>     
>>>> For symbol labeling purposes for policy access control we need to be able
>>>>     
>>>>       
>>>  > to look up symbol hierarchy relationships. I expect we'll do this by exporting
>>>  > the symbol hierarchy via selinuxfs. Does anyone have suggestions on what that
>>>  > should look like? Do we want to export additional information on the symbols
>>>  > at the same time?
>>>
>>> I noticed that userspace object manager also need an interface to get metadata
>>> of types to support permissive domain. Currently, we don't have any interface
>>> to know what domain should be handled as permissive domain.
>>>
>>> If "/selinux/access" can return the 6th value to show whether the given query
>>> should be handled as permissive domain or not, it helps userspace object managers.
>>>   
>>>     
>> Why does a userspace object manager need to know if a domain is marked
>> permissive?  That should be hidden behind security_compute_av().
>>   
> 
> Whoops, nevermind.
> 
> I looked at the patches and they seem reasonable, but there may be a
> compatibility issue with the extra flags thing.  What happens if
> libselinux expects it but it's not there?

If a binary with libselinux assumes the current av_decision structure
without "flags" member, the newer libselinux set flag bits out of the
current av_decision. It may receive -SIGSEGV. Oops.

One idea is to add a new interface without modification of av_decision, like:

   security_compute_av_flags(....,
                             struct av_decision *avd,
                             unsigned long flags);

> Also minor nit, making the flags structure field into a bitmap would
> eliminate the need for a #define, i.e.   "unsigned long permissive:1"

If we keep the definition of av_decision, the #define is also necessary.

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

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