These patches are my first attempt at drafting policy for the new TUN hooks,
any comments or feedback you have would be great. It is worth noting that
permission to create/attach to TUN/TAP devices was not granted to every
domain that has r/w access to the /dev/net/tun device as the operations are
very different; r/w access to /dev/net/tun does not mean the domain needs
the ability to create/attach TUN/TAP devices.
I've done some basic testing but I'm not having a lot of luck running the
current refpolicy on Fedora/Rawhide (unfortunately refpolicy and the current
Rawhide policy diverge quite a bit in a few important areas touched by these
patches), if anyone has any tips I'd love to hear them.
---
Paul Moore (2):
refpol: Policy for the new TUN driver access controls
refpol: Add the "tun_socket" object class flask definitions
policy/flask/access_vectors | 2 ++
policy/flask/security_classes | 2 ++
policy/modules/admin/vpn.te | 1 +
policy/modules/apps/qemu.if | 3 +++
policy/modules/apps/uml.te | 3 +++
policy/modules/services/openvpn.te | 1 +
policy/modules/services/virt.if | 19 +++++++++++++++++++
policy/modules/services/virt.te | 1 +
policy/modules/system/userdomain.if | 23 +++++++++++++++++++++++
policy/modules/system/userdomain.te | 2 ++
policy/modules/system/xen.te | 1 +
11 files changed, 58 insertions(+), 0 deletions(-)
Add the new "tun_socket" class to the flask definitions. The "tun_socket"
object class is used by the new TUN driver hooks which allow policy to control
access to TUN/TAP devices.
---
policy/flask/access_vectors | 2 ++
policy/flask/security_classes | 2 ++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/policy/flask/access_vectors b/policy/flask/access_vectors
index ef4c063..6292db5 100644
--- a/policy/flask/access_vectors
+++ b/policy/flask/access_vectors
@@ -251,6 +251,8 @@ inherits socket
class unix_dgram_socket
inherits socket
+class tun_socket
+inherits socket
#
# Define the access vector interpretation for process-related objects
diff --git a/policy/flask/security_classes b/policy/flask/security_classes
index 9e1bf1a..2bd1bf6 100644
--- a/policy/flask/security_classes
+++ b/policy/flask/security_classes
@@ -119,4 +119,6 @@ class x_application_data # userspace
# kernel services that need to override task security, e.g. cachefiles
class kernel_service
+class tun_socket
+
# FLASK
Add policy for the new TUN driver access controls which allow policy to
control which domains have the ability to create and attach to TUN/TAP
devices. The policy rules for creating and attaching to a device are as
shown below:
# create a new device
allow domain_t self:tun_socket { create };
# attach to a persistent device (created by tunlbl_t)
allow domain_t tunlbl_t:tun_socket { relabelfrom };
allow domain_t self:tun_socket { relabelto };
Further discussion can be found on this thread:
* http://marc.info/?t=125080850900002&r=1&w=2
---
policy/modules/admin/vpn.te | 1 +
policy/modules/apps/qemu.if | 3 +++
policy/modules/apps/uml.te | 3 +++
policy/modules/services/openvpn.te | 1 +
policy/modules/services/virt.if | 19 +++++++++++++++++++
policy/modules/services/virt.te | 1 +
policy/modules/system/userdomain.if | 23 +++++++++++++++++++++++
policy/modules/system/userdomain.te | 2 ++
policy/modules/system/xen.te | 1 +
9 files changed, 54 insertions(+), 0 deletions(-)
diff --git a/policy/modules/admin/vpn.te b/policy/modules/admin/vpn.te
index 11c2dcc..52cf380 100644
--- a/policy/modules/admin/vpn.te
+++ b/policy/modules/admin/vpn.te
@@ -31,6 +31,7 @@ allow vpnc_t self:udp_socket create_socket_perms;
allow vpnc_t self:rawip_socket create_socket_perms;
allow vpnc_t self:unix_dgram_socket create_socket_perms;
allow vpnc_t self:unix_stream_socket create_socket_perms;
+allow vpnc_t self:tun_socket create;
# cjp: this needs to be fixed
allow vpnc_t self:socket create_socket_perms;
diff --git a/policy/modules/apps/qemu.if b/policy/modules/apps/qemu.if
index d258f1d..ee7e214 100644
--- a/policy/modules/apps/qemu.if
+++ b/policy/modules/apps/qemu.if
@@ -149,6 +149,7 @@ template(`qemu_domain_template',`
allow $1_t self:shm create_shm_perms;
allow $1_t self:unix_stream_socket create_stream_socket_perms;
allow $1_t self:tcp_socket create_stream_socket_perms;
+ allow $1_t self:tun_socket create;
manage_dirs_pattern($1_t, $1_tmp_t, $1_tmp_t)
manage_files_pattern($1_t, $1_tmp_t, $1_tmp_t)
@@ -164,6 +165,8 @@ template(`qemu_domain_template',`
corenet_tcp_bind_generic_node($1_t)
corenet_tcp_bind_vnc_port($1_t)
corenet_rw_tun_tap_dev($1_t)
+ virt_tun_attach($1_t)
+ userdom_tun_attach($1_t)
# dev_rw_kvm($1_t)
diff --git a/policy/modules/apps/uml.te b/policy/modules/apps/uml.te
index 05e871c..902c226 100644
--- a/policy/modules/apps/uml.te
+++ b/policy/modules/apps/uml.te
@@ -60,6 +60,7 @@ allow uml_t self:unix_dgram_socket create_socket_perms;
# Use the network.
allow uml_t self:tcp_socket create_stream_socket_perms;
allow uml_t self:udp_socket create_socket_perms;
+allow uml_t self:tun_socket create;
# for mconsole
allow uml_t self:unix_dgram_socket sendto;
@@ -111,6 +112,8 @@ corenet_udp_sendrecv_all_ports(uml_t)
corenet_tcp_connect_all_ports(uml_t)
corenet_sendrecv_all_client_packets(uml_t)
corenet_rw_tun_tap_dev(uml_t)
+virt_tun_attach(uml_t)
+userdom_tun_attach(uml_t)
domain_use_interactive_fds(uml_t)
diff --git a/policy/modules/services/openvpn.te b/policy/modules/services/openvpn.te
index a4e2db2..99149f0 100644
--- a/policy/modules/services/openvpn.te
+++ b/policy/modules/services/openvpn.te
@@ -49,6 +49,7 @@ allow openvpn_t self:unix_dgram_socket { create_socket_perms sendto };
allow openvpn_t self:unix_stream_socket { create_stream_socket_perms connectto };
allow openvpn_t self:udp_socket create_socket_perms;
allow openvpn_t self:tcp_socket server_stream_socket_perms;
+allow openvpn_t self:tun_socket create;
allow openvpn_t self:netlink_route_socket rw_netlink_socket_perms;
can_exec(openvpn_t, openvpn_etc_t)
diff --git a/policy/modules/services/virt.if b/policy/modules/services/virt.if
index 8dc8acf..77c3651 100644
--- a/policy/modules/services/virt.if
+++ b/policy/modules/services/virt.if
@@ -327,3 +327,22 @@ interface(`virt_admin',`
virt_manage_log($1)
')
+
+########################################
+## <summary>
+## Allow domain to attach to virt TUN devices
+## </summary>
+## <param name="domain">
+## <summary>
+## Domain allowed access.
+## </summary>
+## </param>
+#
+interface(`virt_tun_attach',`
+ gen_require(`
+ type virtd_t;
+ ')
+
+ allow $1 virtd_t:tun_socket relabelfrom;
+ allow $1 self:tun_socket relabelto;
+')
diff --git a/policy/modules/services/virt.te b/policy/modules/services/virt.te
index b2fd700..a51755e 100644
--- a/policy/modules/services/virt.te
+++ b/policy/modules/services/virt.te
@@ -58,6 +58,7 @@ allow virtd_t self:process { getsched sigkill signal execmem };
allow virtd_t self:fifo_file rw_file_perms;
allow virtd_t self:unix_stream_socket create_stream_socket_perms;
allow virtd_t self:tcp_socket create_stream_socket_perms;
+allow virtd_t self:tun_socket create;
read_files_pattern(virtd_t, virt_etc_t, virt_etc_t)
read_lnk_files_pattern(virtd_t, virt_etc_t, virt_etc_t)
diff --git a/policy/modules/system/userdomain.if b/policy/modules/system/userdomain.if
index 49ac3fd..22a952c 100644
--- a/policy/modules/system/userdomain.if
+++ b/policy/modules/system/userdomain.if
@@ -1042,6 +1042,7 @@ template(`userdom_unpriv_user_template', `
#
template(`userdom_admin_user_template',`
gen_require(`
+ attribute admin_tun_type;
class passwd { passwd chfn chsh rootok };
')
@@ -1077,6 +1078,9 @@ template(`userdom_admin_user_template',`
allow $1_t self:netlink_audit_socket nlmsg_readpriv;
+ allow $1_t self:tun_socket create;
+ typeattribute $1_t admin_tun_type;
+
kernel_read_software_raid_state($1_t)
kernel_getattr_core_if($1_t)
kernel_getattr_message_if($1_t)
@@ -3027,3 +3031,22 @@ interface(`userdom_dbus_send_all_users',`
allow $1 userdomain:dbus send_msg;
')
+
+########################################
+## <summary>
+## Allow domain to attach to admin created TUN devices
+## </summary>
+## <param name="domain">
+## <summary>
+## Domain allowed access.
+## </summary>
+## </param>
+#
+interface(`userdom_tun_attach',`
+ gen_require(`
+ attribute admin_tun_type;
+ ')
+
+ allow $1 admin_tun_type:tun_socket relabelfrom;
+ allow $1 self:tun_socket relabelto;
+')
diff --git a/policy/modules/system/userdomain.te b/policy/modules/system/userdomain.te
index 48e9070..aff080b 100644
--- a/policy/modules/system/userdomain.te
+++ b/policy/modules/system/userdomain.te
@@ -58,6 +58,8 @@ attribute unpriv_userdomain;
attribute untrusted_content_type;
attribute untrusted_content_tmp_type;
+attribute admin_tun_type;
+
type user_home_dir_t alias { staff_home_dir_t sysadm_home_dir_t secadm_home_dir_t auditadm_home_dir_t unconfined_home_dir_t };
fs_associate_tmpfs(user_home_dir_t)
files_type(user_home_dir_t)
diff --git a/policy/modules/system/xen.te b/policy/modules/system/xen.te
index 40410a7..6c4b06d 100644
--- a/policy/modules/system/xen.te
+++ b/policy/modules/system/xen.te
@@ -88,6 +88,7 @@ allow xend_t self:unix_dgram_socket create_socket_perms;
allow xend_t self:netlink_route_socket r_netlink_socket_perms;
allow xend_t self:tcp_socket create_stream_socket_perms;
allow xend_t self:packet_socket create_socket_perms;
+allow xend_t self:tun_socket create;
allow xend_t xen_image_t:dir list_dir_perms;
manage_dirs_pattern(xend_t, xen_image_t, xen_image_t)
On Tue, 2009-08-25 at 17:12 -0400, Paul Moore wrote:
> Add policy for the new TUN driver access controls which allow policy to
> control which domains have the ability to create and attach to TUN/TAP
> devices. The policy rules for creating and attaching to a device are as
> shown below:
Comments inline.
> # create a new device
> allow domain_t self:tun_socket { create };
>
> # attach to a persistent device (created by tunlbl_t)
> allow domain_t tunlbl_t:tun_socket { relabelfrom };
> allow domain_t self:tun_socket { relabelto };
>
> Further discussion can be found on this thread:
>
> * http://marc.info/?t=125080850900002&r=1&w=2
> ---
>
> policy/modules/admin/vpn.te | 1 +
> policy/modules/apps/qemu.if | 3 +++
> policy/modules/apps/uml.te | 3 +++
> policy/modules/services/openvpn.te | 1 +
> policy/modules/services/virt.if | 19 +++++++++++++++++++
> policy/modules/services/virt.te | 1 +
> policy/modules/system/userdomain.if | 23 +++++++++++++++++++++++
> policy/modules/system/userdomain.te | 2 ++
> policy/modules/system/xen.te | 1 +
> 9 files changed, 54 insertions(+), 0 deletions(-)
>
> diff --git a/policy/modules/admin/vpn.te b/policy/modules/admin/vpn.te
> index 11c2dcc..52cf380 100644
> --- a/policy/modules/admin/vpn.te
> +++ b/policy/modules/admin/vpn.te
> @@ -31,6 +31,7 @@ allow vpnc_t self:udp_socket create_socket_perms;
> allow vpnc_t self:rawip_socket create_socket_perms;
> allow vpnc_t self:unix_dgram_socket create_socket_perms;
> allow vpnc_t self:unix_stream_socket create_socket_perms;
> +allow vpnc_t self:tun_socket create;
> # cjp: this needs to be fixed
> allow vpnc_t self:socket create_socket_perms;
>
> diff --git a/policy/modules/apps/qemu.if b/policy/modules/apps/qemu.if
> index d258f1d..ee7e214 100644
> --- a/policy/modules/apps/qemu.if
> +++ b/policy/modules/apps/qemu.if
> @@ -149,6 +149,7 @@ template(`qemu_domain_template',`
> allow $1_t self:shm create_shm_perms;
> allow $1_t self:unix_stream_socket create_stream_socket_perms;
> allow $1_t self:tcp_socket create_stream_socket_perms;
> + allow $1_t self:tun_socket create;
>
> manage_dirs_pattern($1_t, $1_tmp_t, $1_tmp_t)
> manage_files_pattern($1_t, $1_tmp_t, $1_tmp_t)
> @@ -164,6 +165,8 @@ template(`qemu_domain_template',`
> corenet_tcp_bind_generic_node($1_t)
> corenet_tcp_bind_vnc_port($1_t)
> corenet_rw_tun_tap_dev($1_t)
> + virt_tun_attach($1_t)
> + userdom_tun_attach($1_t)
These should be moved to be with the other virt and userdom calls.
> # dev_rw_kvm($1_t)
>
> diff --git a/policy/modules/apps/uml.te b/policy/modules/apps/uml.te
> index 05e871c..902c226 100644
> --- a/policy/modules/apps/uml.te
> +++ b/policy/modules/apps/uml.te
> @@ -60,6 +60,7 @@ allow uml_t self:unix_dgram_socket create_socket_perms;
> # Use the network.
> allow uml_t self:tcp_socket create_stream_socket_perms;
> allow uml_t self:udp_socket create_socket_perms;
> +allow uml_t self:tun_socket create;
> # for mconsole
> allow uml_t self:unix_dgram_socket sendto;
>
> @@ -111,6 +112,8 @@ corenet_udp_sendrecv_all_ports(uml_t)
> corenet_tcp_connect_all_ports(uml_t)
> corenet_sendrecv_all_client_packets(uml_t)
> corenet_rw_tun_tap_dev(uml_t)
> +virt_tun_attach(uml_t)
> +userdom_tun_attach(uml_t)
Same thing about moving these, as above.
> domain_use_interactive_fds(uml_t)
>
> diff --git a/policy/modules/services/openvpn.te b/policy/modules/services/openvpn.te
> index a4e2db2..99149f0 100644
> --- a/policy/modules/services/openvpn.te
> +++ b/policy/modules/services/openvpn.te
> @@ -49,6 +49,7 @@ allow openvpn_t self:unix_dgram_socket { create_socket_perms sendto };
> allow openvpn_t self:unix_stream_socket { create_stream_socket_perms connectto };
> allow openvpn_t self:udp_socket create_socket_perms;
> allow openvpn_t self:tcp_socket server_stream_socket_perms;
> +allow openvpn_t self:tun_socket create;
> allow openvpn_t self:netlink_route_socket rw_netlink_socket_perms;
>
> can_exec(openvpn_t, openvpn_etc_t)
> diff --git a/policy/modules/services/virt.if b/policy/modules/services/virt.if
> index 8dc8acf..77c3651 100644
> --- a/policy/modules/services/virt.if
> +++ b/policy/modules/services/virt.if
> @@ -327,3 +327,22 @@ interface(`virt_admin',`
>
> virt_manage_log($1)
> ')
> +
> +########################################
> +## <summary>
> +## Allow domain to attach to virt TUN devices
> +## </summary>
> +## <param name="domain">
> +## <summary>
> +## Domain allowed access.
> +## </summary>
> +## </param>
> +#
> +interface(`virt_tun_attach',`
> + gen_require(`
> + type virtd_t;
> + ')
> +
> + allow $1 virtd_t:tun_socket relabelfrom;
> + allow $1 self:tun_socket relabelto;
> +')
> diff --git a/policy/modules/services/virt.te b/policy/modules/services/virt.te
> index b2fd700..a51755e 100644
> --- a/policy/modules/services/virt.te
> +++ b/policy/modules/services/virt.te
> @@ -58,6 +58,7 @@ allow virtd_t self:process { getsched sigkill signal execmem };
> allow virtd_t self:fifo_file rw_file_perms;
> allow virtd_t self:unix_stream_socket create_stream_socket_perms;
> allow virtd_t self:tcp_socket create_stream_socket_perms;
> +allow virtd_t self:tun_socket create;
>
> read_files_pattern(virtd_t, virt_etc_t, virt_etc_t)
> read_lnk_files_pattern(virtd_t, virt_etc_t, virt_etc_t)
> diff --git a/policy/modules/system/userdomain.if b/policy/modules/system/userdomain.if
> index 49ac3fd..22a952c 100644
> --- a/policy/modules/system/userdomain.if
> +++ b/policy/modules/system/userdomain.if
> @@ -1042,6 +1042,7 @@ template(`userdom_unpriv_user_template', `
> #
> template(`userdom_admin_user_template',`
> gen_require(`
> + attribute admin_tun_type;
> class passwd { passwd chfn chsh rootok };
> ')
>
> @@ -1077,6 +1078,9 @@ template(`userdom_admin_user_template',`
>
> allow $1_t self:netlink_audit_socket nlmsg_readpriv;
>
> + allow $1_t self:tun_socket create;
> + typeattribute $1_t admin_tun_type;
> +
> kernel_read_software_raid_state($1_t)
> kernel_getattr_core_if($1_t)
> kernel_getattr_message_if($1_t)
> @@ -3027,3 +3031,22 @@ interface(`userdom_dbus_send_all_users',`
>
> allow $1 userdomain:dbus send_msg;
> ')
> +
> +########################################
> +## <summary>
> +## Allow domain to attach to admin created TUN devices
> +## </summary>
> +## <param name="domain">
> +## <summary>
> +## Domain allowed access.
> +## </summary>
> +## </param>
> +#
> +interface(`userdom_tun_attach',`
> + gen_require(`
> + attribute admin_tun_type;
> + ')
> +
> + allow $1 admin_tun_type:tun_socket relabelfrom;
> + allow $1 self:tun_socket relabelto;
> +')
Why are only admin roles allowed to create tun_sockets? Either the
interface name should be changed to reflect that its not all user
domains, or it should be expanded to cover all user domains.
> diff --git a/policy/modules/system/userdomain.te b/policy/modules/system/userdomain.te
> index 48e9070..aff080b 100644
> --- a/policy/modules/system/userdomain.te
> +++ b/policy/modules/system/userdomain.te
> @@ -58,6 +58,8 @@ attribute unpriv_userdomain;
> attribute untrusted_content_type;
> attribute untrusted_content_tmp_type;
>
> +attribute admin_tun_type;
> +
> type user_home_dir_t alias { staff_home_dir_t sysadm_home_dir_t secadm_home_dir_t auditadm_home_dir_t unconfined_home_dir_t };
> fs_associate_tmpfs(user_home_dir_t)
> files_type(user_home_dir_t)
> diff --git a/policy/modules/system/xen.te b/policy/modules/system/xen.te
> index 40410a7..6c4b06d 100644
> --- a/policy/modules/system/xen.te
> +++ b/policy/modules/system/xen.te
> @@ -88,6 +88,7 @@ allow xend_t self:unix_dgram_socket create_socket_perms;
> allow xend_t self:netlink_route_socket r_netlink_socket_perms;
> allow xend_t self:tcp_socket create_stream_socket_perms;
> allow xend_t self:packet_socket create_socket_perms;
> +allow xend_t self:tun_socket create;
>
> allow xend_t xen_image_t:dir list_dir_perms;
> manage_dirs_pattern(xend_t, xen_image_t, xen_image_t)
No attach?
--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150
On Wednesday 26 August 2009 08:49:14 am Christopher J. PeBenito wrote:
> On Tue, 2009-08-25 at 17:12 -0400, Paul Moore wrote:
> > Add policy for the new TUN driver access controls which allow policy to
> > control which domains have the ability to create and attach to TUN/TAP
> > devices.
...
> > diff --git a/policy/modules/apps/qemu.if b/policy/modules/apps/qemu.if
> > index d258f1d..ee7e214 100644
> > --- a/policy/modules/apps/qemu.if
> > +++ b/policy/modules/apps/qemu.if
> > @@ -149,6 +149,7 @@ template(`qemu_domain_template',`
> > allow $1_t self:shm create_shm_perms;
> > allow $1_t self:unix_stream_socket create_stream_socket_perms;
> > allow $1_t self:tcp_socket create_stream_socket_perms;
> > + allow $1_t self:tun_socket create;
> >
> > manage_dirs_pattern($1_t, $1_tmp_t, $1_tmp_t)
> > manage_files_pattern($1_t, $1_tmp_t, $1_tmp_t)
> > @@ -164,6 +165,8 @@ template(`qemu_domain_template',`
> > corenet_tcp_bind_generic_node($1_t)
> > corenet_tcp_bind_vnc_port($1_t)
> > corenet_rw_tun_tap_dev($1_t)
> > + virt_tun_attach($1_t)
> > + userdom_tun_attach($1_t)
>
> These should be moved to be with the other virt and userdom calls.
Fair enough.
> > diff --git a/policy/modules/apps/uml.te b/policy/modules/apps/uml.te
> > index 05e871c..902c226 100644
> > --- a/policy/modules/apps/uml.te
> > +++ b/policy/modules/apps/uml.te
> > @@ -60,6 +60,7 @@ allow uml_t self:unix_dgram_socket create_socket_perms;
> > # Use the network.
> > allow uml_t self:tcp_socket create_stream_socket_perms;
> > allow uml_t self:udp_socket create_socket_perms;
> > +allow uml_t self:tun_socket create;
> > # for mconsole
> > allow uml_t self:unix_dgram_socket sendto;
> >
> > @@ -111,6 +112,8 @@ corenet_udp_sendrecv_all_ports(uml_t)
> > corenet_tcp_connect_all_ports(uml_t)
> > corenet_sendrecv_all_client_packets(uml_t)
> > corenet_rw_tun_tap_dev(uml_t)
> > +virt_tun_attach(uml_t)
> > +userdom_tun_attach(uml_t)
>
> Same thing about moving these, as above.
Done.
> > diff --git a/policy/modules/system/userdomain.if
> > b/policy/modules/system/userdomain.if index 49ac3fd..22a952c 100644
> > --- a/policy/modules/system/userdomain.if
> > +++ b/policy/modules/system/userdomain.if
> > @@ -1042,6 +1042,7 @@ template(`userdom_unpriv_user_template', `
> > #
> > template(`userdom_admin_user_template',`
> > gen_require(`
> > + attribute admin_tun_type;
> > class passwd { passwd chfn chsh rootok };
> > ')
> >
> > @@ -1077,6 +1078,9 @@ template(`userdom_admin_user_template',`
> >
> > allow $1_t self:netlink_audit_socket nlmsg_readpriv;
> >
> > + allow $1_t self:tun_socket create;
> > + typeattribute $1_t admin_tun_type;
> > +
> > kernel_read_software_raid_state($1_t)
> > kernel_getattr_core_if($1_t)
> > kernel_getattr_message_if($1_t)
> > @@ -3027,3 +3031,22 @@ interface(`userdom_dbus_send_all_users',`
> >
> > allow $1 userdomain:dbus send_msg;
> > ')
> > +
> > +########################################
> > +## <summary>
> > +## Allow domain to attach to admin created TUN devices
> > +## </summary>
> > +## <param name="domain">
> > +## <summary>
> > +## Domain allowed access.
> > +## </summary>
> > +## </param>
> > +#
> > +interface(`userdom_tun_attach',`
> > + gen_require(`
> > + attribute admin_tun_type;
> > + ')
> > +
> > + allow $1 admin_tun_type:tun_socket relabelfrom;
> > + allow $1 self:tun_socket relabelto;
> > +')
>
> Why are only admin roles allowed to create tun_sockets? Either the
> interface name should be changed to reflect that its not all user
> domains, or it should be expanded to cover all user domains.
Considering the nature of TUN/TAP devices and the fact that you must have
CAP_NET_ADMIN to create a new device it seemed reasonable to restrict the
tun_socket/create permission to admin roles. However, we do want to allow
non-admin roles the ability to attach (tun_socket/relabel{from,to}
permissions) to existing persistent TUN/TAP devices - this is why the
interface above does not have "admin" anywhere in the name.
Does that make sense?
> > diff --git a/policy/modules/system/userdomain.te
> > b/policy/modules/system/userdomain.te index 48e9070..aff080b 100644
> > --- a/policy/modules/system/userdomain.te
> > +++ b/policy/modules/system/userdomain.te
> > @@ -58,6 +58,8 @@ attribute unpriv_userdomain;
> > attribute untrusted_content_type;
> > attribute untrusted_content_tmp_type;
> >
> > +attribute admin_tun_type;
> > +
> > type user_home_dir_t alias { staff_home_dir_t sysadm_home_dir_t
> > secadm_home_dir_t auditadm_home_dir_t unconfined_home_dir_t };
> > fs_associate_tmpfs(user_home_dir_t)
> > files_type(user_home_dir_t)
> > diff --git a/policy/modules/system/xen.te b/policy/modules/system/xen.te
> > index 40410a7..6c4b06d 100644
> > --- a/policy/modules/system/xen.te
> > +++ b/policy/modules/system/xen.te
> > @@ -88,6 +88,7 @@ allow xend_t self:unix_dgram_socket
> > create_socket_perms; allow xend_t self:netlink_route_socket
> > r_netlink_socket_perms;
> > allow xend_t self:tcp_socket create_stream_socket_perms;
> > allow xend_t self:packet_socket create_socket_perms;
> > +allow xend_t self:tun_socket create;
> >
> > allow xend_t xen_image_t:dir list_dir_perms;
> > manage_dirs_pattern(xend_t, xen_image_t, xen_image_t)
>
> No attach?
I'm not a Xen expert, but I assumed from discussions with some virtualization
folks that if you are running Xen then the xend_t domain would handle the
creation of any TUN/TAP devices it may need, hence no need to attach to an
existing TUN/TAP device created by another domain. Yes? No?
--
paul moore
linux @ hp
On Wed, 2009-08-26 at 10:32 -0400, Paul Moore wrote:
> On Wednesday 26 August 2009 08:49:14 am Christopher J. PeBenito wrote:
> > On Tue, 2009-08-25 at 17:12 -0400, Paul Moore wrote:
> > > Add policy for the new TUN driver access controls which allow policy to
> > > control which domains have the ability to create and attach to TUN/TAP
> > > devices.
> > > +########################################
> > > +## <summary>
> > > +## Allow domain to attach to admin created TUN devices
> > > +## </summary>
> > > +## <param name="domain">
> > > +## <summary>
> > > +## Domain allowed access.
> > > +## </summary>
> > > +## </param>
> > > +#
> > > +interface(`userdom_tun_attach',`
> > > + gen_require(`
> > > + attribute admin_tun_type;
> > > + ')
> > > +
> > > + allow $1 admin_tun_type:tun_socket relabelfrom;
> > > + allow $1 self:tun_socket relabelto;
> > > +')
> >
> > Why are only admin roles allowed to create tun_sockets? Either the
> > interface name should be changed to reflect that its not all user
> > domains, or it should be expanded to cover all user domains.
>
> Considering the nature of TUN/TAP devices and the fact that you must have
> CAP_NET_ADMIN to create a new device it seemed reasonable to restrict the
> tun_socket/create permission to admin roles. However, we do want to allow
> non-admin roles the ability to attach (tun_socket/relabel{from,to}
> permissions) to existing persistent TUN/TAP devices - this is why the
> interface above does not have "admin" anywhere in the name.
>
> Does that make sense?
I'm fine with only attaching to admin domains, but the interface name
needs to be changed. Its critical that the interface names are
consistent with the interface implementation. So if the implementation
is only for attaching to admin domains, the interface name has to
reflect that.
> > > diff --git a/policy/modules/system/xen.te b/policy/modules/system/xen.te
> > > index 40410a7..6c4b06d 100644
> > > --- a/policy/modules/system/xen.te
> > > +++ b/policy/modules/system/xen.te
> > > @@ -88,6 +88,7 @@ allow xend_t self:unix_dgram_socket
> > > create_socket_perms; allow xend_t self:netlink_route_socket
> > > r_netlink_socket_perms;
> > > allow xend_t self:tcp_socket create_stream_socket_perms;
> > > allow xend_t self:packet_socket create_socket_perms;
> > > +allow xend_t self:tun_socket create;
> > >
> > > allow xend_t xen_image_t:dir list_dir_perms;
> > > manage_dirs_pattern(xend_t, xen_image_t, xen_image_t)
> >
> > No attach?
>
> I'm not a Xen expert, but I assumed from discussions with some virtualization
> folks that if you are running Xen then the xend_t domain would handle the
> creation of any TUN/TAP devices it may need, hence no need to attach to an
> existing TUN/TAP device created by another domain. Yes? No?
I'd rather wait on adding this rule until we can get confirmation on if
its needed.
--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150
On Thursday 27 August 2009 09:54:28 am Christopher J. PeBenito wrote:
> On Wed, 2009-08-26 at 10:32 -0400, Paul Moore wrote:
> > On Wednesday 26 August 2009 08:49:14 am Christopher J. PeBenito wrote:
> > > On Tue, 2009-08-25 at 17:12 -0400, Paul Moore wrote:
> > > > Add policy for the new TUN driver access controls which allow policy
> > > > to control which domains have the ability to create and attach to
> > > > TUN/TAP devices.
> > > >
> > > > +########################################
> > > > +## <summary>
> > > > +## Allow domain to attach to admin created TUN devices
> > > > +## </summary>
> > > > +## <param name="domain">
> > > > +## <summary>
> > > > +## Domain allowed access.
> > > > +## </summary>
> > > > +## </param>
> > > > +#
> > > > +interface(`userdom_tun_attach',`
> > > > + gen_require(`
> > > > + attribute admin_tun_type;
> > > > + ')
> > > > +
> > > > + allow $1 admin_tun_type:tun_socket relabelfrom;
> > > > + allow $1 self:tun_socket relabelto;
> > > > +')
> > >
> > > Why are only admin roles allowed to create tun_sockets? Either the
> > > interface name should be changed to reflect that its not all user
> > > domains, or it should be expanded to cover all user domains.
> >
> > Considering the nature of TUN/TAP devices and the fact that you must have
> > CAP_NET_ADMIN to create a new device it seemed reasonable to restrict the
> > tun_socket/create permission to admin roles. However, we do want to
> > allow non-admin roles the ability to attach (tun_socket/relabel{from,to}
> > permissions) to existing persistent TUN/TAP devices - this is why the
> > interface above does not have "admin" anywhere in the name.
> >
> > Does that make sense?
>
> I'm fine with only attaching to admin domains, but the interface name
> needs to be changed. Its critical that the interface names are
> consistent with the interface implementation. So if the implementation
> is only for attaching to admin domains, the interface name has to
> reflect that.
Okay, I thought the interface name was consistent based on the other
userdomain.if interfaces but I'm obviously missing something :) How about
"admin_tun_attach"? If that isn't right I would appreciate a suggestion ...
> > > > diff --git a/policy/modules/system/xen.te
> > > > b/policy/modules/system/xen.te index 40410a7..6c4b06d 100644
> > > > --- a/policy/modules/system/xen.te
> > > > +++ b/policy/modules/system/xen.te
> > > > @@ -88,6 +88,7 @@ allow xend_t self:unix_dgram_socket
> > > > create_socket_perms; allow xend_t self:netlink_route_socket
> > > > r_netlink_socket_perms;
> > > > allow xend_t self:tcp_socket create_stream_socket_perms;
> > > > allow xend_t self:packet_socket create_socket_perms;
> > > > +allow xend_t self:tun_socket create;
> > > >
> > > > allow xend_t xen_image_t:dir list_dir_perms;
> > > > manage_dirs_pattern(xend_t, xen_image_t, xen_image_t)
> > >
> > > No attach?
> >
> > I'm not a Xen expert, but I assumed from discussions with some
> > virtualization folks that if you are running Xen then the xend_t domain
> > would handle the creation of any TUN/TAP devices it may need, hence no
> > need to attach to an existing TUN/TAP device created by another domain.
> > Yes? No?
>
> I'd rather wait on adding this rule until we can get confirmation on if
> its needed.
Yep, that is why I didn't add the code for attaching, just creation - or are
you talking about removing the creation rule too?
--
paul moore
linux @ hp
On Thu, 2009-08-27 at 10:08 -0400, Paul Moore wrote:
> On Thursday 27 August 2009 09:54:28 am Christopher J. PeBenito wrote:
> > On Wed, 2009-08-26 at 10:32 -0400, Paul Moore wrote:
> > > On Wednesday 26 August 2009 08:49:14 am Christopher J. PeBenito wrote:
> > > > On Tue, 2009-08-25 at 17:12 -0400, Paul Moore wrote:
> > > > > Add policy for the new TUN driver access controls which allow policy
> > > > > to control which domains have the ability to create and attach to
> > > > > TUN/TAP devices.
> > > > >
> > > > > +########################################
> > > > > +## <summary>
> > > > > +## Allow domain to attach to admin created TUN devices
> > > > > +## </summary>
> > > > > +## <param name="domain">
> > > > > +## <summary>
> > > > > +## Domain allowed access.
> > > > > +## </summary>
> > > > > +## </param>
> > > > > +#
> > > > > +interface(`userdom_tun_attach',`
> > > > > + gen_require(`
> > > > > + attribute admin_tun_type;
> > > > > + ')
> > > > > +
> > > > > + allow $1 admin_tun_type:tun_socket relabelfrom;
> > > > > + allow $1 self:tun_socket relabelto;
> > > > > +')
> > > >
> > > > Why are only admin roles allowed to create tun_sockets? Either the
> > > > interface name should be changed to reflect that its not all user
> > > > domains, or it should be expanded to cover all user domains.
> > >
> > > Considering the nature of TUN/TAP devices and the fact that you must have
> > > CAP_NET_ADMIN to create a new device it seemed reasonable to restrict the
> > > tun_socket/create permission to admin roles. However, we do want to
> > > allow non-admin roles the ability to attach (tun_socket/relabel{from,to}
> > > permissions) to existing persistent TUN/TAP devices - this is why the
> > > interface above does not have "admin" anywhere in the name.
> > >
> > > Does that make sense?
> >
> > I'm fine with only attaching to admin domains, but the interface name
> > needs to be changed. Its critical that the interface names are
> > consistent with the interface implementation. So if the implementation
> > is only for attaching to admin domains, the interface name has to
> > reflect that.
>
> Okay, I thought the interface name was consistent based on the other
> userdomain.if interfaces but I'm obviously missing something :) How about
> "admin_tun_attach"? If that isn't right I would appreciate a suggestion ...
userdom_attach_admin_tun_sockets()
At first I wasn't going to add sockets at the end, but
"userdom_attach_admin_tuns()" didn't sound right to me. The virt
interface should be similarly changed: virt_attach_tun_sockets()
> > > > > diff --git a/policy/modules/system/xen.te
> > > > > b/policy/modules/system/xen.te index 40410a7..6c4b06d 100644
> > > > > --- a/policy/modules/system/xen.te
> > > > > +++ b/policy/modules/system/xen.te
> > > > > @@ -88,6 +88,7 @@ allow xend_t self:unix_dgram_socket
> > > > > create_socket_perms; allow xend_t self:netlink_route_socket
> > > > > r_netlink_socket_perms;
> > > > > allow xend_t self:tcp_socket create_stream_socket_perms;
> > > > > allow xend_t self:packet_socket create_socket_perms;
> > > > > +allow xend_t self:tun_socket create;
> > > > >
> > > > > allow xend_t xen_image_t:dir list_dir_perms;
> > > > > manage_dirs_pattern(xend_t, xen_image_t, xen_image_t)
> > > >
> > > > No attach?
> > >
> > > I'm not a Xen expert, but I assumed from discussions with some
> > > virtualization folks that if you are running Xen then the xend_t domain
> > > would handle the creation of any TUN/TAP devices it may need, hence no
> > > need to attach to an existing TUN/TAP device created by another domain.
> > > Yes? No?
> >
> > I'd rather wait on adding this rule until we can get confirmation on if
> > its needed.
>
> Yep, that is why I didn't add the code for attaching, just creation - or are
> you talking about removing the creation rule too?
Oh I got a little confused. If the create is certain, then it can stay.
The attach can be omitted until we get confirmation if its needed.
--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150
On Friday 28 August 2009 08:33:23 am Christopher J. PeBenito wrote:
> On Thu, 2009-08-27 at 10:08 -0400, Paul Moore wrote:
> > On Thursday 27 August 2009 09:54:28 am Christopher J. PeBenito wrote:
> > > On Wed, 2009-08-26 at 10:32 -0400, Paul Moore wrote:
> > > > On Wednesday 26 August 2009 08:49:14 am Christopher J. PeBenito wrote:
> > > > > On Tue, 2009-08-25 at 17:12 -0400, Paul Moore wrote:
> > > > > > Add policy for the new TUN driver access controls which allow
> > > > > > policy to control which domains have the ability to create and
> > > > > > attach to TUN/TAP devices.
> > > > > >
> > > > > > +########################################
> > > > > > +## <summary>
> > > > > > +## Allow domain to attach to admin created TUN devices
> > > > > > +## </summary>
> > > > > > +## <param name="domain">
> > > > > > +## <summary>
> > > > > > +## Domain allowed access.
> > > > > > +## </summary>
> > > > > > +## </param>
> > > > > > +#
> > > > > > +interface(`userdom_tun_attach',`
> > > > > > + gen_require(`
> > > > > > + attribute admin_tun_type;
> > > > > > + ')
> > > > > > +
> > > > > > + allow $1 admin_tun_type:tun_socket relabelfrom;
> > > > > > + allow $1 self:tun_socket relabelto;
> > > > > > +')
> > > > >
> > > > > Why are only admin roles allowed to create tun_sockets? Either the
> > > > > interface name should be changed to reflect that its not all user
> > > > > domains, or it should be expanded to cover all user domains.
> > > >
> > > > Considering the nature of TUN/TAP devices and the fact that you must
> > > > have CAP_NET_ADMIN to create a new device it seemed reasonable to
> > > > restrict the tun_socket/create permission to admin roles. However,
> > > > we do want to allow non-admin roles the ability to attach
> > > > (tun_socket/relabel{from,to} permissions) to existing persistent
> > > > TUN/TAP devices - this is why the interface above does not have
> > > > "admin" anywhere in the name.
> > > >
> > > > Does that make sense?
> > >
> > > I'm fine with only attaching to admin domains, but the interface name
> > > needs to be changed. Its critical that the interface names are
> > > consistent with the interface implementation. So if the implementation
> > > is only for attaching to admin domains, the interface name has to
> > > reflect that.
> >
> > Okay, I thought the interface name was consistent based on the other
> > userdomain.if interfaces but I'm obviously missing something :) How
> > about "admin_tun_attach"? If that isn't right I would appreciate a
> > suggestion ...
>
> userdom_attach_admin_tun_sockets()
>
> At first I wasn't going to add sockets at the end, but
> "userdom_attach_admin_tuns()" didn't sound right to me. The virt
> interface should be similarly changed: virt_attach_tun_sockets()
Okay. I agree "*_admin_tuns()" sounds a little weird but sockets seems not
quite right to me - how about "*_attach_admin_tun_iface()"?
> > > > > > diff --git a/policy/modules/system/xen.te
> > > > > > b/policy/modules/system/xen.te index 40410a7..6c4b06d 100644
> > > > > > --- a/policy/modules/system/xen.te
> > > > > > +++ b/policy/modules/system/xen.te
> > > > > > @@ -88,6 +88,7 @@ allow xend_t self:unix_dgram_socket
> > > > > > create_socket_perms; allow xend_t self:netlink_route_socket
> > > > > > r_netlink_socket_perms;
> > > > > > allow xend_t self:tcp_socket create_stream_socket_perms;
> > > > > > allow xend_t self:packet_socket create_socket_perms;
> > > > > > +allow xend_t self:tun_socket create;
> > > > > >
> > > > > > allow xend_t xen_image_t:dir list_dir_perms;
> > > > > > manage_dirs_pattern(xend_t, xen_image_t, xen_image_t)
> > > > >
> > > > > No attach?
> > > >
> > > > I'm not a Xen expert, but I assumed from discussions with some
> > > > virtualization folks that if you are running Xen then the xend_t
> > > > domain would handle the creation of any TUN/TAP devices it may need,
> > > > hence no need to attach to an existing TUN/TAP device created by
> > > > another domain. Yes? No?
> > >
> > > I'd rather wait on adding this rule until we can get confirmation on if
> > > its needed.
> >
> > Yep, that is why I didn't add the code for attaching, just creation - or
> > are you talking about removing the creation rule too?
>
> Oh I got a little confused. If the create is certain, then it can stay.
> The attach can be omitted until we get confirmation if its needed.
Okay. FWIW, I'm not 100% certain about the create as I don't have working Xen
system to test, I've included it based on discussions I've had.
--
paul moore
linux @ hp
On Fri, 2009-08-28 at 10:48 -0400, Paul Moore wrote:
> On Friday 28 August 2009 08:33:23 am Christopher J. PeBenito wrote:
> > On Thu, 2009-08-27 at 10:08 -0400, Paul Moore wrote:
> > > On Thursday 27 August 2009 09:54:28 am Christopher J. PeBenito wrote:
> > > > On Wed, 2009-08-26 at 10:32 -0400, Paul Moore wrote:
> > > > > On Wednesday 26 August 2009 08:49:14 am Christopher J. PeBenito wrote:
> > > > > > On Tue, 2009-08-25 at 17:12 -0400, Paul Moore wrote:
> > > > > > > Add policy for the new TUN driver access controls which allow
> > > > > > > policy to control which domains have the ability to create and
> > > > > > > attach to TUN/TAP devices.
[...]
> > > > > > > +interface(`userdom_tun_attach',`
[...]
> > > Okay, I thought the interface name was consistent based on the other
> > > userdomain.if interfaces but I'm obviously missing something :) How
> > > about "admin_tun_attach"? If that isn't right I would appreciate a
> > > suggestion ...
> >
> > userdom_attach_admin_tun_sockets()
> >
> > At first I wasn't going to add sockets at the end, but
> > "userdom_attach_admin_tuns()" didn't sound right to me. The virt
> > interface should be similarly changed: virt_attach_tun_sockets()
>
> Okay. I agree "*_admin_tuns()" sounds a little weird but sockets seems not
> quite right to me - how about "*_attach_admin_tun_iface()"?
I think I can go with that.
> > > > > > > +allow xend_t self:tun_socket create;
> > > > > I'm not a Xen expert, but I assumed from discussions with some
> > > > > virtualization folks that if you are running Xen then the xend_t
> > > > > domain would handle the creation of any TUN/TAP devices it may need,
> > > > > hence no need to attach to an existing TUN/TAP device created by
> > > > > another domain. Yes? No?
> > > >
> > > > I'd rather wait on adding this rule until we can get confirmation on if
> > > > its needed.
> > >
> > > Yep, that is why I didn't add the code for attaching, just creation - or
> > > are you talking about removing the creation rule too?
> >
> > Oh I got a little confused. If the create is certain, then it can stay.
> > The attach can be omitted until we get confirmation if its needed.
>
> Okay. FWIW, I'm not 100% certain about the create as I don't have working Xen
> system to test, I've included it based on discussions I've had.
Then in that case, I'd prefer to keep it all out for now, only because
its easier to add rules than to remove them.
--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150