All of lore.kernel.org
 help / color / mirror / Atom feed
* network object
@ 2004-08-11  2:38 Alexis Wagner
  2004-08-12 13:50 ` Stephen Smalley
  0 siblings, 1 reply; 2+ messages in thread
From: Alexis Wagner @ 2004-08-11  2:38 UTC (permalink / raw)
  To: SE-Linux

Hi,

I have some questions about selinux in a labeled network. 

First of all, I have read on the web that network labelling is not 
supported in kernel 2.6 an higher.  I have also read that it will be 
possible to reimplement the necessary features using the packet filter.
Is that true ?

Imagine I want to allow the domain one_t to set up and use  a tcp 
connection with the domain two_t on node two_t.  
Is it the correct way to set up the policy ?

node one  will have the following configuration :
net_contexts  :
        nodecon 10.10.10.2 255.255.255.255 system_u:object_r:node_two_t
one.te :
        allow one_t self:tcp_socket  { create_stream_socket_perms } ;
        allow one_t netif_type:netif  {tcp_recv tcp_send} ;
        allow one_t node_two_t:node {node_bind tcp_send tcp_recv};
        allow one_t port_t:tcp_socket {name_bind  recv_msg send_msg} ;
        allow one_t net_conf_t:file r_file_perms;

        allow one_t kernel_t:tcp_socket {recvfrom } ;
       #Wich domain I put here ? 
        allow one_t ???:tcp_socket {acceptfrom recvfrom } ;

node two will have the following configuration :
net_contexts  :
        nodecon 10.10.10.1 255.255.255.255 system_u:object_r:node_one_t
two.te :
        allow two_t self:tcp_socket  { create_stream_socket_perms } ;
        allow two_t netif_type:netif  {tcp_recv tcp_send} ;
        allow two_t node_one_t:node {node_bind tcp_send tcp_recv};
        allow two_t port_t:tcp_socket {name_bind  recv_msg send_msg} ;
        allow two_t net_conf_t:file r_file_perms;

        allow two_t kernel_t:tcp_socket {recvfrom } ;
       #Wich domain I put here ? 
        allow two_t ???:tcp_socket {acceptfrom recvfrom } ;


It is correct ?

Where could I find more uptodate information about using SELinux in a 
labeled network ?


Thank you,

Alexis Wagner



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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: network object
  2004-08-11  2:38 network object Alexis Wagner
@ 2004-08-12 13:50 ` Stephen Smalley
  0 siblings, 0 replies; 2+ messages in thread
From: Stephen Smalley @ 2004-08-12 13:50 UTC (permalink / raw)
  To: Alexis Wagner; +Cc: SE-Linux

On Tue, 2004-08-10 at 22:38, Alexis Wagner wrote:
> First of all, I have read on the web that network labelling is not 
> supported in kernel 2.6 an higher.  I have also read that it will be 
> possible to reimplement the necessary features using the packet filter.
> Is that true ?

The goal is to provide implicit packet labeling based on IPSEC SA,
rather than explicit labeling ala CIPSO.  The old SELinux included a
CIPSO/FIPS188 explicit packet labeling implementation contributed by
James Morris.  Whether or not implicit packet labeling will be
sufficient has been debated; some believe that explicit labels will
still be desired, so that you can use a single IPSEC SA for a range of
labels and so that packet filters can directly interpret the packet
labels.

> Imagine I want to allow the domain one_t to set up and use  a tcp 
> connection with the domain two_t on node two_t.  
> Is it the correct way to set up the policy ?

We won't truly know until we have the packet labeling mechanism and
permission checks implemented.

>         allow one_t node_two_t:node {node_bind tcp_send tcp_recv};

one_t wouldn't be binding to node_two_t's address.

>        #Wich domain I put here ? 
>         allow one_t ???:tcp_socket {acceptfrom recvfrom } ;

With labeled packets, acceptfrom and connectto could be revived as
socket-to-peersocket permission checks, so if one_t were the client
process domain and two_t were the server process domain, then you would
want:
# Let one_t connect to two_t (client-side check).
allow one_t two_t:tcp_socket connectto;
# Let two_t accept a connection from one_t (server-side check).
allow two_t one_t:tcp_socket acceptfrom;

Note the can_tcp_connect() macro in policy/macros/core_macros.te, a
legacy from the days of labeled packets.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2004-08-12 13:51 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-08-11  2:38 network object Alexis Wagner
2004-08-12 13:50 ` Stephen Smalley

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.