Policy support for the new TUN hooks

RFC PATCH In review Paul Moore 2 participants 10 messages Aug 25, 2009 – Aug 28, 2009 SELinux security module

Share & tools

Paul Moore

author

2009-08-25 21:12 UTC #0 lore raw

cover Policy support for the new TUN hooks

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(-)

Paul Moore

author

2009-08-25 21:12 UTC #1 lore raw

RFC PATCH 1/2 refpol: Add the "tun_socket" object class flask definitions

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(-)

policy/flask/access_vectors +2 -0

index ef4c063..6292db5 100644
@@ -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

policy/flask/security_classes +2 -0

index 9e1bf1a..2bd1bf6 100644
@@ -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

Paul Moore

author

2009-08-25 21:12 UTC #2 lore raw

RFC PATCH 2/2 refpol: Policy for the new TUN driver access controls

In reply to Paul Moore

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(-)

policy/modules/admin/vpn.te +1 -0

index 11c2dcc..52cf380 100644
@@ -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;

policy/modules/apps/qemu.if +3 -0

index d258f1d..ee7e214 100644
@@ -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)

policy/modules/apps/uml.te +3 -0

index 05e871c..902c226 100644
@@ -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)

policy/modules/services/openvpn.te +1 -0

index a4e2db2..99149f0 100644
@@ -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)

policy/modules/services/virt.if +19 -0

index 8dc8acf..77c3651 100644
@@ -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;
+')

policy/modules/services/virt.te +1 -0

index b2fd700..a51755e 100644
@@ -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)

policy/modules/system/userdomain.if +23 -0

index 49ac3fd..22a952c 100644
@@ -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;
+')

policy/modules/system/userdomain.te +2 -0

index 48e9070..aff080b 100644
@@ -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)

policy/modules/system/xen.te +1 -0

index 40410a7..6c4b06d 100644
@@ -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)

Christopher J. PeBenito

2009-08-26 12:49 UTC #3 lore raw

Re: [refpolicy] [RFC PATCH v1 2/2] refpol: Policy for the new TUN driver access controls

Quoted 4 lines · Paul Moore

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.

Quoted 48 lines

  # 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(-)

policy/modules/admin/vpn.te +1 -0

index 11c2dcc..52cf380 100644
@@ -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;

policy/modules/apps/qemu.if +1 -0

index d258f1d..ee7e214 100644
@@ -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)

policy/modules/apps/qemu.if template(`qemu_domain_template',` · line 169

Quoted 5 lines

policy/modules/apps/qemu.if +2 -0

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

Quoted 15 lines

policy/modules/apps/qemu.if +0 -0

 #	dev_rw_kvm($1_t)

policy/modules/apps/uml.te +1 -0

index 05e871c..902c226 100644
@@ -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;

policy/modules/apps/uml.te corenet_udp_sendrecv_all_ports(uml_t) · line 116

Quoted 5 lines

policy/modules/apps/uml.te +2 -0

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

Quoted 88 lines

policy/modules/apps/uml.te +0 -0

 domain_use_interactive_fds(uml_t)

policy/modules/services/openvpn.te +1 -0

index a4e2db2..99149f0 100644
@@ -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)

policy/modules/services/virt.if +19 -0

index 8dc8acf..77c3651 100644
@@ -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;
+')

policy/modules/services/virt.te +1 -0

index b2fd700..a51755e 100644
@@ -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)

policy/modules/system/userdomain.if +13 -0

index 49ac3fd..22a952c 100644
@@ -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>

policy/modules/system/userdomain.if interface(`userdom_dbus_send_all_users',` · line 3052

Quoted 10 lines

policy/modules/system/userdomain.if +10 -0

+## </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.

Quoted 18 lines

policy/modules/system/userdomain.te +2 -0

index 48e9070..aff080b 100644
@@ -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)

policy/modules/system/xen.te +0 -0

index 40410a7..6c4b06d 100644

policy/modules/system/xen.te allow xend_t self:unix_dgram_socket create_socket_perms; · line 94

Quoted 7 lines

policy/modules/system/xen.te +1 -0

@@ -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?

Signature · 3 lines

Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150

Paul Moore

author

2009-08-26 14:32 UTC #4 lore raw

Re: [refpolicy] [RFC PATCH v1 2/2] refpol: Policy for the new TUN driver access controls

Quoted 4 lines · Christopher J. PeBenito

Quoted 3 lines · Paul Moore
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.

...

Quoted 10 lines

policy/modules/apps/qemu.if +1 -0

index d258f1d..ee7e214 100644
@@ -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;

Quoted 10 lines

policy/modules/apps/qemu.if template(`qemu_domain_template',` · line 169
Quoted 8 lines
policy/modules/apps/qemu.if +2 -0
 	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.

Quoted 12 lines

policy/modules/apps/uml.te +1 -0

index 05e871c..902c226 100644
@@ -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;

Quoted 8 lines

policy/modules/apps/uml.te corenet_udp_sendrecv_all_ports(uml_t) · line 116
Quoted 6 lines
policy/modules/apps/uml.te +2 -0
@@ -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.

Quoted 41 lines

(quoted diff) +0 -0

b/policy/modules/system/userdomain.if index 49ac3fd..22a952c 100644

policy/modules/system/userdomain.if +19 -0

@@ -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;
+	')

Quoted 8 lines

policy/modules/system/userdomain.if interface(`userdom_dbus_send_all_users',` · line 3052
Quoted 4 lines
policy/modules/system/userdomain.if +4 -0
+
+	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?

Quoted 25 lines

Quoted 25 lines
(quoted diff) +0 -0
b/policy/modules/system/userdomain.te index 48e9070..aff080b 100644
policy/modules/system/userdomain.te +2 -0
@@ -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)
policy/modules/system/xen.te +0 -0
index 40410a7..6c4b06d 100644
@@ -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;

Quoted 4 lines

Quoted 2 lines
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?

Signature · 2 lines

paul moore
linux @ hp

Christopher J. PeBenito

2009-08-27 13:54 UTC #5 lore raw

Re: [refpolicy] [RFC PATCH v1 2/2] refpol: Policy for the new TUN driver access controls

Quoted 29 lines · Paul Moore

Quoted 19 lines · Christopher J. PeBenito
Quoted 18 lines · Paul Moore
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.
policy/modules/system/userdomain.if +14 -0
+########################################
+## <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;
+	')
Quoted 8 lines
policy/modules/system/userdomain.if interface(`userdom_dbus_send_all_users',` · line 3052
Quoted 4 lines
policy/modules/system/userdomain.if +4 -0
+
+	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.

Quoted 8 lines

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.

Quoted 16 lines

Quoted 11 lines
Quoted 11 lines
policy/modules/system/xen.te +0 -0
index 40410a7..6c4b06d 100644
@@ -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;
Quoted 4 lines
Quoted 2 lines
allow xend_t xen_image_t:dir list_dir_perms; manage_dirs_pattern(xend_t, xen_image_t, xen_image_t)
No attach?

Quoted 4 lines

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.

Signature · 3 lines

Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150

Paul Moore

author

2009-08-27 14:08 UTC #6 lore raw

Re: [refpolicy] [RFC PATCH v1 2/2] refpol: Policy for the new TUN driver access controls

Quoted 37 lines · Christopher J. PeBenito

Quoted 36 lines · Paul Moore
Quoted 19 lines · Christopher J. PeBenito
Quoted 18 lines · Paul Moore
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.
policy/modules/system/userdomain.if +14 -0
+########################################
+## <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;
+	')
Quoted 8 lines
policy/modules/system/userdomain.if interface(`userdom_dbus_send_all_users',` · line 3052
Quoted 4 lines
policy/modules/system/userdomain.if +4 -0
+
+	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.

Quoted 7 lines

Quoted 1 line
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 ...

Quoted 16 lines

Quoted 16 lines
Quoted 15 lines
Quoted 11 lines
(quoted diff) +0 -0
b/policy/modules/system/xen.te index 40410a7..6c4b06d 100644
policy/modules/system/xen.te +0 -0
@@ -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;
Quoted 2 lines
allow xend_t xen_image_t:dir list_dir_perms; manage_dirs_pattern(xend_t, xen_image_t, xen_image_t)
No attach?

Quoted 8 lines

Quoted 5 lines
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?

Signature · 2 lines

paul moore
linux @ hp

Christopher J. PeBenito

2009-08-28 12:33 UTC #7 lore raw

Re: [refpolicy] [RFC PATCH v1 2/2] refpol: Policy for the new TUN driver access controls

Quoted 46 lines · Paul Moore

Quoted 37 lines · Christopher J. PeBenito
Quoted 36 lines · Paul Moore
Quoted 19 lines · Christopher J. PeBenito
Quoted 18 lines · Paul Moore
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.
policy/modules/system/userdomain.if +14 -0
+########################################
+## <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;
+	')
Quoted 8 lines
policy/modules/system/userdomain.if interface(`userdom_dbus_send_all_users',` · line 3052
Quoted 4 lines
policy/modules/system/userdomain.if +4 -0
+
+	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.
Quoted 7 lines
Quoted 1 line
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.

Quoted 3 lines

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()

Quoted 22 lines

Quoted 22 lines
Quoted 21 lines
Quoted 11 lines
Quoted 11 lines
(quoted diff) +0 -0
b/policy/modules/system/xen.te index 40410a7..6c4b06d 100644
policy/modules/system/xen.te +0 -0
@@ -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;
Quoted 4 lines
Quoted 2 lines
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?

Quoted 5 lines

Quoted 2 lines
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.

Signature · 3 lines

Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150

Paul Moore

author

2009-08-28 14:48 UTC #8 lore raw

Re: [refpolicy] [RFC PATCH v1 2/2] refpol: Policy for the new TUN driver access controls

Quoted 53 lines · Christopher J. PeBenito

Quoted 47 lines · Paul Moore
Quoted 38 lines · Christopher J. PeBenito
Quoted 37 lines · Paul Moore
Quoted 19 lines · Christopher J. PeBenito
Quoted 18 lines · Paul Moore
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.
policy/modules/system/userdomain.if +14 -0
+########################################
+## <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;
+	')
Quoted 8 lines
policy/modules/system/userdomain.if interface(`userdom_dbus_send_all_users',` · line 3052
Quoted 4 lines
policy/modules/system/userdomain.if +4 -0
+
+	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.
Quoted 7 lines
Quoted 1 line
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.
Quoted 4 lines
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 ...

Quoted 5 lines

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()"?

Quoted 22 lines

Quoted 22 lines
Quoted 22 lines
Quoted 21 lines
Quoted 11 lines
Quoted 11 lines
(quoted diff) +0 -0
b/policy/modules/system/xen.te index 40410a7..6c4b06d 100644
policy/modules/system/xen.te +0 -0
@@ -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;
Quoted 4 lines
Quoted 2 lines
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?

Quoted 8 lines

Quoted 5 lines
Quoted 2 lines
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.

Signature · 2 lines

paul moore
linux @ hp

Christopher J. PeBenito

2009-08-28 15:49 UTC #9 lore raw

Re: [refpolicy] [RFC PATCH v1 2/2] refpol: Policy for the new TUN driver access controls

Quoted 9 lines · Paul Moore

Quoted 8 lines · Christopher J. PeBenito
Quoted 7 lines · Paul Moore
Quoted 6 lines · Christopher J. PeBenito
Quoted 5 lines · Paul Moore
Quoted 4 lines · Christopher J. PeBenito
Quoted 3 lines · Paul Moore
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.

[...]

Quoted 1 line

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
+interface(userdom_tun_attach',

[...]

Quoted 5 lines

Quoted 5 lines
Quoted 4 lines
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 ...

Quoted 8 lines

Quoted 5 lines
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.

Quoted 11 lines

Quoted 11 lines
Quoted 11 lines
Quoted 10 lines
Quoted 7 lines
Quoted 1 line
Quoted 1 line
+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.

Quoted 8 lines

Quoted 5 lines
Quoted 2 lines
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.

Signature · 3 lines

Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150