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)
Signed-off-by: Sven Vermeulen <[email protected]>
---
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
diff --git a/links.fc b/links.fc
new file mode 100644
index 0000000..5749b58
--- /dev/null
+++ b/links.fc
@@ -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)
diff --git a/links.if b/links.if
new file mode 100644
index 0000000..bf3e20a
--- /dev/null
+++ b/links.if
@@ -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)
+')
diff --git a/links.te b/links.te
new file mode 100644
index 0000000..7c9d03f
--- /dev/null
+++ b/links.te
@@ -0,0 +1,63 @@
+policy_module(links, 1.0.0)
+
+############################
+#
+# Declarations
+#
+
+## <desc>
+## <p>
+## Allow links to manage files in users home directories (download files)
+## </p>
+## </desc>
+gen_tunable(links_manage_user_files, false)
+
+type links_t;
+type links_exec_t;
+userdom_user_application_domain(links_t, links_exec_t)
+
+type links_home_t;
+userdom_user_home_content(links_home_t)
+
+type links_tmpfs_t;
+userdom_user_tmpfs_file(links_tmpfs_t)
+
+############################
+#
+# Policy
+#
+
+allow links_t self:process signal_perms;
+allow links_t self:unix_stream_socket create_stream_socket_perms;
+
+manage_dirs_pattern(links_t, links_home_t, links_home_t)
+manage_files_pattern(links_t, links_home_t, links_home_t)
+manage_lnk_files_pattern(links_t, links_home_t, links_home_t)
+manage_sock_files_pattern(links_t, links_home_t, links_home_t)
+manage_fifo_files_pattern(links_t, links_home_t, links_home_t)
+userdom_user_home_dir_filetrans(links_t, links_home_t, dir)
+
+manage_files_pattern(links_t, links_tmpfs_t, links_tmpfs_t)
+manage_lnk_files_pattern(links_t, links_tmpfs_t, links_tmpfs_t)
+manage_fifo_files_pattern(links_t, links_tmpfs_t, links_tmpfs_t)
+manage_sock_files_pattern(links_t, links_tmpfs_t, links_tmpfs_t)
+fs_tmpfs_filetrans(links_t, links_tmpfs_t, { file lnk_file sock_file fifo_file })
+
+corenet_tcp_connect_http_port(links_t)
+
+domain_use_interactive_fds(links_t)
+
+auth_use_nsswitch(links_t)
+
+miscfiles_read_localization(links_t)
+
+userdom_use_user_terminals(links_t)
+
+tunable_policy(`links_manage_user_files',`
+ userdom_manage_user_home_content_dirs(links_t)
+ userdom_manage_user_home_content_files(links_t)
+')
+
+optional_policy(`
+ xserver_user_x_domain_template(links, links_t, links_tmpfs_t)
+')
--
1.7.3.4
Grant the links_role to the default user domains (staff, sysadm and the
regular user).
Signed-off-by: Sven Vermeulen <[email protected]>
---
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(-)
diff --git a/policy/modules/roles/staff.te b/policy/modules/roles/staff.te
index c10c3d6..ae4a59a 100644
--- a/policy/modules/roles/staff.te
+++ b/policy/modules/roles/staff.te
@@ -109,6 +109,10 @@ ifndef(`distro_redhat',`
')
optional_policy(`
+ links_role(staff_r, staff_t)
+ ')
+
+ optional_policy(`
lockdev_role(staff_r, staff_t)
')
diff --git a/policy/modules/roles/sysadm.te b/policy/modules/roles/sysadm.te
index 954417f..200e490 100644
--- a/policy/modules/roles/sysadm.te
+++ b/policy/modules/roles/sysadm.te
@@ -461,5 +461,9 @@ ifndef(`distro_redhat',`
optional_policy(`
java_role(sysadm_r, sysadm_t)
')
+
+ optional_policy(`
+ links_role(sysadm_r, sysadm_t)
+ ')
')
diff --git a/policy/modules/roles/unprivuser.te b/policy/modules/roles/unprivuser.te
index c576b6c..074155f 100644
--- a/policy/modules/roles/unprivuser.te
+++ b/policy/modules/roles/unprivuser.te
@@ -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
On Sun, 13 Nov 2011, Sven Vermeulen <[email protected]> wrote:
> 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)
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/
On Sun, Nov 13, 2011 at 09:12:57PM +1100, Russell Coker wrote:
> Why do we need separate domains for links and other browsers?
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
On Sun, 13 Nov 2011, Sven Vermeulen <[email protected]> wrote:
> On Sun, Nov 13, 2011 at 09:12:57PM +1100, Russell Coker wrote:
> > Why do we need separate domains for links and other browsers?
>
> 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.
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.
> Likewise, I can argue that the mozilla module does more than links, so why
> use a much more elaborate policy for a small application?
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/
On Sun, Nov 13, 2011 at 10:48:50PM +1100, Russell Coker wrote:
> > 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.
>
> 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.
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.
> > Likewise, I can argue that the mozilla module does more than links, so why
> > use a much more elaborate policy for a small application?
>
> Given that links is described as using an X display the amount of extra
> functionality can't be that great.
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