Add links_t domain for the links browser

This patchset adds support for the links browser.

Changes since v1:
- coding style updates
- use proper userdom_user_* interfaces
- bring user file management into a tunable (links_manage_user_files)
- drop alias creation

Wkr,
Sven Vermeulen

Introduce the links_t domain for the links browser, which is an ncurses/svgalib/X11 browser (so supports both commandline-only as well as GUI environments)

---
 links.fc |    6 +++++
 links.if |   36 +++++++++++++++++++++++++++++++++++
 links.te |   63 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 105 insertions(+), 0 deletions(-)
 create mode 100644 links.fc
 create mode 100644 links.if
 create mode 100644 links.te

new file mode 100644
index 0000000..5749b58
@@ -0,0 +1,6 @@
+HOME_DIR/\.links(/.*)?    gen_context(system_u:object_r:links_home_t,s0)
+
+# 
+# /usr
+#
+/usr/bin/links         -- gen_context(system_u:object_r:links_exec_t,s0)

new file mode 100644
index 0000000..bf3e20a
@@ -0,0 +1,36 @@
+## <summary>Links web browser</summary>
+
+#######################################
+## <summary>
+##      The role interface for the links module.
+## </summary>
+## <param name="user_role">
+##      <summary>
+##      The role associated with the user domain.
+##      </summary>
+## </param>
+## <param name="user_domain">
+##      <summary>
+##      The type of the user domain.
+##      </summary>
+## </param>
+#
+interface(`links_role',`
+	gen_require(`
+		type links_t, links_exec_t, links_tmpfs_t, links_home_t;
+	')
+
+	role $1 types links_t;
+
+	manage_dirs_pattern($2, links_home_t, links_home_t)
+	manage_files_pattern($2, links_home_t, links_home_t)
+	manage_lnk_files_pattern($2, links_home_t, links_home_t)
+
+	relabel_dirs_pattern($2, links_home_t, links_home_t)
+	relabel_files_pattern($2, links_home_t, links_home_t)
+	relabel_lnk_files_pattern($2, links_home_t, links_home_t)
+
+	domtrans_pattern($2, links_exec_t, links_t)
+
+	ps_process_pattern($2, links_t)
+')	

1.7.3.4

Why do we need separate domains for links and other browsers?

My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

When do you consider the need for separate domains and not? An earlier discussion on nginx versus apache was in the direction of a separate domain for nginx because it did some stuff that apache couldn't.

Likewise, I can argue that the mozilla module does more than links, so why use a much more elaborate policy for a small application?

Wkr,
Sven Vermeulen

Most of the stuff that Apache and Nginx do are the same. Having separate policy will lead to more duplication of work. If we want to protect web servers from each other then I think we should do what we did ages ago with SSH and have a template for the base functionality that is instantiated for each one.

Given that links is described as using an X display the amount of extra functionality can't be that great.

My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

I can surely follow this. It would be great to have a template that "upgrades" a domain towards being a browser-domain (i.e. user input, http(s) access, ...) so that individual browsers can quickly be contained within their own domain.

But that would probably mean that we define a "browser" module, and then have links & mozilla work from that module.

I was referring to mozilla, which has a lot more privileges than links would ever need (including plugin subdomains and such). However, links is also used as a console browser, something that mozilla's browser would never need.

Using a browser template in general would fix things to support the bare minimum, but it would still give a separate domain for links imo.

I know this is often a matter of convenience and maintainability: where do you put the line? You can have a generic domain for multiple applications (like the games module), a one-on-one mapping (like for jabber) or multiple domains for one application (like postfix).

I personally aim to have at least one domain per application, and where an application has multiple different processes, use different domains for those as well. But that does mean quite a lot of maintenance/management on the policies. But if that can be simplified by having the appropriate templates, that would be great.

Wkr,
Sven Vermeulen

Grant the links_role to the default user domains (staff, sysadm and the regular user).

---
 policy/modules/roles/staff.te      |    4 ++++
 policy/modules/roles/sysadm.te     |    4 ++++
 policy/modules/roles/unprivuser.te |    4 ++++
 3 files changed, 12 insertions(+), 0 deletions(-)

index c10c3d6..ae4a59a 100644
@@ -109,6 +109,10 @@ ifndef(`distro_redhat',`
 	')
 
 	optional_policy(`
+		links_role(staff_r, staff_t)
+	')
+
+	optional_policy(`
 		lockdev_role(staff_r, staff_t)
 	')
 

index 954417f..200e490 100644
@@ -461,5 +461,9 @@ ifndef(`distro_redhat',`
 	optional_policy(`
 		java_role(sysadm_r, sysadm_t)
 	')
+
+	optional_policy(`
+		links_role(sysadm_r, sysadm_t)
+	')
 ')
 

index c576b6c..074155f 100644
@@ -86,6 +86,10 @@ ifndef(`distro_redhat',`
 	')
 
 	optional_policy(`
+		links_role(user_r, user_t)
+	')
+
+	optional_policy(`
 		lockdev_role(user_r, user_t)
 	')
 

1.7.3.4