object class discovery userland

object class discovery userland

[Christopher J. PeBenito]

I have nearly completed the kernel patch for object class discovery
which creates the structure:

/selinux/class/CLASSNAME/index
/selinux/class/CLASSNAME/perms/PERMNAME

so you get the class index number from the index file, and the
permission name file gets the index number of the permission.  I started
looking at the userland side of this, and there are some relevant
functions:

security_class_t string_to_security_class(const char *name);
const char *security_class_to_string(security_class_t cls);

access_vector_t string_to_av_perm(security_class_t tclass, const char *name);
const char *security_av_perm_to_string(security_class_t tclass, access_vector_t perm);

The implementation for the first one is straightforward, just look at
the index file for the class.  The other three are a little more
problematic with the above structure since they use an index, since it
would have to search through the CLASSNAME/index files to find the right
one.

So to get the reverse lookup we could:
1. search /selinux/class/ in the userland code
2. create symlinks /selinux/class, one possible structure:

/selinux/class/1 -> security
/selinux/class/2 -> process
/selinux/class/security/perms/1 -> compute_av
/selinux/class/security/perms/2 -> compute_create

3. stop exporting class and perm indexes outside of the libraries.  Then
the reverse lookup wouldn't be needed.  This would involve some
overhauling of the libraries.

4. other ideas?

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
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: object class discovery userland

[Joshua Brindle]

> From: Christopher J. PeBenito 
> 
> I have nearly completed the kernel patch for object class 
> discovery which creates the structure:
> 
> /selinux/class/CLASSNAME/index
> /selinux/class/CLASSNAME/perms/PERMNAME
> 
> so you get the class index number from the index file, and 
> the permission name file gets the index number of the 
> permission.  I started looking at the userland side of this, 
> and there are some relevant
> functions:
> 
> security_class_t string_to_security_class(const char *name); 
> const char *security_class_to_string(security_class_t cls);
> 
> access_vector_t string_to_av_perm(security_class_t tclass, 
> const char *name); const char 
> *security_av_perm_to_string(security_class_t tclass, 
> access_vector_t perm);
> 
> The implementation for the first one is straightforward, just 
> look at the index file for the class.  The other three are a 
> little more problematic with the above structure since they 
> use an index, since it would have to search through the 
> CLASSNAME/index files to find the right one.
> 
> So to get the reverse lookup we could:
> 1. search /selinux/class/ in the userland code 2. create 
> symlinks /selinux/class, one possible structure:
> 
> /selinux/class/1 -> security
> /selinux/class/2 -> process
> /selinux/class/security/perms/1 -> compute_av
> /selinux/class/security/perms/2 -> compute_create
> 
> 3. stop exporting class and perm indexes outside of the 
> libraries.  Then the reverse lookup wouldn't be needed.  This 
> would involve some overhauling of the libraries.
> 
> 4. other ideas?
> 

I think we should do the symlink thing to support the current interfaces
but mark them as deprecated and implement a new string based API. Then
work on getting all the object managers switched over to the string API
and eventually deprecate the userspace side and remove the symlinks.


--
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: object class discovery userland

[Karl MacMillan]

On Fri, 2007-04-20 at 10:04 -0400, Joshua Brindle wrote:
> > From: Christopher J. PeBenito 
> > 
> > I have nearly completed the kernel patch for object class 
> > discovery which creates the structure:
> > 
> > /selinux/class/CLASSNAME/index
> > /selinux/class/CLASSNAME/perms/PERMNAME
> > 
> > so you get the class index number from the index file, and 
> > the permission name file gets the index number of the 
> > permission.  I started looking at the userland side of this, 
> > and there are some relevant
> > functions:
> > 
> > security_class_t string_to_security_class(const char *name); 
> > const char *security_class_to_string(security_class_t cls);
> > 
> > access_vector_t string_to_av_perm(security_class_t tclass, 
> > const char *name); const char 
> > *security_av_perm_to_string(security_class_t tclass, 
> > access_vector_t perm);
> > 
> > The implementation for the first one is straightforward, just 
> > look at the index file for the class.  The other three are a 
> > little more problematic with the above structure since they 
> > use an index, since it would have to search through the 
> > CLASSNAME/index files to find the right one.
> > 
> > So to get the reverse lookup we could:
> > 1. search /selinux/class/ in the userland code 2. create 
> > symlinks /selinux/class, one possible structure:
> > 
> > /selinux/class/1 -> security
> > /selinux/class/2 -> process
> > /selinux/class/security/perms/1 -> compute_av
> > /selinux/class/security/perms/2 -> compute_create
> > 
> > 3. stop exporting class and perm indexes outside of the 
> > libraries.  Then the reverse lookup wouldn't be needed.  This 
> > would involve some overhauling of the libraries.
> > 
> > 4. other ideas?
> > 
> 
> I think we should do the symlink thing to support the current interfaces
> but mark them as deprecated and implement a new string based API. Then
> work on getting all the object managers switched over to the string API
> and eventually deprecate the userspace side and remove the symlinks.
> 

If it is deprecated then why do the symlinks? It is only an optimization
and libselinux can cache the mappings after the first lookup. The
symlinks also complicate the code to do string lookup (because they have
to ignore the numeric nodes).

Karl


--
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: object class discovery userland

[Joshua Brindle]

> From: Karl MacMillan [mailto:kmacmillan@mentalrootkit.com] 
> 
> On Fri, 2007-04-20 at 10:04 -0400, Joshua Brindle wrote:
> > > From: Christopher J. PeBenito
> > > 
> > > I have nearly completed the kernel patch for object class 
> discovery 
> > > which creates the structure:
> > > 
> > > /selinux/class/CLASSNAME/index
> > > /selinux/class/CLASSNAME/perms/PERMNAME
> > > 
> > > so you get the class index number from the index file, and the 
> > > permission name file gets the index number of the permission.  I 
> > > started looking at the userland side of this, and there are some 
> > > relevant
> > > functions:
> > > 
> > > security_class_t string_to_security_class(const char 
> *name); const 
> > > char *security_class_to_string(security_class_t cls);
> > > 
> > > access_vector_t string_to_av_perm(security_class_t tclass, const 
> > > char *name); const char 
> *security_av_perm_to_string(security_class_t 
> > > tclass, access_vector_t perm);
> > > 
> > > The implementation for the first one is straightforward, 
> just look 
> > > at the index file for the class.  The other three are a 
> little more 
> > > problematic with the above structure since they use an 
> index, since 
> > > it would have to search through the CLASSNAME/index files to find 
> > > the right one.
> > > 
> > > So to get the reverse lookup we could:
> > > 1. search /selinux/class/ in the userland code 2. create symlinks 
> > > /selinux/class, one possible structure:
> > > 
> > > /selinux/class/1 -> security
> > > /selinux/class/2 -> process
> > > /selinux/class/security/perms/1 -> compute_av
> > > /selinux/class/security/perms/2 -> compute_create
> > > 
> > > 3. stop exporting class and perm indexes outside of the 
> libraries.  
> > > Then the reverse lookup wouldn't be needed.  This would 
> involve some 
> > > overhauling of the libraries.
> > > 
> > > 4. other ideas?
> > > 
> > 
> > I think we should do the symlink thing to support the current 
> > interfaces but mark them as deprecated and implement a new string 
> > based API. Then work on getting all the object managers 
> switched over 
> > to the string API and eventually deprecate the userspace 
> side and remove the symlinks.
> > 
> 
> If it is deprecated then why do the symlinks? It is only an 
> optimization and libselinux can cache the mappings after the 
> first lookup. The symlinks also complicate the code to do 
> string lookup (because they have to ignore the numeric nodes).
> 

The lookup is done by opening %s/perm/%s,class,perm just like the other
libselinux code, not by traversing the directory structure so there is
no complication or ignoring the numeric nodes.


--
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: object class discovery userland

[Karl MacMillan]

On Fri, 2007-04-20 at 10:23 -0400, Joshua Brindle wrote:
> > From: Karl MacMillan [mailto:kmacmillan@mentalrootkit.com] 
> > 
> > On Fri, 2007-04-20 at 10:04 -0400, Joshua Brindle wrote:
> > > > From: Christopher J. PeBenito
> > > > 
> > > > I have nearly completed the kernel patch for object class 
> > discovery 
> > > > which creates the structure:
> > > > 
> > > > /selinux/class/CLASSNAME/index
> > > > /selinux/class/CLASSNAME/perms/PERMNAME
> > > > 
> > > > so you get the class index number from the index file, and the 
> > > > permission name file gets the index number of the permission.  I 
> > > > started looking at the userland side of this, and there are some 
> > > > relevant
> > > > functions:
> > > > 
> > > > security_class_t string_to_security_class(const char 
> > *name); const 
> > > > char *security_class_to_string(security_class_t cls);
> > > > 
> > > > access_vector_t string_to_av_perm(security_class_t tclass, const 
> > > > char *name); const char 
> > *security_av_perm_to_string(security_class_t 
> > > > tclass, access_vector_t perm);
> > > > 
> > > > The implementation for the first one is straightforward, 
> > just look 
> > > > at the index file for the class.  The other three are a 
> > little more 
> > > > problematic with the above structure since they use an 
> > index, since 
> > > > it would have to search through the CLASSNAME/index files to find 
> > > > the right one.
> > > > 
> > > > So to get the reverse lookup we could:
> > > > 1. search /selinux/class/ in the userland code 2. create symlinks 
> > > > /selinux/class, one possible structure:
> > > > 
> > > > /selinux/class/1 -> security
> > > > /selinux/class/2 -> process
> > > > /selinux/class/security/perms/1 -> compute_av
> > > > /selinux/class/security/perms/2 -> compute_create
> > > > 
> > > > 3. stop exporting class and perm indexes outside of the 
> > libraries.  
> > > > Then the reverse lookup wouldn't be needed.  This would 
> > involve some 
> > > > overhauling of the libraries.
> > > > 
> > > > 4. other ideas?
> > > > 
> > > 
> > > I think we should do the symlink thing to support the current 
> > > interfaces but mark them as deprecated and implement a new string 
> > > based API. Then work on getting all the object managers 
> > switched over 
> > > to the string API and eventually deprecate the userspace 
> > side and remove the symlinks.
> > > 
> > 
> > If it is deprecated then why do the symlinks? It is only an 
> > optimization and libselinux can cache the mappings after the 
> > first lookup. The symlinks also complicate the code to do 
> > string lookup (because they have to ignore the numeric nodes).
> > 
> 
> The lookup is done by opening %s/perm/%s,class,perm just like the other
> libselinux code, not by traversing the directory structure so there is
> no complication or ignoring the numeric nodes.

What happens if I ask for a perm called "1"?

Karl


--
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: object class discovery userland

[Joshua Brindle]

> From: Karl MacMillan [mailto:kmacmillan@mentalrootkit.com] 
> 
> On Fri, 2007-04-20 at 10:23 -0400, Joshua Brindle wrote:
> > > From: Karl MacMillan [mailto:kmacmillan@mentalrootkit.com]
> > > 
> > > On Fri, 2007-04-20 at 10:04 -0400, Joshua Brindle wrote:
> > > > > From: Christopher J. PeBenito
> > > > > 
> > > > > I have nearly completed the kernel patch for object class
> > > discovery
> > > > > which creates the structure:
> > > > > 
> > > > > /selinux/class/CLASSNAME/index
> > > > > /selinux/class/CLASSNAME/perms/PERMNAME
> > > > > 
> > > > > so you get the class index number from the index 
> file, and the 
> > > > > permission name file gets the index number of the 
> permission.  I 
> > > > > started looking at the userland side of this, and 
> there are some 
> > > > > relevant
> > > > > functions:
> > > > > 
> > > > > security_class_t string_to_security_class(const char
> > > *name); const
> > > > > char *security_class_to_string(security_class_t cls);
> > > > > 
> > > > > access_vector_t string_to_av_perm(security_class_t 
> tclass, const 
> > > > > char *name); const char
> > > *security_av_perm_to_string(security_class_t
> > > > > tclass, access_vector_t perm);
> > > > > 
> > > > > The implementation for the first one is straightforward,
> > > just look
> > > > > at the index file for the class.  The other three are a
> > > little more
> > > > > problematic with the above structure since they use an
> > > index, since
> > > > > it would have to search through the CLASSNAME/index files to 
> > > > > find the right one.
> > > > > 
> > > > > So to get the reverse lookup we could:
> > > > > 1. search /selinux/class/ in the userland code 2. create 
> > > > > symlinks /selinux/class, one possible structure:
> > > > > 
> > > > > /selinux/class/1 -> security
> > > > > /selinux/class/2 -> process
> > > > > /selinux/class/security/perms/1 -> compute_av
> > > > > /selinux/class/security/perms/2 -> compute_create
> > > > > 
> > > > > 3. stop exporting class and perm indexes outside of the
> > > libraries.  
> > > > > Then the reverse lookup wouldn't be needed.  This would
> > > involve some
> > > > > overhauling of the libraries.
> > > > > 
> > > > > 4. other ideas?
> > > > > 
> > > > 
> > > > I think we should do the symlink thing to support the current 
> > > > interfaces but mark them as deprecated and implement a 
> new string 
> > > > based API. Then work on getting all the object managers
> > > switched over
> > > > to the string API and eventually deprecate the userspace
> > > side and remove the symlinks.
> > > > 
> > > 
> > > If it is deprecated then why do the symlinks? It is only an 
> > > optimization and libselinux can cache the mappings after 
> the first 
> > > lookup. The symlinks also complicate the code to do string lookup 
> > > (because they have to ignore the numeric nodes).
> > > 
> > 
> > The lookup is done by opening %s/perm/%s,class,perm just like the 
> > other libselinux code, not by traversing the directory structure so 
> > there is no complication or ignoring the numeric nodes.
> 
> What happens if I ask for a perm called "1"?
> 

How does that make the code more complex? That's a programming error,
not something we have to safeguard against.


--
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: object class discovery userland

[KaiGai Kohei]

Christopher J. PeBenito wrote:
> I have nearly completed the kernel patch for object class discovery
> which creates the structure:
> 
> /selinux/class/CLASSNAME/index
> /selinux/class/CLASSNAME/perms/PERMNAME
> 
> so you get the class index number from the index file, and the
> permission name file gets the index number of the permission.  I started
> looking at the userland side of this, and there are some relevant
> functions:
> 
> security_class_t string_to_security_class(const char *name);
> const char *security_class_to_string(security_class_t cls);
> 
> access_vector_t string_to_av_perm(security_class_t tclass, const char *name);
> const char *security_av_perm_to_string(security_class_t tclass, access_vector_t perm);
> 
> The implementation for the first one is straightforward, just look at
> the index file for the class.  The other three are a little more
> problematic with the above structure since they use an index, since it
> would have to search through the CLASSNAME/index files to find the right
> one.
> 
> So to get the reverse lookup we could:
> 1. search /selinux/class/ in the userland code
> 2. create symlinks /selinux/class, one possible structure:
> 
> /selinux/class/1 -> security
> /selinux/class/2 -> process
> /selinux/class/security/perms/1 -> compute_av
> /selinux/class/security/perms/2 -> compute_create
> 
> 3. stop exporting class and perm indexes outside of the libraries.  Then
> the reverse lookup wouldn't be needed.  This would involve some
> overhauling of the libraries.
> 
> 4. other ideas?

Chris,

I really wanted the kernel/userland interface to obtain object classes and
permissions number.

BTW, what is the reason for 1:1 mapping between PERMNAME entry and permission number?
For example, if /selinux/class/index provides the pair of object class number/name
and /selinux/class/CLASSNAME provides the pair of permission number/name, we can
obtain them with simple iterations of fscanf("%u %s", ...).

We maybe cache them in userland until the security policy reloaded.
I think it's not necessary to handle easily on the filesystem structure.

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

--
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: object class discovery userland

[Christopher J. PeBenito]

On Fri, 2007-04-20 at 23:58 +0900, KaiGai Kohei wrote:
> Christopher J. PeBenito wrote:
> > I have nearly completed the kernel patch for object class discovery
> > which creates the structure:
> > 
> > /selinux/class/CLASSNAME/index
> > /selinux/class/CLASSNAME/perms/PERMNAME
> > 
> > so you get the class index number from the index file, and the
> > permission name file gets the index number of the permission.

> I really wanted the kernel/userland interface to obtain object classes and
> permissions number.
> 
> BTW, what is the reason for 1:1 mapping between PERMNAME entry and permission number?
> For example, if /selinux/class/index provides the pair of object class number/name
> and /selinux/class/CLASSNAME provides the pair of permission number/name, we can
> obtain them with simple iterations of fscanf("%u %s", ...).

See http://marc.info/?l=selinux&m=117580309612610&w=2

> We maybe cache them in userland until the security policy reloaded.

Class and permission indexes aren't really used outside of userspace
object managers.  I'd expect object managers to do this for the classes
they care about, for themselves.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
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: object class discovery userland

[Eamon Walsh]

Christopher J. PeBenito wrote:
> 3. stop exporting class and perm indexes outside of the libraries.  Then
> the reverse lookup wouldn't be needed.  This would involve some
> overhauling of the libraries.

I don't think this is a good idea because of the disruption it would 
cause with access vector processing (as passed to security_av_string() 
and avc_has_perm()).  How do you or together strings?

Why not just cache the numbers in the library, as Karl suggested, or 
create a parallel "class_num" or "class_index" directory with numeric 
nodes (perhaps renaming class to class_name).

class_num/perms/1
class_num/name


-- 
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: object class discovery userland

[Eamon Walsh]

Eamon Walsh wrote:
> Christopher J. PeBenito wrote:
>> 3. stop exporting class and perm indexes outside of the libraries.  Then
>> the reverse lookup wouldn't be needed.  This would involve some
>> overhauling of the libraries.
> 
> I don't think this is a good idea because of the disruption it would 
> cause with access vector processing (as passed to security_av_string() 
> and avc_has_perm()).  How do you or together strings?
> 
> Why not just cache the numbers in the library, as Karl suggested, or 
> create a parallel "class_num" or "class_index" directory with numeric 
> nodes (perhaps renaming class to class_name).
> 
> class_num/perms/1
> class_num/name
> 
> 

Sorry,
class_num/1/perms/1
class_num/1/name

-- 
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: object class discovery userland

[Christopher J. PeBenito]

On Fri, 2007-04-20 at 13:02 -0400, Eamon Walsh wrote:
> Eamon Walsh wrote:
> > Christopher J. PeBenito wrote:
> >> 3. stop exporting class and perm indexes outside of the libraries.  Then
> >> the reverse lookup wouldn't be needed.  This would involve some
> >> overhauling of the libraries.
> > 
> > I don't think this is a good idea because of the disruption it would 
> > cause with access vector processing (as passed to security_av_string() 
> > and avc_has_perm()).  How do you or together strings?
> > 
> > Why not just cache the numbers in the library, as Karl suggested, or 
> > create a parallel "class_num" or "class_index" directory with numeric 
> > nodes (perhaps renaming class to class_name).
> > 
> class_num/1/perms/1
> class_num/1/name

I don't feel strongly about any of my suggestions, I mainly wanted to
get the discussion going.  The inspiration for symlink idea was from all
the symlinking you see in sysfs, but the above structure certainly is an
option too.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
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: object class discovery userland

[Stephen Smalley]

On Fri, 2007-04-20 at 13:19 -0400, Christopher J. PeBenito wrote:
> On Fri, 2007-04-20 at 13:02 -0400, Eamon Walsh wrote:
> > Eamon Walsh wrote:
> > > Christopher J. PeBenito wrote:
> > >> 3. stop exporting class and perm indexes outside of the libraries.  Then
> > >> the reverse lookup wouldn't be needed.  This would involve some
> > >> overhauling of the libraries.
> > > 
> > > I don't think this is a good idea because of the disruption it would 
> > > cause with access vector processing (as passed to security_av_string() 
> > > and avc_has_perm()).  How do you or together strings?
> > > 
> > > Why not just cache the numbers in the library, as Karl suggested, or 
> > > create a parallel "class_num" or "class_index" directory with numeric 
> > > nodes (perhaps renaming class to class_name).
> > > 
> > class_num/1/perms/1
> > class_num/1/name
> 
> I don't feel strongly about any of my suggestions, I mainly wanted to
> get the discussion going.  The inspiration for symlink idea was from all
> the symlinking you see in sysfs, but the above structure certainly is an
> option too.

I'd recommend caching in the library and doing the reverse lookup there
rather than encoding it into the pseudo filesystem state.

-- 
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: object class discovery userland

[Joshua Brindle]

> From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
> 
> On Fri, 2007-04-20 at 13:19 -0400, Christopher J. PeBenito wrote:
> > On Fri, 2007-04-20 at 13:02 -0400, Eamon Walsh wrote:
> > > Eamon Walsh wrote:
> > > > Christopher J. PeBenito wrote:
> > > >> 3. stop exporting class and perm indexes outside of the 
> > > >> libraries.  Then the reverse lookup wouldn't be needed.  This 
> > > >> would involve some overhauling of the libraries.
> > > > 
> > > > I don't think this is a good idea because of the disruption it 
> > > > would cause with access vector processing (as passed to 
> > > > security_av_string() and avc_has_perm()).  How do you 
> or together strings?
> > > > 
> > > > Why not just cache the numbers in the library, as Karl 
> suggested, 
> > > > or create a parallel "class_num" or "class_index" 
> directory with 
> > > > numeric nodes (perhaps renaming class to class_name).
> > > > 
> > > class_num/1/perms/1
> > > class_num/1/name
> > 
> > I don't feel strongly about any of my suggestions, I mainly 
> wanted to 
> > get the discussion going.  The inspiration for symlink idea 
> was from 
> > all the symlinking you see in sysfs, but the above 
> structure certainly 
> > is an option too.
> 
> I'd recommend caching in the library and doing the reverse 
> lookup there rather than encoding it into the pseudo filesystem state.

Making the library open and cache every class and permission seems
undesirable. What do you have against doing it from the filesystem?


--
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: object class discovery userland

[Stephen Smalley]

On Mon, 2007-04-23 at 10:43 -0400, Joshua Brindle wrote:
> > From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
> > 
> > On Fri, 2007-04-20 at 13:19 -0400, Christopher J. PeBenito wrote:
> > > On Fri, 2007-04-20 at 13:02 -0400, Eamon Walsh wrote:
> > > > Eamon Walsh wrote:
> > > > > Christopher J. PeBenito wrote:
> > > > >> 3. stop exporting class and perm indexes outside of the 
> > > > >> libraries.  Then the reverse lookup wouldn't be needed.  This 
> > > > >> would involve some overhauling of the libraries.
> > > > > 
> > > > > I don't think this is a good idea because of the disruption it 
> > > > > would cause with access vector processing (as passed to 
> > > > > security_av_string() and avc_has_perm()).  How do you 
> > or together strings?
> > > > > 
> > > > > Why not just cache the numbers in the library, as Karl 
> > suggested, 
> > > > > or create a parallel "class_num" or "class_index" 
> > directory with 
> > > > > numeric nodes (perhaps renaming class to class_name).
> > > > > 
> > > > class_num/1/perms/1
> > > > class_num/1/name
> > > 
> > > I don't feel strongly about any of my suggestions, I mainly 
> > wanted to 
> > > get the discussion going.  The inspiration for symlink idea 
> > was from 
> > > all the symlinking you see in sysfs, but the above 
> > structure certainly 
> > > is an option too.
> > 
> > I'd recommend caching in the library and doing the reverse 
> > lookup there rather than encoding it into the pseudo filesystem state.
> 
> Making the library open and cache every class and permission seems
> undesirable. What do you have against doing it from the filesystem?

You don't have to cache them all - the cache can be populated lazily
(but I'd expect it to pull in an entire class at a time).

I'm not keen on having redundant information in the filesystem state,
and I don't think these operations are on the critical path anyway for
performance.

-- 
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: object class discovery userland

[Christopher J. PeBenito]

On Mon, 2007-04-23 at 10:58 -0400, Stephen Smalley wrote:
> On Mon, 2007-04-23 at 10:43 -0400, Joshua Brindle wrote:
> > > From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
> > > 
> > > On Fri, 2007-04-20 at 13:19 -0400, Christopher J. PeBenito wrote:
> > > > On Fri, 2007-04-20 at 13:02 -0400, Eamon Walsh wrote:
> > > > > Eamon Walsh wrote:
> > > > > > Christopher J. PeBenito wrote:
> > > > > >> 3. stop exporting class and perm indexes outside of the 
> > > > > >> libraries.  Then the reverse lookup wouldn't be needed.  This 
> > > > > >> would involve some overhauling of the libraries.
> > > > > > 
> > > > > > I don't think this is a good idea because of the disruption it 
> > > > > > would cause with access vector processing (as passed to 
> > > > > > security_av_string() and avc_has_perm()).  How do you 
> > > or together strings?
> > > > > > 
> > > > > > Why not just cache the numbers in the library, as Karl 
> > > suggested, 
> > > > > > or create a parallel "class_num" or "class_index" 
> > > directory with 
> > > > > > numeric nodes (perhaps renaming class to class_name).
> > > > > > 
> > > > > class_num/1/perms/1
> > > > > class_num/1/name
> > > > 
> > > > I don't feel strongly about any of my suggestions, I mainly 
> > > wanted to 
> > > > get the discussion going.  The inspiration for symlink idea 
> > > was from 
> > > > all the symlinking you see in sysfs, but the above 
> > > structure certainly 
> > > > is an option too.
> > > 
> > > I'd recommend caching in the library and doing the reverse 
> > > lookup there rather than encoding it into the pseudo filesystem state.
> > 
> > Making the library open and cache every class and permission seems
> > undesirable. What do you have against doing it from the filesystem?
> 
> You don't have to cache them all - the cache can be populated lazily
> (but I'd expect it to pull in an entire class at a time).
> 
> I'm not keen on having redundant information in the filesystem state,
> and I don't think these operations are on the critical path anyway for
> performance.

One issue that we realized on this is that the cache is going to have to
be flushed when the policy is reloaded.  For object managers that have a
full AVC that is simple, since we can just add it to the netlink socket
handler where it resets the AVC.

However, for simple ones such as passwd and crond which, don't need an
AVC, there isn't a facility now.  Crond should be ok since it only
checks process permissions, which can't change on policy reload.
Perhaps a lighter version of the netlink support that just listens for
policy reloads?

The object manager will also have to be modified to get the new class
and perm values on a policy reload.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
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: object class discovery userland

[Eamon Walsh]

Christopher J. PeBenito wrote:
> On Mon, 2007-04-23 at 10:58 -0400, Stephen Smalley wrote:
>> On Mon, 2007-04-23 at 10:43 -0400, Joshua Brindle wrote:
>>>> From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
>>>>
>>>> On Fri, 2007-04-20 at 13:19 -0400, Christopher J. PeBenito wrote:
>>>>> On Fri, 2007-04-20 at 13:02 -0400, Eamon Walsh wrote:
>>>>>> Eamon Walsh wrote:
>>>>>>> Christopher J. PeBenito wrote:
>>>>>>>> 3. stop exporting class and perm indexes outside of the 
>>>>>>>> libraries.  Then the reverse lookup wouldn't be needed.  This 
>>>>>>>> would involve some overhauling of the libraries.
>>>>>>> I don't think this is a good idea because of the disruption it 
>>>>>>> would cause with access vector processing (as passed to 
>>>>>>> security_av_string() and avc_has_perm()).  How do you 
>>>> or together strings?
>>>>>>> Why not just cache the numbers in the library, as Karl 
>>>> suggested, 
>>>>>>> or create a parallel "class_num" or "class_index" 
>>>> directory with 
>>>>>>> numeric nodes (perhaps renaming class to class_name).
>>>>>>>
>>>>>> class_num/1/perms/1
>>>>>> class_num/1/name
>>>>> I don't feel strongly about any of my suggestions, I mainly 
>>>> wanted to 
>>>>> get the discussion going.  The inspiration for symlink idea 
>>>> was from 
>>>>> all the symlinking you see in sysfs, but the above 
>>>> structure certainly 
>>>>> is an option too.
>>>> I'd recommend caching in the library and doing the reverse 
>>>> lookup there rather than encoding it into the pseudo filesystem state.
>>> Making the library open and cache every class and permission seems
>>> undesirable. What do you have against doing it from the filesystem?
>> You don't have to cache them all - the cache can be populated lazily
>> (but I'd expect it to pull in an entire class at a time).
>>
>> I'm not keen on having redundant information in the filesystem state,
>> and I don't think these operations are on the critical path anyway for
>> performance.
> 
> One issue that we realized on this is that the cache is going to have to
> be flushed when the policy is reloaded.  For object managers that have a
> full AVC that is simple, since we can just add it to the netlink socket
> handler where it resets the AVC.
> 
> However, for simple ones such as passwd and crond which, don't need an
> AVC, there isn't a facility now.  Crond should be ok since it only
> checks process permissions, which can't change on policy reload.
> Perhaps a lighter version of the netlink support that just listens for
> policy reloads?

We could require a call to avc_init() for anyone wishing to do lookups. 
  An empty AVC shouldn't affect performance that much.

The netlink stuff is all in src/avc_internal.c.  There are two copies of 
the netlink code, one for threaded and one for unthreaded.  Maybe they 
could be refactored down to a single function used by both.


> 
> The object manager will also have to be modified to get the new class
> and perm values on a policy reload.
> 

Sigh.  Maybe we _would_ be better off hiding the numeric values from the 
caller.


-- 
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: object class discovery userland

[Eamon Walsh]

Eamon Walsh wrote:
> Christopher J. PeBenito wrote:
>> The object manager will also have to be modified to get the new class
>> and perm values on a policy reload.
>>
> 
> Sigh.  Maybe we _would_ be better off hiding the numeric values from the 
> caller.
> 

Maybe instead of just looking up class and permission values, object 
managers should be able to give libselinux a mapping from strings to 
numbers.

For example, the X server could pass something like

{"xwindow", 1}

at startup time.  Then libselinux would internally convert 1 to the real 
class value for xwindow, keeping track of any changes resulting from 
reloads.

The object managers are all going to have to do something like this 
anyway.  Doing it in the library could improve performance for AVC 
lookups, since the AVC entries could be keyed off the untranslated numbers.


-- 
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: object class discovery userland

[Joshua Brindle]

Eamon Walsh wrote:
> Eamon Walsh wrote:
>> Christopher J. PeBenito wrote:
>>> The object manager will also have to be modified to get the new
>>> class and perm values on a policy reload.
>>> 
>> 
>> Sigh.  Maybe we _would_ be better off hiding the numeric values from
>> the caller. 
>> 
> 
> Maybe instead of just looking up class and permission values,
> object managers should be able to give libselinux a mapping from
> strings to numbers. 
> 
> For example, the X server could pass something like
> 
> {"xwindow", 1}
> 
> at startup time.  Then libselinux would internally convert 1
> to the real class value for xwindow, keeping track of any
> changes resulting from reloads.
> 
> The object managers are all going to have to do something
> like this anyway.  Doing it in the library could improve
> performance for AVC lookups, since the AVC entries could be
> keyed off the untranslated numbers.

This is interesting.. Then if the permission doesn't exist it would just
naturally be denied (or the library could respect the configuration if
there is such a thing) instead of the users being special cased. One
thing is that the avc remaps with permissions will be painful though.


--
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: object class discovery userland

[Joshua Brindle]

Eamon Walsh wrote:
> Eamon Walsh wrote:
>> Christopher J. PeBenito wrote:
>>> The object manager will also have to be modified to get the new
>>> class and perm values on a policy reload.
>>> 
>> 
>> Sigh.  Maybe we _would_ be better off hiding the numeric values from
>> the caller. 
>> 
> 
> Maybe instead of just looking up class and permission values,
> object managers should be able to give libselinux a mapping from
> strings to numbers. 
> 
> For example, the X server could pass something like
> 
> {"xwindow", 1}
> 
> at startup time.  Then libselinux would internally convert 1
> to the real class value for xwindow, keeping track of any
> changes resulting from reloads.
> 
> The object managers are all going to have to do something
> like this anyway.  Doing it in the library could improve
> performance for AVC lookups, since the AVC entries could be
> keyed off the untranslated numbers.

One other thing, this seems like a nicer way to migrate existing users
since they are already using static defines they can just pass in what
they already have, eg:

In private_flask.h
#define SECCLASS_WINDOW 32

And then:
{"xwindow", SECCLASS_WINDOW}

And then change #include <flask.h> to #include "private_flask.h" and the
calls don't have to be changed.


--
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: object class discovery userland

[Eamon Walsh]

Here's a first go at an interface.  It's an init function that is a
replacement for avc_init().  It takes flags, the class/permission
mapping to use, and callback functions.

This is trying to solve a few other problems at the same time, namely:

- selinux prefix on the function name
- drops support for memory, threading, and locking callbacks (would just
always use malloc and pthread)
- adds type code to logging callback

---

 selinux.h |   37 +++++++++++++++++++++++++++++++++++++
 1 file changed, 37 insertions(+)


Index: libselinux/include/selinux/selinux.h
===================================================================
--- libselinux/include/selinux/selinux.h	(revision 2445)
+++ libselinux/include/selinux/selinux.h	(working copy)
@@ -132,6 +132,43 @@
 		unsigned int seqno;
 	};
 
+	struct av_mapping {
+		const char *name;
+		const access_vector_t value;
+	};
+
+	struct security_class_mapping {
+		const char *name;
+		const security_class_t value;
+		const struct av_mapping *perms;
+	};
+
+/* Initialization routine for caching functions offered by the library */
+
+	struct selinux_callbacks {
+		/* log the printf-style format and arguments,
+		   with the type code indicating the type of message */
+		int (*func_log) (int type, const char *fmt, ...);
+		/* store a string representation of auditdata (corresponding
+		   to the given security class) into msgbuf. */
+		void (*func_audit) (void *auditdata, security_class_t cls,
+				    char *msgbuf, size_t msgbufsize);
+	};
+
+	extern int selinux_init(int flags,
+				const struct security_class_mapping *map,
+				const struct selinux_callbacks *callbacks);
+
+        /* Available flags */
+#define SELINUX_THREAD          1
+#define SELINUX_AVC             2
+
+        /* Logging type codes, passed to the logging callback */
+#define SELINUX_ERROR	        0
+#define SELINUX_WARNING		1
+#define SELINUX_INFO		2
+#define SELINUX_AVC_DENIAL	3
+
 /* Compute an access decision. */
 	extern int security_compute_av(security_context_t scon,
 				       security_context_t tcon,


-- 
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: object class discovery userland

[Joshua Brindle]

Eamon Walsh wrote:
> Here's a first go at an interface.  It's an init function
> that is a replacement for avc_init().  It takes flags, the
> class/permission mapping to use, and callback functions.
> 
> This is trying to solve a few other problems at the same time, namely:
> 
> - selinux prefix on the function name

So the client callsites will have to change then, oh well, we wanted to
do this anyway..

> - drops support for memory, threading, and locking callbacks
> (would just always use malloc and pthread)

Were these ever used or were they a remnant of the early
implementations?

> - adds type code to logging callback
> 
> ---
> 
>  selinux.h |   37 +++++++++++++++++++++++++++++++++++++
>  1 file changed, 37 insertions(+)
> 
> 
> Index: libselinux/include/selinux/selinux.h
> ===================================================================
> --- libselinux/include/selinux/selinux.h	(revision 2445)
> +++ libselinux/include/selinux/selinux.h	(working copy) @@ -132,6
>  		+132,43 @@ unsigned int seqno;
>  	};
> 
> +	struct av_mapping {
> +		const char *name;
> +		const access_vector_t value;
> +	};
> +

Should this be a linked list?

> +	struct security_class_mapping {
> +		const char *name;
> +		const security_class_t value;
> +		const struct av_mapping *perms;
> +	};
> +
> +/* Initialization routine for caching functions offered by
> the library
> +*/
> +
> +	struct selinux_callbacks {
> +		/* log the printf-style format and arguments,
> +		   with the type code indicating the type of message */
> +		int (*func_log) (int type, const char *fmt, ...);
> +		/* store a string representation of auditdata
> (corresponding
> +		   to the given security class) into msgbuf. */
> +		void (*func_audit) (void *auditdata,
> security_class_t cls,
> +				    char *msgbuf, size_t msgbufsize);
> +	};
> +
> +	extern int selinux_init(int flags,
> +				const struct
> security_class_mapping *map,
> +				const struct selinux_callbacks
> *callbacks);
> +

Shouldn't the security_class_mapping either be an array here or be a
linked list above?

> +        /* Available flags */
> +#define SELINUX_THREAD          1
> +#define SELINUX_AVC             2
> +
> +        /* Logging type codes, passed to the logging callback */
> +#define SELINUX_ERROR	        0
> +#define SELINUX_WARNING		1
> +#define SELINUX_INFO		2
> +#define SELINUX_AVC_DENIAL	3
> +
>  /* Compute an access decision. */
>  	extern int security_compute_av(security_context_t scon,
>  				       security_context_t tcon,



--
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: object class discovery userland

[Eamon Walsh]

Joshua Brindle wrote:
> Eamon Walsh wrote:
>> Here's a first go at an interface.  It's an init function
>> that is a replacement for avc_init().  It takes flags, the
>> class/permission mapping to use, and callback functions.
>>
>> This is trying to solve a few other problems at the same time, namely:
>>
>> - selinux prefix on the function name
> 
> So the client callsites will have to change then, oh well, we wanted to
> do this anyway..

Well, the old avc_init() could be kept around for awhile.  Calling it 
would still work, it just wouldn't have a mapping (would treat incoming 
class/perm values literally).

> 
>> - drops support for memory, threading, and locking callbacks
>> (would just always use malloc and pthread)
> 
> Were these ever used or were they a remnant of the early
> implementations?

I'm not aware of any users of them.  I put them in basically because the 
X server wrapped malloc ("Xalloc"), glib has malloc wrappers and so 
forth.  But the X people are moving away from this and back to straight 
malloc.  I've come around to the belief that this is better done through 
the linker with private functions.


>> - adds type code to logging callback
>>
>> ---
>>
>>  selinux.h |   37 +++++++++++++++++++++++++++++++++++++
>>  1 file changed, 37 insertions(+)
>>
>>
>> Index: libselinux/include/selinux/selinux.h
>> ===================================================================
>> --- libselinux/include/selinux/selinux.h	(revision 2445)
>> +++ libselinux/include/selinux/selinux.h	(working copy) @@ -132,6
>>  		+132,43 @@ unsigned int seqno;
>>  	};
>>
>> +	struct av_mapping {
>> +		const char *name;
>> +		const access_vector_t value;
>> +	};
>> +
> 
> Should this be a linked list?

I was thinking that the last element could be zeroed out.  Same thing 
with the last class element.  Would make it easier to have a static 
initializer e.g.

struct security_class_mapping *mapping = {
	{ "xwindow", 32, {{"create", 1}, {"draw", 2}, {NULL, 0}} },
	{ "xcursor", 33, {{"create", 1}, {"show", 2}, {NULL, 0}} },
	{ NULL, 0, NULL }
};


-- 
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: object class discovery userland

[Stephen Smalley]

On Tue, 2007-05-29 at 13:50 -0400, Eamon Walsh wrote:
> Joshua Brindle wrote:
> > Eamon Walsh wrote:
> >> Here's a first go at an interface.  It's an init function
> >> that is a replacement for avc_init().  It takes flags, the
> >> class/permission mapping to use, and callback functions.
> >>
> >> This is trying to solve a few other problems at the same time, namely:
> >>
> >> - selinux prefix on the function name
> > 
> > So the client callsites will have to change then, oh well, we wanted to
> > do this anyway..
> 
> Well, the old avc_init() could be kept around for awhile.  Calling it 
> would still work, it just wouldn't have a mapping (would treat incoming 
> class/perm values literally).
> 
> > 
> >> - drops support for memory, threading, and locking callbacks
> >> (would just always use malloc and pthread)
> > 
> > Were these ever used or were they a remnant of the early
> > implementations?
> 
> I'm not aware of any users of them.  I put them in basically because the 
> X server wrapped malloc ("Xalloc"), glib has malloc wrappers and so 
> forth.  But the X people are moving away from this and back to straight 
> malloc.  I've come around to the belief that this is better done through 
> the linker with private functions.

Might want to look at dbusd; it uses the callbacks.

-- 
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: object class discovery userland

[Stephen Smalley]

On Fri, 2007-05-25 at 17:10 -0400, Eamon Walsh wrote:
> Here's a first go at an interface.  It's an init function that is a
> replacement for avc_init().  It takes flags, the class/permission
> mapping to use, and callback functions.
> 
> This is trying to solve a few other problems at the same time, namely:
> 
> - selinux prefix on the function name
> - drops support for memory, threading, and locking callbacks (would just
> always use malloc and pthread)
> - adds type code to logging callback

As you seem to be making this a generic init function, shouldn't it also
handle the matchpathcon flags and init support as well?  

> 
> ---
> 
>  selinux.h |   37 +++++++++++++++++++++++++++++++++++++
>  1 file changed, 37 insertions(+)
> 
> 
> Index: libselinux/include/selinux/selinux.h
> ===================================================================
> --- libselinux/include/selinux/selinux.h	(revision 2445)
> +++ libselinux/include/selinux/selinux.h	(working copy)
> @@ -132,6 +132,43 @@
>  		unsigned int seqno;
>  	};
>  
> +	struct av_mapping {
> +		const char *name;
> +		const access_vector_t value;
> +	};
> +
> +	struct security_class_mapping {
> +		const char *name;
> +		const security_class_t value;
> +		const struct av_mapping *perms;
> +	};
> +
> +/* Initialization routine for caching functions offered by the library */
> +
> +	struct selinux_callbacks {
> +		/* log the printf-style format and arguments,
> +		   with the type code indicating the type of message */
> +		int (*func_log) (int type, const char *fmt, ...);
> +		/* store a string representation of auditdata (corresponding
> +		   to the given security class) into msgbuf. */
> +		void (*func_audit) (void *auditdata, security_class_t cls,
> +				    char *msgbuf, size_t msgbufsize);
> +	};
> +
> +	extern int selinux_init(int flags,
> +				const struct security_class_mapping *map,
> +				const struct selinux_callbacks *callbacks);
> +
> +        /* Available flags */
> +#define SELINUX_THREAD          1
> +#define SELINUX_AVC             2
> +
> +        /* Logging type codes, passed to the logging callback */
> +#define SELINUX_ERROR	        0
> +#define SELINUX_WARNING		1
> +#define SELINUX_INFO		2
> +#define SELINUX_AVC_DENIAL	3
> +
>  /* Compute an access decision. */
>  	extern int security_compute_av(security_context_t scon,
>  				       security_context_t tcon,
> 
> 
-- 
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: object class discovery userland

[Eamon Walsh]

Stephen Smalley wrote:
> On Fri, 2007-05-25 at 17:10 -0400, Eamon Walsh wrote:
>> Here's a first go at an interface.  It's an init function that is a
>> replacement for avc_init().  It takes flags, the class/permission
>> mapping to use, and callback functions.
>>
>> This is trying to solve a few other problems at the same time, namely:
>>
>> - selinux prefix on the function name
>> - drops support for memory, threading, and locking callbacks (would just
>> always use malloc and pthread)
>> - adds type code to logging callback
> 
> As you seem to be making this a generic init function, shouldn't it also
> handle the matchpathcon flags and init support as well?  
> 

I have taken this into account wrt the labeling interface that I have 
been working on that would replace matchpathcon and friends.

Specifically, the patchset would add label flags ("SELINUX_LABEL", 
"SELINUX_VALIDATE", etc.) and a validation/canonicalization callback to 
the arguments to selinux_init(); the labeling interface is handle-based 
so there would be a separate create() function that would take the 
backend to open.


-- 
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: object class discovery userland

[KaiGai Kohei]

Eamon Walsh wrote:
> Here's a first go at an interface.  It's an init function that is a
> replacement for avc_init().  It takes flags, the class/permission
> mapping to use, and callback functions.
> 
> This is trying to solve a few other problems at the same time, namely:
> 
> - selinux prefix on the function name
> - drops support for memory, threading, and locking callbacks (would just
> always use malloc and pthread)
> - adds type code to logging callback

Eamon,

At first, I want to confirm whether the new selinux_init() intend to
place userspace AVC on shared memory segment, or not.
(SE-PostgreSQL has its userspace avc on shared memory segment.)

When we put userspace AVC on shared memory segment, following points
should be paid attention.

- Locking primitive
  Several processes can refer the userspace AVC on shmem, so inter-processes
  locking primitive are necessary.

- Memory allocation
  Allocating small memory block on shared memory segment is not simple as
  malloc(). In SE-PostgreSQL case, a fixed length region is assigned by
  shared memory management subsystem during process initialization.

  From same reason, we cannot have a mapping table between security context
  and SID value on the region managed by libselinux, because the total length
  of security context is not clear when we call selinux_init().

IMO, Locking callbacks and an option which enables to place userspace AVC
on given memory region (including fixed length shmem) are desirable.

Thanks,

> selinux.h |   37 +++++++++++++++++++++++++++++++++++++
> 1 file changed, 37 insertions(+)
> 
> 
> Index: libselinux/include/selinux/selinux.h
> ===================================================================
> --- libselinux/include/selinux/selinux.h    (revision 2445)
> +++ libselinux/include/selinux/selinux.h    (working copy)
> @@ -132,6 +132,43 @@
>         unsigned int seqno;
>     };
> 
> +    struct av_mapping {
> +        const char *name;
> +        const access_vector_t value;
> +    };
> +
> +    struct security_class_mapping {
> +        const char *name;
> +        const security_class_t value;
> +        const struct av_mapping *perms;
> +    };
> +
> +/* Initialization routine for caching functions offered by the library */
> +
> +    struct selinux_callbacks {
> +        /* log the printf-style format and arguments,
> +           with the type code indicating the type of message */
> +        int (*func_log) (int type, const char *fmt, ...);
> +        /* store a string representation of auditdata (corresponding
> +           to the given security class) into msgbuf. */
> +        void (*func_audit) (void *auditdata, security_class_t cls,
> +                    char *msgbuf, size_t msgbufsize);
> +    };
> +
> +    extern int selinux_init(int flags,
> +                const struct security_class_mapping *map,
> +                const struct selinux_callbacks *callbacks);
> +
> +        /* Available flags */
> +#define SELINUX_THREAD          1
> +#define SELINUX_AVC             2
> +
> +        /* Logging type codes, passed to the logging callback */
> +#define SELINUX_ERROR            0
> +#define SELINUX_WARNING        1
> +#define SELINUX_INFO        2
> +#define SELINUX_AVC_DENIAL    3
> +
> /* Compute an access decision. */
>     extern int security_compute_av(security_context_t scon,
>                        security_context_t tcon,
> 
> 


-- 
Open Source Software Promotion Center, 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.

Re: object class discovery userland

[Eamon Walsh]

KaiGai Kohei wrote:
> 
> Eamon,
> 
> At first, I want to confirm whether the new selinux_init() intend to
> place userspace AVC on shared memory segment, or not.
> (SE-PostgreSQL has its userspace avc on shared memory segment.)
> 
> When we put userspace AVC on shared memory segment, following points
> should be paid attention.
> 
> - Locking primitive
>   Several processes can refer the userspace AVC on shmem, so inter-processes
>   locking primitive are necessary.
> 
> - Memory allocation
>   Allocating small memory block on shared memory segment is not simple as
>   malloc(). In SE-PostgreSQL case, a fixed length region is assigned by
>   shared memory management subsystem during process initialization.
> 
>   From same reason, we cannot have a mapping table between security context
>   and SID value on the region managed by libselinux, because the total length
>   of security context is not clear when we call selinux_init().
> 
> IMO, Locking callbacks and an option which enables to place userspace AVC
> on given memory region (including fixed length shmem) are desirable.
> 

I think that because of the heavy customization in the Postgres AVC 
implementation it is best kept outside-of-tree at the current time.

There are other applications that use process pools such as Apache and 
if these become hosts to object managers then it may be useful to 
provide a shared memory option in the libselinux version.  The solution 
would involve a flag to the init function, some method of providing the 
shared memory segment to attach to, and special functionality for the 
"manager" process that will listen on netlink.

However, the Postgres implementation is not fully "shared memory" based. 
  The SID-to-context mapping is kept in a "pg_selinux" database table 
which is not stored in shared memory but rather is mapped from disk 
(correct me if I'm wrong).  In the previous thread, the possibility of 
providing callbacks for doing the SID-to-context mapping was discussed. 
  However IMO if this part of the library has to be outsourced to the 
application then the application might as well do the entire AVC.


-- 
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: object class discovery userland

[KaiGai Kohei]

> I think that because of the heavy customization in the Postgres AVC 
> implementation it is best kept outside-of-tree at the current time.

OK,

> There are other applications that use process pools such as Apache and 
> if these become hosts to object managers then it may be useful to 
> provide a shared memory option in the libselinux version.  The solution 
> would involve a flag to the init function, some method of providing the 
> shared memory segment to attach to, and special functionality for the 
> "manager" process that will listen on netlink.

Can I consider those features as a future todo? Or, do you want to have
a discussion in this chance?

> However, the Postgres implementation is not fully "shared memory" based. 
>  The SID-to-context mapping is kept in a "pg_selinux" database table 
> which is not stored in shared memory but rather is mapped from disk 
> (correct me if I'm wrong). 

It's correct. SE-PostgreSQL leverages one of the subsystems provided by native
PostgreSQL, to implement SID-to-context mapping. It is not based on share memory
directly.

> In the previous thread, the possibility of 
> providing callbacks for doing the SID-to-context mapping was discussed. 
>  However IMO if this part of the library has to be outsourced to the 
> application then the application might as well do the entire AVC.

I agrees your opinion.
In the case that applications can handle SID-to-context mapping well,
those works should be outsourced and being detachable from libselinux's AVC.

In my case, an idea using PostgreSQL's Oid (Object Identifier) as a persistent
SID works well :)

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

--
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: object class discovery userland

[Eamon Walsh]

KaiGai Kohei wrote:
>> I think that because of the heavy customization in the Postgres AVC 
>> implementation it is best kept outside-of-tree at the current time.
> 
> OK,
> 
>> There are other applications that use process pools such as Apache and 
>> if these become hosts to object managers then it may be useful to 
>> provide a shared memory option in the libselinux version.  The solution 
>> would involve a flag to the init function, some method of providing the 
>> shared memory segment to attach to, and special functionality for the 
>> "manager" process that will listen on netlink.
> 
> Can I consider those features as a future todo? Or, do you want to have
> a discussion in this chance?

Future todo.

> 
>> However, the Postgres implementation is not fully "shared memory" based. 
>>  The SID-to-context mapping is kept in a "pg_selinux" database table 
>> which is not stored in shared memory but rather is mapped from disk 
>> (correct me if I'm wrong). 
> 
> It's correct. SE-PostgreSQL leverages one of the subsystems provided by native
> PostgreSQL, to implement SID-to-context mapping. It is not based on share memory
> directly.
> 
>> In the previous thread, the possibility of 
>> providing callbacks for doing the SID-to-context mapping was discussed. 
>>  However IMO if this part of the library has to be outsourced to the 
>> application then the application might as well do the entire AVC.
> 
> I agrees your opinion.
> In the case that applications can handle SID-to-context mapping well,
> those works should be outsourced and being detachable from libselinux's AVC.
> 
> In my case, an idea using PostgreSQL's Oid (Object Identifier) as a persistent
> SID works well :)
> 
> 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: object class discovery userland

[Stephen Smalley]

On Wed, 2007-05-23 at 14:17 +0000, Christopher J. PeBenito wrote:
> On Mon, 2007-04-23 at 10:58 -0400, Stephen Smalley wrote:
> > On Mon, 2007-04-23 at 10:43 -0400, Joshua Brindle wrote:
> > > > From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
> > > > 
> > > > On Fri, 2007-04-20 at 13:19 -0400, Christopher J. PeBenito wrote:
> > > > > On Fri, 2007-04-20 at 13:02 -0400, Eamon Walsh wrote:
> > > > > > Eamon Walsh wrote:
> > > > > > > Christopher J. PeBenito wrote:
> > > > > > >> 3. stop exporting class and perm indexes outside of the 
> > > > > > >> libraries.  Then the reverse lookup wouldn't be needed.  This 
> > > > > > >> would involve some overhauling of the libraries.
> > > > > > > 
> > > > > > > I don't think this is a good idea because of the disruption it 
> > > > > > > would cause with access vector processing (as passed to 
> > > > > > > security_av_string() and avc_has_perm()).  How do you 
> > > > or together strings?
> > > > > > > 
> > > > > > > Why not just cache the numbers in the library, as Karl 
> > > > suggested, 
> > > > > > > or create a parallel "class_num" or "class_index" 
> > > > directory with 
> > > > > > > numeric nodes (perhaps renaming class to class_name).
> > > > > > > 
> > > > > > class_num/1/perms/1
> > > > > > class_num/1/name
> > > > > 
> > > > > I don't feel strongly about any of my suggestions, I mainly 
> > > > wanted to 
> > > > > get the discussion going.  The inspiration for symlink idea 
> > > > was from 
> > > > > all the symlinking you see in sysfs, but the above 
> > > > structure certainly 
> > > > > is an option too.
> > > > 
> > > > I'd recommend caching in the library and doing the reverse 
> > > > lookup there rather than encoding it into the pseudo filesystem state.
> > > 
> > > Making the library open and cache every class and permission seems
> > > undesirable. What do you have against doing it from the filesystem?
> > 
> > You don't have to cache them all - the cache can be populated lazily
> > (but I'd expect it to pull in an entire class at a time).
> > 
> > I'm not keen on having redundant information in the filesystem state,
> > and I don't think these operations are on the critical path anyway for
> > performance.
> 
> One issue that we realized on this is that the cache is going to have to
> be flushed when the policy is reloaded.  For object managers that have a
> full AVC that is simple, since we can just add it to the netlink socket
> handler where it resets the AVC.
> 
> However, for simple ones such as passwd and crond which, don't need an
> AVC, there isn't a facility now.  Crond should be ok since it only
> checks process permissions, which can't change on policy reload.
> Perhaps a lighter version of the netlink support that just listens for
> policy reloads?
> 
> The object manager will also have to be modified to get the new class
> and perm values on a policy reload.

Why not just require them to remain stable at runtime, and require a
restart of the object manager if you are going to change them?  Allowing
them to change at any time will introduce a fair amount of
complexity/overhead at runtime.


-- 
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: object class discovery userland

[Eamon Walsh]

Stephen Smalley wrote:
> On Wed, 2007-05-23 at 14:17 +0000, Christopher J. PeBenito wrote:

>> The object manager will also have to be modified to get the new class
>> and perm values on a policy reload.
> 
> Why not just require them to remain stable at runtime, and require a
> restart of the object manager if you are going to change them?  Allowing
> them to change at any time will introduce a fair amount of
> complexity/overhead at runtime.
> 

I'm fine with this, however I think it should be the kernel's job to 
enforce the stability of the values.  The policyload should fail if the 
values are changing.

Perhaps this could be a configurable "experimental" versus "production" 
option, or perhaps userspace object managers could somehow register with 
the kernel which will then refuse to change the values if any are 
currently running.


-- 
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: object class discovery userland

[Nick Nam]

-----Original Message-----
From: Joshua Brindle
To: Stephen Smalley; Christopher J. PeBenito
CC: Eamon Walsh; SELinux Mail List
Sent: Mon Apr 23 10:43:52 2007
Subject: RE: object class discovery userland

> From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
> 
> On Fri, 2007-04-20 at 13:19 -0400, Christopher J. PeBenito wrote:
> > On Fri, 2007-04-20 at 13:02 -0400, Eamon Walsh wrote:
> > > Eamon Walsh wrote:
> > > > Christopher J. PeBenito wrote:
> > > >> 3. stop exporting class and perm indexes outside of the 
> > > >> libraries.  Then the reverse lookup wouldn't be needed.  This 
> > > >> would involve some overhauling of the libraries.
> > > > 
> > > > I don't think this is a good idea because of the disruption it 
> > > > would cause with access vector processing (as passed to 
> > > > security_av_string() and avc_has_perm()).  How do you 
> or together strings?
> > > > 
> > > > Why not just cache the numbers in the library, as Karl 
> suggested, 
> > > > or create a parallel "class_num" or "class_index" 
> directory with 
> > > > numeric nodes (perhaps renaming class to class_name).
> > > > 
> > > class_num/1/perms/1
> > > class_num/1/name
> > 
> > I don't feel strongly about any of my suggestions, I mainly 
> wanted to 
> > get the discussion going.  The inspiration for symlink idea 
> was from 
> > all the symlinking you see in sysfs, but the above 
> structure certainly 
> > is an option too.
> 
> I'd recommend caching in the library and doing the reverse 
> lookup there rather than encoding it into the pseudo filesystem state.

Making the library open and cache every class and permission seems
undesirable. What do you have against doing it from the filesystem?


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




--
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: object class discovery userland

[Nick Nam]

-----Original Message-----
From: Joshua Brindle
To: Stephen Smalley; Christopher J. PeBenito
CC: Eamon Walsh; SELinux Mail List
Sent: Mon Apr 23 10:43:52 2007
Subject: RE: object class discovery userland

> From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
> 
> On Fri, 2007-04-20 at 13:19 -0400, Christopher J. PeBenito wrote:
> > On Fri, 2007-04-20 at 13:02 -0400, Eamon Walsh wrote:
> > > Eamon Walsh wrote:
> > > > Christopher J. PeBenito wrote:
> > > >> 3. stop exporting class and perm indexes outside of the 
> > > >> libraries.  Then the reverse lookup wouldn't be needed.  This 
> > > >> would involve some overhauling of the libraries.
> > > > 
> > > > I don't think this is a good idea because of the disruption it 
> > > > would cause with access vector processing (as passed to 
> > > > security_av_string() and avc_has_perm()).  How do you 
> or together strings?
> > > > 
> > > > Why not just cache the numbers in the library, as Karl 
> suggested, 
> > > > or create a parallel "class_num" or "class_index" 
> directory with 
> > > > numeric nodes (perhaps renaming class to class_name).
> > > > 
> > > class_num/1/perms/1
> > > class_num/1/name
> > 
> > I don't feel strongly about any of my suggestions, I mainly 
> wanted to 
> > get the discussion going.  The inspiration for symlink idea 
> was from 
> > all the symlinking you see in sysfs, but the above 
> structure certainly 
> > is an option too.
> 
> I'd recommend caching in the library and doing the reverse 
> lookup there rather than encoding it into the pseudo filesystem state.

Making the library open and cache every class and permission seems
undesirable. What do you have against doing it from the filesystem?


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




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