Iptables discussion

[Ivan Gyurdiev <gyurdiev@redhat.com>]

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.