RE: [RFC] selinux management API

RE: [RFC] selinux management API

[Chad Hanson]

A use case and example below.

> -----Original Message-----
> From: Daniel J Walsh [mailto:dwalsh@redhat.com]
> Sent: Monday, July 18, 2005 2:36 PM
> To: gyurdiev@redhat.com
> Cc: Chad Hanson; Joshua Brindle; selinux@tycho.nsa.gov
> Subject: Re: [RFC] selinux management API
> 
> >>>
> >>Are nodes and interfaces on this list as well? These are 
> very necessary
> >>IMHO.
> >>    
> >>
> >
> >Can you give a usage scenario... 
> >
> >
> I belieive the way to make this work from the users 
> perspective is via iptables.  I am not sure if iptables would talk
> directly to the kernel or would use libsemanage to rewrite rules.
> 
> So you could say something like
> iptables allow named_t to listen on eth0
> iptables allow mail to write on eth1
> 

In the current setup you can use the interface and node rules to limit
traffic, both by TE and MLS. This is especially important in MLS and TE
separation of networks. I'll show a case for interface rules.

In the current global_macros.te:712 there is the following rule

allow $1 netif_type:netif *;

where netif_type is an attribute on netif_lo_t, netif_eth0_t, netif_eth1_t,
etc.... 

If you have three interfaces on a machine lo, eth0, eth1, you could prevent
traffic from unconfined_t to eth1 by changing to the follwing rules:

#allow $1 netif_type:netif *;
allow $1 netif_lo_t:netif *;
allow $1 netif_eth0_t:netif *;

In practice MLS and TE systems used for network domain separation you would
want to assign types and MLS labels to intefaces and nodes (networks) to
prevent data from going where it shouldn't.  An MLS/TE example is making one
interface INSIDE and another OUTSIDE. You could then have node rules for
network descriptions of INSIDE/OUTSIDE.

-Chad


 

--
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: [RFC] selinux management API

[Daniel J Walsh]

Chad Hanson wrote:

>A use case and example below.
>
>  
>
>>-----Original Message-----
>>From: Daniel J Walsh [mailto:dwalsh@redhat.com]
>>Sent: Monday, July 18, 2005 2:36 PM
>>To: gyurdiev@redhat.com
>>Cc: Chad Hanson; Joshua Brindle; selinux@tycho.nsa.gov
>>Subject: Re: [RFC] selinux management API
>>
>>    
>>
>>>>Are nodes and interfaces on this list as well? These are 
>>>>        
>>>>
>>very necessary
>>    
>>
>>>>IMHO.
>>>>   
>>>>
>>>>        
>>>>
>>>Can you give a usage scenario... 
>>>
>>>
>>>      
>>>
>>I belieive the way to make this work from the users 
>>perspective is via iptables.  I am not sure if iptables would talk
>>directly to the kernel or would use libsemanage to rewrite rules.
>>
>>So you could say something like
>>iptables allow named_t to listen on eth0
>>iptables allow mail to write on eth1
>>
>>    
>>
>
>In the current setup you can use the interface and node rules to limit
>traffic, both by TE and MLS. This is especially important in MLS and TE
>separation of networks. I'll show a case for interface rules.
>
>In the current global_macros.te:712 there is the following rule
>
>allow $1 netif_type:netif *;
>
>where netif_type is an attribute on netif_lo_t, netif_eth0_t, netif_eth1_t,
>etc.... 
>
>If you have three interfaces on a machine lo, eth0, eth1, you could prevent
>traffic from unconfined_t to eth1 by changing to the follwing rules:
>
>#allow $1 netif_type:netif *;
>allow $1 netif_lo_t:netif *;
>allow $1 netif_eth0_t:netif *;
>
>In practice MLS and TE systems used for network domain separation you would
>want to assign types and MLS labels to intefaces and nodes (networks) to
>prevent data from going where it shouldn't.  An MLS/TE example is making one
>interface INSIDE and another OUTSIDE. You could then have node rules for
>network descriptions of INSIDE/OUTSIDE.
>
>-Chad
>
>
> 
>  
>
But I don't like the idea of Admins modifying policy in order to 
customize their system.  This is what we
are trying to get away from.    Try to explain to an administrator that 
you only want the apache web site to
be allowed to listen on your intranet side and not on the internet.  I 
would have a hard time writing policy for
that.   I can imagine it could be fairly easy using iptables type syntax 
to do it though.

We (Red Hat) want to get to the point where we eliminate policy-sources 
and it becomes just policy.src.rpm.  The
same way we did with kernel-sources.

Dan

-- 



--
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: [RFC] selinux management API

[Chad Hanson]

> -----Original Message-----
> From: Daniel J Walsh [mailto:dwalsh@redhat.com]
> Sent: Tuesday, July 19, 2005 9:09 AM
> To: Chad Hanson
> Cc: gyurdiev@redhat.com; Joshua Brindle; selinux@tycho.nsa.gov
> Subject: Re: [RFC] selinux management API
> 
> >
> But I don't like the idea of Admins modifying policy in order to 
> customize their system.  This is what we
> are trying to get away from.    Try to explain to an administrator that 
> you only want the apache web site to
> be allowed to listen on your intranet side and not on the 
> internet.  I would have a hard time writing policy for

It really could be done be expanding can_network or other macro to take a
value, such as the interface, and restrict the network access to just a
specific interface instead of all interfaces.


> that.   I can imagine it could be fairly easy using iptables type syntax 
> to do it though.
> 
> We (Red Hat) want to get to the point where we eliminate policy-sources 
> and it becomes just policy.src.rpm.  The
> same way we did with kernel-sources.
> 

I agree that this customization is bad. My example could have been better. A
better topic is just talking about the contents of the net_contexts file,
particularly nodes and interfaces.  Currently all of netifcon and nodecon
rules are static. One, this isn't modular and doesn't fall into the category
if not in use remove it, and second if server has four ethernet interface
cards the fourth defaults back to the initial sid instead of policy defined
in net_contexts. The same would hold true for virtual interfaces. Nodes have
a similiar issue. In MLS, the interface and node rules need to be customized
for attaching the desired MLS label (such as unclassified, secret, etc...).
In TE, you can definitely use strict rules to prevent certain types from
transmitting data to interfaces or nodes, possibly this should be an
addition to the mls or strict policy initially. I would think we would want
the ability to configure these objects even if everyone doesn't choose to. I
can guarantee in a guard environment, it would be highly desirable for the
policy to restrict a process to communicate on one interface only.

-Chad

--
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: [RFC] selinux management API

[Ivan Gyurdiev]

I believe we're discussing the same thing, from different points 
of view, and a solution can be designed that fits everyone's needs.

> > But I don't like the idea of Admins modifying policy in order to 
> > customize their system.  This is what we
> > are trying to get away from.   

Dan's concern is from usability point of view.
The policy source is not a good way for a sysadmin
to modify security restrictions. It is better suited
for specifying static parts of policy, shipped by
the vendor, which require rich language to
properly describe..

I'm not sure setools are an acceptable replacement 
either. There are existing tools and systems,
which we could integrate with. From our discussions at Red Hat, 
I understand that Dan wants iptables to be used as a frontend
to configuring certain parts of policy. He also
wants to hide the interface security context from the user.
I can only assume that he wants the port context hidden too.
On the other hand he'd like to be able to specify the
source context (application context) and match against it. 

I'm not sure whether all of this is a good idea or not,
(or wheter entirely possible), but it seems clear that 
any policy manipulation should occur through 
libsemanage, and eventually through libsepol.
Any iptables integration (if implemented) would have
to occur via those libaries.

So yes, it seems to me that it would be appropriate
to provide an API for managing network interfaces.
Whether we support changing the context of an interface,
or simply querying it, is an implementation detail.
I started writing some libsepol support with
the query operation today. I've also implemented
query on ports (give sepol a number, or a range,
get back the security context).


--
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: [RFC] selinux management API

[Chad Hanson]

I want to clarify something below.

> -----Original Message-----
> From: Ivan Gyurdiev [mailto:gyurdiev@redhat.com]
> Sent: Friday, July 15, 2005 10:57 AM
> To: Joshua Brindle
> Cc: selinux@tycho.nsa.gov
> Subject: Re: [RFC] selinux management API
> 
> ===========================
> 
> During a teleconference meeting with Tresys, and Stephen, we 
> discussed Karl's proposal for mapping users to selinux users 
> many-to-one (see previous discussions), and several key points were
> established:
> 
> 1) Granularity at the Unix user level (and not just the selinux user
> level) is useful for implementing the categories for the MCS policy
> that Redhat is developing. As a result, we plan to move MLS categories
> from the selinux user config file into the map file (or alternative
> backend), where they can be associated with users, and not just selinux
> users. The set of accessible categories will be configured by login
> programs. Sensitivities would remain associated with selinux users.
> 

Is this just having categories available in the mapping file for users and
leaving the original MLS Range definition as per the current binary policy
in the selinux users file? 

Some simple MLS scenarios scenarios could be satisfied by a Unix user to
SELinux user mapping.   

-Chad


--
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: [RFC] selinux management API

[Chad Hanson]

> -----Original Message-----
> From: Joshua Brindle [mailto:jbrindle@tresys.com]
> Sent: Friday, July 15, 2005 9:47 AM
> To: selinux@tycho.nsa.gov
> Subject: [RFC] selinux management API
> 
> 
> After some discussion about the newly introduced libsemod and the user 
> management that Red Hat wants to introduce we've tried to come up with 
> an API that all management applications can use, which allow management 
> of many components of SELinux policy, including users, booleans states, 
> and soon ports. It's written with the expectation to add more managed 

Are nodes and interfaces on this list as well? These are very necessary
IMHO.

-Chad

> components later, without disturbing the API. We plan on make a new 
> library called libsemanage with this API exported through a shared 
> library and getting rid of libsemod.
> 

--
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: [RFC] selinux management API

[Ivan Gyurdiev]

> > After some discussion about the newly introduced libsemod and the user 
> > management that Red Hat wants to introduce we've tried to come up with 
> > an API that all management applications can use, which allow management 
> > of many components of SELinux policy, including users, booleans states, 
> > and soon ports. It's written with the expectation to add more managed 
> 
> Are nodes and interfaces on this list as well? These are very necessary
> IMHO.

Can you give a usage scenario... 

Joshua, will you be renaming libsemod to libsemanage soon?




--
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: [RFC] selinux management API

[Daniel J Walsh]

Ivan Gyurdiev wrote:

>>>After some discussion about the newly introduced libsemod and the user 
>>>management that Red Hat wants to introduce we've tried to come up with 
>>>an API that all management applications can use, which allow management 
>>>of many components of SELinux policy, including users, booleans states, 
>>>and soon ports. It's written with the expectation to add more managed 
>>>      
>>>
>>Are nodes and interfaces on this list as well? These are very necessary
>>IMHO.
>>    
>>
>
>Can you give a usage scenario... 
>
>Joshua, will you be renaming libsemod to libsemanage soon?
>
>  
>
I belieive the way to make this work from the users perspective is via 
iptables.  I am not sure if iptables would talk
directly to the kernel or would use libsemanage to rewrite rules.

So you could say something like
iptables allow named_t to listen on eth0
iptables allow mail to write on eth1

>--
>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: [RFC] selinux management API

[Joshua Brindle]

Ivan Gyurdiev wrote:

>>>After some discussion about the newly introduced libsemod and the user 
>>>management that Red Hat wants to introduce we've tried to come up with 
>>>an API that all management applications can use, which allow management 
>>>of many components of SELinux policy, including users, booleans states, 
>>>and soon ports. It's written with the expectation to add more managed 
>>>      
>>>
>>Are nodes and interfaces on this list as well? These are very necessary
>>IMHO.
>>    
>>
The API was made to be extensible, any policy components that need to be 
managed can be.

>Can you give a usage scenario... 
>
>Joshua, will you be renaming libsemod to libsemanage soon?
>  
>
I'll submit patches after the new API is in place, just renaming the lib 
won't do anything at this point since we are going to be making changes 
to anything that links against it anyway. I should have some patches 
ready after OLS.

Joshua

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

[RFC] selinux management API

[Joshua Brindle]

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

After some discussion about the newly introduced libsemod and the user 
management that Red Hat wants to introduce we've tried to come up with 
an API that all management applications can use, which allow management 
of many components of SELinux policy, including users, booleans states, 
and soon ports. It's written with the expectation to add more managed 
components later, without disturbing the API. We plan on make a new 
library called libsemanage with this API exported through a shared 
library and getting rid of libsemod.

This library should seamlessly handle management on systems with the 
current policy, policy modules or the policy management server. This way 
the management apps do not need to know what kind of SELinux system is 
running.

Comments are appreciated.


Joshua Brindle

[-- Attachment #2: semanage.h --]
[-- Type: text/x-chdr, Size: 6016 bytes --]

/* This #include needed to get struct timeval. */
#include <sys/time.h>

/* All accesses with semanage is through a "semanage_handle".  This
 * handler may be with the monolithic policy, directly to a module
 * store, or with a policy management server.  The handler represents
 * a persistent connection to that policy manager.  It is created
 * through a semanage_connect() call and must be afterwards
 * deallocated with semanage_handle_free(). */
typedef struct semanage_handle semanage_handle_t;

/* "Connect" to a manager, as specified in the file
 * /etc/selinux/semanage.conf.  This function always allocates a new
 * semanage_handle_t and assigns it to the passed reference pointer.
 * The caller is later responsible for deallocating the pointer by
 * calling semanage_handle_free().  If the connect fails then this
 * function returns a negative value, else it returns zero. */
int semanage_connect(semanage_handle_t **);

/* Disconnect from the manager given by the handle.  If already
 * disconnected then this function does nothing.  Return 0 if
 * disconnected properly or already disconnected, negative value on
 * error. */
int semanage_disconnect(semanage_handle_t *);

/* Deallocate all space associated with a semanage_handle_t, including
 * the pointer itself.  CAUTION: this function does not disconnect
 * from the manager; be sure that a semanage_disconnect() was
 * previously called. */
void semanage_handle_free(semanage_handle_t *);

/* Return a string describing the most recently encountered error
 * associated with a semanage_handle_t.  The returned string must not
 * be modified by the caller.  Be aware that this string is not
 * persistent; future calls to this library may alter the buffer
 * contents. */
const char *semanage_strerror(semanage_handle_t *);


/* Attempt to obtain a transaction lock on the manager.  If another
 * process has the lock then this function may block, depending upon
 * the timeout value.  The timeout parameter acts similarly to
 * select(2).
 *
 * Note that if the semanage_handle has not yet obtained a transaction
 * lock whenever a writer function is called, there will be an
 * implicit call to this function with timeout set to zero (i.e.,
 * return immediately if unable to obtain). */
int semanage_begin_transaction(semanage_handle_t *,
                               struct timeval *timeout);

/* Attempt to commit all changes since this transaction began.  If the
 * commit is successful then increment the "policy sequence number"
 * and then release the transaction lock.
 */
int semanage_commit(semanage_handle_t *);


/* META NOTES
 *
 * All of the below functions exepct a semanage_handle as its first
 * parameter.  If an error occurs then the function returns a negative
 * value.  Call semanage_strerror() to retrieve a string that fully
 * describes the error.
 *
 * For all functions a non-negative number indicates success.  The
 * particular returned value is the "policy sequence number".  This
 * number keeps tracks of policy revisions and is used to detect if
 * one semanage client has committed policy changes while another is
 * still connected.
 *
 * The info structs are nebulous at this time.  They will have
 * accessor functions from which to retrieve particular information.
 * The particular accessors are unknown at this time; as design
 * progresses those accessors will be decided.  Two such proposed
 * accessors are:

const char *semanage_module_get_name(semanage_module_info_t *);
const char *semanage_module_get_version(semanage_module_info_t *);

 */

int semanage_module_install(semanage_handle_t *,
                            char *module_data, size_t data_len);
int semanage_module_upgrade(semanage_handle_t *,
                            char *module_data, size_t data_len);
int semanage_module_install_base(semanage_handle_t *,
                                 char *module_data, size_t data_len);
int semanage_module_remove(semanage_handle_t *,
                           char *module_name);
typedef struct semanage_module_info semanage_module_info_t;
int semanage_module_list(semanage_handle_t *,
                         semanage_module_info_t **, int *num_modules);
void semanage_module_info_free(semanage_module_info_t *);


int semanage_user_add(semanage_handle_t *,
                      char *selinux_user_name,
                      char **roles, int num_roles);
int semanage_user_remove(semanage_handle_t *,
                         char *selinux_user_name);
typedef struct semanage_user_info semanage_user_info_t;
int semanage_user_list(semanage_handle_t *,
                       semanage_user_info_t **, int *num_users);
void semanage_user_info_free(semanage_user_info_t *);


int semanage_homedir_add(semanage_handle_t *,
                         char *dirname, char *context);
int semanage_homedir_remove(semanage_handle_t *,
                            char *dirname);
typedef struct semanage_homedir_info semanage_homedir_info_t;
int semanage_homedir_list(semanage_handle_t *,
                          semanage_homedir_info_t **, int *num_homedirs);
void semanage_homedir_info_free(semanage_homedir_info_t *);


int semanage_boolean_set(semanage_handle_t *,
                         char *boolname, int new_bool_value, int permanent);
/* if for some reason the caller does not have permission to read a
 * particular boolean value, it will not be added to the returned
 * array */
typedef struct semanage_boolean_info semanage_boolean_info_t;
int semanage_boolean_list(semanage_handle_t *,
                          semanage_boolean_info_t **, int *num_bools);
void semanage_boolean_info_free(semanage_boolean_info_t *);


int semanage_tunable_set(semanage_handle_t *,
                         char *tunablename, int new_tunable_value);
typedef struct semanage_tunable_info semanage_tunable_info_t;
int semanage_tunable_list(semanage_handle_t *,
                          semanage_tunable_info_t **, int *num_tunables);
void semanage_tunable_info_free(semanage_tunable_info_t *);

Re: [RFC] selinux management API

[Ivan Gyurdiev]

To expand on that, the plan is to make libsemanage (new name for 
libsemod) become the central access point for anything that manipulates
the policy. It would implement things like policy access, configuration
files, and transaction guarantees.

Libsepol, which currently handles access to the binary policy file,
would become a static backend library for libsemanage and checkpolicy - 
it would supply common code to work with the policy image.

Libselinux would only contain code necessary for access decisions,
and communicating with the kernel policy. 

===========================

During a teleconference meeting with Tresys, and Stephen, we 
discussed Karl's proposal for mapping users to selinux users 
many-to-one (see previous discussions), and several key points were
established:

1) Granularity at the Unix user level (and not just the selinux user
level) is useful for implementing the categories for the MCS policy
that Redhat is developing. As a result, we plan to move MLS categories
from the selinux user config file into the map file (or alternative
backend), where they can be associated with users, and not just selinux
users. The set of accessible categories will be configured by login
programs. Sensitivities would remain associated with selinux users.

2) It is desirable for the selinux libraries to have no knowledge
of Unix users, and to only work with SELinux users. So, instead
of changing get_ordered_context_list to accomplish the discussed
mapping, all callers will be changed to pass in the sel user.
API compatibility is not broken, until the fallback to the user_u
default user is removed from get_ordered_context_list.

3) It is important to be able to select from multiple backends
for storing the user-to-sel_user mappings, just like you can
select where to store the users. The current plan is to add
a "selusers" field in nsswitch.conf, and write the corresponding
support in libnss_files.so. In the course of doing that, we cannot
add library dependencies to libnss_files.so, so any parser and related
code has to be self-contained.

4) Management of file_contexts is still a point of contention, and I 
am not clear exactly how the current API as proposed by Tresys will
solve this problem.  

5) I would also like to see single record query functions implemented 
by the libsemanage APIs (as opposed to iterating lists), as well as 
a way to modify records. I think the add methods should take a
structure.

6) It is also planned to change the configuration files from being
the authoritative data source, to something that's merged into
the binary policy on every transaction (not every function call).
What this means is, when a user is added, the modifications
will be written to the binary file, and load_policy and init
will no longer read the config file on startup, and risk failure.
The purpose of config files is as the source to be compiled 
into the binary policy, not loaded on every boot. On upgrades,
a utility (genpolicy) would read in all relevant files and
modules (Tresys' loadable modules work), and construct the
new image. 

I hope this summarizes what we've been discussing off-list 
to some degree. Please make corrections as necessary.


--
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: [RFC] selinux management API

[Joshua Brindle]

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

I think this summarizes the dialog well Ivan, thanks.

Attached is an updated header file that uses structs for all 
add/remove/update functions so that arbitrary information can be added 
to any of them later, accessors would accompany all these structs but 
aren't in this header.

Joshua

Ivan Gyurdiev wrote:

> To expand on that, the plan is to make libsemanage (new name for
> libsemod) become the central access point for anything that manipulates
> the policy. It would implement things like policy access, configuration
> files, and transaction guarantees.
>
> Libsepol, which currently handles access to the binary policy file,
> would become a static backend library for libsemanage and checkpolicy -
> it would supply common code to work with the policy image.
>
> Libselinux would only contain code necessary for access decisions,
> and communicating with the kernel policy.
>
> ===========================
>
> During a teleconference meeting with Tresys, and Stephen, we
> discussed Karl's proposal for mapping users to selinux users
> many-to-one (see previous discussions), and several key points were
> established:
>
> 1) Granularity at the Unix user level (and not just the selinux user
> level) is useful for implementing the categories for the MCS policy
> that Redhat is developing. As a result, we plan to move MLS categories
> from the selinux user config file into the map file (or alternative
> backend), where they can be associated with users, and not just selinux
> users. The set of accessible categories will be configured by login
> programs. Sensitivities would remain associated with selinux users.
>
> 2) It is desirable for the selinux libraries to have no knowledge
> of Unix users, and to only work with SELinux users. So, instead
> of changing get_ordered_context_list to accomplish the discussed
> mapping, all callers will be changed to pass in the sel user.
> API compatibility is not broken, until the fallback to the user_u
> default user is removed from get_ordered_context_list.
>
> 3) It is important to be able to select from multiple backends
> for storing the user-to-sel_user mappings, just like you can
> select where to store the users. The current plan is to add
> a "selusers" field in nsswitch.conf, and write the corresponding
> support in libnss_files.so. In the course of doing that, we cannot
> add library dependencies to libnss_files.so, so any parser and related
> code has to be self-contained.
>
> 4) Management of file_contexts is still a point of contention, and I
> am not clear exactly how the current API as proposed by Tresys will
> solve this problem.
>
> 5) I would also like to see single record query functions implemented
> by the libsemanage APIs (as opposed to iterating lists), as well as
> a way to modify records. I think the add methods should take a
> structure.
>
> 6) It is also planned to change the configuration files from being
> the authoritative data source, to something that's merged into
> the binary policy on every transaction (not every function call).
> What this means is, when a user is added, the modifications
> will be written to the binary file, and load_policy and init
> will no longer read the config file on startup, and risk failure.
> The purpose of config files is as the source to be compiled
> into the binary policy, not loaded on every boot. On upgrades,
> a utility (genpolicy) would read in all relevant files and
> modules (Tresys' loadable modules work), and construct the
> new image.
>
> I hope this summarizes what we've been discussing off-list
> to some degree. Please make corrections as necessary.
>
>
> --
> 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.
>


[-- Attachment #2: semanage.h --]
[-- Type: text/x-chdr, Size: 5603 bytes --]

/* This #include needed to get struct timeval. */
#include <sys/time.h>

/* All accesses with semanage is through a "semanage_handle".  This
 * handler may be with the monolithic policy, directly to a module
 * store, or with a policy management server.  The handler represents
 * a persistent connection to that policy manager.  It is created
 * through a semanage_connect() call and must be afterwards
 * deallocated with semanage_handle_free(). */
typedef struct semanage_handle semanage_handle_t;

/* "Connect" to a manager, as specified in the file
 * /etc/selinux/semanage.conf.  This function always allocates a new
 * semanage_handle_t and assigns it to the passed reference pointer.
 * The caller is later responsible for deallocating the pointer by
 * calling semanage_handle_free().  If the connect fails then this
 * function returns a negative value, else it returns zero. */
int semanage_connect(semanage_handle_t **);

/* Disconnect from the manager given by the handle.  If already
 * disconnected then this function does nothing.  Return 0 if
 * disconnected properly or already disconnected, negative value on
 * error. */
int semanage_disconnect(semanage_handle_t *);

/* Deallocate all space associated with a semanage_handle_t, including
 * the pointer itself.  CAUTION: this function does not disconnect
 * from the manager; be sure that a semanage_disconnect() was
 * previously called. */
void semanage_handle_free(semanage_handle_t *);

/* Return a string describing the most recently encountered error
 * associated with a semanage_handle_t.  The returned string must not
 * be modified by the caller.  Be aware that this string is not
 * persistent; future calls to this library may alter the buffer
 * contents. */
const char *semanage_strerror(semanage_handle_t *);


/* Attempt to obtain a transaction lock on the manager.  If another
 * process has the lock then this function may block, depending upon
 * the timeout value.  The timeout parameter acts similarly to
 * select(2).
 *
 * Note that if the semanage_handle has not yet obtained a transaction
 * lock whenever a writer function is called, there will be an
 * implicit call to this function with timeout set to zero (i.e.,
 * return immediately if unable to obtain). */
int semanage_begin_transaction(semanage_handle_t *,
                               struct timeval *timeout);

/* Attempt to commit all changes since this transaction began.  If the
 * commit is successful then increment the "policy sequence number"
 * and then release the transaction lock.
 */
int semanage_commit(semanage_handle_t *);


/* META NOTES
 *
 * All of the below functions exepct a semanage_handle as its first
 * parameter.  If an error occurs then the function returns a negative
 * value.  Call semanage_strerror() to retrieve a string that fully
 * describes the error.
 *
 * For all functions a non-negative number indicates success.  The
 * particular returned value is the "policy sequence number".  This
 * number keeps tracks of policy revisions and is used to detect if
 * one semanage client has committed policy changes while another is
 * still connected.
 *
 * The info structs are nebulous at this time.  They will have
 * accessor functions from which to retrieve particular information.
 * The particular accessors are unknown at this time; as design
 * progresses those accessors will be decided.  Two such proposed
 * accessors are:

const char *semanage_module_get_name(semanage_module_info_t *);
const char *semanage_module_get_version(semanage_module_info_t *);

 */

int semanage_module_install(semanage_handle_t *,
                            char *module_data, size_t data_len);
int semanage_module_upgrade(semanage_handle_t *,
                            char *module_data, size_t data_len);
int semanage_module_install_base(semanage_handle_t *,
                                 char *module_data, size_t data_len);
int semanage_module_remove(semanage_handle_t *,
                           char *module_name);
typedef struct semanage_module_info semanage_module_info_t;
int semanage_module_list(semanage_handle_t *,
                         semanage_module_info_t **, int *num_modules);
void semanage_module_info_free(semanage_module_info_t *);


typedef struct semanage_user semanage_user_t;

int semanage_user_add(semanage_handle_t *, semanage_user_t *userdata);
int semanage_user_remove(semanage_handle_t *, semanage_user_t *userdata);
int semanage_user_list(semanage_handle_t *, semanage_user_t **users, int *num_users);
void semanage_user_free(semanage_user_t *);


typedef struct semanage_homedir semanage_homedir_t;

int semanage_homedir_add(semanage_handle_t *, semanage_homedir_t *homedir);
int semanage_homedir_remove(semanage_handle_t *, semanage_homedir_t *homedir);
int semanage_homedir_list(semanage_handle_t *, semanage_homedir_t **, int *num_homedirs);
void semanage_homedir_free(semanage_homedir_t *);


typedef struct semanage_boolean semanage_boolean_t;
int semanage_boolean_set(semanage_handle_t *, semanage_boolean_t *bool);
/* if for some reason the caller does not have permission to read a
 * particular boolean value, it will not be added to the returned
 * array */
int semanage_boolean_list(semanage_handle_t *, semanage_boolean_t **, int *num_bools);
void semanage_boolean_free(semanage_boolean_t *);

typedef struct semanage_tunable semanage_tunable_t;
int semanage_tunable_set(semanage_handle_t *, semanage_tunable_t *tunable); 
int semanage_tunable_list(semanage_handle_t *, semanage_tunable_t **list, int num_tunables);
void semanage_tunable_free(semanage_tunable_t *);

Re: [RFC] selinux management API

[Ivan Gyurdiev]

int semanage_user_remove(semanage_handle_t *, semanage_user_t
*userdata);

You want to remove based on name, not based on a full
data structure. Similarly there should be a query function.

void semanage_user_free(semanage_user_t *);

Seems to me like the free functions should be declared
with the other handlers for their corresponding opaque 
data structure (which are not shown here).







--
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: [RFC] selinux management API

[Joshua Brindle]

On Fri, 2005-07-15 at 15:19 -0400, Ivan Gyurdiev wrote:
> int semanage_user_remove(semanage_handle_t *, semanage_user_t
> *userdata);
> 
> You want to remove based on name, not based on a full
> data structure. Similarly there should be a query function.
> 
But maybe not in the future, this is meant to be future-proof

and the query functions can be added in, but those are convenience
functions and have nothing to do with the design we are proposing here.

> void semanage_user_free(semanage_user_t *);
> 
> Seems to me like the free functions should be declared
> with the other handlers for their corresponding opaque 
> data structure (which are not shown here).

eh? 
void semanage_module_info_free(semanage_module_info_t *);
void semanage_homedir_free(semanage_homedir_t *);
void semanage_boolean_free(semanage_boolean_t *);
void semanage_tunable_free(semanage_tunable_t *);

all of the structures have free's


--
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: [RFC] selinux management API

[Ivan Gyurdiev]

On Fri, 2005-07-15 at 15:29 -0400, Joshua Brindle wrote:
> On Fri, 2005-07-15 at 15:19 -0400, Ivan Gyurdiev wrote:
> > int semanage_user_remove(semanage_handle_t *, semanage_user_t
> > *userdata);
> > 
> > You want to remove based on name, not based on a full
> > data structure. Similarly there should be a query function.
> > 
> But maybe not in the future, this is meant to be future-proof

Hmm....looks strange, but that's a good point.

> and the query functions can be added in, but those are convenience
> functions and have nothing to do with the design we are proposing here.

You don't seem to like implementation details :)

I think it's all about the implementation details...
the interface is a great guideline, but in the end all of this
has to be implemented, and it has to be convenient for the caller..

> > void semanage_user_free(semanage_user_t *);
> > 
> > Seems to me like the free functions should be declared
> > with the other handlers for their corresponding opaque 
> > data structure (which are not shown here).
> 
> eh? 
> void semanage_module_info_free(semanage_module_info_t *);
> void semanage_homedir_free(semanage_homedir_t *);
> void semanage_boolean_free(semanage_boolean_t *);
> void semanage_tunable_free(semanage_tunable_t *);
> 
> all of the structures have free's

Yes, I think they should be moved into individual headers for
each structure, where the accessors, and constructor are defined...
wherever the constructor is, the free() should accompany 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: [RFC] selinux management API

[Joshua Brindle]

On Fri, 2005-07-15 at 15:45 -0400, Ivan Gyurdiev wrote:
> On Fri, 2005-07-15 at 15:29 -0400, Joshua Brindle wrote:
> > On Fri, 2005-07-15 at 15:19 -0400, Ivan Gyurdiev wrote:
> > > int semanage_user_remove(semanage_handle_t *, semanage_user_t
> > > *userdata);
> > > 
> > > You want to remove based on name, not based on a full
> > > data structure. Similarly there should be a query function.
> > > 
> > But maybe not in the future, this is meant to be future-proof
> 
> Hmm....looks strange, but that's a good point.
> 
> > and the query functions can be added in, but those are convenience
> > functions and have nothing to do with the design we are proposing here.
> 
> You don't seem to like implementation details :)
> 
not during design

> I think it's all about the implementation details...
> the interface is a great guideline, but in the end all of this
> has to be implemented, and it has to be convenient for the caller..
> 

thats fine but we want a future proof, stable, scalable API, the
implementation details will be handled at implementation time.

> > > void semanage_user_free(semanage_user_t *);
> > > 
> > > Seems to me like the free functions should be declared
> > > with the other handlers for their corresponding opaque 
> > > data structure (which are not shown here).
> > 
> > eh? 
> > void semanage_module_info_free(semanage_module_info_t *);
> > void semanage_homedir_free(semanage_homedir_t *);
> > void semanage_boolean_free(semanage_boolean_t *);
> > void semanage_tunable_free(semanage_tunable_t *);
> > 
> > all of the structures have free's
> 
> Yes, I think they should be moved into individual headers for
> each structure, where the accessors, and constructor are defined...
> wherever the constructor is, the free() should accompany it. 

Ah, I get what you mean now. The accessors, constructors, free's, etc
will be in this header since it will be the single exported API file for
libsemanage. They just weren't added to this because they are
implementation details :)

Joshua


--
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: [RFC] selinux management API

[Ivan Gyurdiev]

> > I think it's all about the implementation details...
> > the interface is a great guideline, but in the end all of this
> > has to be implemented, and it has to be convenient for the caller..
> > 
> 
> thats fine but we want a future proof, stable, scalable API, the
> implementation details will be handled at implementation time.

I was under the impression that you'd want me to help with the
implementation... I already have code that does precisely this.
With some modification, it can be made to work on libsemanage.

====

Anyway, I still don't understand how you plan to do the 
template expansion - you're treating that as an implementation detail,
and I think you shouldn't overlook this concern, because it's
not clear how it will work. 


--
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: [RFC] selinux management API

[Russell Coker]

On Saturday 16 July 2005 04:12, Joshua Brindle <jbrindle@tresys.com> wrote:
> I think this summarizes the dialog well Ivan, thanks.
>
> Attached is an updated header file that uses structs for all

int semanage_module_install(semanage_handle_t *,
                            char *module_data, size_t data_len);
int semanage_module_upgrade(semanage_handle_t *,
                            char *module_data, size_t data_len);
int semanage_module_install_base(semanage_handle_t *,
                                 char *module_data, size_t data_len);

Is the plan to support binary or text modules for these operations?  If binary 
modules then module_data should have type void *.

Also more liberal use of const would be good.  I expect that the above 
functions will not change the module data so const void * would probably be 
the correct type.  I realise that this is still in the design phase, but I 
think that we are ready to design which data gets modified by the library 
code and which doesn't.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
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: [RFC] selinux management API

[Joshua Brindle]

Russell Coker wrote:

>On Saturday 16 July 2005 04:12, Joshua Brindle <jbrindle@tresys.com> wrote:
>  
>
>>I think this summarizes the dialog well Ivan, thanks.
>>
>>Attached is an updated header file that uses structs for all
>>    
>>
>
>int semanage_module_install(semanage_handle_t *,
>                            char *module_data, size_t data_len);
>int semanage_module_upgrade(semanage_handle_t *,
>                            char *module_data, size_t data_len);
>int semanage_module_install_base(semanage_handle_t *,
>                                 char *module_data, size_t data_len);
>
>Is the plan to support binary or text modules for these operations?  If binary 
>modules then module_data should have type void *.
>
>  
>
Yea, I'd like to make this able to handle the monolithic policy and 
modules but I haven't figured out exactly how that is going to work yet.

I think that for the monolithic case you may be limited to only the 
special modifiers (eg., users, ports, booleans, etc) and so this would 
not apply to it, I'm not quite sure yet though.

>Also more liberal use of const would be good.  I expect that the above 
>functions will not change the module data so const void * would probably be 
>the correct type.  I realise that this is still in the design phase, but I 
>think that we are ready to design which data gets modified by the library 
>code and which doesn't.
>  
>
sure but only if it doesn't ripple throughout the rest of the library

--
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: [RFC] selinux management API

[Russell Coker]

On Thursday 28 July 2005 23:43, Joshua Brindle <jbrindle@tresys.com> wrote:
> >Also more liberal use of const would be good.  I expect that the above
> >functions will not change the module data so const void * would probably
> > be the correct type.  I realise that this is still in the design phase,
> > but I think that we are ready to design which data gets modified by the
> > library code and which doesn't.
>
> sure but only if it doesn't ripple throughout the rest of the library

It would only ripple throughout the rest of the library if necessary.

If a function has a const parameter and then passes that parameter to another 
function then either the second function needs a const parameter or the data 
must be copied.  This is a feature not a bug!

When my code passes data to a library function via a const pointer then I know 
that (as long as there are no bugs in the library) the data will not be 
modified.  If the pointer is not const then it may be modified and my program 
has to correctly manage the situation where it is changed.

If the code is designed well then using const in all the places that the 
design suggests it will not be difficult or complex.  If the code is badly 
designed then it needs a better design.  In either case there is no reason 
for not using const!

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
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: [RFC] selinux management API

[Jason Tang]

On Thu, 2005-07-28 at 18:36 +1000, Russell Coker wrote:
> int semanage_module_install(semanage_handle_t *,
>                             char *module_data, size_t data_len);
> int semanage_module_upgrade(semanage_handle_t *,
>                             char *module_data, size_t data_len);
> int semanage_module_install_base(semanage_handle_t *,
>                                  char *module_data, size_t data_len);
> 
> Is the plan to support binary or text modules for these operations?  If binary 
> modules then module_data should have type void *.

libsemanage will handle only binary modules.  The caller is assumed to
have invoked checkmodule beforehand.

The reason why these pointers are 'char' is that we want
byte-addressible memory.  It is true that using 'char' can be
misleading, but alas C is deficient here.

-- 
Jason Tang / jtang@tresys.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: [RFC] selinux management API

[Russell Coker]

On Tuesday 02 August 2005 04:12, Jason Tang <jtang@tresys.com> wrote:
> > Is the plan to support binary or text modules for these operations?  If
> > binary modules then module_data should have type void *.
>
> libsemanage will handle only binary modules.  The caller is assumed to
> have invoked checkmodule beforehand.
>
> The reason why these pointers are 'char' is that we want
> byte-addressible memory.  It is true that using 'char' can be
> misleading, but alas C is deficient here.

In what situations is void * not byte addressable?

System calls such as send(2) use void * on Linux (char * on Solaris), are you 
saying that you can't send arbitrary data down a socket?

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

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