[ libsepol 2/6] Ports

[ libsepol 2/6] Ports

[Ivan Gyurdiev]

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

The following patch pushes the port loading
code into libsepol. It adds a function to
load a port, and a function to get the context
for a port. No shadowing is allowed. It creates
a structure for high level representation of
a port (sepol_portinfo_t). Uses new debug system
and writes to policydb object. Comments welcome.

libsepol-1.2-ports.diff

This patch depends on:
libsepol-1.1-context.diff



[-- Attachment #2: libsepol-1.2-ports.diff --]
[-- Type: text/x-patch, Size: 5356 bytes --]

diff -aru libsepol.work/include/sepol/ports.h libsepol-1.2-ports/include/sepol/ports.h
--- libsepol.work/include/sepol/ports.h	2005-07-08 19:30:00.000000000 -0400
+++ libsepol-1.2-ports/include/sepol/ports.h	2005-07-21 08:48:52.000000000 -0400
@@ -0,0 +1,42 @@
+#ifndef _SEPOL_PORTS_H_
+#define _SEPOL_PORTS_H_
+
+#include <sepol/policydb.h>
+#include <sepol/context.h>
+
+#define SEPOL_TCP_PROTO 0
+#define SEPOL_UDP_PROTO 1
+
+/* High level representation of a port */
+typedef struct sepol_portinfo {
+
+	/* Port parameters */
+	int protocol;
+	int low, high;
+
+	/* Sufficient information to construct 
+	 * the port context */
+	sepol_ctxinfo_t con;
+} sepol_portinfo_t;
+
+/* Create a port structure from high level representation */
+extern int sepol_port_create(
+	policydb_t* policydb,
+	ocontext_t** port,
+	sepol_portinfo_t* data);
+
+/* Get the current context mapping
+ * for this port. Returns 1 if no match, -1 on error, 0 on
+ * success. The returned data is allocated on the heap */
+int sepol_port_get_context(
+	policydb_t* policydb,
+	sepol_portinfo_t* data,
+	char** con_str,
+	size_t* con_str_len);
+
+/* Load the given port into policy. No shadowing is allowed. */
+extern int sepol_port_load(
+	policydb_t* policydb, 
+	sepol_portinfo_t* port);
+
+#endif /* _SEPOL_PORTS_H_ */
diff -aru libsepol.work/src/ports.c libsepol-1.2-ports/src/ports.c
--- libsepol.work/src/ports.c	2005-07-08 19:30:04.000000000 -0400
+++ libsepol-1.2-ports/src/ports.c	2005-07-21 12:19:19.000000000 -0400
@@ -0,0 +1,167 @@
+#include <netinet/in.h>
+#include <stdlib.h>
+
+#include "debug.h"
+#include <sepol/sepol.h>
+#include <sepol/policydb.h>
+#include <sepol/context.h>
+#include <sepol/sidtab.h>
+#include <sepol/services.h>
+#include <sepol/ports.h>
+
+static const char* proto_to_str(int proto) {
+	switch(proto) {
+		case SEPOL_TCP_PROTO:
+			return "TCP";
+		case SEPOL_UDP_PROTO:
+			return "UDP";
+		default:
+			return "???";
+	}
+}
+
+static int sepol2ipproto(int proto) {
+	switch(proto) {
+		case SEPOL_TCP_PROTO:
+			return IPPROTO_TCP;
+		case SEPOL_UDP_PROTO:
+			return IPPROTO_UDP;
+		default:
+			DEBUG(__FUNCTION__, "unsupported protocol %d\n",
+                                proto);
+			return -1;
+	}
+}
+
+/* Create a low level port structure from
+ * a high level representation */
+int sepol_port_create(
+	policydb_t* policydb,
+	ocontext_t** port,
+	sepol_portinfo_t* data) {
+
+	ocontext_t* tmp_port = NULL;
+	context_struct_t* tmp_con = NULL;
+	int tmp_proto;
+
+	tmp_port = (ocontext_t *) calloc(1, sizeof(ocontext_t));
+	if (!tmp_port) {
+		DEBUG(__FUNCTION__, "out of memory\n");
+		goto err;
+	}
+	
+	/* Process protocol */
+	tmp_proto = sepol2ipproto(data->protocol);
+	if (tmp_proto < 0)
+		goto err;
+	tmp_port->u.port.protocol = tmp_proto;
+
+	/* Port range */
+	tmp_port->u.port.low_port = data->low;
+	tmp_port->u.port.high_port = data->high;
+	if (data->low > data->high) {
+		DEBUG(__FUNCTION__, "low port %d exceeds high port %d\n",
+			data->low, data->high);
+		goto err;
+	}
+
+	/* Context */
+	if (sepol_context_create(policydb, &tmp_con, &data->con) < 0)
+		goto err;
+	context_cpy(&tmp_port->context[0], tmp_con);
+	free(tmp_con);
+
+	*port = tmp_port;
+	return STATUS_SUCCESS;
+
+	err:
+	free(tmp_port);
+	DEBUG(__FUNCTION__, "error creating port structure\n");
+	return STATUS_ERR;
+}
+
+/* Get the current context mapping for this port */
+int sepol_port_get_context(
+	policydb_t* policydb,
+	sepol_portinfo_t* data,
+	char** con_str,	
+	size_t* con_str_len) {
+
+	int low = data->low;	
+	int high = data->high;
+
+	int proto = sepol2ipproto(data->protocol);
+	if (proto < 0)
+		goto err;
+
+	ocontext_t *c, *l, *head;
+
+	head = policydb->ocontexts[OCON_PORT];
+	for (l = NULL, c = head; c; l = c, c = c->next) {
+		int proto2 = c->u.port.protocol;
+		int low2 = c->u.port.low_port;
+		int high2 = c->u.port.high_port;
+		context_struct_t* con2 = &c->context[0];
+
+		if (proto != proto2)
+			continue;
+
+		if ((low == low2 && high == high2) ||
+		    (low2 <= low && high2 >= high)) {
+			if (sepol_context_to_string(policydb, con2, 
+				con_str, con_str_len) < 0)
+				goto err;		
+	
+			return STATUS_SUCCESS;
+		}
+	}
+
+	return STATUS_NODATA;
+
+	err: 
+	DEBUG(__FUNCTION__, "could not retrieve context string for "
+		"port entry %s %d-%d\n", proto_to_str(data->protocol), 
+			low, high);
+	return STATUS_ERR;
+
+}
+
+/* Load a port into policy */
+int sepol_port_load(
+	policydb_t* policydb, 
+	sepol_portinfo_t* data) {
+
+	ocontext_t* port = NULL;
+	char* dup_match;
+	size_t dup_size; 
+	int rc;
+
+	if (sepol_port_create(policydb, &port, data) < 0)
+		goto err;
+
+	rc = sepol_port_get_context(policydb, data, &dup_match, &dup_size);
+	if (rc < 0) 
+		goto err;
+
+#warning Is dup_match null terminated ??
+#warning if so, what's the purpose of dup_size
+	else if (rc != STATUS_NODATA) {
+		DEBUG(__FUNCTION__, "port entry for %s %d-%d "
+			"is already mapped to context %s\n",
+			proto_to_str(data->protocol), 
+			data->low, data->high, dup_match);
+		goto err;
+	}
+	
+	/* Attach to context list */
+	port->next = policydb->ocontexts[OCON_PORT];
+	policydb->ocontexts[OCON_PORT] = port;
+
+	return STATUS_SUCCESS;
+
+	err:
+	DEBUG(__FUNCTION__, "error while loading port %s %d-%d\n",
+		proto_to_str(data->protocol), data->low, data->high);
+	free(port);
+	return STATUS_ERR;
+}

Re: [ libsepol 2/6] Ports

[Joshua Brindle]

Ivan Gyurdiev wrote:

>The following patch pushes the port loading
>code into libsepol. It adds a function to
>load a port, and a function to get the context
>for a port. No shadowing is allowed. It creates
>a structure for high level representation of
>a port (sepol_portinfo_t). Uses new debug system
>and writes to policydb object. Comments welcome.
>
>libsepol-1.2-ports.diff
>
>This patch depends on:
>libsepol-1.1-context.diff
>  
>
This probably belongs in libsemanage. I'm trying to get a comprehensive 
API and set of structs so that you can start writing the port and user 
code with respect to it. I'll try to get this out later today.

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: [ libsepol 2/6] Ports

[Ivan Gyurdiev]

On Thu, 2005-07-21 at 14:04 -0400, Joshua Brindle wrote:
> Ivan Gyurdiev wrote:
> 
> >The following patch pushes the port loading
> >code into libsepol. It adds a function to
> >load a port, and a function to get the context
> >for a port. No shadowing is allowed. It creates
> >a structure for high level representation of
> >a port (sepol_portinfo_t). Uses new debug system
> >and writes to policydb object. Comments welcome.
> >
> >libsepol-1.2-ports.diff
> >
> >This patch depends on:
> >libsepol-1.1-context.diff
> >  
> >
> This probably belongs in libsemanage. I'm trying to get a comprehensive 
> API and set of structs so that you can start writing the port and user 
> code with respect to it. I'll try to get this out later today.

There are two chunks to every piece - the data source chunk, file
iteration, transactions, and opaque-structure API go into libsemanage...

Then the part that actually modifies policy goes into libsepol, in
order to keep things self-contained.


--
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: [ libsepol 2/6] Ports

[Ivan Gyurdiev]

> This probably belongs in libsemanage. I'm trying to get a comprehensive 
> API and set of structs so that you can start writing the port and user 
> code with respect to it. I'll try to get this out later today.

I already have a whole bunch of code written that has to do with
parsing things. I need to do a better job with transactions in
that code, but hopefully I won't need to go and rewrite all of it.

The code is based on the wrapper structures that I showed you earlier - 
they are called records. Then I have record_iterate_file() and
record_modify_file() that can be made to work on any type
of record. They handle record creation/destruction/parsing
according to an object table that you pass in. They
invoke an arbitrary handler to process each record, 
which can send signals, such as 
SIGADD, SIGDEL, SIGERR, SIGOK... The handler can
also send back a feedback record in addition
to the one being processed (for add).
Then record_modify_file() can act upon those signals 
by exiting the iteration loop, or skipping the user 
from writing to the modified stream, or adding a new 
user, etc...

So basically, it comes down to writing a bunch of handlers
that signal the iterator functions. For a different backend,
obviously you'd implement this very differently, since
you don't need to iterate things.



--
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: [ libsepol 2/6] Ports

[Karl MacMillan]

> -----Original Message-----
> From: owner-selinux@tycho.nsa.gov [mailto:owner-selinux@tycho.nsa.gov] On
> Behalf Of Ivan Gyurdiev
> Sent: Thursday, July 21, 2005 2:28 PM
> To: Joshua Brindle
> Cc: selinux@tycho.nsa.gov
> Subject: Re: [ libsepol 2/6] Ports
> 
> 
> > This probably belongs in libsemanage. I'm trying to get a comprehensive
> > API and set of structs so that you can start writing the port and user
> > code with respect to it. I'll try to get this out later today.
> 
> I already have a whole bunch of code written that has to do with
> parsing things. I need to do a better job with transactions in
> that code, but hopefully I won't need to go and rewrite all of it.
> 
> The code is based on the wrapper structures that I showed you earlier -
> they are called records. Then I have record_iterate_file() and
> record_modify_file() that can be made to work on any type
> of record. They handle record creation/destruction/parsing
> according to an object table that you pass in. They
> invoke an arbitrary handler to process each record,
> which can send signals, such as
> SIGADD, SIGDEL, SIGERR, SIGOK... The handler can
> also send back a feedback record in addition
> to the one being processed (for add).
> Then record_modify_file() can act upon those signals
> by exiting the iteration loop, or skipping the user
> from writing to the modified stream, or adding a new
> user, etc...
> 
> So basically, it comes down to writing a bunch of handlers
> that signal the iterator functions. For a different backend,
> obviously you'd implement this very differently, since
> you don't need to iterate things.
> 
> 

I don't think libsepol should be doing file modification - that is the
responsibility of libsemanage and the transaction infrastructure included in
that library.

I am not opposed to better abstractions in libsepol, but it should only deal
with modifying the in memory policy database. I also agree with Josh that I'm
not certain that spending a large amount of effort on abstractions in libsepol
is worth the effort. Everything that uses libsepol in the future will have to be
painfully aware of the details of the policy representation. This is regardless
of whether there is an abstraction or not - changes to the policy representation
will effect all of the users of libsepol. It is just a question of whether it
results in an api change or a data structure change.

Karl

---
Karl MacMillan
Tresys Technology
http://www.tresys.com
(410) 290-1411 ext 134

> 
> --
> 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: [ libsepol 2/6] Ports

[Ivan Gyurdiev]

> I don't think libsepol should be doing file modification - that is the
> responsibility of libsemanage and the transaction infrastructure included in
> that library.

Yes, that's what I was saying in my mail - that part of the code
would be in libsemanage. 

> I am not opposed to better abstractions in libsepol, but it should only deal
> with modifying the in memory policy database. 

Correct.

> I also agree with Josh that I'm
> not certain that spending a large amount of effort on abstractions in libsepol
> is worth the effort. Everything that uses libsepol in the future will have to be
> painfully aware of the details of the policy representation. 

That's a self-fulfilling statement - we shouldn't make this assumption,
and then put all kinds of internal-modifying code outside
libsepol where it does not belong. Is there a reason why your 
module code is not in libsepol?




--
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: [ libsepol 2/6] Ports

[Karl MacMillan]

> -----Original Message-----
> From: Ivan Gyurdiev [mailto:gyurdiev@redhat.com]
> Sent: Thursday, July 21, 2005 3:38 PM
> To: Karl MacMillan
> Cc: 'Joshua Brindle'; selinux@tycho.nsa.gov
> Subject: RE: [ libsepol 2/6] Ports
> 
> 
> > I don't think libsepol should be doing file modification - that is the
> > responsibility of libsemanage and the transaction infrastructure included in
> > that library.
> 
> Yes, that's what I was saying in my mail - that part of the code
> would be in libsemanage.
> 

Ok - sorry for the misread.

> > I am not opposed to better abstractions in libsepol, but it should only deal
> > with modifying the in memory policy database.
> 
> Correct.
> 
> > I also agree with Josh that I'm
> > not certain that spending a large amount of effort on abstractions in
> libsepol
> > is worth the effort. Everything that uses libsepol in the future will have
> to be
> > painfully aware of the details of the policy representation.
> 
> That's a self-fulfilling statement - we shouldn't make this assumption,
> and then put all kinds of internal-modifying code outside
> libsepol where it does not belong.

Like I said, I'm not opposed in principal just wondering whether the payoff will
really come.

> Is there a reason why your
> module code is not in libsepol?
> 

The code that deals with the policy representation (including linking and
expanding) is in libsepol. Additionally, we are going to move the code that
understands the module file format to libsepol. That leaves the code that
manages the policy store (or in the future talks to the policy server) in
libsemanage.

Karl

---
Karl MacMillan
Tresys Technology
http://www.tresys.com
(410) 290-1411 ext 134



--
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: [ libsepol 2/6] Ports

[Ivan Gyurdiev]

> Like I said, I'm not opposed in principal just wondering whether the payoff will
> really come.

It might, once all the non-parsing code from checkpolicy finds 
itself over in libsepol where it belongs. I am now thinking of how
to implement an API for adding allow rules on the fly for more
dynamic policy customization. 


--
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: [ libsepol 2/6] Ports

[Joshua Brindle]

Ivan Gyurdiev wrote:

>>Like I said, I'm not opposed in principal just wondering whether the payoff will
>>really come.
>>    
>>
>
>It might, once all the non-parsing code from checkpolicy finds 
>itself over in libsepol where it belongs. I am now thinking of how
>to implement an API for adding allow rules on the fly for more
>dynamic policy customization. 
>  
>
checkpolicy has very little non-parsing code. even the assertion 
checking which was in there moved to libsepol when we merged modules. 
What are you specifically talking about that should move?

--
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: [ libsepol 2/6] Ports

[Ivan Gyurdiev]

On Thu, 2005-07-21 at 17:06 -0400, Joshua Brindle wrote:
> Ivan Gyurdiev wrote:
> 
> >>Like I said, I'm not opposed in principal just wondering whether the payoff will
> >>really come.
> >>    
> >>
> >
> >It might, once all the non-parsing code from checkpolicy finds 
> >itself over in libsepol where it belongs. I am now thinking of how
> >to implement an API for adding allow rules on the fly for more
> >dynamic policy customization. 
> >  
> >
> checkpolicy has very little non-parsing code. even the assertion 
> checking which was in there moved to libsepol when we merged modules. 
> What are you specifically talking about that should move?

The rest of it... 

policy_parse.y/define*

All those things the lex parser calls to.


--
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: [ libsepol 2/6] Ports

[Joshua Brindle]

Ivan Gyurdiev wrote:

>On Thu, 2005-07-21 at 17:06 -0400, Joshua Brindle wrote:
>  
>
>>Ivan Gyurdiev wrote:
>>
>>    
>>
>>>>Like I said, I'm not opposed in principal just wondering whether the payoff will
>>>>really come.
>>>>   
>>>>
>>>>        
>>>>
>>>It might, once all the non-parsing code from checkpolicy finds 
>>>itself over in libsepol where it belongs. I am now thinking of how
>>>to implement an API for adding allow rules on the fly for more
>>>dynamic policy customization. 
>>> 
>>>
>>>      
>>>
>>checkpolicy has very little non-parsing code. even the assertion 
>>checking which was in there moved to libsepol when we merged modules. 
>>What are you specifically talking about that should move?
>>    
>>
>
>The rest of it... 
>
>policy_parse.y/define*
>
>All those things the lex parser calls to.
>  
>
I don't think thats such a great idea. Really alot of the meat of the 
define_* functions has already moved to declare_symbol. The stuff that 
is remaining is really parser specific such as handling where things can 
be declared, handling multiple declarations, etc. It serves no purpose 
to generalize this code as it really is about how to parse the policy 
and not how to build up these structures.

--
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: [ libsepol 2/6] Ports

[Ivan Gyurdiev]

> I don't think thats such a great idea. Really alot of the meat of the 
> define_* functions has already moved to declare_symbol. The stuff that 
> is remaining is really parser specific such as handling where things can 
> be declared, handling multiple declarations, etc. It serves no purpose 
> to generalize this code as it really is about how to parse the policy 
> and not how to build up these structures.

How can I add te_avtab rules to policy at the moment, without
using checkpolicy?






--
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: [ libsepol 2/6] Ports

[Joshua Brindle]

Ivan Gyurdiev wrote:

>>I don't think thats such a great idea. Really alot of the meat of the 
>>define_* functions has already moved to declare_symbol. The stuff that 
>>is remaining is really parser specific such as handling where things can 
>>be declared, handling multiple declarations, etc. It serves no purpose 
>>to generalize this code as it really is about how to parse the policy 
>>and not how to build up these structures.
>>    
>>
>
>How can I add te_avtab rules to policy at the moment, without
>using checkpolicy?
>  
>
All the te_avtab code has been removed from checkpolicy for the modules. 
In fact, aside from checking type transition conflicts, checkpolicy 
doesn't add any rules at all to the avtab, this is done at expand time.

further, avtab_insert, avtab_search, etc have always been in libsepol, 
in avtab.c

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

Iptables discussion

[Ivan Gyurdiev]

On Thu, 2005-07-21 at 19:34 -0400, Joshua Brindle wrote:
> Ivan Gyurdiev wrote:
> 
> >>I don't think thats such a great idea. Really alot of the meat of the 
> >>define_* functions has already moved to declare_symbol. The stuff that 
> >>is remaining is really parser specific such as handling where things can 
> >>be declared, handling multiple declarations, etc. It serves no purpose 
> >>to generalize this code as it really is about how to parse the policy 
> >>and not how to build up these structures.
> >>    
> >>
> >
> >How can I add te_avtab rules to policy at the moment, without
> >using checkpolicy?
> >  
> >
> All the te_avtab code has been removed from checkpolicy for the modules. 
> In fact, aside from checking type transition conflicts, checkpolicy 
> doesn't add any rules at all to the avtab, this is done at expand time.
> 
> further, avtab_insert, avtab_search, etc have always been in libsepol, 
> in avtab.c

static avtab_ptr_t
   avtab_insert_node(avtab_t *h, int hvalue, avtab_ptr_t prev,
avtab_key_t *key, avtab_datum_t *datum)


This is not the high level API that I am looking for.
A caller of this function would not know, or care, what prev is,
or what the format of a datum is, or what table this would go into.

------

Let me get to the point - we have iptables, which configures netfilter.
Then we have policy, which configures selinux. That's two configuration
systems, and having two configuration systems is not good - you have to 
go change both to get anything to work. Furthermore, iptables has
a superior configuration system from a user's point of view, because
it's easier to work with than writing policy in m4 macros.

So, what do we do about that? Dan is suggesting we might integrate
iptables with policy, and have it automatically generate some rules,
pertaining to interfaces, ports, etc... we can now query sepol
for the port label, and query sepol for the interface label. 

I'm not sure how this should be done, or whether this should be done,
but it merits further discussion. Should modules play a role into
this...is it a good idea...etc.



--
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: Iptables discussion

[Daniel J Walsh]

Network Integration with SELinux, stinks from a users point of view.

Lets look at some potential usage scenarios.

User has two network devices (Internal and External)  He wants to allow 
only Apache to listen on the external device, and only communicate via 
LDAP over the internal device?  How would he set that up?  (IF someone 
says he will rewrite policy, I will scream, and then ask you to write 
policy to allow this. ) 

MLS System, wants to have two Apache systems,  One listening at port 80 
for Top Secret communications, another at port 81 for secret.  How do 
you do this?

You want to setup a Zone Transfer between your two named servers.  You 
want to guarantee that named_t on one machine is talking to named_t on 
another machine over an encrypted line? 

I believe the only way for users to do these things successfully is to 
have integration of SELinux with iptables, and no writing/rewriting of 
policy will solve the problem.

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: Iptables discussion

[Karl MacMillan]

> -----Original Message-----
> From: Daniel J Walsh [mailto:dwalsh@redhat.com]
> Sent: Friday, July 22, 2005 8:31 AM
> To: gyurdiev@redhat.com
> Cc: Joshua Brindle; Karl MacMillan; selinux@tycho.nsa.gov
> Subject: Re: Iptables discussion
> 
> Network Integration with SELinux, stinks from a users point of view.
> 
> Lets look at some potential usage scenarios.
> 
> User has two network devices (Internal and External)  He wants to allow
> only Apache to listen on the external device, and only communicate via
> LDAP over the internal device?  How would he set that up?  (IF someone
> says he will rewrite policy, I will scream, and then ask you to write
> policy to allow this. )
> 
> MLS System, wants to have two Apache systems,  One listening at port 80
> for Top Secret communications, another at port 81 for secret.  How do
> you do this?
> 

I know that this is just a motivating example, but I feel compelled to point out
that 1) this problem is not really related to MLS in the real world and 2)
separation based on ports is _very_ unlikely to meet the requirements of a
system that will be processing data at different sensitivities.

> You want to setup a Zone Transfer between your two named servers.  You
> want to guarantee that named_t on one machine is talking to named_t on
> another machine over an encrypted line?
> 
> I believe the only way for users to do these things successfully is to
> have integration of SELinux with iptables, and no writing/rewriting of
> policy will solve the problem.
> 

I disagree - I think you are conflating two separate issues:

1) Implementation details about how SELinux enforces access control over network
resources and
2) User-interface issues about how the user specifies their security policy.

I suggest that iptables may be a part of how SELinux enforces access control,
but that in no way means that detail should be exposed to the user. In fact, as
I said in my other email on the subject, I think it is undesirable to have the
policy expressed in two divergent languages and the iptables syntax may have
some very serious problems.

Solving the user-interface issues can be done more effectively, in my opinion,
by hiding both iptables and SElinux. My preference would be to extend the
SELinux policy language to be able to express the kind of controls that you are
interested in expressing and create a configuration tool (gui or text based)
that generates the policy. That would leave a policy.conf or equivalent that
could be analyzed for correctness.

Karl 

> Dan
> 
> --

---
Karl MacMillan
Tresys Technology
http://www.tresys.com
(410) 290-1411 ext 134



--
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: Iptables discussion

[Ivan Gyurdiev]

> Solving the user-interface issues can be done more effectively, in my opinion,
> by hiding both iptables and SElinux. My preference would be to extend the
> SELinux policy language to be able to express the kind of controls that you are
> interested in expressing and create a configuration tool (gui or text based)
> that generates the policy. That would leave a policy.conf or equivalent that
> could be analyzed for correctness.

I think whatever rules are automatically generated will be at a low
level of complexity, because anything else would be better handled by
writing policy. Given this, I think it will be trivial to generate
additions to policy.conf to address your analysis concern. Where
exactly this is done is an implementation detail :)

What's missing here, is a good API to work with policy, so that you
can manipulate policy internals with anything other than checkpolicy.
That's why I'm asking for an intermediate representation. My particular
implementation of it may not be very good (suggestions welcome), 
but it's certainly better than what's out there - I don't think 
passing in policy-dependent integer id's, and exposing internal data
structures will make a successful api.


--
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: Iptables discussion

[Karl MacMillan]

> -----Original Message-----
> From: Ivan Gyurdiev [mailto:gyurdiev@redhat.com]
> Sent: Friday, July 22, 2005 9:45 AM
> To: Karl MacMillan
> Cc: 'Daniel J Walsh'; 'Joshua Brindle'; selinux@tycho.nsa.gov
> Subject: RE: Iptables discussion
> 
> 
> > Solving the user-interface issues can be done more effectively, in my
> opinion,
> > by hiding both iptables and SElinux. My preference would be to extend the
> > SELinux policy language to be able to express the kind of controls that you
> are
> > interested in expressing and create a configuration tool (gui or text based)
> > that generates the policy. That would leave a policy.conf or equivalent that
> > could be analyzed for correctness.
> 
> I think whatever rules are automatically generated will be at a low
> level of complexity, because anything else would be better handled by
> writing policy. Given this, I think it will be trivial to generate
> additions to policy.conf to address your analysis concern. Where
> exactly this is done is an implementation detail :)
> 

Good - after re-reading you and Dan's messages I realized that you might be
simply suggesting that the iptables program generate SELinux policy. That makes
sense to me and is consistent with what I am saying about a user-interface. The
only other comment is that I would like this to be optional. We have a need to
create systems that have a fixed policy.

> What's missing here, is a good API to work with policy, so that you
> can manipulate policy internals with anything other than checkpolicy.
> That's why I'm asking for an intermediate representation. My particular
> implementation of it may not be very good (suggestions welcome),
> but it's certainly better than what's out there - I don't think
> passing in policy-dependent integer id's, and exposing internal data
> structures will make a successful api.

Why not continue down the path that we have started with libsemanage? I think it
is better to have a well-defined set of local machine customizations that are
available via libsemanage than forcing applications to do direct policy
manipulation. This will, I think, result in an smaller, easier to use API that
will allow a transition path to the policy server (which will hopefully allow us
to do these kinds of customizations across multiple machines). It also helps
with policy updates - by clearly defining local customizations and upstream
policy it is easier for package managers and admins to handle policy updates.

Karl

---
Karl MacMillan
Tresys Technology
http://www.tresys.com
(410) 290-1411 ext 134



--
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: Iptables discussion

[Ivan Gyurdiev]

> > What's missing here, is a good API to work with policy, so that you
> > can manipulate policy internals with anything other than checkpolicy.
> > That's why I'm asking for an intermediate representation. My particular
> > implementation of it may not be very good (suggestions welcome),
> > but it's certainly better than what's out there - I don't think
> > passing in policy-dependent integer id's, and exposing internal data
> > structures will make a successful api.
> 
> Why not continue down the path that we have started with libsemanage? I think it
> is better to have a well-defined set of local machine customizations that are
> available via libsemanage than forcing applications to do direct policy
> manipulation. This will, I think, result in an smaller, easier to use API that
> will allow a transition path to the policy server (which will hopefully allow us
> to do these kinds of customizations across multiple machines). It also helps
> with policy updates - by clearly defining local customizations and upstream
> policy it is easier for package managers and admins to handle policy updates.

Well, libsemanage will end up relying on libsepol, so it's just a
question of where this issue is resolved - I think both libraries should
present API that does not expose policydb internals. Then program X that
wants to do rule generation would call libsemanage, and libsemanage
would handle (1) the transaction, (2) the audit trail you want in
policy.conf, and then would pass down the request to libsepol without
doing things like generating sid's itself, and looking at caches, and
other policydb details.






--
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: Iptables discussion

[Karl MacMillan]

> -----Original Message-----
> From: Ivan Gyurdiev [mailto:gyurdiev@redhat.com]
> Sent: Friday, July 22, 2005 10:25 AM
> To: Karl MacMillan
> Cc: 'Daniel J Walsh'; 'Joshua Brindle'; selinux@tycho.nsa.gov
> Subject: RE: Iptables discussion
> 
> 
> > > What's missing here, is a good API to work with policy, so that you
> > > can manipulate policy internals with anything other than checkpolicy.
> > > That's why I'm asking for an intermediate representation. My particular
> > > implementation of it may not be very good (suggestions welcome),
> > > but it's certainly better than what's out there - I don't think
> > > passing in policy-dependent integer id's, and exposing internal data
> > > structures will make a successful api.
> >
> > Why not continue down the path that we have started with libsemanage? I
> think it
> > is better to have a well-defined set of local machine customizations that
> are
> > available via libsemanage than forcing applications to do direct policy
> > manipulation. This will, I think, result in an smaller, easier to use API
> that
> > will allow a transition path to the policy server (which will hopefully
> allow us
> > to do these kinds of customizations across multiple machines). It also helps
> > with policy updates - by clearly defining local customizations and upstream
> > policy it is easier for package managers and admins to handle policy
> updates.
> 
> Well, libsemanage will end up relying on libsepol, so it's just a
> question of where this issue is resolved - I think both libraries should
> present API that does not expose policydb internals. Then program X that
> wants to do rule generation would call libsemanage, and libsemanage
> would handle (1) the transaction, (2) the audit trail you want in
> policy.conf, and then would pass down the request to libsepol without
> doing things like generating sid's itself, and looking at caches, and
> other policydb details.
> 

OK - that sounds like a good plan to me. Josh is working on getting the
libsemanage updates done as soon as possible. Why don't we push on getting that
ready for you to add the network related APIs and you continue pushing on
libsepol? Also, as Josh Guttman pointed out your work would benefit slat as
well.

Are you imagining a file like local.users for network related configuration -
this would allow direct modification of the configuration files for those that
would prefer that to using tools / libsemanage? Any idea about what the rules
that will be generated will look like? I'm trying to get a handle on exactly how
this network configuration will look and whether it is going to require pulling
out parts of the existing policy. For example, would the apache module stop
allowing any send / receive on any node, netif, or port and then there would be
a default local network configuration provided? 

Karl

---
Karl MacMillan
Tresys Technology
http://www.tresys.com
(410) 290-1411 ext 134

> 
> 




--
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: Iptables discussion

[Ivan Gyurdiev]

> Are you imagining a file like local.users for network related configuration -
> this would allow direct modification of the configuration files for those that
> would prefer that to using tools / libsemanage?

If you're talking about ports and interfaces, then yes, that would make
sense. For iptables-generated allow rules and such, I don't
know....it actually makes little sense to write out the rules.

>  Any idea about what the rules
> that will be generated will look like? I'm trying to get a handle on exactly how
> this network configuration will look and whether it is going to require pulling
> out parts of the existing policy.

I don't know what the rules will look like yet, but please note
that iptables has both deny and allow rules...right...
I'm not sure how we can handle the deny ones.

>  For example, would the apache module stop
> allowing any send / receive on any node, netif, or port and then there would be
> a default local network configuration provided? 

So, when the firewall shuts down, the default networking policy
is reset to ACCEPT all in our firewall scripts, but that's
done only after the interfaces are shut down. Similarly,
the firewall comes up before the interfaces go up...
I'm not sure how all that applies to selinux.


--
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: Iptables discussion

[Karl MacMillan]

> -----Original Message-----
> From: Ivan Gyurdiev [mailto:gyurdiev@redhat.com]
> >  Any idea about what the rules
> > that will be generated will look like? I'm trying to get a handle on exactly
> how
> > this network configuration will look and whether it is going to require
> pulling
> > out parts of the existing policy.
> 
> I don't know what the rules will look like yet, but please note
> that iptables has both deny and allow rules...right...
> I'm not sure how we can handle the deny ones.
> 
> >  For example, would the apache module stop
> > allowing any send / receive on any node, netif, or port and then there would
> be
> > a default local network configuration provided?
> 
> So, when the firewall shuts down, the default networking policy
> is reset to ACCEPT all in our firewall scripts, but that's
> done only after the interfaces are shut down. Similarly,
> the firewall comes up before the interfaces go up...
> I'm not sure how all that applies to selinux.

This brings up the tension that Josh mentioned between the 'runtime' nature of
the iptables policy and the selinux - regenerating the policy everytime you
invoke iptables seems problematic. This and the whole everything is allowed
until denied approach seems like it is going to make this challenging.

Karl

---
Karl MacMillan
Tresys Technology
http://www.tresys.com
(410) 290-1411 ext 134



--
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: Iptables discussion

[Ivan Gyurdiev]

> This brings up the tension that Josh mentioned between the 'runtime' nature of
> the iptables policy and the selinux - regenerating the policy everytime you
> invoke iptables seems problematic. This and the whole everything is allowed
> until denied approach seems like it is going to make this challenging.

To solve that problem I guess you'd add a tool that could process 
iptables rules in a loop, rather than restarting the process at every
rule. 

Once you have a concept of a config block of rules, instead of a
bunch of invocations...you could do configuration-wide auditing and say:
no DENY rules or ALLOW default policy are allowed on an selinux system.
Of course, that's completely changing the way iptables works, at which
point you lose the benefit of having frontend tools already 
written for you.

Then, if I remember correctly, there was talk about preserving
attributes in the kernel... will that help us? If we remove
the netif_type attribute somehow once iptables starts managing
that interface? I don't know anything about kernel-side selinux,
so I'm not sure if that's even possible.






--
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: Iptables discussion

[Daniel J Walsh]

Karl MacMillan wrote:

>>-----Original Message-----
>>From: Ivan Gyurdiev [mailto:gyurdiev@redhat.com]
>>Sent: Friday, July 22, 2005 9:45 AM
>>To: Karl MacMillan
>>Cc: 'Daniel J Walsh'; 'Joshua Brindle'; selinux@tycho.nsa.gov
>>Subject: RE: Iptables discussion
>>
>>
>>    
>>
>>>Solving the user-interface issues can be done more effectively, in my
>>>      
>>>
>>opinion,
>>    
>>
>>>by hiding both iptables and SElinux. My preference would be to extend the
>>>SELinux policy language to be able to express the kind of controls that you
>>>      
>>>
>>are
>>    
>>
>>>interested in expressing and create a configuration tool (gui or text based)
>>>that generates the policy. That would leave a policy.conf or equivalent that
>>>could be analyzed for correctness.
>>>      
>>>
>>I think whatever rules are automatically generated will be at a low
>>level of complexity, because anything else would be better handled by
>>writing policy. Given this, I think it will be trivial to generate
>>additions to policy.conf to address your analysis concern. Where
>>exactly this is done is an implementation detail :)
>>
>>    
>>
>
>Good - after re-reading you and Dan's messages I realized that you might be
>simply suggesting that the iptables program generate SELinux policy. That makes
>sense to me and is consistent with what I am saying about a user-interface. The
>only other comment is that I would like this to be optional. We have a need to
>create systems that have a fixed policy.
>  
>
Yes,  I am suggesting potentially IPTables could generate policy that 
you could check, and I am
not suggesting that you remove the existing policy semantics.  I believe 
that users have a need and
knowledge on how to configue iptables, and many tools have been written 
to allow the mangement of
network security via IPTables.  The enhancement I would be looking for 
is how we could get
iptables to communicate with SELinux to further constrain the system.

I see policy as being somewhat static.  IE We write the core policy that 
will work pretty much the same way
on everyones machine.  The problem is that users have sections of policy 
that will differ.  Users, Ports, Interfaces
on a machine by machine basis.  They have to be able to simply extend or 
modify policy to work better in their environments.
I also see users needing to write small sections of policy, without 
modifying policy sources.  As an example I have a bug
report right now from a user looking to use an app (plugin) with 
squirrelmail to do mail forwarding.   This app gets execed via 
squirrelmail and fails because it needs the setgid capability.  Now if 
the user could write one line of code, he could get the app working the 
way he wants, without having to disable squirrelmail protection or all 
of httpd.  

There are customers that will pay for a customized policy that will lock 
down their system to a security specification and want it proovably 
secure.  There are a lot more customers who will pay for security  that 
they are reasonably certain protects their machine, but are not willing 
to pay someone to customize it.

>  
>
>>What's missing here, is a good API to work with policy, so that you
>>can manipulate policy internals with anything other than checkpolicy.
>>That's why I'm asking for an intermediate representation. My particular
>>implementation of it may not be very good (suggestions welcome),
>>but it's certainly better than what's out there - I don't think
>>passing in policy-dependent integer id's, and exposing internal data
>>structures will make a successful api.
>>    
>>
>
>Why not continue down the path that we have started with libsemanage? I think it
>is better to have a well-defined set of local machine customizations that are
>available via libsemanage than forcing applications to do direct policy
>manipulation. This will, I think, result in an smaller, easier to use API that
>will allow a transition path to the policy server (which will hopefully allow us
>to do these kinds of customizations across multiple machines). It also helps
>with policy updates - by clearly defining local customizations and upstream
>policy it is easier for package managers and admins to handle policy updates.
>
>  
>
I agree.

>Karl
>
>---
>Karl MacMillan
>Tresys Technology
>http://www.tresys.com
>(410) 290-1411 ext 134
>
>
>  
>


-- 



--
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: Iptables discussion

[Karl MacMillan]

> -----Original Message-----
> From: Daniel J Walsh [mailto:dwalsh@redhat.com]
> Sent: Friday, July 22, 2005 10:43 AM
> To: Karl MacMillan
> Cc: gyurdiev@redhat.com; 'Joshua Brindle'; selinux@tycho.nsa.gov
> Subject: Re: Iptables discussion
> 
> Karl MacMillan wrote:
> 
> >>-----Original Message-----
> >>From: Ivan Gyurdiev [mailto:gyurdiev@redhat.com]
> >>Sent: Friday, July 22, 2005 9:45 AM
> >>To: Karl MacMillan
> >>Cc: 'Daniel J Walsh'; 'Joshua Brindle'; selinux@tycho.nsa.gov
> >>Subject: RE: Iptables discussion
> >>
> >>
> >>
> >>
> >>>Solving the user-interface issues can be done more effectively, in my
> >>>
> >>>
> >>opinion,
> >>
> >>
> >>>by hiding both iptables and SElinux. My preference would be to extend the
> >>>SELinux policy language to be able to express the kind of controls that you
> >>>
> >>>
> >>are
> >>
> >>
> >>>interested in expressing and create a configuration tool (gui or text
> based)
> >>>that generates the policy. That would leave a policy.conf or equivalent
> that
> >>>could be analyzed for correctness.
> >>>
> >>>
> >>I think whatever rules are automatically generated will be at a low
> >>level of complexity, because anything else would be better handled by
> >>writing policy. Given this, I think it will be trivial to generate
> >>additions to policy.conf to address your analysis concern. Where
> >>exactly this is done is an implementation detail :)
> >>
> >>
> >>
> >
> >Good - after re-reading you and Dan's messages I realized that you might be
> >simply suggesting that the iptables program generate SELinux policy. That
> makes
> >sense to me and is consistent with what I am saying about a user-interface.
> The
> >only other comment is that I would like this to be optional. We have a need
> to
> >create systems that have a fixed policy.
> >
> >
> Yes,  I am suggesting potentially IPTables could generate policy that
> you could check, and I am
> not suggesting that you remove the existing policy semantics.  I believe
> that users have a need and
> knowledge on how to configue iptables, and many tools have been written
> to allow the mangement of
> network security via IPTables.  The enhancement I would be looking for
> is how we could get
> iptables to communicate with SELinux to further constrain the system.
> 
> I see policy as being somewhat static.  IE We write the core policy that
> will work pretty much the same way
> on everyones machine.  The problem is that users have sections of policy
> that will differ.  Users, Ports, Interfaces
> on a machine by machine basis.  They have to be able to simply extend or
> modify policy to work better in their environments.
> I also see users needing to write small sections of policy, without
> modifying policy sources.  As an example I have a bug
> report right now from a user looking to use an app (plugin) with
> squirrelmail to do mail forwarding.   This app gets execed via
> squirrelmail and fails because it needs the setgid capability.  Now if
> the user could write one line of code, he could get the app working the
> way he wants, without having to disable squirrelmail protection or all
> of httpd.
> 

I agree that there are different kinds of policy customizations. We have been
using a model of:

Upstream policy (e.g. NSA, ref policy) -> oem modification / additions (e.g.,
Red Hat) -> third party additions (e.g. ISVs) -> local customizations.

Each of these has different needs. I agree that when we hit third part additions
the bulk of the policy is static. I had been assuming that the local
customizations would be a well-defined set of settings that the admin could
twiddle. Your squirrelmail example is sort-of different, though. I can clearly
see the need for it, but don't have a good idea of how to facilitate that
without pushing the user into full-on policy customization.

> There are customers that will pay for a customized policy that will lock
> down their system to a security specification and want it proovably
> secure.  There are a lot more customers who will pay for security  that
> they are reasonably certain protects their machine, but are not willing
> to pay someone to customize it.
> 

Definitely, and the former category will probably stay small of the foreseeable
future. I think we can meet the needs of both, though. 

> >
> >
> >>What's missing here, is a good API to work with policy, so that you
> >>can manipulate policy internals with anything other than checkpolicy.
> >>That's why I'm asking for an intermediate representation. My particular
> >>implementation of it may not be very good (suggestions welcome),
> >>but it's certainly better than what's out there - I don't think
> >>passing in policy-dependent integer id's, and exposing internal data
> >>structures will make a successful api.
> >>
> >>
> >
> >Why not continue down the path that we have started with libsemanage? I think
> it
> >is better to have a well-defined set of local machine customizations that are
> >available via libsemanage than forcing applications to do direct policy
> >manipulation. This will, I think, result in an smaller, easier to use API
> that
> >will allow a transition path to the policy server (which will hopefully allow
> us
> >to do these kinds of customizations across multiple machines). It also helps
> >with policy updates - by clearly defining local customizations and upstream
> >policy it is easier for package managers and admins to handle policy updates.
> >
> >
> >
> I agree.
> 

OK.

Karl

---
Karl MacMillan
Tresys Technology
http://www.tresys.com
(410) 290-1411 ext 134

> >Karl
> >
> >---
> >Karl MacMillan
> >Tresys Technology
> >http://www.tresys.com
> >(410) 290-1411 ext 134
> >
> >
> >
> >
> 
> 
> --




--
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: Iptables discussion

[Joshua Brindle]

Karl MacMillan wrote:

>>-----Original Message-----
>>From: Ivan Gyurdiev [mailto:gyurdiev@redhat.com]
>>Sent: Friday, July 22, 2005 9:45 AM
>>To: Karl MacMillan
>>Cc: 'Daniel J Walsh'; 'Joshua Brindle'; selinux@tycho.nsa.gov
>>Subject: RE: Iptables discussion
>>
>>
>>    
>>
>>>Solving the user-interface issues can be done more effectively, in my
>>>      
>>>
>>opinion,
>>    
>>
>>>by hiding both iptables and SElinux. My preference would be to extend the
>>>SELinux policy language to be able to express the kind of controls that you
>>>      
>>>
>>are
>>    
>>
>>>interested in expressing and create a configuration tool (gui or text based)
>>>that generates the policy. That would leave a policy.conf or equivalent that
>>>could be analyzed for correctness.
>>>      
>>>
>>I think whatever rules are automatically generated will be at a low
>>level of complexity, because anything else would be better handled by
>>writing policy. Given this, I think it will be trivial to generate
>>additions to policy.conf to address your analysis concern. Where
>>exactly this is done is an implementation detail :)
>>
>>    
>>
>
>Good - after re-reading you and Dan's messages I realized that you might be
>simply suggesting that the iptables program generate SELinux policy. That makes
>sense to me and is consistent with what I am saying about a user-interface. The
>only other comment is that I would like this to be optional. We have a need to
>create systems that have a fixed policy.
>
>  
>
>>What's missing here, is a good API to work with policy, so that you
>>can manipulate policy internals with anything other than checkpolicy.
>>That's why I'm asking for an intermediate representation. My particular
>>implementation of it may not be very good (suggestions welcome),
>>but it's certainly better than what's out there - I don't think
>>passing in policy-dependent integer id's, and exposing internal data
>>structures will make a successful api.
>>    
>>
>
>Why not continue down the path that we have started with libsemanage? I think it
>is better to have a well-defined set of local machine customizations that are
>available via libsemanage than forcing applications to do direct policy
>manipulation. This will, I think, result in an smaller, easier to use API that
>will allow a transition path to the policy server (which will hopefully allow us
>to do these kinds of customizations across multiple machines). It also helps
>with policy updates - by clearly defining local customizations and upstream
>policy it is easier for package managers and admins to handle policy updates.
>  
>
This may cause consistency problems. Adding a iptable rule would add it 
to the current running firewall config (in memory) and may or may not 
store it in a state file to be rerun on boot. If adding that rule 
triggers a policy change that presumably becomes part of the binary 
policy on disk you will end up with alot of extra rules. Also, removing 
rules is much harder than adding them, and it's probably not uncommon to 
delete firewall rules. with respect to analysis, perhaps the analysis 
tools should be able to analyze a linked module format policy and we 
should use modules to add these rules (on the backend behind libsemanage 
ofcourse) that way you can still analyze the policy after iptables has 
added rules :) .

--
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: Iptables discussion

[Joshua Brindle]

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

Ivan Gyurdiev wrote:

>>Solving the user-interface issues can be done more effectively, in my opinion,
>>by hiding both iptables and SElinux. My preference would be to extend the
>>SELinux policy language to be able to express the kind of controls that you are
>>interested in expressing and create a configuration tool (gui or text based)
>>that generates the policy. That would leave a policy.conf or equivalent that
>>could be analyzed for correctness.
>>    
>>
>
>I think whatever rules are automatically generated will be at a low
>level of complexity, because anything else would be better handled by
>writing policy. Given this, I think it will be trivial to generate
>additions to policy.conf to address your analysis concern. 
>
This is not very forward looking, needs will undoubtedly become more complex

>Where
>exactly this is done is an implementation detail :)
>
>  
>
sure but there are right ways to do this and not-so-right ways to do it.

>What's missing here, is a good API to work with policy, so that you
>can manipulate policy internals with anything other than checkpolicy.
>  
>
I'm pretty sure thats what we've been proposing

>That's why I'm asking for an intermediate representation. My particular
>implementation of it may not be very good (suggestions welcome), 
>but it's certainly better than what's out there - I don't think 
>passing in policy-dependent integer id's, and exposing internal data
>structures will make a successful api.
>  
>
The module format is an intermediate representation. I don't think 
anyone is suggesting we expose anything about the policy, the last few 
days of discussion has been about abstracting this. With respect to the 
proposed libsemanage API, please let us know what else you need, or 
better yet add some structs and functions and send an rfc. The more 
comprehensive semanage api is attached and can probably start being used 
for the user management and port management.

[-- Attachment #2: semanage.h --]
[-- Type: text/plain, Size: 7298 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:
 */


/* 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_free(semanage_module_info_t *);

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_role_t;
typedef struct semanage_role semanage_role_t;

const char* semanage_mls_get_range(semanage_mls *);
const char* semanage_mls_get_level(semanage_mls *);

int semanage_mls_set_range(semanage_mls *);
int semanage_mls_set_level(semanage_mls *);

const char* semanage_role_get_name(semanage_role *);

int semanage_role_set_name(semanage_role *);

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

/* semanage_user accessor functions */
const char* semanage_user_get_name(semanage_user_t *);
int semanage_user_get_roles(semanage_user_t *, semanage_role **roles, int num_roles);
int semanage_user_get_mls(semanage_user_t *, semanage_mls *mls);
 
int semanage_user_set_name(semange_user_t *);
int semanage_user_set_roles(semanage_user_t *, semanage_roles **roles, int num_roles);
int semanage_user_set_mls(semanage_user_t *, semanage_mls *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 */
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 *);
const 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);

[-- Attachment #3: semanage_structs.h --]
[-- Type: text/plain, Size: 1467 bytes --]

/*
 *  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
 */

/* This defines the data structures which are exported opaquely through 
   semanage.h for policy management clients. */

struct semanage_handle {
	int con_id;		/* Connection ID */
	int policy_serial;	/* Policy serial number at connect time */
	char *err_buf;
}	

struct semanage_module_info {
	char *name;		/* Key */
	char *version;
}

struct semanage_role {
	char *name;		/* Key */
}

struct semanage_mls {
	char *level;
	char *range;
}

struct semanage_user {
	char *selinux_name;		/* Key */
	struct semanage_role **roles;
	int num_roles;
	struct semanage_mls *mls;
}

struct semanage_homedir {
	char *user;
	char *path;		/* Key */
}

struct semanage_boolean {
	char *name;		/* Key */
	char default_state;
}

Re: Iptables discussion

[Ivan Gyurdiev]

> >That's why I'm asking for an intermediate representation. My particular
> >implementation of it may not be very good (suggestions welcome), 
> >but it's certainly better than what's out there - I don't think 
> >passing in policy-dependent integer id's, and exposing internal data
> >structures will make a successful api.
> >  
> >
> The module format is an intermediate representation.

No...an intermediate representation on the libsepol level,
as well as the libsemanage level. 

>  I don't think 
> anyone is suggesting we expose anything about the policy, the last few 
> days of discussion has been about abstracting this. With respect to the 
> proposed libsemanage API, please let us know what else you need, or 
> better yet add some structs and functions and send an rfc. 

Can you please rename the library, so I can send patches against it?
I tried to do this myself, but you didn't like my patch.

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

Dan asked why the API is assymetric (connect vs disconnect-free),
but no one has answered this question yet. In addition, I see a 
"CAUTION: don't do this" in free, which makes me wonder
why this function exists, and is not done inside disconnect.

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

Can you look at the sepol debugging system which I added,
and see if you have any objections to the same thing
being done in libsemanage.

> /* accessors for mls and role support structs */
> typedef struct semanage_mls semanage_role_t;
> typedef struct semanage_role semanage_role_t;

??

> const char* semanage_mls_get_range(semanage_mls *);
> const char* semanage_mls_get_level(semanage_mls *);
> 
> int semanage_mls_set_range(semanage_mls *);
> int semanage_mls_set_level(semanage_mls *);

Shouldn't the setters take a parameter of 
what to set? You omit those in many places.

> /* semanage_user management functions */
> int semanage_user_init(semanage_handle_t **);

You mean 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);

There's still no query or a way to modify the user other than delete 
and re-add. This applies to the entire API. Delete and add may be
acceptable (even though that automatically means two iterations
in the file case), but no query just seems wrong. 

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

There is no api to trigger regeneration of the file_contexts file.

Also, I believe the mapping of paths to selinux users is 
fundamentally flawed, and needs to be more generic. I will
acknowledge that the code I've posted so far offers no solution 
either, and may actually be worse. 

I want to add a new expansion called... CONTENT_DIR, which maps
to a bunch of locations where I store music and movies on my home 
computer, and labels those to a certain type. 

I want to add a new expansion called... REMOVABLE_MNT_POINT, that
I want labeled removable_t via integration with udev, which follows
my custom naming policy.

How does this future-proof API handle those scenarios.

> struct semanage_handle {
> 	int con_id;		/* Connection ID */
> 	int policy_serial;	/* Policy serial number at connect time */
> 	char *err_buf;

We should not buffer errors - we should provide the user
with a better debugging system - do you oppose sepol_enable_debug* ?

> struct semanage_mls {
> 	char *level;
> 	char *range;
> }

Whether or not the mls data should be opaque I am not sure about.
It's certainly easier to deal with it that way...that's how
I'm implementing the sepol support... but it doesn't
offer much insight into the composition of level and range..


--
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: Iptables discussion

[Karl MacMillan]

> -----Original Message-----
> From: Ivan Gyurdiev [mailto:gyurdiev@redhat.com]

<snip>

Josh will answer the above questions.

> > /* 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);
> 
> There is no api to trigger regeneration of the file_contexts file.
> 

Trigger? The commit should cause the regeneration to happen.

> Also, I believe the mapping of paths to selinux users is
> fundamentally flawed, and needs to be more generic. I will
> acknowledge that the code I've posted so far offers no solution
> either, and may actually be worse.
> 
> I want to add a new expansion called... CONTENT_DIR, which maps
> to a bunch of locations where I store music and movies on my home
> computer, and labels those to a certain type.
> 
> I want to add a new expansion called... REMOVABLE_MNT_POINT, that
> I want labeled removable_t via integration with udev, which follows
> my custom naming policy.
> 
> How does this future-proof API handle those scenarios.
> 

I agree that this api doesn't cut it. The only alternative I have is the ability
to specify arbitrary name-value pairs that get expanded and pass in the selinux
user in addition to the pairs. HOME_DIR would just be one of the name-value
pairs. This has a few problems that I have no solution to:

1) How are reasonable defaults determined with the caller doesn't set a
particular name that a file context expects? Is it just not expanded?

2) How do we handle the case where some of the labeling should be present but
not others (e.g., /tmp but not /home/username when home directories are remote)?

> > struct semanage_handle {
> > 	int con_id;		/* Connection ID */
> > 	int policy_serial;	/* Policy serial number at connect time */
> > 	char *err_buf;
> 
> We should not buffer errors - we should provide the user
> with a better debugging system - do you oppose sepol_enable_debug* ?
> 

I think that the caller should be able to chose how to display errors - that is
what this api is for and it seems straight forward to me. What is your
objection? Not that may be separate from a logging mechanism that sends errors
to a log file.

Karl
---
Karl MacMillan
Tresys Technology
http://www.tresys.com
(410) 290-1411 ext 134



--
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: Iptables discussion

[Ivan Gyurdiev]

> I think that the caller should be able to chose how to display errors - that is
> what this api is for and it seems straight forward to me. What is your
> objection? Not that may be separate from a logging mechanism that sends errors
> to a log file.

(1) The errors are buffered, and not displayed as they occur, so you
don't know what is happening if something hangs

(2) I have to rewrite my code to use it, while my API seems better.
What's your objection?


--
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: Iptables discussion

[Karl MacMillan]

> -----Original Message-----
> From: Ivan Gyurdiev [mailto:gyurdiev@redhat.com]
> Sent: Friday, July 22, 2005 12:15 PM
> To: Karl MacMillan
> Cc: 'Joshua Brindle'; 'Daniel J Walsh'; selinux@tycho.nsa.gov
> Subject: RE: Iptables discussion
> 
> 
> > I think that the caller should be able to chose how to display errors - that
> is
> > what this api is for and it seems straight forward to me. What is your
> > objection? Not that may be separate from a logging mechanism that sends
> errors
> > to a log file.
> 
> (1) The errors are buffered, and not displayed as they occur, so you
> don't know what is happening if something hangs
> 

Ok - that makes sense, but see below for how that may not always work. This can
also be solved by careful api design that gives the caller the choice of
immediately aborting on error (which I think is true of the current api
suggestions).

> (2) I have to rewrite my code to use it, while my API seems better.
> What's your objection?

1) Very difficult to use for a multi-threaded application. How do I know what
function call by which thread generated the error?

2) Possibly difficult to implement if the the API is making RPC calls to a
remote server. In that case the underlying implementation will look like what we
have proposed and will simply strip the error, make the callback, and then
return normally - all with the same delay as if the api looks like our proposal.

3) Again, in the server case I don't think that I want to trust the remote
server to pass back a format and a string that I interpret locally. Seems like a
vector for format string vulnerabilities.

Karl

---
Karl MacMillan
Tresys Technology
http://www.tresys.com
(410) 290-1411 ext 134



--
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: Iptables discussion

[Ivan Gyurdiev]

> > (2) I have to rewrite my code to use it, while my API seems better.
> > What's your objection?
> 
> 1) Very difficult to use for a multi-threaded application. How do I know what
> function call by which thread generated the error?

The function name is actually passed back by the error system I have.
I suppose you could have your callback write the thread id (can't
remember if pthread api provides that), although if RPC gets involved
with scheme starts not to make sense.

> 2) Possibly difficult to implement if the the API is making RPC calls to a
> remote server. In that case the underlying implementation will look like what we
> have proposed and will simply strip the error, make the callback, and then
> return normally - all with the same delay as if the api looks like our proposal.

That's a valid argument, I hadn't thought about that issue.
Ok I will alter my code to use your buffer system.


--
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: Iptables discussion

[Ivan Gyurdiev]

> Trigger? The commit should cause the regeneration to happen.

Can you describe in more detail how the regeneration will occur.

Will you be regenerating a single file_contexts file, or per user 
(which is what should happen, IMHO). If the latter, how do you plan
to take the Unix users out of the equation for libsemanage.

Will you be rewriting the file as the change occurs, and simply 
renaming the result file upon commit, or will you delay template
expansion upon commit. 

Basically, how will the implementation work.

> > Also, I believe the mapping of paths to selinux users is
> > fundamentally flawed, and needs to be more generic. I will
> > acknowledge that the code I've posted so far offers no solution
> > either, and may actually be worse.
> > 
> > I want to add a new expansion called... CONTENT_DIR, which maps
> > to a bunch of locations where I store music and movies on my home
> > computer, and labels those to a certain type.
> > 
> > I want to add a new expansion called... REMOVABLE_MNT_POINT, that
> > I want labeled removable_t via integration with udev, which follows
> > my custom naming policy.
> > 
> > How does this future-proof API handle those scenarios.
> > 
> 
> I agree that this api doesn't cut it. The only alternative I have is the ability
> to specify arbitrary name-value pairs that get expanded and pass in the selinux
> user in addition to the pairs.

Let's postpone this discussion until the questions above are answered,
which are highly relevant.

Yes, I support name-value pairs... I also think we need to index such
name value pairs by a key (say the user), and that key will be used
to connect them together. I've thought about this a bit, and to me
this whole business maps very well to sql relations. All those config
files should be tables with key-value relations, and foreign keys,
and cascading deletes.... but let's not get into that right now, and
look for a more immediate solution.



--
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: Iptables discussion

[Jason Tang]

Greetings Ivan.  I co-authored libsemanage.  Karl requested that I
respond to your concerns.

On Fri, 2005-07-22 at 11:39 -0400, Ivan Gyurdiev wrote:
> Dan asked why the API is assymetric (connect vs disconnect-free),
> but no one has answered this question yet. In addition, I see a 

One reason for this proposed design is to allow for SELinux clients that
employ a multi-processor design (i.e., fork() + do stuff in the child).
Suppose that the semanage backend is writing directly to /etc/selinux.
If the child process performs a disconnect() it will release the
semanage file lock that its parent had acquired.  What the child really
wants to do is free() its memory without disturbing the file lock.

> We should not buffer errors - we should provide the user
> with a better debugging system - do you oppose sepol_enable_debug* ?

The error reporting system is primarily for error reporting and not
debugging purposes.

Furthermore:

On Fri, 2005-07-22 at 12:14 -0400, Ivan Gyurdiev wrote: 
> (1) The errors are buffered, and not displayed as they occur, so you
> don't know what is happening if something hangs

As Karl mentioned, callbacks (and other asynchronous events) in
multi-threaded programs are dangerous.  In addition some programs might
not want immediate feedback for various reasons or designs.  Any kind of
system with hard real-time requirements would definitely not use it.

In what manner could a program "hang" without affording the possibility
of reporting an error?  Suppose that your _debug() callback scheme were
to be employed.  At some point in time the program recognizes an error
and invokes the callback.  Now instead one were to use our proposed
error handling scheme.  Instead of making the callback it merely returns
an error code.  Either way program execution has not hung.

-- 
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: Iptables discussion

[Ivan Gyurdiev]

> On Fri, 2005-07-22 at 12:14 -0400, Ivan Gyurdiev wrote: 
> > (1) The errors are buffered, and not displayed as they occur, so you
> > don't know what is happening if something hangs
> 
> As Karl mentioned, callbacks (and other asynchronous events) in
> multi-threaded programs are dangerous.  

I admit that I haven't thought much about the implications
of doing a callback over the wire. For this kind of thing,
it would seem appropriate to buffer error output.

> In addition some programs might
> not want immediate feedback for various reasons or designs. 

You can buffer the feedback in the callback function if you wish.

> In what manner could a program "hang" without affording the possibility
> of reporting an error?  Suppose that your _debug() callback scheme were
> to be employed.  At some point in time the program recognizes an error
> and invokes the callback.  Now instead one were to use our proposed
> error handling scheme.  Instead of making the callback it merely returns
> an error code.  Either way program execution has not hung.

I was thinking of status output, and not error output, so you are
correct that this is not an issue. In the case of status output, it is
easy to tell where a loop/hang may occur, because you can see the 
messages prior.




--
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: Iptables discussion

[Jason Tang]

On Fri, 2005-07-22 at 13:54 -0400, Ivan Gyurdiev wrote:
> You can buffer the feedback in the callback function if you wish.

No, buffering in callbacks is also dangerous in multi-threaded programs.
The callback function, if not properly written, is no longer MT-safe nor
reentrant.

On Fri, 2005-07-22 at 13:59 -0400, Ivan Gyurdiev wrote: 
> The function name is actually passed back by the error system I have.

Having a function name is not sufficient for multi-threaded programs.

> I suppose you could have your callback write the thread id (can't
> remember if pthread api provides that),

The function is pthread_self().


-- 
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: Iptables discussion

[Ivan Gyurdiev]

> No, buffering in callbacks is also dangerous in multi-threaded programs.
> The callback function, if not properly written, is no longer MT-safe nor
> reentrant.

So what you're saying that "a piece of software, if not properly
written, can have bugs". I definitely agree with that :)

> On Fri, 2005-07-22 at 13:59 -0400, Ivan Gyurdiev wrote: 
> > The function name is actually passed back by the error system I have.
> 
> Having a function name is not sufficient for multi-threaded programs.

You can get the thread id via pthread_self(), but this wouldn't work
with RPC.

====

Let's end this discussion here, because I've agreed to use your 
non-callback system, on the grounds that eventually libsemanage
will need to work over the network, where callback error reporting
is probably a mistake.


--
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: Iptables discussion

[Joshua Brindle]

Ivan Gyurdiev wrote:

>>>That's why I'm asking for an intermediate representation. My particular
>>>implementation of it may not be very good (suggestions welcome), 
>>>but it's certainly better than what's out there - I don't think 
>>>passing in policy-dependent integer id's, and exposing internal data
>>>structures will make a successful api.
>>> 
>>>
>>>      
>>>
>>The module format is an intermediate representation.
>>    
>>
>
>No...an intermediate representation on the libsepol level,
>as well as the libsemanage level. 
>
>  
>
we need to figure out what we need to store before we decide if we need 
another policy representation.

>> I don't think 
>>anyone is suggesting we expose anything about the policy, the last few 
>>days of discussion has been about abstracting this. With respect to the 
>>proposed libsemanage API, please let us know what else you need, or 
>>better yet add some structs and functions and send an rfc. 
>>    
>>
>
>Can you please rename the library, so I can send patches against it?
>I tried to do this myself, but you didn't like my patch.
>
>  
>
It won't matter since the library doesn't currently match the proposed 
API. Probably the best thing would be to write your user and port 
management stuff against the new API and see if it actually works.

>>/* 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 *);
>>    
>>
>
>Dan asked why the API is assymetric (connect vs disconnect-free),
>but no one has answered this question yet. In addition, I see a 
>"CAUTION: don't do this" in free, which makes me wonder
>why this function exists, and is not done inside disconnect.
>
>  
>
it doesn't say not to do it, it says not to do it before disconnect. The 
reason there is a difference is because you may want to reuse the 
handles and we force the caller to initialize them therefore they have 
to destroy them.

<snip>

>>/* accessors for mls and role support structs */
>>typedef struct semanage_mls semanage_role_t;
>>typedef struct semanage_role semanage_role_t;
>>    
>>
>
>??
>
>  
>
??? those aren't directly used, they are for supporting users

>>const char* semanage_mls_get_range(semanage_mls *);
>>const char* semanage_mls_get_level(semanage_mls *);
>>
>>int semanage_mls_set_range(semanage_mls *);
>>int semanage_mls_set_level(semanage_mls *);
>>    
>>
>
>Shouldn't the setters take a parameter of 
>what to set? You omit those in many places.
>
>  
>
yea, my mistake, obviously I was writing this to get the concepts out 
and let you see if they actually work for you, hopefully they will :)

>>/* semanage_user management functions */
>>int semanage_user_init(semanage_handle_t **);
>>    
>>
>
>You mean semanage_user_t** ?
>
>  
>
probably :)

>>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);
>>    
>>
>
>There's still no query or a way to modify the user other than delete 
>and re-add. This applies to the entire API. Delete and add may be
>acceptable (even though that automatically means two iterations
>in the file case), but no query just seems wrong. 
>
>  
>
oops, add
semanage_user_change(semanage_handle_t *, semanage_user_t *userdata, 
char* key);
it would totally replace the datum, no unioning or anything like that

<snip>

--
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: Iptables discussion

[Ivan Gyurdiev]

> >No...an intermediate representation on the libsepol level,
> >as well as the libsemanage level. 
> >
> >  
> >
> we need to figure out what we need to store before we decide if we need 
> another policy representation.

Speaking of which... I'm duplicating your sepol_*_t records
almost one-to-one in the libsepol api. I don't see a way around 
that, however, because they are located in libsemanage.

> >Can you please rename the library, so I can send patches against it?
> >I tried to do this myself, but you didn't like my patch.
> >
> >  
> >
> It won't matter since the library doesn't currently match the proposed 
> API.

It does matter, because I can write patches against it, and not write
semod_ everywhere that I need to fix later.

>  Probably the best thing would be to write your user and port 
> management stuff against the new API and see if it actually works.

I can't see if actually works, because there is no library to test it
with. It used to work when it was in libselinux... I'm sure I'll have
to change it a bit to fit with your structure names, and your apis,
and your transaction processing.

> semanage_user_change(semanage_handle_t *, semanage_user_t *userdata, 
> char* key);
> it would totally replace the datum, no unioning or anything like that

If you're assuming character key, please assume character key in
the delete functions as well. I'm not against it, simply pointing out..

The drawback to not providing any more specific change functions 
to the caller, is that now you have to do a query and a change for
everything, even if all you're doing is adding information, and not
extracting any. That means two iterations in the flat file case...
but for the sake of simplicity and cleanness of API, maybe I'll agree.

However, not having a query function is just wrong, I disagree with
that.


--
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: Iptables discussion

[Joshua Brindle]

<snip>

>Speaking of which... I'm duplicating your sepol_*_t records
>almost one-to-one in the libsepol api. I don't see a way around 
>that, however, because they are located in libsemanage.
>
>  
>
Why do you need them in libsepol? You don't need or want opaque types in 
libsepol, libsepol is a direct representation of the policy data 
structures. All the abstracted structures go in libsemanage.

<snip>

>It does matter, because I can write patches against it, and not write
>semod_ everywhere that I need to fix later.
>
>  
>
We aren't writing patches right now, we are trying to design a library. 
I'm really asking for your help to flesh out what is required for this 
API to work so that we can actually implement it.

>> Probably the best thing would be to write your user and port 
>>management stuff against the new API and see if it actually works.
>>    
>>
>
>I can't see if actually works, because there is no library to test it
>with. It used to work when it was in libselinux... I'm sure I'll have
>to change it a bit to fit with your structure names, and your apis,
>and your transaction processing.
>
>  
>
I mean that it works conceptually, ie: the API provides everything you 
need. Compiling and testing is very irrelavent right now since we are 
trying to design a very abstract management API for SELinux, something 
that needs to be carefully designed.

>>semanage_user_change(semanage_handle_t *, semanage_user_t *userdata, 
>>char* key);
>>it would totally replace the datum, no unioning or anything like that
>>    
>>
>
>If you're assuming character key, please assume character key in
>the delete functions as well. I'm not against it, simply pointing out..
>
>  
>
or we make opaque types for all keys and all datums just incase we want 
a composite key later.

>The drawback to not providing any more specific change functions 
>to the caller, is that now you have to do a query and a change for
>everything, even if all you're doing is adding information, and not
>extracting any. That means two iterations in the flat file case...
>but for the sake of simplicity and cleanness of API, maybe I'll agree.
>
>However, not having a query function is just wrong, I disagree with
>that.
>  
>
We'll add them, they are just convenience functions that will be added 
as needed.


Please, please stop focusing on the implementation details and help with 
the API design, I really need to know if this is sufficient for you 
(sans the labeling stuff that we are still working out). This is going 
to be an API that is used by every single tool that manages policy and 
it needs to be well thought out and flexible.

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: Iptables discussion

[Ivan Gyurdiev]

On Fri, 2005-07-22 at 15:56 -0400, Joshua Brindle wrote:
> <snip>
> 
> >Speaking of which... I'm duplicating your sepol_*_t records
> >almost one-to-one in the libsepol api. I don't see a way around 
> >that, however, because they are located in libsemanage.
> >
> >  
> >
> Why do you need them in libsepol? You don't need or want opaque types in 
> libsepol, libsepol is a direct representation of the policy data 
> structures. All the abstracted structures go in libsemanage.

I don't _want_ libsepol to be a direct representation of the policy data
structures. This is the state of affairs right now, and I think it's
completely wrong, and needs to be changed. 

You can't do any representation changes without modifying libsepol _and_
everything that goes and manipulates internal structures outside 
libsepol. 

The whole point of a library is to hide internal functionality, not
to expose it to everything, so that you get dependencies.
Your desire to make libsepol static addresses the symptom of the 
problem, not the problem itself. To really address the problem,
we should move sepol structural dependencies inside sepol.
We should be building libsepol, not destroying it, and reducing
it down to a bunch of random object files with no interface.

I remember Stephen Smalley saying he wanted the internal headers
hidden, but they had to be shared with checkpolicy, and he didn't
know how to solve this - I think the answer is that all the
code in checkpolicy that manipulates data structures shouldn't
be in checkpolicy at all. I disagree with you that all the
code that matters has already been moved - this is just not
true in my opinion.

========

Now, the structures I've added to libsepol are not actually opaque,
they're just...higher level than the ones that manipulate sids.
This could be a bad thing or not - I don't know - people
who know and care more about ABI compatibility should say
something here. The fact of the matter is that I don't want 
to manipulate sids from libsemanage, and I think that's the 
completely wrong level for it. The code I have has nothing 
to do with sids - it manipulates files, and has to do with 
parsing information from those files, and relaying it to sepol.
 

> >It does matter, because I can write patches against it, and not write
> >semod_ everywhere that I need to fix later.
> >
> >  
> >
> We aren't writing patches right now, we are trying to design a library. 
> I'm really asking for your help to flesh out what is required for this 
> API to work so that we can actually implement it.

I am trying to help, but you're ignoring the fact that I had a working
implementation already when we began this discussion, and I've been
trying to turn it into something usable that people agree with
before my internship at RedHat ends by the end of next week.

> >I can't see if actually works, because there is no library to test it
> >with. It used to work when it was in libselinux... I'm sure I'll have
> >to change it a bit to fit with your structure names, and your apis,
> >and your transaction processing.
> >
> >  
> >
> I mean that it works conceptually, ie: the API provides everything you 
> need. Compiling and testing is very irrelavent right now since we are 
> trying to design a very abstract management API for SELinux, something 
> that needs to be carefully designed.

Ok, so let's carefully design it.. and then
add an implementation.

> >>semanage_user_change(semanage_handle_t *, semanage_user_t *userdata, 
> >>char* key);
> >>it would totally replace the datum, no unioning or anything like that
> >>    
> >>
> >
> >If you're assuming character key, please assume character key in
> >the delete functions as well. I'm not against it, simply pointing out..
> >
> >  
> >
> or we make opaque types for all keys and all datums just incase we want 
> a composite key later.

...or that...
I agree with your point that this way you can use a composite data key..
but it just looks weird. Is this a widely used practice of software
development - I don't have enough experience? 

> >The drawback to not providing any more specific change functions 
> >to the caller, is that now you have to do a query and a change for
> >everything, even if all you're doing is adding information, and not
> >extracting any. That means two iterations in the flat file case...
> >but for the sake of simplicity and cleanness of API, maybe I'll agree.
> >
> >However, not having a query function is just wrong, I disagree with
> >that.
> >  
> >
> We'll add them, they are just convenience functions that will be added 
> as needed.

The query functions are not a convenience functions - they
are fundamental to this whole thing working, especially the way
you have it right now.

I know the name of a selinux user, and I want to add a role.
How would I do that? I can't - it's impossible, because you've
provided no way to query the existing information (which provides
the rest of user's data to combine with this new role). I have
to completely regenerate the user record in order to add a new
role.

> Please, please stop focusing on the implementation details and help with 
> the API design, I really need to know if this is sufficient for you 
> (sans the labeling stuff that we are still working out). This is going 
> to be an API that is used by every single tool that manages policy and 
> it needs to be well thought out and flexible.

Okay... 



--
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: Iptables discussion

[Ivan Gyurdiev]

> > I mean that it works conceptually, ie: the API provides everything you 
> > need. Compiling and testing is very irrelavent right now since we are 
> > trying to design a very abstract management API for SELinux, something 
> > that needs to be carefully designed.
> 
> Ok, so let's carefully design it.. and then
> add an implementation.

To expand on that:

I'll try changing my code to all those new names and functions next 
week, but off the top of my head, I can tell you that this api doesn't
work without query function, because you have a single modify function
that doesn't provide for ways to explain *how* to modify the record.
That means two things - (1) the caller needs to do the modify,
which means that query is absolutely necessary, because you
shouldn't assume the modifying application can recreate the record, 
and (2) two iterations will be required, instead of one in the flat file
case for every modify (one for the query, and one for the modify).

The second issue I have is that the homedirs thing just isn't finalized
- please respond to some of my questions about potential implementation
(see my response to Karl). My current implementation of this
is ugly, and I want to replace it, and I'm not sure how - it's a
difficult issue to deal with.

The answer to how the file_contexts issue will be handled may also
determine whether or not libsemanage needs access to the user map,
and add more arguments against/for placing map handling in libsemanage.

Let's continue this discussion next week.


--
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: Iptables discussion

[Casey Schaufler]

--- Karl MacMillan <kmacmillan@tresys.com> wrote:


> I know that this is just a motivating example, but I
> feel compelled to point out
> that 1) this problem is not really related to MLS in
> the real world and 

On the contrary, it is a commonly requested
scenario, not always with web services but
often enough. Frequently the situation is an
application written and owned by a 3rd party
that provides a "special" service of some kind.
Running two servers, one at Secret, one at
TopSecret is the mode they prefer.

> 2)
> separation based on ports is _very_ unlikely to meet
> the requirements of a
> system that will be processing data at different
> sensitivities.

It is done all the time. Yes, policy enforcing
trusted applications are better, but y'all don't
seem to have an interface for doing that, and
most users couldn't change the applications
anyway.

In Trix 4 we had polyinstantiated sockets. We
dropped them in Trix 6 to be more like the
other systems available at the time. I don't
think anyone noticed because everyone was
already doing "a server per label".




Casey Schaufler
casey@schaufler-ca.com


		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 

--
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: Iptables discussion

[Joshua Brindle]

Casey Schaufler wrote:

>--- Karl MacMillan <kmacmillan@tresys.com> wrote:
>
>
>  
>
>>I know that this is just a motivating example, but I
>>feel compelled to point out
>>that 1) this problem is not really related to MLS in
>>the real world and 
>>    
>>
>
>On the contrary, it is a commonly requested
>scenario, not always with web services but
>often enough. Frequently the situation is an
>application written and owned by a 3rd party
>that provides a "special" service of some kind.
>Running two servers, one at Secret, one at
>TopSecret is the mode they prefer.
>
>  
>
>>2)
>>separation based on ports is _very_ unlikely to meet
>>the requirements of a
>>system that will be processing data at different
>>sensitivities.
>>    
>>
>
>It is done all the time. Yes, policy enforcing
>trusted applications are better, but y'all don't
>seem to have an interface for doing that, and
>most users couldn't change the applications
>anyway.
>  
>
eh? we certainly have userspace object managers, some in production use 
such as dbus, passwd, cron, and others in development like SE-X

We are also working on better support for userspace object managers 
currently, such as adding a userspace security server for providing 
decisions to userspace object managers (thus reducing the policy in the 
kernel) and allowing object managers to register their object classes 
dynamically.

>In Trix 4 we had polyinstantiated sockets. We
>dropped them in Trix 6 to be more like the
>other systems available at the time. I don't
>think anyone noticed because everyone was
>already doing "a server per label".
>
>
>
>
>Casey Schaufler
>casey@schaufler-ca.com
>
>
>		
>____________________________________________________
>Start your day with Yahoo! - make it your home page 
>http://www.yahoo.com/r/hs 
> 
>
>  
>


--
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: Iptables discussion

[Frank Mayer]

>> I know that this is just a motivating example, but I feel compelled
>> to point out that 1) this problem is not really related to MLS in the
>> real world and
> 
> On the contrary, it is a commonly requested scenario, not always with
> web services but often enough. Frequently the situation is an
> application written and owned by a 3rd party that provides a
> "special" service of some kind. Running two servers, one at Secret,
> one at TopSecret is the mode they prefer.   

I think Karl's point, which I believe Chad also made, is that for most "MLS"
applications with 2 interfaces (e.g., guards), the whole interfaces are
treated differently (e.g., a low interface and a high interface), and
port/host level access is not the central MLS issue. Certainly true given
the lack of trusted network protocols. Of course outside of the "MLS" arena
(and also inside MLS applications as an added, but less critical "defense in
dept" security filtering), port/host level access control is used all the
time, which I think was Dan's point.

BTW, I think our only difference with Chad for the "MLS" apps is that in our
experience with many such applications using SELinux so far, we didn't need
the Bell-LaPadula MLS features; TE has proven a superior MAC mechanisms for
the needed domain separation for most guarding applications. Frank



--
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: Iptables discussion

[Casey Schaufler]

--- Frank Mayer <mayerf@tresys.com> wrote:


> I think Karl's point, which I believe Chad also
> made, is that for most "MLS"
> applications with 2 interfaces (e.g., guards), the
> whole interfaces are
> treated differently (e.g., a low interface and a
> high interface), and
> port/host level access is not the central MLS issue.

TE does have a certain appeal for guard
applications. Guard applications are in
fact one of the important class of applications
for which MLS systems are traditionally
used. For guard applications the "MLS issue"
is internal to the application.



Casey Schaufler
casey@schaufler-ca.com


		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 

--
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: Iptables discussion

[James Morris]

On Fri, 22 Jul 2005, Daniel J Walsh wrote:

> User has two network devices (Internal and External)  He wants to allow only 
> Apache to listen on the external device, and only communicate via LDAP over 
> the internal device?  How would he set that up?  (IF someone says he will 
> rewrite policy, I will scream, and then ask you to write policy to allow 
> this. )

name_bind allows control over which local IP address type the domain can 
bind to, but not network device.

You can then control which type of netdev the domain sends and receives 
packets over via {udp,tcp,raw}_{send,rcv} in the netif class.

There's also some control over port use (i.e. LDAP) on a per packet basis.

All of these currently require policy modifications.  The per packet 
controls are probably better served via iptables integration as the 
iptables framework is more expressive and has more useful features.  It 
would also not require SELinux policy modification (but iptables updates 
instead).

I'm not sure how to make name_bind user-customizable, or if you really 
need it in this case if packet level controls are doing their job,

> MLS System, wants to have two Apache systems,  One listening at port 80 for 
> Top Secret communications, another at port 81 for secret.  How do you do 
> this?

IPsec is likely the best way to do this, but what you're really asking for 
is more general:

   How do you handle policy for multiple instances of the same software
   running in different domains with different configurations?

Hierarchical & loadable policy modules?

For something as common and complex as Apache, you could have a reference 
policy which is modifiable by some GUI tool which understands the httpd 
config file and also provides abstractions for further user customization, 
and writes out a loadable module and fc file.

> You want to setup a Zone Transfer between your two named servers.  You want 
> to guarantee that named_t on one machine is talking to named_t on another 
> machine over an encrypted line?

IPsec labeling.

> I believe the only way for users to do these things successfully is to have 
> integration of SELinux with iptables, and no writing/rewriting of policy will 
> solve the problem.

iptables integration would only help with the per-packet controls 
mentioned in the first scenario.


- James
-- 
James Morris
<jmorris@redhat.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: Iptables discussion

[Casey Schaufler]

--- James Morris <jmorris@redhat.com> wrote:


> > MLS System, wants to have two Apache systems,  One
> listening at port 80 for 
> > Top Secret communications, another at port 81 for
> secret.  How do you do 
> > this?
> 
> IPsec is likely the best way to do this

IPsec is an important part of the "correct"
solution but it requires that the application
is aware of IPsec and takes advantage of it
and can be trusted to do so properly. There
are many examples (web serving is one) of
applications that you don't really want to
muck with the internals of (and the maintainers
ain't gonna let you anyhow) that work just
fine in a server-per-label scheme. At least,
that's true for B&L+Biba. There are many
deployed examples, which is where I suspect
the original questino can from.



Casey Schaufler
casey@schaufler-ca.com

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.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: Iptables discussion

[James Morris]

On Sun, 24 Jul 2005, Casey Schaufler wrote:

>> IPsec is likely the best way to do this
>
> IPsec is an important part of the "correct" solution but it requires 
> that the application is aware of IPsec and takes advantage of it and can 
> be trusted to do so properly.

I was referring to the IPsec labeling scheme from Trent Jaeger, which 
should not require any modification of the web servers.

> There are many examples (web serving is one) of applications that you 
> don't really want to muck with the internals of (and the maintainers 
> ain't gonna let you anyhow) that work just fine in a server-per-label 
> scheme. At least, that's true for B&L+Biba. There are many deployed 
> examples, which is where I suspect the original questino can from.

Yes, I was thinking of server per level, where IPsec labeling is used to 
enforce security policy across the network.


- James
-- 
James Morris
<jmorris@redhat.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: Iptables discussion

[Daniel J Walsh]

With the current way that policy is written all devices get the 
netif_type by default.  This type is then only used in the can_network 
macros. 

define(`base_can_network',`
...
#
# Allow the domain to send or receive using any network interface.
# netif_type is a type attribute for all network interface types.
#
allow $1 netif_type:netif { $2_send rawip_send };
allow $1 netif_type:netif { $2_recv rawip_recv };
...


Since we would want to take this ability away from a specific device, we 
would need some kind of
boolean or tunable to take away the netif_type for say the ethernet 
device.   I could envision something
like the following

in types/network.te

define(`network_device_domain', `
type netif_$1_t;
boolean allow_$1_all_communication true;
if (allow_$1_all_communication) {
typeattribute netif_$1_t netif_type;
}
')

Of course you can wrap typeattributes in booleans yet, so this would 
have to be enhanced.
Then the user or iptables would have to add the appropriate rules for 
the selinux domain

define(`can_nitif_communicate', `
allow $1_t netif_$2_t:netif { $3_send rawip_send };
allow $1_t netif_$2_t:netif { $3_recv rawip_recv };
')
can_netif_communicate(httpd_t, eth0, tcp)


--
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: Iptables discussion

[Christopher J. PeBenito]

On Mon, 2005-07-25 at 11:37 -0400, Daniel J Walsh wrote:
> With the current way that policy is written all devices get the 
> netif_type by default.  This type is then only used in the can_network 
> macros. 
> 
> define(`base_can_network',`
> ...
> #
> # Allow the domain to send or receive using any network interface.
> # netif_type is a type attribute for all network interface types.
> #
> allow $1 netif_type:netif { $2_send rawip_send };
> allow $1 netif_type:netif { $2_recv rawip_recv };
> ...
> 
> 
> Since we would want to take this ability away from a specific device,
> we would need some kind of boolean or tunable to take away the
> netif_type for say the ethernet device.

I think the better way would be to change the way the policy works,
rather then conditionally applying the attribute.  The default should
probably be to not have any netifcon statements except for interfaces we
want different behavior.  The above macro would be changed to use
netif_t as the target, rather then netif_type.  Then all interface types
still keep the netif_type attribute, so the privilege of using all
interfaces still exists, if needed, but since there are no netifcons,
all interfaces fall back to the initial sid type (netif_t).  When the
user wants different behaviors for a specific interface, then the tool
would add the netifcon to the policy, and add the appropriate rules to
the policy.

To make this work better, then the can_network*() macros could be
modified to have an additional optional parameter to specify which
interface(s) to use.  Then if the interface is supplied, the specified
interface type is used; otherwise, the generic interface (netif_t) is
used.

So you could have:

can_network(apache_t)

and then to change it to only use eth0,

can_network(apache_t,eth0_netif_t)

and label the external interface in net_contexts:

netifcon eth0 system_u:object_r:eth0_netif_t system_u:object_r:unlabeled_t

or perhaps the type could just be shortened to just eth0, and the type
name inferred.  This would then just result in a one line policy change,
and a netifcon for each specified interface.

The reference policy does not have the can_network() style macros, but
rather specifies ports, nodes, and netifs interfaces separately, so this
would also be fairly simple.  So the apache policy might start out with
this:

corenet_tcp_sendrecv_generic_if(apache_t)

to use generic (netif_t) interfaces, and to make it use the "external"
interfaces eth1 and eth2, we just change it to

corenet_tcp_sendrecv_external_if(apache_t)

and label the external interfaces by adding this in corenetwork:

network_interface(external, eth1,s0, eth2,s0)

(sensitivity would be dropped on non MLS policies)

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Iptables discussion

[Ivan Gyurdiev]

> So you could have:
> 
> can_network(apache_t)
> 
> and then to change it to only use eth0,
> 
> can_network(apache_t,eth0_netif_t)

I think automatic policy editing has to occur post-m4 - it doesn't
make sense to me to be generating pre-m4 macros - this is going
to be very hard to validate, and require a long time to compile and
process.

Your 1-line change expands to several hundred rules in policy.



--
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: Iptables discussion

[Ivan Gyurdiev]

On Mon, 2005-07-25 at 14:28 -0400, Ivan Gyurdiev wrote:
> > So you could have:
> > 
> > can_network(apache_t)
> > 
> > and then to change it to only use eth0,
> > 
> > can_network(apache_t,eth0_netif_t)
> 
> I think automatic policy editing has to occur post-m4 - it doesn't
> make sense to me to be generating pre-m4 macros - this is going
> to be very hard to validate, and require a long time to compile and
> process.
> 
> Your 1-line change expands to several hundred rules in policy.

Perhaps I misunderstood what you were saying.
Dan's saying you want the netif argument to be optional,
and we fallback to a default label where everything's allowed 
if the argument is missing - so you'd only add a specific 
label for things you want managed by iptables. 

That would make sense, and might be a good idea.



--
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: Iptables discussion

[Daniel J Walsh]

Ivan Gyurdiev wrote:

>On Mon, 2005-07-25 at 14:28 -0400, Ivan Gyurdiev wrote:
>  
>
>>>So you could have:
>>>
>>>can_network(apache_t)
>>>
>>>and then to change it to only use eth0,
>>>
>>>can_network(apache_t,eth0_netif_t)
>>>      
>>>
>>I think automatic policy editing has to occur post-m4 - it doesn't
>>make sense to me to be generating pre-m4 macros - this is going
>>to be very hard to validate, and require a long time to compile and
>>process.
>>
>>Your 1-line change expands to several hundred rules in policy.
>>    
>>
>
>Perhaps I misunderstood what you were saying.
>Dan's saying you want the netif argument to be optional,
>and we fallback to a default label where everything's allowed 
>if the argument is missing - so you'd only add a specific 
>label for things you want managed by iptables. 
>
>That would make sense, and might be a good idea.
>
>
>  
>
Ok so then a tool could add the following rules to only allow apache and 
named to run on 0.

type netif_eth0_t, netif_type;
netifcon eth0 system_u:object_r:netif_eth0_t system_u:object_r:unlabeled_t
allow httpd_t netif_eth0_t:netif { tcp_recv tcp_send rawip_send 
rawip_recv };
allow named_t netif_eth0_t:netif { udp_recv udp_send tcp_recv tcp_send 
rawip_send rawip_recv };


-- 



--
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: Iptables discussion

[Joshua Brindle]

Daniel J Walsh wrote:

> Ivan Gyurdiev wrote:
>
>> On Mon, 2005-07-25 at 14:28 -0400, Ivan Gyurdiev wrote:
>>  
>>
>>>> So you could have:
>>>>
>>>> can_network(apache_t)
>>>>
>>>> and then to change it to only use eth0,
>>>>
>>>> can_network(apache_t,eth0_netif_t)
>>>>     
>>>
>>> I think automatic policy editing has to occur post-m4 - it doesn't
>>> make sense to me to be generating pre-m4 macros - this is going
>>> to be very hard to validate, and require a long time to compile and
>>> process.
>>>
>>> Your 1-line change expands to several hundred rules in policy.
>>>   
>>
>>
>> Perhaps I misunderstood what you were saying.
>> Dan's saying you want the netif argument to be optional,
>> and we fallback to a default label where everything's allowed if the 
>> argument is missing - so you'd only add a specific label for things 
>> you want managed by iptables.
>> That would make sense, and might be a good idea.
>>
>>
>>  
>>
> Ok so then a tool could add the following rules to only allow apache 
> and named to run on 0.
>
> type netif_eth0_t, netif_type;
> netifcon eth0 system_u:object_r:netif_eth0_t 
> system_u:object_r:unlabeled_t
> allow httpd_t netif_eth0_t:netif { tcp_recv tcp_send rawip_send 
> rawip_recv };
> allow named_t netif_eth0_t:netif { udp_recv udp_send tcp_recv tcp_send 
> rawip_send rawip_recv };
>
IMHO, I think that we _cannot_ add code to iptables to manage policy. 
This is a bad idea for a number of reasons that I've talked about in 
other emails.

This functionality should be put in system-config-security to set up the 
firewall iptables rules and manage a subset of the network related 
policy rules. This should leverage the module system so that 
system-config-security essentially owns a module that it can put it's 
rules in, remove them, etc. We can later use the policy server to limit 
this applications policy actions to just those under the primary network 
type.

I still think there are consistency issues with this, the software will 
have to be careful. All of the network rules will have to be moved to a 
single module (this is odd since apache has it's own rules, etc.. maybe 
those will be removed and all network access is defined centrally). I 
really don't like this but if you want configurable network rules there 
really isn't much choice.

The interfaces to do this work should be exported through libsemanage to 
do it seamlessly regardless of policy backend. The labels will have to 
(unfortunatly) be part of some configutation file, which is policy 
specific. This means that there needs to be some config files that are 
tightly coupled with the policy to tell these management applications 
what types they want to refer to.

Also the other issue with allow-by-default firewalls and deny rules, 
which can't be addresssed in policy at all (and I think it's a very bad 
idea for some network config app to recurse the entire policy looking 
for rules that might violate it's internal settings).



--
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: Iptables discussion

[Ivan Gyurdiev]

> > type netif_eth0_t, netif_type;
> > netifcon eth0 system_u:object_r:netif_eth0_t 
> > system_u:object_r:unlabeled_t
> > allow httpd_t netif_eth0_t:netif { tcp_recv tcp_send rawip_send 
> > rawip_recv };
> > allow named_t netif_eth0_t:netif { udp_recv udp_send tcp_recv tcp_send 
> > rawip_send rawip_recv };

Those seem reasonable.

> IMHO, I think that we _cannot_ add code to iptables to manage policy. 
> This is a bad idea for a number of reasons that I've talked about in 
> other emails.

I haven't seen any of those, can you point me somewhere?

> This functionality should be put in system-config-security to set up the 
> firewall iptables rules and manage a subset of the network related 
> policy rules. 

I don't understand why we have two sets of rules to manage the same
thing.

> This should leverage the module system so that 
> system-config-security essentially owns a module that it can put it's 
> rules in, remove them, etc. We can later use the policy server to limit 
> this applications policy actions to just those under the primary network 
> type.

Good idea...

> The interfaces to do this work should be exported through libsemanage to 
> do it seamlessly regardless of policy backend. The labels will have to 
> (unfortunatly) be part of some configutation file, which is policy 
> specific. 

The labels can be inferred from the card name, if necessary.

> Also the other issue with allow-by-default firewalls and deny rules, 
> which can't be addresssed in policy at all (and I think it's a very bad 
> idea for some network config app to recurse the entire policy looking 
> for rules that might violate it's internal settings).

Deny rules could possibly be ... denied :) on an selinux-enabled system.


--
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: Iptables discussion

[Joshua Brindle]

Ivan Gyurdiev wrote:

>>>type netif_eth0_t, netif_type;
>>>netifcon eth0 system_u:object_r:netif_eth0_t 
>>>system_u:object_r:unlabeled_t
>>>allow httpd_t netif_eth0_t:netif { tcp_recv tcp_send rawip_send 
>>>rawip_recv };
>>>allow named_t netif_eth0_t:netif { udp_recv udp_send tcp_recv tcp_send 
>>>rawip_send rawip_recv };
>>>      
>>>
>
>Those seem reasonable.
>
>  
>
rawip_* isn't necessary and should not be added

>>IMHO, I think that we _cannot_ add code to iptables to manage policy. 
>>This is a bad idea for a number of reasons that I've talked about in 
>>other emails.
>>    
>>
>
>I haven't seen any of those, can you point me somewhere?
>
>  
>
earlier in this thread, the consistency arguments (iptables having a 
run-time state vs. a persistant state, contrary to the persistant state 
of the selinux policy)

>>This functionality should be put in system-config-security to set up the 
>>firewall iptables rules and manage a subset of the network related 
>>policy rules. 
>>    
>>
>
>I don't understand why we have two sets of rules to manage the same
>thing.
>
>  
>
there will always be 2 sets, we are trying to keep them consistent. 
Also, iptables can state alot more than the policy currently supports. 
Adding this to iptables means defining certain types of 'supported' 
rules to add to the policy. Rather than do that this should be done from 
the interface that already limits what kind of rules you can do and 
simplifies them for the user (system-config-network{,-tui}

>>This should leverage the module system so that 
>>system-config-security essentially owns a module that it can put it's 
>>rules in, remove them, etc. We can later use the policy server to limit 
>>this applications policy actions to just those under the primary network 
>>type.
>>    
>>
>
>Good idea...
>
>  
>
>>The interfaces to do this work should be exported through libsemanage to 
>>do it seamlessly regardless of policy backend. The labels will have to 
>>(unfortunatly) be part of some configutation file, which is policy 
>>specific. 
>>    
>>
>
>The labels can be inferred from the card name, if necessary.
>
>  
>
no, implicit labeling considered harmful. This destroys the concept of 
equivalence classes (which is what types are). You should be able to 
make 2 interfaces equivalent without having a set of rules for each of them.

>>Also the other issue with allow-by-default firewalls and deny rules, 
>>which can't be addresssed in policy at all (and I think it's a very bad 
>>idea for some network config app to recurse the entire policy looking 
>>for rules that might violate it's internal settings).
>>    
>>
>
>Deny rules could possibly be ... denied :) on an selinux-enabled system.
>
>  
>
that means the app needs to get a full copy of the policy and try to 
find allow rules that could violate the deny state of the iptables rule, 
this is bad

--
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: Iptables discussion

[Ivan Gyurdiev]

> earlier in this thread, the consistency arguments (iptables having a 
> run-time state vs. a persistant state, contrary to the persistant state 
> of the selinux policy)

Ah, I see:

"This may cause consistency problems. Adding a iptable rule 
would add it to the current running firewall config (in memory) 
and may or may not store it in a state file to be rerun on boot."

Well, actually we can't add anything to iptables, because
of the performance overhead of a policy rewrite. We need
to have a concept of a configuration, so that we 
can begin and end the transaction appropriately and not per rule
invocation.

In which case, yes, this is a valid argument - something higher level
than iptables needs to handle this... but system-config-security is
written in python...perhaps some iptables wrapper.

> no, implicit labeling considered harmful. This destroys the concept of 
> equivalence classes (which is what types are). You should be able to 
> make 2 interfaces equivalent without having a set of rules for each of them.

I understand the argument, but realize that most users will not,
and should not care - they want to configure their ethernet cards,
not any security labels. Anyway, configuring the network 
interface labels is a lot easier than dealing with allow rules.
Then you can look them up via the query function which I submitted.

> >Deny rules could possibly be ... denied :) on an selinux-enabled system.
> >
> >  
> >
> that means the app needs to get a full copy of the policy and try to 
> find allow rules that could violate the deny state of the iptables rule, 
> this is bad

I don't understand this - I was implying that we completely disallow 
deny rules. Perhaps you can clarify...



--
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: Iptables discussion

[Joshua Brindle]

Ivan Gyurdiev wrote:

>>earlier in this thread, the consistency arguments (iptables having a 
>>run-time state vs. a persistant state, contrary to the persistant state 
>>of the selinux policy)
>>    
>>
>
>Ah, I see:
>
>"This may cause consistency problems. Adding a iptable rule 
>would add it to the current running firewall config (in memory) 
>and may or may not store it in a state file to be rerun on boot."
>
>Well, actually we can't add anything to iptables, because
>of the performance overhead of a policy rewrite. We need
>to have a concept of a configuration, so that we 
>can begin and end the transaction appropriately and not per rule
>invocation.
>
>In which case, yes, this is a valid argument - something higher level
>than iptables needs to handle this... but system-config-security is
>written in python...perhaps some iptables wrapper.
>
>  
>
sounds like we need some python wrappers for libsemanage :)

Since portage will probably need to manage policy these will emerge (no 
pun intended) at some point regardless. Whoever needs them first gets to 
write them though :)

some already exist for parts of libselinux 
(http://sourceforge.net/projects/python-selinux) which were created to 
handle selinux functions for portage (the gentoo package manager)

>>no, implicit labeling considered harmful. This destroys the concept of 
>>equivalence classes (which is what types are). You should be able to 
>>make 2 interfaces equivalent without having a set of rules for each of them.
>>    
>>
>
>I understand the argument, but realize that most users will not,
>and should not care - they want to configure their ethernet cards,
>not any security labels. Anyway, configuring the network 
>interface labels is a lot easier than dealing with allow rules.
>Then you can look them up via the query function which I submitted.
>
>  
>
most users don't understand type enforcement at all, thats why we are 
abstracting this. Clearly the application configuring the interfaces 
won't need to burden the users with this information, which is why i 
suggested that a policy specific configuration file may be necessary for 
this.

>>>Deny rules could possibly be ... denied :) on an selinux-enabled system.
>>>
>>> 
>>>
>>>      
>>>
>>that means the app needs to get a full copy of the policy and try to 
>>find allow rules that could violate the deny state of the iptables rule, 
>>this is bad
>>    
>>
>
>I don't understand this - I was implying that we completely disallow 
>deny rules. Perhaps you can clarify...
>  
>
ah, I read it wrong, sorry :)

I thought you meant deny rules would somehow reflect a similar denial in 
selinux, which is problematic

--
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: Iptables discussion

[Karl MacMillan]

> -----Original Message-----
> From: Ivan Gyurdiev [mailto:gyurdiev@redhat.com]
> 
> ------
> 
> Let me get to the point - we have iptables, which configures netfilter.
> Then we have policy, which configures selinux. That's two configuration
> systems, and having two configuration systems is not good - you have to
> go change both to get anything to work. Furthermore, iptables has
> a superior configuration system from a user's point of view, because
> it's easier to work with than writing policy in m4 macros.
> 
> So, what do we do about that? Dan is suggesting we might integrate
> iptables with policy, and have it automatically generate some rules,
> pertaining to interfaces, ports, etc... we can now query sepol
> for the port label, and query sepol for the interface label.
> 
> I'm not sure how this should be done, or whether this should be done,
> but it merits further discussion. Should modules play a role into
> this...is it a good idea...etc.

I understand the goal of this integration and agree that it is difficult for a
user to specify network policy in two places. The same could be said, though,
about many aspects of the policy. There must be agreement between the apache
config and the apache policy for example. This is a general failing of Linux (it
is also a strength in that the loose coupling allows replacing large subsystems
easily).

Having said that, I have a _very_ strong preference for all of the network
policy being part of the SELinux policy. Many of our customers care about the
ability to reason about and analyze SELinux policy in an automated way. If
significant parts of the policy are moved out of the SELinux policy proper or,
more importantly, expressed in a language with a model that has received none of
the rigorous scrutiny that type enforcement has received then our ability to do
this automated analysis will be seriously degraded. This would be a real loss,
particular for customers that need higher levels of assurance about the
correctness of the security of their systems (I'm using the term assurance in an
informal way here).

I would suggest that making this choice based on whether the iptables syntax or
the SELinux policy syntax is more intuitive is missing an important point: both
are too complicated and potentially beyond the ability or patience of many users
/ admins that will want to make these customizations. Why not create a tool that
generates both and leave the loose coupling? That frees you to do some real
user-interface work to create something easier to understand.

Karl

---
Karl MacMillan
Tresys Technology
http://www.tresys.com
(410) 290-1411 ext 134



--
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: Iptables discussion

[Chad Hanson]

>> 
>> MLS System, wants to have two Apache systems,  One listening at port 80
>> for Top Secret communications, another at port 81 for secret.  How do
>> you do this?
>> 
>
>I know that this is just a motivating example, but I feel compelled to
>point out that 1) this problem is not really related to MLS in the real
>world and 2) separation based on ports is _very_ unlikely to meet the
>requirements of a system that will be processing data at different
>sensitivities.
>

Common MLS networking uses are having at least 2 interfaces, these
interfaces have different MLS labels. Also nodes/networks are given MLS
labels to tie together their usage on an interface.  

A simple web server example for say label unclass and confidential  would
want to make sure that those servers no matter which port they listen, only
communicate to nodes or the same label across an interface of the same label
as well. 

A client example of a web browser is the same. If you are unclass, the
browser should only communicate to unclass nodes and interfaces.  

iptables is complimentary and essential to solutions as it does the needed
filtering. 

-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: Iptables discussion

[James Morris]

On Fri, 22 Jul 2005, Chad Hanson wrote:

> A simple web server example for say label unclass and confidential  would
> want to make sure that those servers no matter which port they listen, only
> communicate to nodes or the same label across an interface of the same label
> as well.
>
> A client example of a web browser is the same. If you are unclass, the
> browser should only communicate to unclass nodes and interfaces.

This would be a job for IPsec implicit labeling.

> iptables is complimentary and essential to solutions as it does the needed
> filtering.

In this case, IPsec would do its own filtering.

- James
-- 
James Morris
<jmorris@redhat.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: Iptables discussion

[Chad Hanson]

> > The interfaces to do this work should be exported through libsemanage to

> > do it seamlessly regardless of policy backend. The labels will have to 
> > (unfortunatly) be part of some configutation file, which is policy 
> > specific. 
> 
> The labels can be inferred from the card name, if necessary.
> 

contexts for interfaces and nodes need to managed and shouldn't be just
inferred.

--
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: Iptables discussion

[Chad Hanson]

> 
> I think the better way would be to change the way the policy works,
> rather then conditionally applying the attribute.  The default should
> probably be to not have any netifcon statements except for interfaces we
> want different behavior.  The above macro would be changed to use
> netif_t as the target, rather then netif_type.  Then all interface types
> still keep the netif_type attribute, so the privilege of using all
> interfaces still exists, if needed, but since there are no netifcons,
> all interfaces fall back to the initial sid type (netif_t).  When the
> user wants different behaviors for a specific interface, then the tool
> would add the netifcon to the policy, and add the appropriate rules to
> the policy.
> 
> To make this work better, then the can_network*() macros could be
> modified to have an additional optional parameter to specify which
> interface(s) to use.  Then if the interface is supplied, the specified
> interface type is used; otherwise, the generic interface (netif_t) is
> used.
> 
> So you could have:
> 
> can_network(apache_t)
> 
> and then to change it to only use eth0,
> 
> can_network(apache_t,eth0_netif_t)
> 
> and label the external interface in net_contexts:
> 
> netifcon eth0 system_u:object_r:eth0_netif_t 
> system_u:object_r:unlabeled_t
> 
> or perhaps the type could just be shortened to just eth0, and the type
> name inferred.  This would then just result in a one line 
> policy change,
> and a netifcon for each specified interface.

There is a problem with virtual interfaces here as they contain colons I
believe.

> 
> The reference policy does not have the can_network() style macros, but
> rather specifies ports, nodes, and netifs interfaces 
> separately, so this
> would also be fairly simple.  So the apache policy might 
> start out with
> this:
> 
> corenet_tcp_sendrecv_generic_if(apache_t)
> 
> to use generic (netif_t) interfaces, and to make it use the "external"
> interfaces eth1 and eth2, we just change it to
> 
> corenet_tcp_sendrecv_external_if(apache_t)
> 
> and label the external interfaces by adding this in corenetwork:
> 
> network_interface(external, eth1,s0, eth2,s0)
> 
> (sensitivity would be dropped on non MLS policies)
> 

I like the ideas above and think they sound reasonable.  

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