[PATCH] semanage-functionality 4/17

[PATCH] semanage-functionality 4/17

[Karl MacMillan]

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

This patch adds semanage.h - this is the new public interface for
libsemanage.

------
Karl MacMillan
Tresys Technology
http://www.tresys.com 


[-- Attachment #2: libsemanage_include_semanage_semanage.h.diff --]
[-- Type: application/octet-stream, Size: 9065 bytes --]

diff -purN -x .svn libsemanage/include/semanage/semanage.h libsemanage/include/semanage/semanage.h
--- libsemanage/include/semanage/semanage.h	1969-12-31 19:00:00.000000000 -0500
+++ libsemanage/include/semanage/semanage.h	2005-09-26 09:59:04.000000000 -0400
@@ -0,0 +1,203 @@
+/* Authors: Joshua Brindle  <jbrindle@tresys.com>
+ *	    Jason Tang	    <jtang@tresys.com>
+ *
+ * Copyright (C) 2005 Tresys Technology, LLC
+ *
+ *  This library is free software; you can redistribute it and/or
+ *  modify it under the terms of the GNU Lesser General Public
+ *  License as published by the Free Software Foundation; either
+ *  version 2.1 of the License, or (at your option) any later version.
+ *
+ *  This library is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ *  Lesser General Public License for more details.
+ *
+ *  You should have received a copy of the GNU Lesser General Public
+ *  License along with this library; if not, write to the Free Software
+ *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ */
+
+#ifndef SEMANAGE_H
+#define SEMANAGE_H
+
+/* 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_destroy(). */
+typedef struct semanage_handle semanage_handle_t;
+
+/* Initialize the library - this needs to be called first. This loads
+ * any defaults from the configuration files and performs any other
+ * needed initialization.
+ * 
+ * returns:
+ *	0	success
+ *	-1	general error
+ *	-2	error parsing configuration files
+ *
+ * WARNING: This function is NOT thread-safe.
+ */
+int semanage_init(void);
+
+/* "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_destroy().  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_destroy(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, so make a copy of it if necessary.
+ */
+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 in the handle.
+ *
+ * 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. */
+int semanage_begin_transaction(semanage_handle_t *);
+
+/* 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.  Return that policy number
+ * afterwards, or -1 on error.
+ */
+int semanage_commit(semanage_handle_t *);
+
+
+/* META NOTES
+ *
+ * All of the below functions expect 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. For query 
+ * fucntions a >=0 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.
+ */
+
+/* High level module management functions. These are all part of
+ * a transaction  
+ */
+
+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);
+
+
+/* semanage_module_info is for getting information on installed
+   modules, only name and version at this time */
+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_datum_destroy(semanage_module_info_t *);
+semanage_module_info_t *semanage_module_list_nth(semanage_module_info_t *list, int n);
+const char *semanage_module_get_name(semanage_module_info_t *);
+const char *semanage_module_get_version(semanage_module_info_t *);
+
+/* accessors for mls and role support structs */
+typedef struct semanage_mls semanage_mls_t;
+typedef struct semanage_role semanage_role_t;
+
+const char* semanage_mls_get_range(semanage_mls_t *);
+const char* semanage_mls_get_level(semanage_mls_t *);
+
+int semanage_mls_set_range(semanage_mls_t *);
+int semanage_mls_set_level(semanage_mls_t *);
+
+const char* semanage_role_get_name(semanage_role_t *);
+
+int semanage_role_set_name(semanage_role_t *, char *name);
+
+/* semanage_user represents selinux users in the policy */
+typedef struct semanage_user semanage_user_t;
+
+/* semanage_user management functions */
+int semanage_user_init(semanage_handle_t **);
+int semanage_user_add(semanage_handle_t *, semanage_user_t *userdata);
+int semanage_user_remove(semanage_handle_t *, char *userdata);
+int semanage_user_list(semanage_handle_t *, semanage_user_t **users, int *num_users);
+int semanage_user_change(semanage_handle_t *, semanage_user_t *userdata, char *key);
+void semanage_user_free(semanage_user_t *);
+
+/* semanage_user accessor functions */
+const char* semanage_user_get_name(semanage_user_t *);
+int semanage_user_get_roles(semanage_user_t *, semanage_role_t **roles, int num_roles);
+int semanage_user_get_mls(semanage_user_t *, semanage_mls_t *mls);
+ 
+int semanage_user_set_name(semanage_user_t *, char *name);
+int semanage_user_set_roles(semanage_user_t *, semanage_role_t **roles, int num_roles);
+int semanage_user_set_mls(semanage_user_t *, semanage_mls_t *mls);
+
+/* semanage_homedir manages selinux_user->directory maps so that 
+   we can expand home directory contexts */
+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 *);
+
+/* semanage_homedir accessors */
+
+const char* semanage_homedir_get_user(semanage_handle_t *);
+const char* semanage_homedir_get_path(semanage_handle_t *);
+
+int semanage_homedir_set_user(semanage_handle_t *, char *user);
+int semanage_homedir_set_path(semanage_handle_t *, char *path); 
+
+/* semanage_boolean manages default boolean states */
+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 -- only if something enforces that (eg. policy server) */
+int semanage_boolean_list(semanage_handle_t *, semanage_boolean_t **, int *num_bools);
+void semanage_boolean_free(semanage_boolean_t *);
+
+/* semanage_boolean accessors */
+
+const char *semanage_boolean_get_name(semanage_boolean_t *);
+char semanage_boolean_get_state(semanage_boolean_t *);
+
+int semanage_boolean_set_name(semanage_boolean_t *, char *name);
+int semanage_boolean_set_state(semanage_boolean_t *, char state);
+
+#endif

Re: [PATCH] semanage-functionality 4/17

[Ivan Gyurdiev]

\Karl MacMillan wrote:

>This patch adds semanage.h - this is the new public interface for
>libsemanage.
>  
>
Why is it that you have to keep re-adding the components that I'm 
currently working on. Please leave those out of the semanage.h header 
for now. If you don't approve of my APIs, then you should submit patches 
on top of them, instead of introducing duplicate work. Anything that 
says semanage_mls_* semanage_user_*, semanage_boolean_*, and 
semanage_homedir_* should be left out for now.

1) Users - those will be handled via the user_record data structure, 
which is already in CVS. The implementation is in sepol, but I've 
uninlined the data structure, so the API is now opaque.

2) Booleans - those will be handle via the boolean_record data 
structure. I have no included that in semanage yet, because I'm still 
testing how other records (like the user record) will work, but you can 
look at the data structure in sepol.

3) Homedirs - this part of the API is too unclear to add at this point 
(at least, it's not clear to me yet, and I'll probably be implementing it..)

P.S. Your semanage header should likely draw in my user/port/record 
headers, but please don't do this yet, as those interfaces are in flux. 
Also, I think the handle stuff and the module stuff should go into 
separate headers, and you should include those into semanage.h.

--
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: [PATCH] semanage-functionality 4/17

[Stephen Smalley]

On Tue, 2005-09-27 at 12:54 -0400, Ivan Gyurdiev wrote:
> Why is it that you have to keep re-adding the components that I'm 
> currently working on. Please leave those out of the semanage.h header 
> for now. If you don't approve of my APIs, then you should submit patches 
> on top of them, instead of introducing duplicate work. Anything that 
> says semanage_mls_* semanage_user_*, semanage_boolean_*, and 
> semanage_homedir_* should be left out for now.

Ack, I'll prune these prior to merging.

> P.S. Your semanage header should likely draw in my user/port/record 
> headers, but please don't do this yet, as those interfaces are in flux. 
> Also, I think the handle stuff and the module stuff should go into 
> separate headers, and you should include those into semanage.h.

This also makes sense to me.  

A consistency nitpick:  we have decidedly mixed usage of typedefs in
libsemanage and libsepol, with some typedefs being pointers to structs
and others being aliases for structs.  Possibly we just need to
aggressively prune typedefs throughout.  They seem to offer little real
benefit for the struct types, and are more likely to just cause
confusion in maintaining the code.

-- 
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: [PATCH] semanage-functionality 4/17

[Ivan Gyurdiev]

>A consistency nitpick:  we have decidedly mixed usage of typedefs in
>libsemanage and libsepol, with some typedefs being pointers to structs
>and others being aliases for structs.  
>
Most likely my fault - I introduced the pointer ones for records - that 
can be changed if necessary. The nice thing about pointer typedefs is 
that the pointer is hidden within the data type, which makes it possible 
to eliminate, if necessary - type can be replaced with a primitive 
without changing any of the functions to get rid of the star.... not 
that we're ever going to use primitive types for any of those things.

>Possibly we just need to
>aggressively prune typedefs throughout.  They seem to offer little real
>benefit for the struct types, and are more likely to just cause
>confusion in maintaining the code.
>  
>
Then we'll have to type struct everywhere...

--
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: [PATCH] semanage-functionality 4/17

[Stephen Smalley]

On Tue, 2005-09-27 at 16:48 -0400, Ivan Gyurdiev wrote:
> Most likely my fault - I introduced the pointer ones for records - that 
> can be changed if necessary. The nice thing about pointer typedefs is 
> that the pointer is hidden within the data type, which makes it possible 
> to eliminate, if necessary - type can be replaced with a primitive 
> without changing any of the functions to get rid of the star.... not 
> that we're ever going to use primitive types for any of those things.

Yes, and I'm dubious that such elimination is practically useful; you
still have to audit the code for correct usage and in any case where it
affects an exposed interface, you have the whole stable API/ABI issue to
deal with.

> Then we'll have to type struct everywhere...

Yes, I see it as a benefit to be able to easily see from the code
whether a function (and the code) is dealing with a pointer or a struct
without needing to look up a separate type definition.  Think in terms
of long term code maintainability / readability, particularly for
patches.  Besides, typing "struct foobahblaz" isn't so much worse than
typing "foobahblaz_t".  The kernel maintainers are right on the issue of
typedefs...

-- 
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: [PATCH] semanage-functionality 4/17

[Ivan Gyurdiev]

>Yes, and I'm dubious that such elimination is practically useful; you
>still have to audit the code for correct usage and in any case where it
>affects an exposed interface, you have the whole stable API/ABI issue to
>deal with.
>  
>
Struct pointer typedefs eliminated in favor of consistency.  See patches.

>  
>
>>Then we'll have to type struct everywhere...
>>    
>>
>
>Yes, I see it as a benefit to be able to easily see from the code
>whether a function (and the code) is dealing with a pointer or a struct
>without needing to look up a separate type definition.  Think in terms
>of long term code maintainability / readability, particularly for
>patches.  Besides, typing "struct foobahblaz" isn't so much worse than
>typing "foobahblaz_t".  The kernel maintainers are right on the issue of
>typedefs...
>  
>
Todo. I am less excited about removing the _t types - I don't like 
typing struct... You can now see whether you are dealing with a pointer 
or struct...because there are no more pointer typedefs...so there's a 
star everywhere, meaning pointer. I'm not sure that was a good idea, but 
at least it's consistent, which is much better than being inconsistent 
(of course, we could have tried to go the other way instead too...).



--
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: [PATCH] semanage-functionality 4/17

[Karl MacMillan]

> -----Original Message-----
> From: Ivan Gyurdiev [mailto:ivg2@cornell.edu]
> Sent: Friday, September 30, 2005 9:03 AM
> To: Stephen Smalley
> Cc: Karl MacMillan; selinux@tycho.nsa.gov; 'Joshua Brindle'
> Subject: Re: [PATCH] semanage-functionality 4/17
> 
> 
> >Yes, and I'm dubious that such elimination is practically useful; you
> >still have to audit the code for correct usage and in any case where it
> >affects an exposed interface, you have the whole stable API/ABI issue to
> >deal with.
> >
> >
> Struct pointer typedefs eliminated in favor of consistency.  See patches.
> 
> >
> >
> >>Then we'll have to type struct everywhere...
> >>
> >>
> >
> >Yes, I see it as a benefit to be able to easily see from the code
> >whether a function (and the code) is dealing with a pointer or a struct
> >without needing to look up a separate type definition.  Think in terms
> >of long term code maintainability / readability, particularly for
> >patches.  Besides, typing "struct foobahblaz" isn't so much worse than
> >typing "foobahblaz_t".  The kernel maintainers are right on the issue of
> >typedefs...
> >
> >
> Todo. I am less excited about removing the _t types - I don't like
> typing struct... You can now see whether you are dealing with a pointer
> or struct...because there are no more pointer typedefs...so there's a
> star everywhere, meaning pointer. I'm not sure that was a good idea, but
> at least it's consistent, which is much better than being inconsistent
> (of course, we could have tried to go the other way instead too...).

I agree with Steve here - the more information the user of a type is aware
of the better. In my experience, typedef pointers just become confusing and
hard to maintain. Typedef's are useful when the type will change (e.g.,
uint23_t) but not to simply obscure type information.

Karl

------
Karl MacMillan
Tresys Technology
http://www.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: [PATCH] semanage-functionality 4/17

[Karl MacMillan]

> -----Original Message-----
> From: Stephen Smalley [mailto:sds@tycho.nsa.gov]
> Sent: Tuesday, September 27, 2005 4:09 PM
> To: Ivan Gyurdiev
> Cc: Karl MacMillan; selinux@tycho.nsa.gov; 'Joshua Brindle'
> Subject: Re: [PATCH] semanage-functionality 4/17
> 
> On Tue, 2005-09-27 at 12:54 -0400, Ivan Gyurdiev wrote:
> > Why is it that you have to keep re-adding the components that I'm
> > currently working on. Please leave those out of the semanage.h header
> > for now. If you don't approve of my APIs, then you should submit patches
> > on top of them, instead of introducing duplicate work. Anything that
> > says semanage_mls_* semanage_user_*, semanage_boolean_*, and
> > semanage_homedir_* should be left out for now.
> 
> Ack, I'll prune these prior to merging.
> 
> > P.S. Your semanage header should likely draw in my user/port/record
> > headers, but please don't do this yet, as those interfaces are in flux.
> > Also, I think the handle stuff and the module stuff should go into
> > separate headers, and you should include those into semanage.h.
> 
> This also makes sense to me.
> 
> A consistency nitpick:  we have decidedly mixed usage of typedefs in
> libsemanage and libsepol, with some typedefs being pointers to structs
> and others being aliases for structs.  Possibly we just need to
> aggressively prune typedefs throughout.  They seem to offer little real
> benefit for the struct types, and are more likely to just cause
> confusion in maintaining the code.
> 

I agree that making the specifics of the type clear at the point in the code
that it is used is best. Too bad we didn't strip the typedefs way back when
they were stripped from the kernel code . . .

Karl

------
Karl MacMillan
Tresys Technology
http://www.tresys.com

> --
> 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: [PATCH] semanage-functionality 4/17

[Karl MacMillan]

> -----Original Message-----
> From: Ivan Gyurdiev [mailto:ivg2@cornell.edu]
> Sent: Tuesday, September 27, 2005 12:55 PM
> To: Karl MacMillan
> Cc: selinux@tycho.nsa.gov; 'Joshua Brindle'
> Subject: Re: [PATCH] semanage-functionality 4/17
> 
> \Karl MacMillan wrote:
> 
> >This patch adds semanage.h - this is the new public interface for
> >libsemanage.
> >
> >
> Why is it that you have to keep re-adding the components that I'm
> currently working on. Please leave those out of the semanage.h header
> for now. If you don't approve of my APIs, then you should submit patches
> on top of them, instead of introducing duplicate work. Anything that
> says semanage_mls_* semanage_user_*, semanage_boolean_*, and
> semanage_homedir_* should be left out for now.
> 

These are the stubs that we put in a while ago - we will send a patch to
remove those. I would prefer that everything be in semanage.h, however. I
don't think that it will make the header too long and it will make it
clearer I believe. 

> 1) Users - those will be handled via the user_record data structure,
> which is already in CVS. The implementation is in sepol, but I've
> uninlined the data structure, so the API is now opaque.
> 

These also need to be routed through the handle function pointers so that
alternative implementations for the policy server can be provided. This can
be done by:

1) adding the function pointers to the semanage_func_table in
src/include/semanage_private.h.

2) Adding a routing function in semanage.c that calls the function pointer
in the handle and performs any error passing. This function cannot assume
any implementation details.

3) Filling in the function pointers in semange_direct_connect
(direct_api.c).

> 2) Booleans - those will be handle via the boolean_record data
> structure. I have no included that in semanage yet, because I'm still
> testing how other records (like the user record) will work, but you can
> look at the data structure in sepol.
> 
> 3) Homedirs - this part of the API is too unclear to add at this point
> (at least, it's not clear to me yet, and I'll probably be implementing
> it..)
> 

We'll leave these in for now as we work on what they should look like.

> P.S. Your semanage header should likely draw in my user/port/record
> headers, but please don't do this yet, as those interfaces are in flux.
> Also, I think the handle stuff and the module stuff should go into
> separate headers, and you should include those into semanage.h.

As above - I disagree. I would prefer a single header for everything that
works with the transactions. The header will not be that large and it makes
it easier to see the API as a whole.

Karl

------
Karl MacMillan
Tresys Technology
http://www.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: [PATCH] semanage-functionality 4/17

[Ivan Gyurdiev]

>These also need to be routed through the handle function pointers so that
>alternative implementations for the policy server can be provided. This can
>be done by:
>
>1) adding the function pointers to the semanage_func_table in
>src/include/semanage_private.h.
>
>2) Adding a routing function in semanage.c that calls the function pointer
>in the handle and performs any error passing. This function cannot assume
>any implementation details.
>
>3) Filling in the function pointers in semange_direct_connect
>(direct_api.c).
>  
>
...I'll get to this eventually... the first portion (passing the handle) 
was in my dbase initialization patch, but I need to update that to fit 
with your code. It's not entirely clear how policy connections will work 
- that's the next thing I was going to figure out. I want to fill out 
another record table for policy functions (look at the initialization 
patch, and how it separates things out into several tables).

--
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: [PATCH] semanage-functionality 4/17

[Stephen Smalley]

On Tue, 2005-09-27 at 16:38 -0400, Karl MacMillan wrote:
> These are the stubs that we put in a while ago - we will send a patch to
> remove those. I would prefer that everything be in semanage.h, however. I
> don't think that it will make the header too long and it will make it
> clearer I believe. 

Clearer in what sense?  Logically, the module interfaces are distinct
from the user interfaces, and they will have different clients
(programs) typically.  

> These also need to be routed through the handle function pointers so that
> alternative implementations for the policy server can be provided.

Right, the handles have to be common to all, but that can certainly be
done by a handle.h that is included by the other headers.

> As above - I disagree. I would prefer a single header for everything that
> works with the transactions. The header will not be that large and it makes
> it easier to see the API as a whole.

But if the API consists of logically separable components, with
different clients/users, then why do you want that?

-- 
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: [PATCH] semanage-functionality 4/17

[Karl MacMillan]

> -----Original Message-----
> From: Stephen Smalley [mailto:sds@tycho.nsa.gov]
> Sent: Tuesday, September 27, 2005 5:10 PM
> To: Karl MacMillan
> Cc: 'Ivan Gyurdiev'; selinux@tycho.nsa.gov; 'Joshua Brindle'
> Subject: RE: [PATCH] semanage-functionality 4/17
> 
> On Tue, 2005-09-27 at 16:38 -0400, Karl MacMillan wrote:
> > These are the stubs that we put in a while ago - we will send a patch to
> > remove those. I would prefer that everything be in semanage.h, however.
> I
> > don't think that it will make the header too long and it will make it
> > clearer I believe.
> 
> Clearer in what sense?  Logically, the module interfaces are distinct
> from the user interfaces, and they will have different clients
> (programs) typically.
> 

Clearer in that the whole API is visible in a single file. I don't feel
strongly about this - it is a matter of preference. I'm in the minority
here, I guess, so I'll go with the separate headers. I would also like to
separate out semanage.c in that case - I do have a preference for c and h
files matching closely unless there is a reason not to.

Karl

> > These also need to be routed through the handle function pointers so
> that
> > alternative implementations for the policy server can be provided.
> 
> Right, the handles have to be common to all, but that can certainly be
> done by a handle.h that is included by the other headers.
> 
> > As above - I disagree. I would prefer a single header for everything
> that
> > works with the transactions. The header will not be that large and it
> makes
> > it easier to see the API as a whole.
> 
> But if the API consists of logically separable components, with
> different clients/users, then why do you want that?
> 
> --
> Stephen Smalley
> National Security Agency

------
Karl MacMillan
Tresys Technology
http://www.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: [PATCH] semanage-functionality 4/17

[Stephen Smalley]

On Tue, 2005-09-27 at 08:46 -0400, Karl MacMillan wrote:
> This patch adds semanage.h - this is the new public interface for
> libsemanage.

diff -purN -x .svn libsemanage/include/semanage/semanage.h libsemanage/include/semanage/semanage.h
--- libsemanage/include/semanage/semanage.h	1969-12-31 19:00:00.000000000 -0500
+++ libsemanage/include/semanage/semanage.h	2005-09-26 09:59:04.000000000 -0400
<snip>
+/* This #include needed to get struct timeval. */
+#include <sys/time.h>

I don't see why this is needed in the header.  Will move to the particular .c file
in question.

+/* 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_destroy(). */
+typedef struct semanage_handle semanage_handle_t;

It seems cleaner to separate create from connect, to parallel the
separation of disconnect from destroy.  Further, the implementation
already makes this easy to do; just need to make the
semanage_handle_create function exported and change connect to take an
already created handle rather than creating one of its own.  Barring
objections, I will do this.

Also, moving to handle.h, #include'd by this and other headers that use
it.

+/* Initialize the library - this needs to be called first. This loads
+ * any defaults from the configuration files and performs any other
+ * needed initialization.
+ * 
+ * returns:
+ *	0	success
+ *	-1	general error
+ *	-2	error parsing configuration files
+ *
+ * WARNING: This function is NOT thread-safe.
+ */
+int semanage_init(void);

Seems odd, particularly given that the implementation doesn't use it or
rely on it.  I'd expect it to be done via library constructor instead,
with the other functions just checking a flag on entry to verify
successful initialization (bailing immediately with an error otherwise).
Will drop barring objections.

+/* "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_destroy().  If the connect fails then this
+ * function returns a negative value, else it returns zero.
+ */
+int semanage_connect(semanage_handle_t **);

Will split out the create interface as noted above.
Unclear as to whether these also go to handle.h or a separate
transaction.h.

+/* 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 *);

Will move to same place as connect.

+/* 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_destroy(semanage_handle_t *);

Will move to handle.h.

+/* 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, so make a copy of it if necessary.
+ */
+const char *semanage_strerror(semanage_handle_t *);

Will move to handle.h.

+/* 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 in the handle.
+ *
+ * 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. */
+int semanage_begin_transaction(semanage_handle_t *);

Will move to transaction.h.

+/* 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.  Return that policy number
+ * afterwards, or -1 on error.
+ */
+int semanage_commit(semanage_handle_t *);

Will move to transaction.h.

+/* META NOTES
+ *
+ * All of the below functions expect 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. For query 
+ * fucntions a >=0 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.
+ */

Will move to handle.h.

+/* High level module management functions. These are all part of
+ * a transaction  
+ */
+
+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);
+
+
+/* semanage_module_info is for getting information on installed
+   modules, only name and version at this time */
+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_datum_destroy(semanage_module_info_t *);
+semanage_module_info_t *semanage_module_list_nth(semanage_module_info_t *list, int n);
+const char *semanage_module_get_name(semanage_module_info_t *);
+const char *semanage_module_get_version(semanage_module_info_t *);

Will move to modules.h.

+/* accessors for mls and role support structs */
+typedef struct semanage_mls semanage_mls_t;
+typedef struct semanage_role semanage_role_t;
+
+const char* semanage_mls_get_range(semanage_mls_t *);
+const char* semanage_mls_get_level(semanage_mls_t *);
+
+int semanage_mls_set_range(semanage_mls_t *);
+int semanage_mls_set_level(semanage_mls_t *);
+
+const char* semanage_role_get_name(semanage_role_t *);
+
+int semanage_role_set_name(semanage_role_t *, char *name);
+
+/* semanage_user represents selinux users in the policy */
+typedef struct semanage_user semanage_user_t;
+
+/* semanage_user management functions */
+int semanage_user_init(semanage_handle_t **);
+int semanage_user_add(semanage_handle_t *, semanage_user_t *userdata);
+int semanage_user_remove(semanage_handle_t *, char *userdata);
+int semanage_user_list(semanage_handle_t *, semanage_user_t **users, int *num_users);
+int semanage_user_change(semanage_handle_t *, semanage_user_t *userdata, char *key);
+void semanage_user_free(semanage_user_t *);
+
+/* semanage_user accessor functions */
+const char* semanage_user_get_name(semanage_user_t *);
+int semanage_user_get_roles(semanage_user_t *, semanage_role_t **roles, int num_roles);
+int semanage_user_get_mls(semanage_user_t *, semanage_mls_t *mls);
+ 
+int semanage_user_set_name(semanage_user_t *, char *name);
+int semanage_user_set_roles(semanage_user_t *, semanage_role_t **roles, int num_roles);
+int semanage_user_set_mls(semanage_user_t *, semanage_mls_t *mls);
+
+/* semanage_homedir manages selinux_user->directory maps so that 
+   we can expand home directory contexts */
+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 *);
+
+/* semanage_homedir accessors */
+
+const char* semanage_homedir_get_user(semanage_handle_t *);
+const char* semanage_homedir_get_path(semanage_handle_t *);
+
+int semanage_homedir_set_user(semanage_handle_t *, char *user);
+int semanage_homedir_set_path(semanage_handle_t *, char *path); 
+
+/* semanage_boolean manages default boolean states */
+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 -- only if something enforces that (eg. policy server) */
+int semanage_boolean_list(semanage_handle_t *, semanage_boolean_t **, int *num_bools);
+void semanage_boolean_free(semanage_boolean_t *);
+
+/* semanage_boolean accessors */
+
+const char *semanage_boolean_get_name(semanage_boolean_t *);
+char semanage_boolean_get_state(semanage_boolean_t *);
+
+int semanage_boolean_set_name(semanage_boolean_t *, char *name);
+int semanage_boolean_set_state(semanage_boolean_t *, char state);

Dropping all of these.

-- 
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: [PATCH] semanage-functionality 4/17

[Ivan Gyurdiev]

>+/* 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_destroy(). */
>+typedef struct semanage_handle semanage_handle_t;
>
>It seems cleaner to separate create from connect, to parallel the
>separation of disconnect from destroy.  Further, the implementation
>already makes this easy to do; just need to make the
>semanage_handle_create function exported and change connect to take an
>already created handle rather than creating one of its own.  Barring
>objections, I will do this.
>  
>
Yes! I was trying to write a sample session with libsemanage yesterday, 
to imagine how it would work. I think we should allow queries on local 
files with disconnected handles (there's no reason to connect to any 
policy server (or create a policydb object), just to enumerate all local 
users or booleans (not base), for example).



--
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: [PATCH] semanage-functionality 4/17

[Karl MacMillan]

> -----Original Message-----
> From: Ivan Gyurdiev [mailto:ivg2@cornell.edu]
> Sent: Wednesday, September 28, 2005 11:21 AM
> To: Stephen Smalley
> Cc: Karl MacMillan; selinux@tycho.nsa.gov; 'Joshua Brindle'
> Subject: Re: [PATCH] semanage-functionality 4/17
> 
> 
> >+/* 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_destroy(). */
> >+typedef struct semanage_handle semanage_handle_t;
> >
> >It seems cleaner to separate create from connect, to parallel the
> >separation of disconnect from destroy.  Further, the implementation
> >already makes this easy to do; just need to make the
> >semanage_handle_create function exported and change connect to take an
> >already created handle rather than creating one of its own.  Barring
> >objections, I will do this.
> >
> >
> Yes! I was trying to write a sample session with libsemanage yesterday,
> to imagine how it would work. I think we should allow queries on local
> files with disconnected handles (there's no reason to connect to any
> policy server (or create a policydb object), just to enumerate all local
> users or booleans (not base), for example).

I disagree - in order to enforce security on the viewing of users, booleans,
etc. you need to get these from the policy server. The client may not have
permission to directly view the files.

All functions should, I believe, fail if you have not connected.

Karl

------
Karl MacMillan
Tresys Technology
http://www.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: [PATCH] semanage-functionality 4/17

[Karl MacMillan]

> -----Original Message-----
> From: Stephen Smalley [mailto:sds@tycho.nsa.gov]
> Sent: Wednesday, September 28, 2005 10:52 AM
> To: Karl MacMillan
> Cc: Ivan Gyurdiev; selinux@tycho.nsa.gov; 'Joshua Brindle'
> Subject: Re: [PATCH] semanage-functionality 4/17
> 
> On Tue, 2005-09-27 at 08:46 -0400, Karl MacMillan wrote:
> > This patch adds semanage.h - this is the new public interface for
> > libsemanage.
> 
> diff -purN -x .svn libsemanage/include/semanage/semanage.h
> libsemanage/include/semanage/semanage.h
> --- libsemanage/include/semanage/semanage.h	1969-12-31
> 19:00:00.000000000 -0500
> +++ libsemanage/include/semanage/semanage.h	2005-09-26
> 09:59:04.000000000 -0400
> <snip>
> +/* This #include needed to get struct timeval. */
> +#include <sys/time.h>
> 
> I don't see why this is needed in the header.  Will move to the particular
> .c file
> in question.
> 

Struct timeval used to be used in the API - the header wasn't properly
removed when this was removed.

> +/* 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_destroy(). */
> +typedef struct semanage_handle semanage_handle_t;
> 
> It seems cleaner to separate create from connect, to parallel the
> separation of disconnect from destroy.  Further, the implementation
> already makes this easy to do; just need to make the
> semanage_handle_create function exported and change connect to take an
> already created handle rather than creating one of its own.  Barring
> objections, I will do this.
> 
> Also, moving to handle.h, #include'd by this and other headers that use
> it.
> 

Sounds fine to me.

> +/* Initialize the library - this needs to be called first. This loads
> + * any defaults from the configuration files and performs any other
> + * needed initialization.
> + *
> + * returns:
> + *	0	success
> + *	-1	general error
> + *	-2	error parsing configuration files
> + *
> + * WARNING: This function is NOT thread-safe.
> + */
> +int semanage_init(void);
> 
> Seems odd, particularly given that the implementation doesn't use it or
> rely on it.  I'd expect it to be done via library constructor instead,
> with the other functions just checking a flag on entry to verify
> successful initialization (bailing immediately with an error otherwise).
> Will drop barring objections.
> 

Go ahead and drop, but I would like to add it back in the future. I'm not a
big fan of library constructors, but we can do it that way if you would
prefer (partially, it makes it harder to use this as a static library I
believe).

Part of this is that config scheme currently doesn't make sense (this was
discussed in the past). The current config has 3 things:

1) Information on how to connect, etc.

2) Verification programs to run on commit.

3) Information on the location and commandline args to programs like
load_policy.

I think that 1 should move to /etc/selinux/config. This will require changes
to libselinux. Objections?

2 should be part of each policy, e.g., /etc/selinux/targeted/semanage.conf.
This is really the current config file.

3 should be dropped in favor of Makefile variables or moved to
/etc/selinux/config. I can't imagine a different load_policy per policy. 

> +/* "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_destroy().  If the connect fails then this
> + * function returns a negative value, else it returns zero.
> + */
> +int semanage_connect(semanage_handle_t **);
> 
> Will split out the create interface as noted above.
> Unclear as to whether these also go to handle.h or a separate
> transaction.h.
> 

Why not just handle.h for connections and transactions instead of the a
separate transaction.h and handle.h?

> +/* 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 *);
> 
> Will move to same place as connect.
> 
> +/* 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_destroy(semanage_handle_t *);
> 
> Will move to handle.h.
> 
> +/* 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, so make a copy of it if necessary.
> + */
> +const char *semanage_strerror(semanage_handle_t *);
> 
> Will move to handle.h.
> 
> +/* 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 in the handle.
> + *
> + * 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. */
> +int semanage_begin_transaction(semanage_handle_t *);
> 
> Will move to transaction.h.
> 

See above - seems like putting this in handle.h would be easier.

> +/* 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.  Return that policy number
> + * afterwards, or -1 on error.
> + */
> +int semanage_commit(semanage_handle_t *);
> 
> Will move to transaction.h.
> 
> +/* META NOTES
> + *
> + * All of the below functions expect 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. For query
> + * fucntions a >=0 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.
> + */
> 
> Will move to handle.h.
> 
> +/* High level module management functions. These are all part of
> + * a transaction
> + */
> +
> +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);
> +
> +
> +/* semanage_module_info is for getting information on installed
> +   modules, only name and version at this time */
> +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_datum_destroy(semanage_module_info_t *);
> +semanage_module_info_t *semanage_module_list_nth(semanage_module_info_t
> *list, int n);
> +const char *semanage_module_get_name(semanage_module_info_t *);
> +const char *semanage_module_get_version(semanage_module_info_t *);
> 
> Will move to modules.h.
> 
> +/* accessors for mls and role support structs */
> +typedef struct semanage_mls semanage_mls_t;
> +typedef struct semanage_role semanage_role_t;
> +
> +const char* semanage_mls_get_range(semanage_mls_t *);
> +const char* semanage_mls_get_level(semanage_mls_t *);
> +
> +int semanage_mls_set_range(semanage_mls_t *);
> +int semanage_mls_set_level(semanage_mls_t *);
> +
> +const char* semanage_role_get_name(semanage_role_t *);
> +
> +int semanage_role_set_name(semanage_role_t *, char *name);
> +
> +/* semanage_user represents selinux users in the policy */
> +typedef struct semanage_user semanage_user_t;
> +
> +/* semanage_user management functions */
> +int semanage_user_init(semanage_handle_t **);
> +int semanage_user_add(semanage_handle_t *, semanage_user_t *userdata);
> +int semanage_user_remove(semanage_handle_t *, char *userdata);
> +int semanage_user_list(semanage_handle_t *, semanage_user_t **users, int
> *num_users);
> +int semanage_user_change(semanage_handle_t *, semanage_user_t *userdata,
> char *key);
> +void semanage_user_free(semanage_user_t *);
> +
> +/* semanage_user accessor functions */
> +const char* semanage_user_get_name(semanage_user_t *);
> +int semanage_user_get_roles(semanage_user_t *, semanage_role_t **roles,
> int num_roles);
> +int semanage_user_get_mls(semanage_user_t *, semanage_mls_t *mls);
> +
> +int semanage_user_set_name(semanage_user_t *, char *name);
> +int semanage_user_set_roles(semanage_user_t *, semanage_role_t **roles,
> int num_roles);
> +int semanage_user_set_mls(semanage_user_t *, semanage_mls_t *mls);
> +
> +/* semanage_homedir manages selinux_user->directory maps so that
> +   we can expand home directory contexts */
> +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 *);
> +
> +/* semanage_homedir accessors */
> +
> +const char* semanage_homedir_get_user(semanage_handle_t *);
> +const char* semanage_homedir_get_path(semanage_handle_t *);
> +
> +int semanage_homedir_set_user(semanage_handle_t *, char *user);
> +int semanage_homedir_set_path(semanage_handle_t *, char *path);
> +
> +/* semanage_boolean manages default boolean states */
> +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 -- only if something enforces that (eg. policy server) */
> +int semanage_boolean_list(semanage_handle_t *, semanage_boolean_t **, int
> *num_bools);
> +void semanage_boolean_free(semanage_boolean_t *);
> +
> +/* semanage_boolean accessors */
> +
> +const char *semanage_boolean_get_name(semanage_boolean_t *);
> +char semanage_boolean_get_state(semanage_boolean_t *);
> +
> +int semanage_boolean_set_name(semanage_boolean_t *, char *name);
> +int semanage_boolean_set_state(semanage_boolean_t *, char state);
> 
> Dropping all of these.
> 

Agreed. Are you making these changes, or do you want an updated patch?

Karl

> --
> Stephen Smalley
> National Security Agency

------
Karl MacMillan
Tresys Technology
http://www.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: [PATCH] semanage-functionality 4/17

[Stephen Smalley]

On Wed, 2005-09-28 at 11:31 -0400, Karl MacMillan wrote:
> Go ahead and drop, but I would like to add it back in the future. I'm not a
> big fan of library constructors, but we can do it that way if you would
> prefer (partially, it makes it harder to use this as a static library I
> believe).
> 
> Part of this is that config scheme currently doesn't make sense (this was
> discussed in the past). The current config has 3 things:
> 
> 1) Information on how to connect, etc.
> 
> 2) Verification programs to run on commit.
> 
> 3) Information on the location and commandline args to programs like
> load_policy.
> 
> I think that 1 should move to /etc/selinux/config. This will require changes
> to libselinux. Objections?

Hmmm...that seems specific to libsemanage, although I agree it is
unlikely to be policy-specific.  Not sure it necessarily requires
changes to libselinux, unless you want libselinux to handle parsing and
extraction of the value.  I think libselinux just ignores any content
in /etc/selinux/config other than its own variables (SELINUX=,
SELINUXTYPE=), so you could introduce new tags there and have
libsemanage interpret them directly.  system-config-securitylevel just
needs to know not to clobber them.

> 2 should be part of each policy, e.g., /etc/selinux/targeted/semanage.conf.
> This is really the current config file.

Not sure about this one in practice, as a single verifier program could
certainly load policy-specific settings itself based on $SELINUXTYPE
without requiring the verifier program and args to be
policy-specific.    

> 3 should be dropped in favor of Makefile variables or moved to
> /etc/selinux/config. I can't imagine a different load_policy per policy. 

Yes, I agree.

> Why not just handle.h for connections and transactions instead of the a
> separate transaction.h and handle.h?

It is unclear to me as to whether we need connections and transactions
for all uses of libsemanage.  If we do, then I'd agree that putting them
all into handle.h is correct, but it does raise the question again of
why we have separate connect/create and disconnect/destroy (well, you
only had the latter, but it yields an inconsistent interface).

> Agreed. Are you making these changes, or do you want an updated patch?

I'm already on it.

-- 
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: [PATCH] semanage-functionality 4/17

[Karl MacMillan]

> -----Original Message-----
> From: Stephen Smalley [mailto:sds@tycho.nsa.gov]
> Sent: Wednesday, September 28, 2005 11:59 AM
> To: Karl MacMillan
> Cc: 'Ivan Gyurdiev'; selinux@tycho.nsa.gov; 'Joshua Brindle'
> Subject: RE: [PATCH] semanage-functionality 4/17
> 
> On Wed, 2005-09-28 at 11:31 -0400, Karl MacMillan wrote:
> > Go ahead and drop, but I would like to add it back in the future. I'm
> not a
> > big fan of library constructors, but we can do it that way if you would
> > prefer (partially, it makes it harder to use this as a static library I
> > believe).
> >
> > Part of this is that config scheme currently doesn't make sense (this
> was
> > discussed in the past). The current config has 3 things:
> >
> > 1) Information on how to connect, etc.
> >
> > 2) Verification programs to run on commit.
> >
> > 3) Information on the location and commandline args to programs like
> > load_policy.
> >
> > I think that 1 should move to /etc/selinux/config. This will require
> changes
> > to libselinux. Objections?
> 
> Hmmm...that seems specific to libsemanage, although I agree it is
> unlikely to be policy-specific.  Not sure it necessarily requires
> changes to libselinux, unless you want libselinux to handle parsing and
> extraction of the value.  I think libselinux just ignores any content
> in /etc/selinux/config other than its own variables (SELINUX=,
> SELINUXTYPE=), so you could introduce new tags there and have
> libsemanage interpret them directly.  system-config-securitylevel just
> needs to know not to clobber them.
> 

That sounds fine. We could also just have a separate config file (see
below).

> > 2 should be part of each policy, e.g.,
> /etc/selinux/targeted/semanage.conf.
> > This is really the current config file.
> 
> Not sure about this one in practice, as a single verifier program could
> certainly load policy-specific settings itself based on $SELINUXTYPE
> without requiring the verifier program and args to be
> policy-specific.
> 

We don't really have examples of this yet, so I would argue for the simple
approach and do something more complex later. That means, I think, that we
should move the current config to /etc/selinux/semanage.conf, simplify it a
bit, and allow the verification programes (when they appear) to load
settings based on $SELINUXTYPE.

> > 3 should be dropped in favor of Makefile variables or moved to
> > /etc/selinux/config. I can't imagine a different load_policy per policy.
> 
> Yes, I agree.
> 
> > Why not just handle.h for connections and transactions instead of the a
> > separate transaction.h and handle.h?
> 
> It is unclear to me as to whether we need connections and transactions
> for all uses of libsemanage.  If we do, then I'd agree that putting them
> all into handle.h is correct, but it does raise the question again of
> why we have separate connect/create and disconnect/destroy (well, you
> only had the latter, but it yields an inconsistent interface).
> 

I think that we always need a connection - which is why the separate create
was not provided. The separate destroy was required, however, to:

a) allow extraction of errors from the handle after disconnect and
b) permit a handle to be destroyed without disconnecting. This is required
when a client forks I believe. One of the processes will have a handle that
needs to be destroyed without disconnecting.

I think that we need to have a create to allow:

1) create a handle
2) set connection options (timeout, where to connect - remote policy server,
local policy server, direct, etc.).
3) connect.
4) etc., etc.

> > Agreed. Are you making these changes, or do you want an updated patch?
> 
> I'm already on it.
> 

Ok - after you commit your changes we will sync and get you a patch for the
other issues.

------
Karl MacMillan
Tresys Technology
http://www.tresys.com

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