From: Daniel J Walsh <dwalsh@redhat.com>
To: Stephen Smalley <sds@epoch.ncsc.mil>,
Russell Coker <rcoker@redhat.com>,
sgrubb@redhat.com, Colin Walters <walters@redhat.com>,
SELinux <SELinux@tycho.nsa.gov>
Subject: Limiting the power of can_network, improving the security of strict policy.
Date: Wed, 27 Oct 2004 11:04:55 -0400 [thread overview]
Message-ID: <417FB917.8030109@redhat.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1306 bytes --]
We have been talking about ways of improving the security of strict
policy. So I have been working
to eliminate tunables and replace them with booleans. So an
administrator can easily turn them off.
(allow_ypbind and use_nfs_home_dirs defaulting to off as an example).
Also I have been working to eliminate the ncsd_ tunables by adding
ncsd_client_domain to all daemons that need it.
Finally we are looking into limiting the power of can_network.
Currently any daemon that has can_network can receive
and establish TCP/UDP connections. The only thing not provided is
name_bind. I want to break this out to eliminate the
ability for daemons also to connect. So an incoming only daemon, can
not establish a connection back out. To do this
I have modified create_socket_perms and eliminated the connect call. I
have added a connect_socket_perms which includes
the create_socket_perms. This has caused many changes to be made in
policy, and I am not sure if it was a good idea?
Also I modified can_network to take a second parameter of the type of
the connection (udp or tcp). This allows you to turn off tcp, connections
on a UDP application. (I am not sure you can do this for a tcp only app
if they are going to use name service.)
Is this a good idea or am I wasting my time?
Dan
[-- Attachment #2: network_macros.te --]
[-- Type: text/plain, Size: 2032 bytes --]
#################################
#
# can_network(domain)
#
# Permissions for accessing the network.
# See types/network.te for the network types.
# See net_contexts for security contexts for network entities.
#
define(`base_can_network',`
#
# Allow the domain to create and use $2 sockets.
# Other kinds of sockets must be separately authorized for use.
allow $1 self:$2_socket create_socket_perms;
#
# 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 };
#
# Allow the domain to send to or receive from any node.
# node_type is a type attribute for all node types.
#
allow $1 node_type:node { $2_send rawip_send };
allow $1 node_type:node { $2_recv rawip_recv };
#
# Allow the domain to send to or receive from any port.
# port_type is a type attribute for all port types.
#
allow $1 $3:{ $2_socket } { send_msg recv_msg };
# XXX Allow binding to any node type. Remove once
# individual rules have been added to all domains that
# bind sockets.
allow $1 node_type: { $2_socket } node_bind;
')dnl end can_network definition
#################################
#
# can_network(domain)
#
# Permissions for accessing the network.
# See types/network.te for the network types.
# See net_contexts for security contexts for network entities.
#
define(`can_network',`
ifelse($2, `', `
base_can_network($1, udp, port_type)
base_can_network($1, tcp, port_type)
allow $1 self:tcp_socket { listen accept };
', `
ifelse($3, `', `
base_can_network($1, $2, $3)
', `
base_can_network($1, $2, port_type)
') dnl ifelse $3
ifelse($2, `tcp', `
allow $1 self:tcp_socket { listen accept };
')
')
#
# Allow the domain to send NFS client requests via the socket
# created by mount.
#
allow $1 mount_t:udp_socket rw_socket_perms;
#
# Allow access to network files including /etc/resolv.conf
#
allow $1 net_conf_t:file r_file_perms;
')dnl end can_network definition
next reply other threads:[~2004-10-27 15:04 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-27 15:04 Daniel J Walsh [this message]
2004-10-27 15:17 ` Limiting the power of can_network, improving the security of strict policy steven harp
2004-10-27 17:27 ` Jayendren Anand Maduray
2004-10-27 20:39 ` Valdis.Kletnieks
2004-10-28 11:07 ` Russell Coker
2004-10-27 15:18 ` Russell Coker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=417FB917.8030109@redhat.com \
--to=dwalsh@redhat.com \
--cc=SELinux@tycho.nsa.gov \
--cc=rcoker@redhat.com \
--cc=sds@epoch.ncsc.mil \
--cc=sgrubb@redhat.com \
--cc=walters@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.