[refpolicy] [PATCH] Initial BIRD Internet Routing Daemon policy

[refpolicy] [PATCH] Initial BIRD Internet Routing Daemon policy

[Dominick Grift]

Signed-off-by: Dominick Grift <dominick.grift@gmail.com>
diff --git a/bird.fc b/bird.fc
new file mode 100644
index 0000000..7b63b8e
--- /dev/null
+++ b/bird.fc
@@ -0,0 +1,11 @@
+/etc/bird\.conf	--	gen_context(system_u:object_r:bird_etc_t,s0)
+
+/etc/default/bird	--	gen_context(system_u:object_r:bird_etc_t,s0)
+
+/etc/rc\.d/init\.d/bird	--	gen_context(system_u:object_r:bird_initrc_exec_t,s0)
+
+/usr/sbin/bird	--	gen_context(system_u:object_r:bird_exec_t,s0)
+
+/var/log/bird\.log.*	--	gen_context(system_u:object_r:bird_log_t,s0)
+
+/var/run/bird\.ctl	-s	gen_context(system_u:object_r:bird_var_run_t,s0)
diff --git a/bird.if b/bird.if
new file mode 100644
index 0000000..fae3f36
--- /dev/null
+++ b/bird.if
@@ -0,0 +1,42 @@
+## <summary>BIRD Internet Routing Daemon.</summary>
+
+########################################
+## <summary>
+##	All of the rules required to administrate
+##	an bird environment.
+## </summary>
+## <param name="domain">
+##	<summary>
+##	Domain allowed access.
+##	</summary>
+## </param>
+## <param name="role">
+##	<summary>
+##	Role allowed access..
+##	</summary>
+## </param>
+## <rolecap/>
+#
+interface(`bird_admin',`
+	gen_require(`
+		type bird_t, bird_etc_t, bird_log_t;
+		type bird_var_run_t, bird_initrc_exec_t;
+	')
+
+	allow $1 bird_t:process { ptrace signal_perms };
+	ps_process_pattern($1, bird_t)
+
+	init_labeled_script_domtrans($1, bird_initrc_exec_t)
+	domain_system_change_exemption($1)
+	role_transition $2 bird_initrc_exec_t system_r;
+	allow $2 system_r;
+
+	files_list_etc($1)
+	admin_pattern($1, bird_etc_t)
+
+	logging_list_logs($1)
+	admin_pattern($1, bird_log_t)
+
+	files_list_pids($1)
+	admin_pattern($1, bird_var_run_t)
+')
diff --git a/bird.te b/bird.te
new file mode 100644
index 0000000..9afd52b
--- /dev/null
+++ b/bird.te
@@ -0,0 +1,57 @@
+policy_module(bird, 1.0.0)
+
+########################################
+#
+# Declarations
+#
+
+type bird_t;
+type bird_exec_t;
+init_daemon_domain(bird_t, bird_exec_t)
+
+type bird_initrc_exec_t;
+init_script_file(bird_initrc_exec_t)
+
+type bird_etc_t;
+files_config_file(bird_etc_t)
+
+type bird_log_t;
+logging_log_file(bird_log_t)
+
+type bird_var_run_t;
+files_pid_file(bird_var_run_t)
+
+########################################
+#
+# Local policy
+#
+
+allow bird_t self:capability { net_admin net_bind_service };
+allow bird_t self:netlink_route_socket create_netlink_socket_perms;
+allow bird_t self:tcp_socket create_stream_socket_perms;
+
+allow bird_t bird_etc_t:file read_file_perms;
+
+allow bird_t bird_log_t:file { create_file_perms append_file_perms setattr_file_perms };
+logging_log_filetrans(bird_t, bird_log_t, file)
+
+allow bird_t bird_var_run_t:sock_file manage_sock_file_perms;
+files_pid_filetrans(bird_t, bird_var_run_t, sock_file)
+
+corenet_all_recvfrom_unlabeled(bird_t)
+corenet_all_recvfrom_netlabel(bird_t)
+corenet_tcp_sendrecv_generic_if(bird_t)
+corenet_tcp_bind_generic_node(bird_t)
+corenet_tcp_sendrecv_generic_node(bird_t)
+corenet_tcp_sendrecv_bgp_port(bird_t)
+corenet_sendrecv_bgp_client_packets(bird_t)
+corenet_tcp_connect_bgp_port(bird_t)
+corenet_sendrecv_bgp_server_packets(bird_t)
+corenet_tcp_bind_bgp_port(bird_t)
+
+# /etc/iproute2/rt_realms
+files_read_etc_files(bird_t)
+
+logging_send_syslog_msg(bird_t)
+
+miscfiles_read_localization(bird_t)

[refpolicy] [PATCH] Initial BIRD Internet Routing Daemon policy

[Guido Trentalancia]

Hello Dominick.

A very quick and possibly incomplete review, if it helps...

On 08/08/2012 10:52, Dominick Grift wrote:
>
> Signed-off-by: Dominick Grift <dominick.grift@gmail.com>
> diff --git a/bird.fc b/bird.fc
> new file mode 100644
> index 0000000..7b63b8e
> --- /dev/null
> +++ b/bird.fc
> @@ -0,0 +1,11 @@
> +/etc/bird\.conf	--	gen_context(system_u:object_r:bird_etc_t,s0)
> +
> +/etc/default/bird	--	gen_context(system_u:object_r:bird_etc_t,s0)
> +
> +/etc/rc\.d/init\.d/bird	--	gen_context(system_u:object_r:bird_initrc_exec_t,s0)

You might want to support init script locations for other distributions 
here, as in the oident module that you proposed to modify yesterday (I 
am going to modify the mcelog too for this purpose).

Debian (but also Gentoo and many others) are currently using /etc/init\.d.

The rest is unlikely to change, if it does, it's their business to 
modify the contexts, I think.

> +/usr/sbin/bird	--	gen_context(system_u:object_r:bird_exec_t,s0)
> +
> +/var/log/bird\.log.*	--	gen_context(system_u:object_r:bird_log_t,s0)
> +
> +/var/run/bird\.ctl	-s	gen_context(system_u:object_r:bird_var_run_t,s0)
> diff --git a/bird.if b/bird.if
> new file mode 100644
> index 0000000..fae3f36
> --- /dev/null
> +++ b/bird.if
> @@ -0,0 +1,42 @@
> +## <summary>BIRD Internet Routing Daemon.</summary>
> +
> +########################################
> +## <summary>
> +##	All of the rules required to administrate
> +##	an bird environment.

I think "Rules to administrate a BIRD environment" would read a bit 
better, but clearly it's not critical.

> +## </summary>
> +## <param name="domain">
> +##	<summary>
> +##	Domain allowed access.
> +##	</summary>
> +## </param>
> +## <param name="role">
> +##	<summary>
> +##	Role allowed access..
> +##	</summary>
> +## </param>
> +## <rolecap/>
> +#
> +interface(`bird_admin',`
> +	gen_require(`
> +		type bird_t, bird_etc_t, bird_log_t;
> +		type bird_var_run_t, bird_initrc_exec_t;
> +	')
> +
> +	allow $1 bird_t:process { ptrace signal_perms };
> +	ps_process_pattern($1, bird_t)
> +
> +	init_labeled_script_domtrans($1, bird_initrc_exec_t)
> +	domain_system_change_exemption($1)
> +	role_transition $2 bird_initrc_exec_t system_r;
> +	allow $2 system_r;
> +
> +	files_list_etc($1)
> +	admin_pattern($1, bird_etc_t)
> +
> +	logging_list_logs($1)
> +	admin_pattern($1, bird_log_t)
> +
> +	files_list_pids($1)
> +	admin_pattern($1, bird_var_run_t)
> +')

Not checked (see below).

> diff --git a/bird.te b/bird.te
> new file mode 100644
> index 0000000..9afd52b
> --- /dev/null
> +++ b/bird.te
> @@ -0,0 +1,57 @@
> +policy_module(bird, 1.0.0)
> +
> +########################################
> +#
> +# Declarations
> +#
> +
> +type bird_t;
> +type bird_exec_t;
> +init_daemon_domain(bird_t, bird_exec_t)
> +
> +type bird_initrc_exec_t;
> +init_script_file(bird_initrc_exec_t)
> +
> +type bird_etc_t;
> +files_config_file(bird_etc_t)
> +
> +type bird_log_t;
> +logging_log_file(bird_log_t)
> +
> +type bird_var_run_t;
> +files_pid_file(bird_var_run_t)
> +
> +########################################
> +#
> +# Local policy
> +#
> +
> +allow bird_t self:capability { net_admin net_bind_service };
> +allow bird_t self:netlink_route_socket create_netlink_socket_perms;
> +allow bird_t self:tcp_socket create_stream_socket_perms;
> +
> +allow bird_t bird_etc_t:file read_file_perms;

Use of patterns for reading, writing or managing standard files is more 
common throughout the whole reference policy. It's not critical but 
think about it, it might improve readability and coherence across the 
work as a whole...

> +allow bird_t bird_log_t:file { create_file_perms append_file_perms setattr_file_perms };

I think create+append+setattr grants more permissions than the 
manage_file_perms (or preferably corrispondent pattern), however I have 
not checked.

See above for using patterns versus individual or grouped permissions.

> +logging_log_filetrans(bird_t, bird_log_t, file)
> +
> +allow bird_t bird_var_run_t:sock_file manage_sock_file_perms;

See above for using patterns versus individual or grouped permissions.

> +files_pid_filetrans(bird_t, bird_var_run_t, sock_file)
> +
> +corenet_all_recvfrom_unlabeled(bird_t)

Unlabelled receive could probably made tunable as not everybody might 
like that.

> +corenet_all_recvfrom_netlabel(bird_t)
> +corenet_tcp_sendrecv_generic_if(bird_t)
> +corenet_tcp_bind_generic_node(bird_t)
> +corenet_tcp_sendrecv_generic_node(bird_t)
> +corenet_tcp_sendrecv_bgp_port(bird_t)
> +corenet_sendrecv_bgp_client_packets(bird_t)
> +corenet_tcp_connect_bgp_port(bird_t)
> +corenet_sendrecv_bgp_server_packets(bird_t)
> +corenet_tcp_bind_bgp_port(bird_t)
> +
> +# /etc/iproute2/rt_realms
> +files_read_etc_files(bird_t)
> +
> +logging_send_syslog_msg(bird_t)
> +
> +miscfiles_read_localization(bird_t)

You have not used the bird_admin() interface, since it's not a simple 
and generic interface (such as for managing files), you should really 
remove it in my opinion.

The most important reason is that permissions needed by BIRD might 
change with subsequent releases of the daemon by the time somebody will 
actually use the bird_admin() interface: if they shrink, it's a security 
matter (interface is loose) and you don't be doing much of a favour to 
anyone.

Regards,

Guido

[refpolicy] [PATCH] Initial BIRD Internet Routing Daemon policy

[Dominick Grift]

On Wed, 2012-08-08 at 12:49 +0200, Guido Trentalancia wrote:
> Hello Dominick.
> 
> A very quick and possibly incomplete review, if it helps...
> 
> On 08/08/2012 10:52, Dominick Grift wrote:
> >
> > Signed-off-by: Dominick Grift <dominick.grift@gmail.com>
> > diff --git a/bird.fc b/bird.fc
> > new file mode 100644
> > index 0000000..7b63b8e
> > --- /dev/null
> > +++ b/bird.fc
> > @@ -0,0 +1,11 @@
> > +/etc/bird\.conf	--	gen_context(system_u:object_r:bird_etc_t,s0)
> > +
> > +/etc/default/bird	--	gen_context(system_u:object_r:bird_etc_t,s0)
> > +
> > +/etc/rc\.d/init\.d/bird	--	gen_context(system_u:object_r:bird_initrc_exec_t,s0)
> 
> You might want to support init script locations for other distributions 
> here, as in the oident module that you proposed to modify yesterday (I 
> am going to modify the mcelog too for this purpose).
> 
> Debian (but also Gentoo and many others) are currently using /etc/init\.d.
> 
> The rest is unlikely to change, if it does, it's their business to 
> modify the contexts, I think.


You have a good point and i have been thinking abou this issue
obviously. I decided to go this way because existing init daemons also
only have the /etc/rc.d/init.d and not the /etc/init.d.

Maybe a better solution is to just add:

/etc/init.d /etc/rc.d/init.d

to file_contexts.subs_dist

> > +/usr/sbin/bird	--	gen_context(system_u:object_r:bird_exec_t,s0)
> > +
> > +/var/log/bird\.log.*	--	gen_context(system_u:object_r:bird_log_t,s0)
> > +
> > +/var/run/bird\.ctl	-s	gen_context(system_u:object_r:bird_var_run_t,s0)
> > diff --git a/bird.if b/bird.if
> > new file mode 100644
> > index 0000000..fae3f36
> > --- /dev/null
> > +++ b/bird.if
> > @@ -0,0 +1,42 @@
> > +## <summary>BIRD Internet Routing Daemon.</summary>
> > +
> > +########################################
> > +## <summary>
> > +##	All of the rules required to administrate
> > +##	an bird environment.
> 
> I think "Rules to administrate a BIRD environment" would read a bit 
> better, but clearly it's not critical.

good point. However for the sake of uniformity ill just keep it like
this. (this is the common summary for this interface)

> > +## </summary>
> > +## <param name="domain">
> > +##	<summary>
> > +##	Domain allowed access.
> > +##	</summary>
> > +## </param>
> > +## <param name="role">
> > +##	<summary>
> > +##	Role allowed access..
> > +##	</summary>
> > +## </param>
> > +## <rolecap/>
> > +#
> > +interface(`bird_admin',`
> > +	gen_require(`
> > +		type bird_t, bird_etc_t, bird_log_t;
> > +		type bird_var_run_t, bird_initrc_exec_t;
> > +	')
> > +
> > +	allow $1 bird_t:process { ptrace signal_perms };
> > +	ps_process_pattern($1, bird_t)
> > +
> > +	init_labeled_script_domtrans($1, bird_initrc_exec_t)
> > +	domain_system_change_exemption($1)
> > +	role_transition $2 bird_initrc_exec_t system_r;
> > +	allow $2 system_r;
> > +
> > +	files_list_etc($1)
> > +	admin_pattern($1, bird_etc_t)
> > +
> > +	logging_list_logs($1)
> > +	admin_pattern($1, bird_log_t)
> > +
> > +	files_list_pids($1)
> > +	admin_pattern($1, bird_var_run_t)
> > +')
> 
> Not checked (see below).
> 
> > diff --git a/bird.te b/bird.te
> > new file mode 100644
> > index 0000000..9afd52b
> > --- /dev/null
> > +++ b/bird.te
> > @@ -0,0 +1,57 @@
> > +policy_module(bird, 1.0.0)
> > +
> > +########################################
> > +#
> > +# Declarations
> > +#
> > +
> > +type bird_t;
> > +type bird_exec_t;
> > +init_daemon_domain(bird_t, bird_exec_t)
> > +
> > +type bird_initrc_exec_t;
> > +init_script_file(bird_initrc_exec_t)
> > +
> > +type bird_etc_t;
> > +files_config_file(bird_etc_t)
> > +
> > +type bird_log_t;
> > +logging_log_file(bird_log_t)
> > +
> > +type bird_var_run_t;
> > +files_pid_file(bird_var_run_t)
> > +
> > +########################################
> > +#
> > +# Local policy
> > +#
> > +
> > +allow bird_t self:capability { net_admin net_bind_service };
> > +allow bird_t self:netlink_route_socket create_netlink_socket_perms;
> > +allow bird_t self:tcp_socket create_stream_socket_perms;
> > +
> > +allow bird_t bird_etc_t:file read_file_perms;
> 
> Use of patterns for reading, writing or managing standard files is more 
> common throughout the whole reference policy. It's not critical but 
> think about it, it might improve readability and coherence across the 
> work as a whole...

This is better in my view. The patterns provide permissions that are not
needed here. i.e. read_files_pattern(bird_t, bird_etc_t , bird_etc_t)
allow bird_t to search bird_etc_t dirs but there aren't any.

> > +allow bird_t bird_log_t:file { create_file_perms append_file_perms setattr_file_perms };
> 
> I think create+append+setattr grants more permissions than the 
> manage_file_perms (or preferably corrispondent pattern), however I have 
> not checked.
> 

No, This combination make it possible to not allow bird_T to "write"
bird_log_t files which is a real benefit over manage_file_perms.

> See above for using patterns versus individual or grouped permissions.
> 
> > +logging_log_filetrans(bird_t, bird_log_t, file)
> > +
> > +allow bird_t bird_var_run_t:sock_file manage_sock_file_perms;
> 
> See above for using patterns versus individual or grouped permissions.
> 
> > +files_pid_filetrans(bird_t, bird_var_run_t, sock_file)
> > +
> > +corenet_all_recvfrom_unlabeled(bird_t)
> 
> Unlabelled receive could probably made tunable as not everybody might 
> like that.

unlabeled is a default in systems. The boolean would be have to be on by
default. On other systems this rules would harm since the packets would
be labeled.

and for the sake of uniformity i will leave it like this (other existing
modules also dont have this conditional)

> > +corenet_all_recvfrom_netlabel(bird_t)
> > +corenet_tcp_sendrecv_generic_if(bird_t)
> > +corenet_tcp_bind_generic_node(bird_t)
> > +corenet_tcp_sendrecv_generic_node(bird_t)
> > +corenet_tcp_sendrecv_bgp_port(bird_t)
> > +corenet_sendrecv_bgp_client_packets(bird_t)
> > +corenet_tcp_connect_bgp_port(bird_t)
> > +corenet_sendrecv_bgp_server_packets(bird_t)
> > +corenet_tcp_bind_bgp_port(bird_t)
> > +
> > +# /etc/iproute2/rt_realms
> > +files_read_etc_files(bird_t)
> > +
> > +logging_send_syslog_msg(bird_t)
> > +
> > +miscfiles_read_localization(bird_t)
> 
> You have not used the bird_admin() interface, since it's not a simple 
> and generic interface (such as for managing files), you should really 
> remove it in my opinion.

True and in general it is a good argument to not create unused
interfaces. However this is a exception to that rules. We want end-users
to be able to easily create a birdadm_r role. This interface facilitates
that. If we would create a role for each init daemon by default we would
end up with too many roles.

So the middle road is to not create the role by default but to provide
the interface so that endusers can easily create it if they so desire.

> The most important reason is that permissions needed by BIRD might 
> change with subsequent releases of the daemon by the time somebody will 
> actually use the bird_admin() interface: if they shrink, it's a security 
> matter (interface is loose) and you don't be doing much of a favour to 
> anyone.

This argument is not valid in light of my comment above.

> Regards,
> 
> Guido

[refpolicy] [PATCH] Initial BIRD Internet Routing Daemon policy

[Dominick Grift]

On Wed, 2012-08-08 at 13:42 +0200, Dominick Grift wrote:
> 
> On Wed, 2012-08-08 at 12:49 +0200, Guido Trentalancia wrote:
> > Hello Dominick.
> > 
> > A very quick and possibly incomplete review, if it helps...
> > 
> > On 08/08/2012 10:52, Dominick Grift wrote:
> > >
> > > Signed-off-by: Dominick Grift <dominick.grift@gmail.com>
> > > diff --git a/bird.fc b/bird.fc
> > > new file mode 100644
> > > index 0000000..7b63b8e
> > > --- /dev/null
> > > +++ b/bird.fc
> > > @@ -0,0 +1,11 @@
> > > +/etc/bird\.conf	--	gen_context(system_u:object_r:bird_etc_t,s0)
> > > +
> > > +/etc/default/bird	--	gen_context(system_u:object_r:bird_etc_t,s0)
> > > +
> > > +/etc/rc\.d/init\.d/bird	--	gen_context(system_u:object_r:bird_initrc_exec_t,s0)
> > 
> > You might want to support init script locations for other distributions 
> > here, as in the oident module that you proposed to modify yesterday (I 
> > am going to modify the mcelog too for this purpose).
> > 
> > Debian (but also Gentoo and many others) are currently using /etc/init\.d.
> > 
> > The rest is unlikely to change, if it does, it's their business to 
> > modify the contexts, I think.
> 
> 
> You have a good point and i have been thinking abou this issue
> obviously. I decided to go this way because existing init daemons also
> only have the /etc/rc.d/init.d and not the /etc/init.d.
> 
> Maybe a better solution is to just add:
> 
> /etc/init.d /etc/rc.d/init.d
> 
> to file_contexts.subs_dist
> 
> > > +/usr/sbin/bird	--	gen_context(system_u:object_r:bird_exec_t,s0)
> > > +
> > > +/var/log/bird\.log.*	--	gen_context(system_u:object_r:bird_log_t,s0)
> > > +
> > > +/var/run/bird\.ctl	-s	gen_context(system_u:object_r:bird_var_run_t,s0)
> > > diff --git a/bird.if b/bird.if
> > > new file mode 100644
> > > index 0000000..fae3f36
> > > --- /dev/null
> > > +++ b/bird.if
> > > @@ -0,0 +1,42 @@
> > > +## <summary>BIRD Internet Routing Daemon.</summary>
> > > +
> > > +########################################
> > > +## <summary>
> > > +##	All of the rules required to administrate
> > > +##	an bird environment.
> > 
> > I think "Rules to administrate a BIRD environment" would read a bit 
> > better, but clearly it's not critical.
> 
> good point. However for the sake of uniformity ill just keep it like
> this. (this is the common summary for this interface)

s/uniformity/consistency

> > > +## </summary>
> > > +## <param name="domain">
> > > +##	<summary>
> > > +##	Domain allowed access.
> > > +##	</summary>
> > > +## </param>
> > > +## <param name="role">
> > > +##	<summary>
> > > +##	Role allowed access..
> > > +##	</summary>
> > > +## </param>
> > > +## <rolecap/>
> > > +#
> > > +interface(`bird_admin',`
> > > +	gen_require(`
> > > +		type bird_t, bird_etc_t, bird_log_t;
> > > +		type bird_var_run_t, bird_initrc_exec_t;
> > > +	')
> > > +
> > > +	allow $1 bird_t:process { ptrace signal_perms };
> > > +	ps_process_pattern($1, bird_t)
> > > +
> > > +	init_labeled_script_domtrans($1, bird_initrc_exec_t)
> > > +	domain_system_change_exemption($1)
> > > +	role_transition $2 bird_initrc_exec_t system_r;
> > > +	allow $2 system_r;
> > > +
> > > +	files_list_etc($1)
> > > +	admin_pattern($1, bird_etc_t)
> > > +
> > > +	logging_list_logs($1)
> > > +	admin_pattern($1, bird_log_t)
> > > +
> > > +	files_list_pids($1)
> > > +	admin_pattern($1, bird_var_run_t)
> > > +')
> > 
> > Not checked (see below).
> > 
> > > diff --git a/bird.te b/bird.te
> > > new file mode 100644
> > > index 0000000..9afd52b
> > > --- /dev/null
> > > +++ b/bird.te
> > > @@ -0,0 +1,57 @@
> > > +policy_module(bird, 1.0.0)
> > > +
> > > +########################################
> > > +#
> > > +# Declarations
> > > +#
> > > +
> > > +type bird_t;
> > > +type bird_exec_t;
> > > +init_daemon_domain(bird_t, bird_exec_t)
> > > +
> > > +type bird_initrc_exec_t;
> > > +init_script_file(bird_initrc_exec_t)
> > > +
> > > +type bird_etc_t;
> > > +files_config_file(bird_etc_t)
> > > +
> > > +type bird_log_t;
> > > +logging_log_file(bird_log_t)
> > > +
> > > +type bird_var_run_t;
> > > +files_pid_file(bird_var_run_t)
> > > +
> > > +########################################
> > > +#
> > > +# Local policy
> > > +#
> > > +
> > > +allow bird_t self:capability { net_admin net_bind_service };
> > > +allow bird_t self:netlink_route_socket create_netlink_socket_perms;
> > > +allow bird_t self:tcp_socket create_stream_socket_perms;
> > > +
> > > +allow bird_t bird_etc_t:file read_file_perms;
> > 
> > Use of patterns for reading, writing or managing standard files is more 
> > common throughout the whole reference policy. It's not critical but 
> > think about it, it might improve readability and coherence across the 
> > work as a whole...
> 
> This is better in my view. The patterns provide permissions that are not
> needed here. i.e. read_files_pattern(bird_t, bird_etc_t , bird_etc_t)
> allow bird_t to search bird_etc_t dirs but there aren't any.
> 
> > > +allow bird_t bird_log_t:file { create_file_perms append_file_perms setattr_file_perms };
> > 
> > I think create+append+setattr grants more permissions than the 
> > manage_file_perms (or preferably corrispondent pattern), however I have 
> > not checked.
> > 
> 
> No, This combination make it possible to not allow bird_T to "write"
> bird_log_t files which is a real benefit over manage_file_perms.
> 
> > See above for using patterns versus individual or grouped permissions.
> > 
> > > +logging_log_filetrans(bird_t, bird_log_t, file)
> > > +
> > > +allow bird_t bird_var_run_t:sock_file manage_sock_file_perms;
> > 
> > See above for using patterns versus individual or grouped permissions.
> > 
> > > +files_pid_filetrans(bird_t, bird_var_run_t, sock_file)
> > > +
> > > +corenet_all_recvfrom_unlabeled(bird_t)
> > 
> > Unlabelled receive could probably made tunable as not everybody might 
> > like that.
> 
> unlabeled is a default in systems. The boolean would be have to be on by
> default. On other systems this rules would harm since the packets would
> be labeled.


would *not* harm

> and for the sake of uniformity i will leave it like this (other existing
> modules also dont have this conditional)


s/uniformity/consistency

> > > +corenet_all_recvfrom_netlabel(bird_t)
> > > +corenet_tcp_sendrecv_generic_if(bird_t)
> > > +corenet_tcp_bind_generic_node(bird_t)
> > > +corenet_tcp_sendrecv_generic_node(bird_t)
> > > +corenet_tcp_sendrecv_bgp_port(bird_t)
> > > +corenet_sendrecv_bgp_client_packets(bird_t)
> > > +corenet_tcp_connect_bgp_port(bird_t)
> > > +corenet_sendrecv_bgp_server_packets(bird_t)
> > > +corenet_tcp_bind_bgp_port(bird_t)
> > > +
> > > +# /etc/iproute2/rt_realms
> > > +files_read_etc_files(bird_t)
> > > +
> > > +logging_send_syslog_msg(bird_t)
> > > +
> > > +miscfiles_read_localization(bird_t)
> > 
> > You have not used the bird_admin() interface, since it's not a simple 
> > and generic interface (such as for managing files), you should really 
> > remove it in my opinion.
> 
> True and in general it is a good argument to not create unused
> interfaces. However this is a exception to that rules. We want end-users
> to be able to easily create a birdadm_r role. This interface facilitates
> that. If we would create a role for each init daemon by default we would
> end up with too many roles.
> 
> So the middle road is to not create the role by default but to provide
> the interface so that endusers can easily create it if they so desire.
> 
> > The most important reason is that permissions needed by BIRD might 
> > change with subsequent releases of the daemon by the time somebody will 
> > actually use the bird_admin() interface: if they shrink, it's a security 
> > matter (interface is loose) and you don't be doing much of a favour to 
> > anyone.
> 
> This argument is not valid in light of my comment above.
> 
> > Regards,
> > 
> > Guido
> 
> 

[refpolicy] [PATCH] Initial BIRD Internet Routing Daemon policy

[Christopher J. PeBenito]

On 08/08/12 07:42, Dominick Grift wrote:
> On Wed, 2012-08-08 at 12:49 +0200, Guido Trentalancia wrote:
>> On 08/08/2012 10:52, Dominick Grift wrote:

>>> --- /dev/null
>>> +++ b/bird.fc
>>> @@ -0,0 +1,11 @@
>>> +/etc/bird\.conf	--	gen_context(system_u:object_r:bird_etc_t,s0)
>>> +
>>> +/etc/default/bird	--	gen_context(system_u:object_r:bird_etc_t,s0)
>>> +
>>> +/etc/rc\.d/init\.d/bird	--	gen_context(system_u:object_r:bird_initrc_exec_t,s0)
>>
>> You might want to support init script locations for other distributions 
>> here, as in the oident module that you proposed to modify yesterday (I 
>> am going to modify the mcelog too for this purpose).
>>
>> Debian (but also Gentoo and many others) are currently using /etc/init\.d.
>>
>> The rest is unlikely to change, if it does, it's their business to 
>> modify the contexts, I think.
> 
> You have a good point and i have been thinking abou this issue
> obviously. I decided to go this way because existing init daemons also
> only have the /etc/rc.d/init.d and not the /etc/init.d.
> 
> Maybe a better solution is to just add:
> 
> /etc/init.d /etc/rc.d/init.d
> 
> to file_contexts.subs_dist

Its not a bad idea.  I'd take a patch that cleaned this up across the entire policy.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

[refpolicy] [PATCH] Initial BIRD Internet Routing Daemon policy

[Dominick Grift]

On Wed, 2012-08-08 at 09:17 -0400, Christopher J. PeBenito wrote:
> On 08/08/12 07:42, Dominick Grift wrote:
> > On Wed, 2012-08-08 at 12:49 +0200, Guido Trentalancia wrote:
> >> On 08/08/2012 10:52, Dominick Grift wrote:
> 
> >>> --- /dev/null
> >>> +++ b/bird.fc
> >>> @@ -0,0 +1,11 @@
> >>> +/etc/bird\.conf	--	gen_context(system_u:object_r:bird_etc_t,s0)
> >>> +
> >>> +/etc/default/bird	--	gen_context(system_u:object_r:bird_etc_t,s0)
> >>> +
> >>> +/etc/rc\.d/init\.d/bird	--	gen_context(system_u:object_r:bird_initrc_exec_t,s0)
> >>
> >> You might want to support init script locations for other distributions 
> >> here, as in the oident module that you proposed to modify yesterday (I 
> >> am going to modify the mcelog too for this purpose).
> >>
> >> Debian (but also Gentoo and many others) are currently using /etc/init\.d.
> >>
> >> The rest is unlikely to change, if it does, it's their business to 
> >> modify the contexts, I think.
> > 
> > You have a good point and i have been thinking abou this issue
> > obviously. I decided to go this way because existing init daemons also
> > only have the /etc/rc.d/init.d and not the /etc/init.d.
> > 
> > Maybe a better solution is to just add:
> > 
> > /etc/init.d /etc/rc.d/init.d
> > 
> > to file_contexts.subs_dist
> 
> Its not a bad idea.  I'd take a patch that cleaned this up across the entire policy.
> 

Should be as easy as appending /etc/init.d /etc/rc.d/init.d to
config/file_contexts.subs_dist

However i am not sure if we should escape the periods

[refpolicy] [PATCH] Initial BIRD Internet Routing Daemon policy

[Guido Trentalancia]

On 08/08/2012 16:23, Dominick Grift wrote:
>
>
> On Wed, 2012-08-08 at 09:17 -0400, Christopher J. PeBenito wrote:
>> On 08/08/12 07:42, Dominick Grift wrote:
>>> On Wed, 2012-08-08 at 12:49 +0200, Guido Trentalancia wrote:
>>>> On 08/08/2012 10:52, Dominick Grift wrote:
>>
>>>>> --- /dev/null
>>>>> +++ b/bird.fc
>>>>> @@ -0,0 +1,11 @@
>>>>> +/etc/bird\.conf	--	gen_context(system_u:object_r:bird_etc_t,s0)
>>>>> +
>>>>> +/etc/default/bird	--	gen_context(system_u:object_r:bird_etc_t,s0)
>>>>> +
>>>>> +/etc/rc\.d/init\.d/bird	--	gen_context(system_u:object_r:bird_initrc_exec_t,s0)
>>>>
>>>> You might want to support init script locations for other distributions
>>>> here, as in the oident module that you proposed to modify yesterday (I
>>>> am going to modify the mcelog too for this purpose).
>>>>
>>>> Debian (but also Gentoo and many others) are currently using /etc/init\.d.
>>>>
>>>> The rest is unlikely to change, if it does, it's their business to
>>>> modify the contexts, I think.
>>>
>>> You have a good point and i have been thinking abou this issue
>>> obviously. I decided to go this way because existing init daemons also
>>> only have the /etc/rc.d/init.d and not the /etc/init.d.
>>>
>>> Maybe a better solution is to just add:
>>>
>>> /etc/init.d /etc/rc.d/init.d
>>>
>>> to file_contexts.subs_dist
>>
>> Its not a bad idea.  I'd take a patch that cleaned this up across the entire policy.
>>
>
> Should be as easy as appending /etc/init.d /etc/rc.d/init.d to
> config/file_contexts.subs_dist
>
> However i am not sure if we should escape the periods

It's probably safer to escape the periods anyway.

But the point with using this, is that it would probably be a mutually 
exclusive substitution.

Therefore we might need ifdef distro conditionals (which makes the whole 
thing more robust anyway). Done in one central place should not 
constitute over-engineering, I suppose.

Regards,

Guido

[refpolicy] [PATCH] Initial BIRD Internet Routing Daemon policy

[Guido Trentalancia]

On 08/08/2012 17:01, Guido Trentalancia wrote:
> On 08/08/2012 16:23, Dominick Grift wrote:
>>
>>
>> On Wed, 2012-08-08 at 09:17 -0400, Christopher J. PeBenito wrote:
>>> On 08/08/12 07:42, Dominick Grift wrote:
>>>> On Wed, 2012-08-08 at 12:49 +0200, Guido Trentalancia wrote:
>>>>> On 08/08/2012 10:52, Dominick Grift wrote:
>>>
>>>>>> --- /dev/null
>>>>>> +++ b/bird.fc
>>>>>> @@ -0,0 +1,11 @@
>>>>>> +/etc/bird\.conf	--	gen_context(system_u:object_r:bird_etc_t,s0)
>>>>>> +
>>>>>> +/etc/default/bird	--	gen_context(system_u:object_r:bird_etc_t,s0)
>>>>>> +
>>>>>> +/etc/rc\.d/init\.d/bird	--	gen_context(system_u:object_r:bird_initrc_exec_t,s0)
>>>>>
>>>>> You might want to support init script locations for other distributions
>>>>> here, as in the oident module that you proposed to modify yesterday (I
>>>>> am going to modify the mcelog too for this purpose).
>>>>>
>>>>> Debian (but also Gentoo and many others) are currently using /etc/init\.d.
>>>>>
>>>>> The rest is unlikely to change, if it does, it's their business to
>>>>> modify the contexts, I think.
>>>>
>>>> You have a good point and i have been thinking abou this issue
>>>> obviously. I decided to go this way because existing init daemons also
>>>> only have the /etc/rc.d/init.d and not the /etc/init.d.
>>>>
>>>> Maybe a better solution is to just add:
>>>>
>>>> /etc/init.d /etc/rc.d/init.d
>>>>
>>>> to file_contexts.subs_dist
>>>
>>> Its not a bad idea.  I'd take a patch that cleaned this up across the entire policy.
>>>
>>
>> Should be as easy as appending /etc/init.d /etc/rc.d/init.d to
>> config/file_contexts.subs_dist
>>
>> However i am not sure if we should escape the periods
>
> It's probably safer to escape the periods anyway.
>
> But the point with using this, is that it would probably be a mutually
> exclusive substitution.
>
> Therefore we might need ifdef distro conditionals (which makes the whole
> thing more robust anyway). Done in one central place should not
> constitute over-engineering, I suppose.

I have checked and file_contexts.subs_dist is a run-time configuration 
file and not a build-time configuration file. Therefore it's does not 
support conditionals such as ifdef distro, but just the simplest form of 
substitutions.

> Regards,
>
> Guido

[refpolicy] [PATCH] Initial BIRD Internet Routing Daemon policy

[Dominick Grift]

On Thu, 2012-08-09 at 11:11 +0200, Guido Trentalancia wrote:
> On 08/08/2012 17:01, Guido Trentalancia wrote:
> > On 08/08/2012 16:23, Dominick Grift wrote:
> >>
> >>
> >> On Wed, 2012-08-08 at 09:17 -0400, Christopher J. PeBenito wrote:
> >>> On 08/08/12 07:42, Dominick Grift wrote:
> >>>> On Wed, 2012-08-08 at 12:49 +0200, Guido Trentalancia wrote:
> >>>>> On 08/08/2012 10:52, Dominick Grift wrote:
> >>>
> >>>>>> --- /dev/null
> >>>>>> +++ b/bird.fc
> >>>>>> @@ -0,0 +1,11 @@
> >>>>>> +/etc/bird\.conf	--	gen_context(system_u:object_r:bird_etc_t,s0)
> >>>>>> +
> >>>>>> +/etc/default/bird	--	gen_context(system_u:object_r:bird_etc_t,s0)
> >>>>>> +
> >>>>>> +/etc/rc\.d/init\.d/bird	--	gen_context(system_u:object_r:bird_initrc_exec_t,s0)
> >>>>>
> >>>>> You might want to support init script locations for other distributions
> >>>>> here, as in the oident module that you proposed to modify yesterday (I
> >>>>> am going to modify the mcelog too for this purpose).
> >>>>>
> >>>>> Debian (but also Gentoo and many others) are currently using /etc/init\.d.
> >>>>>
> >>>>> The rest is unlikely to change, if it does, it's their business to
> >>>>> modify the contexts, I think.
> >>>>
> >>>> You have a good point and i have been thinking abou this issue
> >>>> obviously. I decided to go this way because existing init daemons also
> >>>> only have the /etc/rc.d/init.d and not the /etc/init.d.
> >>>>
> >>>> Maybe a better solution is to just add:
> >>>>
> >>>> /etc/init.d /etc/rc.d/init.d
> >>>>
> >>>> to file_contexts.subs_dist
> >>>
> >>> Its not a bad idea.  I'd take a patch that cleaned this up across the entire policy.
> >>>
> >>
> >> Should be as easy as appending /etc/init.d /etc/rc.d/init.d to
> >> config/file_contexts.subs_dist
> >>
> >> However i am not sure if we should escape the periods
> >
> > It's probably safer to escape the periods anyway.
> >
> > But the point with using this, is that it would probably be a mutually
> > exclusive substitution.
> >
> > Therefore we might need ifdef distro conditionals (which makes the whole
> > thing more robust anyway). Done in one central place should not
> > constitute over-engineering, I suppose.
> 
> I have checked and file_contexts.subs_dist is a run-time configuration 
> file and not a build-time configuration file. Therefore it's does not 
> support conditionals such as ifdef distro, but just the simplest form of 
> substitutions.

I do not think it matters because the paths aren't mutually exclusive i
believe.

The name substitution (subs) is misleading i believe, its not actually
substitution but rather equivalence.

> > Regards,
> >
> > Guido
> 
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy

[refpolicy] [PATCH] Initial BIRD Internet Routing Daemon policy

[Guido Trentalancia]

On 09/08/2012 11:59, Dominick Grift wrote:
>
>
> On Thu, 2012-08-09 at 11:11 +0200, Guido Trentalancia wrote:
>> On 08/08/2012 17:01, Guido Trentalancia wrote:
>>> On 08/08/2012 16:23, Dominick Grift wrote:
>>>>
>>>>
>>>> On Wed, 2012-08-08 at 09:17 -0400, Christopher J. PeBenito wrote:
>>>>> On 08/08/12 07:42, Dominick Grift wrote:
>>>>>> On Wed, 2012-08-08 at 12:49 +0200, Guido Trentalancia wrote:
>>>>>>> On 08/08/2012 10:52, Dominick Grift wrote:
>>>>>
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/bird.fc
>>>>>>>> @@ -0,0 +1,11 @@
>>>>>>>> +/etc/bird\.conf	--	gen_context(system_u:object_r:bird_etc_t,s0)
>>>>>>>> +
>>>>>>>> +/etc/default/bird	--	gen_context(system_u:object_r:bird_etc_t,s0)
>>>>>>>> +
>>>>>>>> +/etc/rc\.d/init\.d/bird	--	gen_context(system_u:object_r:bird_initrc_exec_t,s0)
>>>>>>>
>>>>>>> You might want to support init script locations for other distributions
>>>>>>> here, as in the oident module that you proposed to modify yesterday (I
>>>>>>> am going to modify the mcelog too for this purpose).
>>>>>>>
>>>>>>> Debian (but also Gentoo and many others) are currently using /etc/init\.d.
>>>>>>>
>>>>>>> The rest is unlikely to change, if it does, it's their business to
>>>>>>> modify the contexts, I think.
>>>>>>
>>>>>> You have a good point and i have been thinking abou this issue
>>>>>> obviously. I decided to go this way because existing init daemons also
>>>>>> only have the /etc/rc.d/init.d and not the /etc/init.d.
>>>>>>
>>>>>> Maybe a better solution is to just add:
>>>>>>
>>>>>> /etc/init.d /etc/rc.d/init.d
>>>>>>
>>>>>> to file_contexts.subs_dist
>>>>>
>>>>> Its not a bad idea.  I'd take a patch that cleaned this up across the entire policy.
>>>>>
>>>>
>>>> Should be as easy as appending /etc/init.d /etc/rc.d/init.d to
>>>> config/file_contexts.subs_dist
>>>>
>>>> However i am not sure if we should escape the periods
>>>
>>> It's probably safer to escape the periods anyway.
>>>
>>> But the point with using this, is that it would probably be a mutually
>>> exclusive substitution.
>>>
>>> Therefore we might need ifdef distro conditionals (which makes the whole
>>> thing more robust anyway). Done in one central place should not
>>> constitute over-engineering, I suppose.
>>
>> I have checked and file_contexts.subs_dist is a run-time configuration
>> file and not a build-time configuration file. Therefore it's does not
>> support conditionals such as ifdef distro, but just the simplest form of
>> substitutions.
>
> I do not think it matters because the paths aren't mutually exclusive i
> believe.
>
> The name substitution (subs) is misleading i believe, its not actually
> substitution but rather equivalence.

To be honest, I did not check this. The wording "substitution" usually 
implies "mutually exclusive" (as in something being replaced by 
something else).

Anway, I think each individual distribution packager can figure this out 
easily.

I have just completed the patch suggested by Christopher, so there is 
now at least one specific comment reminding of the possibility to use 
such configuration file...

>>> Regards,
>>>
>>> Guido

[refpolicy] [PATCH]: clean up some useless duplicated file contexts for the initrc base directory (was Re: [PATCH] Initial BIRD Internet Routing Daemon policy)

[Guido Trentalancia]

Hello Christopher.

On 08/08/2012 15:17, Christopher J. PeBenito wrote:
> On 08/08/12 07:42, Dominick Grift wrote:
>> On Wed, 2012-08-08 at 12:49 +0200, Guido Trentalancia wrote:
>>> On 08/08/2012 10:52, Dominick Grift wrote:
>
>>>> --- /dev/null
>>>> +++ b/bird.fc
>>>> @@ -0,0 +1,11 @@
>>>> +/etc/bird\.conf	--	gen_context(system_u:object_r:bird_etc_t,s0)
>>>> +
>>>> +/etc/default/bird	--	gen_context(system_u:object_r:bird_etc_t,s0)
>>>> +
>>>> +/etc/rc\.d/init\.d/bird	--	gen_context(system_u:object_r:bird_initrc_exec_t,s0)
>>>
>>> You might want to support init script locations for other distributions
>>> here, as in the oident module that you proposed to modify yesterday (I
>>> am going to modify the mcelog too for this purpose).
>>>
>>> Debian (but also Gentoo and many others) are currently using /etc/init\.d.
>>>
>>> The rest is unlikely to change, if it does, it's their business to
>>> modify the contexts, I think.
>>
>> You have a good point and i have been thinking abou this issue
>> obviously. I decided to go this way because existing init daemons also
>> only have the /etc/rc.d/init.d and not the /etc/init.d.
>>
>> Maybe a better solution is to just add:
>>
>> /etc/init.d /etc/rc.d/init.d
>>
>> to file_contexts.subs_dist
>
> Its not a bad idea.  I'd take a patch that cleaned this up across the entire policy.

Here is a possible patch:

Maintenance patch to remove some ambiguity and disomogeneity introduced
by the file contexts for the init scripts. The standard location for such
files is assumed by the Reference Policy to be /etc/rc.d/init.d and
distributions can customize such location by using the 
file_contexts.subs_dist
file appropriately.

- modify file contexts definitions for the hadoop contributed module;
- improve a comment for the timidity contributed module;
- clarify some comments in the init system interfaces.

Signed-off-by: Guido Trentalancia <guido@trentalancia.com>
---
  policy/modules/contrib/hadoop.fc   |    8 +-------
  policy/modules/contrib/timidity.te |    2 +-
  policy/modules/system/init.if      |   34 
++++++++++++++++++++++++----------
  3 files changed, 26 insertions(+), 18 deletions(-)

diff -pruN refpolicy-08082012/policy/modules/contrib/hadoop.fc 
refpolicy-08082012-remove-duplicate-initd-fc/policy/modules/contrib/hadoop.fc
--- refpolicy-08082012/policy/modules/contrib/hadoop.fc	2012-06-21 
20:18:45.722498642 +0200
+++ 
refpolicy-08082012-remove-duplicate-initd-fc/policy/modules/contrib/hadoop.fc 
2012-08-09 15:01:30.698380454 +0200
@@ -1,18 +1,12 @@
  /etc/hadoop.*							gen_context(system_u:object_r:hadoop_etc_t,s0)

-/etc/init\.d/hadoop-(.*-)?datanode			-- 
gen_context(system_u:object_r:hadoop_datanode_initrc_exec_t,s0)
-/etc/init\.d/hadoop-(.*-)?jobtracker			-- 
gen_context(system_u:object_r:hadoop_jobtracker_initrc_exec_t,s0)
-/etc/init\.d/hadoop-(.*-)?namenode			-- 
gen_context(system_u:object_r:hadoop_namenode_initrc_exec_t,s0)
-/etc/init\.d/hadoop-(.*-)?secondarynamenode		-- 
gen_context(system_u:object_r:hadoop_secondarynamenode_initrc_exec_t,s0)
-/etc/init\.d/hadoop-(.*-)?tasktracker			-- 
gen_context(system_u:object_r:hadoop_tasktracker_initrc_exec_t,s0)
-/etc/init\.d/zookeeper					-- 
gen_context(system_u:object_r:zookeeper_server_initrc_exec_t,s0)
-
  /etc/rc\.d/init\.d/hadoop-(.*-)?datanode		-- 
gen_context(system_u:object_r:hadoop_datanode_initrc_exec_t,s0)
  /etc/rc\.d/init\.d/hadoop-(.*-)?jobtracker		-- 
gen_context(system_u:object_r:hadoop_jobtracker_initrc_exec_t,s0)
  /etc/rc\.d/init\.d/hadoop-(.*-)?namenode		-- 
gen_context(system_u:object_r:hadoop_namenode_initrc_exec_t,s0)
  /etc/rc\.d/init\.d/hadoop-(.*-)?secondarynamenode	-- 
gen_context(system_u:object_r:hadoop_secondarynamenode_initrc_exec_t,s0)
  /etc/rc\.d/init\.d/hadoop-(.*-)?tasktracker		-- 
gen_context(system_u:object_r:hadoop_tasktracker_initrc_exec_t,s0)
  /etc/rc\.d/init\.d/hadoop-zookeeper			-- 
gen_context(system_u:object_r:zookeeper_server_initrc_exec_t,s0)
+/etc/rc\.d/init\.d/zookeeper				-- 
gen_context(system_u:object_r:zookeeper_server_initrc_exec_t,s0)

  /etc/zookeeper(/.*)?					 
gen_context(system_u:object_r:zookeeper_etc_t,s0)
  /etc/zookeeper\.dist(/.*)?				 
gen_context(system_u:object_r:zookeeper_etc_t,s0)
diff -pruN refpolicy-08082012/policy/modules/contrib/timidity.te 
refpolicy-08082012-remove-duplicate-initd-fc/policy/modules/contrib/timidity.te
--- refpolicy-08082012/policy/modules/contrib/timidity.te	2012-06-21 
20:18:45.757497382 +0200
+++ 
refpolicy-08082012-remove-duplicate-initd-fc/policy/modules/contrib/timidity.te 
2012-08-09 15:06:45.923204027 +0200
@@ -72,7 +72,7 @@ sysnet_read_config(timidity_t)
  userdom_dontaudit_use_unpriv_user_fds(timidity_t)

  # stupid timidity won't start if it can't search its current directory.
-# allow this so /etc/init.d/alsasound start works from /root
+# allow this so the initrc script alsasound can be started from /root
  # cjp: this should be fixed if possible so this rule can be removed.
  userdom_search_user_home_dirs(timidity_t)

diff -pruN refpolicy-08082012/policy/modules/system/init.if 
refpolicy-08082012-remove-duplicate-initd-fc/policy/modules/system/init.if
--- refpolicy-08082012/policy/modules/system/init.if	2012-06-21 
20:10:29.029804243 +0200
+++ 
refpolicy-08082012-remove-duplicate-initd-fc/policy/modules/system/init.if 
2012-08-09 15:21:12.996017552 +0200
@@ -8,7 +8,9 @@
  ##	<p>
  ##	Create a file type used for init scripts.  It can not be
  ##	used in conjunction with init_script_domain(). These
-##	script files are typically stored in the /etc/init.d directory.
+##	script files are typically stored in either the /etc/init.d
+##	or the /etc/rc.d/init.d directory (depending on the
+##	specific distribution).
  ##	</p>
  ##	<p>
  ##	Typically this is used to constrain what services an
@@ -21,6 +23,15 @@
  ##	This also makes the type usable for files; thus an
  ##	explicit call to files_type() is redundant.
  ##	</p>
+##	<p>
+##	A quick and convenient way of adapting the location of the
+##	init scripts (and in general any other base directory) for
+##	different distributions is to edit the run-time configuration
+##	file file_contexts.subs_dist. This file is located under the
+##	subdirectory config/ of the Reference Policy build tree and
+##	it is then available after installation in the subdirectory
+##	contexts/files/ of the installed policy.
+##	</p>
  ## </desc>
  ## <param name="script_file">
  ##	<summary>
@@ -165,8 +176,8 @@ interface(`init_ranged_domain',`
  ##	which are started by init scripts. Short running processes
  ##	should use the init_system_domain() interface instead.
  ##	Typically all long running processes started by an init
-##	script (usually in /etc/init.d) will need to use this
-##	interface.
+##	script (usually in /etc/init.d or /etc/rc.d/init.d, depending
+##	on the distribution) will need to use this interface.
  ##	</p>
  ##	<p>
  ##	The types will be made usable as a domain and file, making
@@ -251,8 +262,9 @@ interface(`init_daemon_domain',`
  ##	MLS/MCS range. Short running processes
  ##	should use the init_ranged_system_domain() interface instead.
  ##	Typically all long running processes started by an init
-##	script (usually in /etc/init.d) will need to use this
-##	interface if they need to run in a specific MLS/MCS range.
+##	script (usually in /etc/init.d or /etc/rc.d/init.d, depending
+##	on the distribution) will need to use this interface if
+##	they need to run in a specific MLS/MCS range.
  ##	</p>
  ##	<p>
  ##	The types will be made usable as a domain and file, making
@@ -310,8 +322,8 @@ interface(`init_ranged_daemon_domain',`
  ##	Long running processes, such as daemons/services
  ##	should use the init_daemon_domain() interface instead.
  ##	Typically all short running processes started by an init
-##	script (usually in /etc/init.d) will need to use this
-##	interface.
+##	script (usually in /etc/init.d or /etc/rc.d/init.d, depending on the
+##	distribution) will need to use this interface.
  ##	</p>
  ##	<p>
  ##	The types will be made usable as a domain and file, making
@@ -369,8 +381,9 @@ interface(`init_system_domain',`
  ##	Long running processes
  ##	should use the init_ranged_system_domain() interface instead.
  ##	Typically all short running processes started by an init
-##	script (usually in /etc/init.d) will need to use this
-##	interface if they need to run in a specific MLS/MCS range.
+##	script (usually in /etc/init.d or /etc/rc.d/init.d, depending
+##	on the distribution) will need to use this interface if they
+##	need to run in a specific MLS/MCS range.
  ##	</p>
  ##	<p>
  ##	The types will be made usable as a domain and file, making
@@ -939,7 +952,8 @@ interface(`init_all_labeled_script_domtr
  ##	<p>
  ##	Start and stop daemon programs directly
  ##	in the traditional "/etc/init.d/daemon start"
-##	style, and do not require run_init.
+##	or "/etc/rc.d/init.d/daemon start" style,
+##	and do not require run_init.
  ##	</p>
  ## </desc>
  ## <param name="domain">

[refpolicy] [PATCH] Initial BIRD Internet Routing Daemon policy

[Guido Trentalancia]

On 08/08/2012 13:42, Dominick Grift wrote:
>
>
> On Wed, 2012-08-08 at 12:49 +0200, Guido Trentalancia wrote:
>> Hello Dominick.
>>
>> A very quick and possibly incomplete review, if it helps...
>>
>> On 08/08/2012 10:52, Dominick Grift wrote:
>>>
>>> Signed-off-by: Dominick Grift <dominick.grift@gmail.com>
>>> diff --git a/bird.fc b/bird.fc
>>> new file mode 100644
>>> index 0000000..7b63b8e
>>> --- /dev/null
>>> +++ b/bird.fc
>>> @@ -0,0 +1,11 @@
>>> +/etc/bird\.conf	--	gen_context(system_u:object_r:bird_etc_t,s0)
>>> +
>>> +/etc/default/bird	--	gen_context(system_u:object_r:bird_etc_t,s0)
>>> +
>>> +/etc/rc\.d/init\.d/bird	--	gen_context(system_u:object_r:bird_initrc_exec_t,s0)
>>
>> You might want to support init script locations for other distributions
>> here, as in the oident module that you proposed to modify yesterday (I
>> am going to modify the mcelog too for this purpose).
>>
>> Debian (but also Gentoo and many others) are currently using /etc/init\.d.
>>
>> The rest is unlikely to change, if it does, it's their business to
>> modify the contexts, I think.
>
>
> You have a good point and i have been thinking abou this issue
> obviously. I decided to go this way because existing init daemons also
> only have the /etc/rc.d/init.d and not the /etc/init.d.
>
> Maybe a better solution is to just add:
>
> /etc/init.d /etc/rc.d/init.d
>
> to file_contexts.subs_dist

Yes, that should be a better solution.

>>> +/usr/sbin/bird	--	gen_context(system_u:object_r:bird_exec_t,s0)
>>> +
>>> +/var/log/bird\.log.*	--	gen_context(system_u:object_r:bird_log_t,s0)
>>> +
>>> +/var/run/bird\.ctl	-s	gen_context(system_u:object_r:bird_var_run_t,s0)
>>> diff --git a/bird.if b/bird.if
>>> new file mode 100644
>>> index 0000000..fae3f36
>>> --- /dev/null
>>> +++ b/bird.if
>>> @@ -0,0 +1,42 @@
>>> +## <summary>BIRD Internet Routing Daemon.</summary>
>>> +

[cut]

>>> +########################################
>>> +#
>>> +# Local policy
>>> +#
>>> +
>>> +allow bird_t self:capability { net_admin net_bind_service };
>>> +allow bird_t self:netlink_route_socket create_netlink_socket_perms;
>>> +allow bird_t self:tcp_socket create_stream_socket_perms;
>>> +
>>> +allow bird_t bird_etc_t:file read_file_perms;
>>
>> Use of patterns for reading, writing or managing standard files is more
>> common throughout the whole reference policy. It's not critical but
>> think about it, it might improve readability and coherence across the
>> work as a whole...
>
> This is better in my view. The patterns provide permissions that are not
> needed here. i.e. read_files_pattern(bird_t, bird_etc_t , bird_etc_t)
> allow bird_t to search bird_etc_t dirs but there aren't any.

What often happens is that distributions create internal directories 
within /etc (as in /etc/bird), that's why using the pattern is a bit 
more future-proof.

>>> +allow bird_t bird_log_t:file { create_file_perms append_file_perms setattr_file_perms };
>>
>> I think create+append+setattr grants more permissions than the
>> manage_file_perms (or preferably corrispondent pattern), however I have
>> not checked.
>>
>
> No, This combination make it possible to not allow bird_T to "write"
> bird_log_t files which is a real benefit over manage_file_perms.

You're right, it's the other way around. manage is lots more permissions 
than create+append+setattr. I think I got confused by the fact that most 
other modules simply use manage.

>> See above for using patterns versus individual or grouped permissions.
>>
>>> +logging_log_filetrans(bird_t, bird_log_t, file)
>>> +
>>> +allow bird_t bird_var_run_t:sock_file manage_sock_file_perms;
>>
>> See above for using patterns versus individual or grouped permissions.
>>
>>> +files_pid_filetrans(bird_t, bird_var_run_t, sock_file)
>>> +
>>> +corenet_all_recvfrom_unlabeled(bird_t)
>>
>> Unlabelled receive could probably made tunable as not everybody might
>> like that.
>
> unlabeled is a default in systems. The boolean would be have to be on by
> default. On other systems this rules would harm since the packets would
> be labeled.
>
> and for the sake of uniformity i will leave it like this (other existing
> modules also dont have this conditional)

Perhaps a tunable policy can be introduced internally within all 
interfaces that are using unlabelled connections so that there is only 
one boolean defaulting to on...

>>> +corenet_all_recvfrom_netlabel(bird_t)
>>> +corenet_tcp_sendrecv_generic_if(bird_t)
>>> +corenet_tcp_bind_generic_node(bird_t)
>>> +corenet_tcp_sendrecv_generic_node(bird_t)
>>> +corenet_tcp_sendrecv_bgp_port(bird_t)
>>> +corenet_sendrecv_bgp_client_packets(bird_t)
>>> +corenet_tcp_connect_bgp_port(bird_t)
>>> +corenet_sendrecv_bgp_server_packets(bird_t)
>>> +corenet_tcp_bind_bgp_port(bird_t)
>>> +
>>> +# /etc/iproute2/rt_realms
>>> +files_read_etc_files(bird_t)
>>> +
>>> +logging_send_syslog_msg(bird_t)
>>> +
>>> +miscfiles_read_localization(bird_t)
>>
>> You have not used the bird_admin() interface, since it's not a simple
>> and generic interface (such as for managing files), you should really
>> remove it in my opinion.
>
> True and in general it is a good argument to not create unused
> interfaces. However this is a exception to that rules. We want end-users
> to be able to easily create a birdadm_r role. This interface facilitates
> that. If we would create a role for each init daemon by default we would
> end up with too many roles.
>
> So the middle road is to not create the role by default but to provide
> the interface so that endusers can easily create it if they so desire.
>
>> The most important reason is that permissions needed by BIRD might
>> change with subsequent releases of the daemon by the time somebody will
>> actually use the bird_admin() interface: if they shrink, it's a security
>> matter (interface is loose) and you don't be doing much of a favour to
>> anyone.
>
> This argument is not valid in light of my comment above.

Ok.

>> Regards,
>>
>> Guido

[refpolicy] [PATCH] Initial BIRD Internet Routing Daemon policy

[Dominick Grift]

On Wed, 2012-08-08 at 16:54 +0200, Guido Trentalancia wrote:

> 
> [cut]

> >>> +allow bird_t bird_etc_t:file read_file_perms;
> >>
> >> Use of patterns for reading, writing or managing standard files is more
> >> common throughout the whole reference policy. It's not critical but
> >> think about it, it might improve readability and coherence across the
> >> work as a whole...
> >
> > This is better in my view. The patterns provide permissions that are not
> > needed here. i.e. read_files_pattern(bird_t, bird_etc_t , bird_etc_t)
> > allow bird_t to search bird_etc_t dirs but there aren't any.
> 
> What often happens is that distributions create internal directories 
> within /etc (as in /etc/bird), that's why using the pattern is a bit 
> more future-proof.

I do not like assumptions. If there is a real use to it then i will be
happy to use the pattern.

If there is anything i have learned, it is that one should be
conservative/efficient with adding rules.

assumptions , routine are bad habits imho.

[refpolicy] [PATCH] Initial BIRD Internet Routing Daemon policy

[Guido Trentalancia]

On 08/08/2012 17:06, Dominick Grift wrote:
>
>
> On Wed, 2012-08-08 at 16:54 +0200, Guido Trentalancia wrote:
>
>>
>> [cut]
>
>>>>> +allow bird_t bird_etc_t:file read_file_perms;
>>>>
>>>> Use of patterns for reading, writing or managing standard files is more
>>>> common throughout the whole reference policy. It's not critical but
>>>> think about it, it might improve readability and coherence across the
>>>> work as a whole...
>>>
>>> This is better in my view. The patterns provide permissions that are not
>>> needed here. i.e. read_files_pattern(bird_t, bird_etc_t , bird_etc_t)
>>> allow bird_t to search bird_etc_t dirs but there aren't any.
>>
>> What often happens is that distributions create internal directories
>> within /etc (as in /etc/bird), that's why using the pattern is a bit
>> more future-proof.
>
> I do not like assumptions. If there is a real use to it then i will be
> happy to use the pattern.
>
> If there is anything i have learned, it is that one should be
> conservative/efficient with adding rules.
>
> assumptions , routine are bad habits imho.

A policy writer simply might not know what all distributions are going 
to do.

It was just a note. There is real use of that. I am not referring 
specifically to this BIRD daemon, which I do not know. And at the moment 
I can remember any specific package on a specific distribution which 
does that, but it happens.

It's just the opposite of an assumption, as it means assume nothing 
(thus including: do not assume that bird.conf is located top-level in an 
etc_t directory).

Regards,

Guido

[refpolicy] [PATCH] Initial BIRD Internet Routing Daemon policy

[Christopher J. PeBenito]

On 08/08/12 04:52, Dominick Grift wrote:
> 
> Signed-off-by: Dominick Grift <dominick.grift@gmail.com>

Merged.


> diff --git a/bird.fc b/bird.fc
> new file mode 100644
> index 0000000..7b63b8e
> --- /dev/null
> +++ b/bird.fc
> @@ -0,0 +1,11 @@
> +/etc/bird\.conf	--	gen_context(system_u:object_r:bird_etc_t,s0)
> +
> +/etc/default/bird	--	gen_context(system_u:object_r:bird_etc_t,s0)
> +
> +/etc/rc\.d/init\.d/bird	--	gen_context(system_u:object_r:bird_initrc_exec_t,s0)
> +
> +/usr/sbin/bird	--	gen_context(system_u:object_r:bird_exec_t,s0)
> +
> +/var/log/bird\.log.*	--	gen_context(system_u:object_r:bird_log_t,s0)
> +
> +/var/run/bird\.ctl	-s	gen_context(system_u:object_r:bird_var_run_t,s0)
> diff --git a/bird.if b/bird.if
> new file mode 100644
> index 0000000..fae3f36
> --- /dev/null
> +++ b/bird.if
> @@ -0,0 +1,42 @@
> +## <summary>BIRD Internet Routing Daemon.</summary>
> +
> +########################################
> +## <summary>
> +##	All of the rules required to administrate
> +##	an bird environment.
> +## </summary>
> +## <param name="domain">
> +##	<summary>
> +##	Domain allowed access.
> +##	</summary>
> +## </param>
> +## <param name="role">
> +##	<summary>
> +##	Role allowed access..
> +##	</summary>
> +## </param>
> +## <rolecap/>
> +#
> +interface(`bird_admin',`
> +	gen_require(`
> +		type bird_t, bird_etc_t, bird_log_t;
> +		type bird_var_run_t, bird_initrc_exec_t;
> +	')
> +
> +	allow $1 bird_t:process { ptrace signal_perms };
> +	ps_process_pattern($1, bird_t)
> +
> +	init_labeled_script_domtrans($1, bird_initrc_exec_t)
> +	domain_system_change_exemption($1)
> +	role_transition $2 bird_initrc_exec_t system_r;
> +	allow $2 system_r;
> +
> +	files_list_etc($1)
> +	admin_pattern($1, bird_etc_t)
> +
> +	logging_list_logs($1)
> +	admin_pattern($1, bird_log_t)
> +
> +	files_list_pids($1)
> +	admin_pattern($1, bird_var_run_t)
> +')
> diff --git a/bird.te b/bird.te
> new file mode 100644
> index 0000000..9afd52b
> --- /dev/null
> +++ b/bird.te
> @@ -0,0 +1,57 @@
> +policy_module(bird, 1.0.0)
> +
> +########################################
> +#
> +# Declarations
> +#
> +
> +type bird_t;
> +type bird_exec_t;
> +init_daemon_domain(bird_t, bird_exec_t)
> +
> +type bird_initrc_exec_t;
> +init_script_file(bird_initrc_exec_t)
> +
> +type bird_etc_t;
> +files_config_file(bird_etc_t)
> +
> +type bird_log_t;
> +logging_log_file(bird_log_t)
> +
> +type bird_var_run_t;
> +files_pid_file(bird_var_run_t)
> +
> +########################################
> +#
> +# Local policy
> +#
> +
> +allow bird_t self:capability { net_admin net_bind_service };
> +allow bird_t self:netlink_route_socket create_netlink_socket_perms;
> +allow bird_t self:tcp_socket create_stream_socket_perms;
> +
> +allow bird_t bird_etc_t:file read_file_perms;
> +
> +allow bird_t bird_log_t:file { create_file_perms append_file_perms setattr_file_perms };
> +logging_log_filetrans(bird_t, bird_log_t, file)
> +
> +allow bird_t bird_var_run_t:sock_file manage_sock_file_perms;
> +files_pid_filetrans(bird_t, bird_var_run_t, sock_file)
> +
> +corenet_all_recvfrom_unlabeled(bird_t)
> +corenet_all_recvfrom_netlabel(bird_t)
> +corenet_tcp_sendrecv_generic_if(bird_t)
> +corenet_tcp_bind_generic_node(bird_t)
> +corenet_tcp_sendrecv_generic_node(bird_t)
> +corenet_tcp_sendrecv_bgp_port(bird_t)
> +corenet_sendrecv_bgp_client_packets(bird_t)
> +corenet_tcp_connect_bgp_port(bird_t)
> +corenet_sendrecv_bgp_server_packets(bird_t)
> +corenet_tcp_bind_bgp_port(bird_t)
> +
> +# /etc/iproute2/rt_realms
> +files_read_etc_files(bird_t)
> +
> +logging_send_syslog_msg(bird_t)
> +
> +miscfiles_read_localization(bird_t)
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
> 


-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com