From: dominick.grift@gmail.com (Dominick Grift)
Date: Wed, 05 Sep 2012 00:03:28 +0200
Subject: [refpolicy] [PATCH 6/9] Include policy for the iodine IP over
 DNS tunnel daemon
In-Reply-To: <1346794648-27101-6-git-send-email-bigon@debian.org>
References: <1346794648-27101-1-git-send-email-bigon@debian.org>
	<1346794648-27101-6-git-send-email-bigon@debian.org>
Message-ID: <1346796208.15262.47.camel@d30.localdomain>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

Just a quick review. comments in-line:

On Tue, 2012-09-04 at 23:37 +0200, Laurent Bigonville wrote:
> From: Russell Coker <russell@coker.com.au>
> 
> ---
>  contrib/iodine.fc |    1 +
>  contrib/iodine.if |    1 +
>  contrib/iodine.te |   26 ++++++++++++++++++++++++++
>  3 files changed, 28 insertions(+)
>  create mode 100644 contrib/iodine.fc
>  create mode 100644 contrib/iodine.if
>  create mode 100644 contrib/iodine.te
> 
> diff --git a/contrib/iodine.fc b/contrib/iodine.fc
> new file mode 100644
> index 0000000..4e144ea
> --- /dev/null
> +++ b/contrib/iodine.fc
> @@ -0,0 +1 @@
> +/usr/sbin/iodine.*	-- gen_context(system_u:object_r:iodine_exec_t,s0)
> diff --git a/contrib/iodine.if b/contrib/iodine.if
> new file mode 100644
> index 0000000..3eb6a30
> --- /dev/null
> +++ b/contrib/iodine.if
> @@ -0,0 +1 @@
> +## <summary></summary>
> diff --git a/contrib/iodine.te b/contrib/iodine.te
> new file mode 100644
> index 0000000..96a7de7
> --- /dev/null
> +++ b/contrib/iodine.te
> @@ -0,0 +1,26 @@
> +policy_module(iodine,1.0.0)
> +
> +# policy for the iodine IP over DNS tunneling daemon

the above description should be in the iodine.if between the
<summary></summary> tags

> +type iodine_t;
> +type iodine_exec_t;
> +files_type(iodine_exec_t)

The above line is redundant. it is already included with the line below

> +init_daemon_domain(iodine_t, iodine_exec_t)
> +

The first rules should be the rules wher the target is self, starting
with and rules where the object class is capability then process (if
theres any)

Then use alfa-numeric sorting of "self" rules

below that go rules where the target types are local to the module if
any.

Then the calls to external interface. starting with calls to kernel
layer, kernel interfaces, again

then other kernel layer interfaces in alfa numeric order

then calls to external interfaces in other layers in the following order

so after kernel layer interface calls:

system layer

others

then ifdefs, tunable then optional policy in that order

see:
http://oss.tresys.com/projects/refpolicy/wiki/StyleGuide

You might think why all these style rules? well consistency make policy
writing and maintaining much earier and intuitive. if done correctly
things start to make sense and one can get far by just following
intuition.

If you peruse the existing refpolicy and look for patterns youll see
that everything has a place and reason. if you look long enough things
start to make more sense.

> +logging_send_syslog_msg(iodine_t)

> +kernel_search_network_sysctl(iodine_t)
> +kernel_read_network_state(iodine_t)
> +kernel_request_load_module(iodine_t)
> +kernel_read_system_state(iodine_t)
> +files_read_etc_files(iodine_t)
> +corecmd_exec_shell(iodine_t)
> +allow iodine_t self:capability { setgid setuid net_bind_service net_admin net_raw sys_chroot };
> +sysnet_domtrans_ifconfig(iodine_t)
> +
> +allow iodine_t self:rawip_socket { write read create };
> +allow iodine_t self:unix_dgram_socket { create connect };
> +corenet_raw_receive_generic_node(iodine_t)
> +corenet_rw_tun_tap_dev(iodine_t)
> +corenet_udp_bind_dns_port(iodine_t)
> +corenet_udp_bind_generic_node(iodine_t)
> +allow iodine_t self:udp_socket connected_socket_perms;
> +allow iodine_t self:tun_socket create;