The skype application is a popular voice and video chat application.
This patch adds preliminary support for skype on SELinux.
This is currently a "one patch" offer, so I'd like to know if it is okay
when adding new applications to refpolicy like this to use a single patch
(as long as it isn't too complicated)?
Also a quick review on the policy wouldn't hurt ;-) Feedback always
appreciated.
Signed-off-by: Sven Vermeulen <[email protected]>
---
policy/modules/apps/skype.fc | 3 +
policy/modules/apps/skype.if | 51 ++++++++++++++++++
policy/modules/apps/skype.te | 99 ++++++++++++++++++++++++++++++++++++
policy/modules/roles/staff.te | 4 ++
policy/modules/roles/sysadm.te | 4 ++
policy/modules/roles/unprivuser.te | 4 ++
6 files changed, 165 insertions(+), 0 deletions(-)
create mode 100644 policy/modules/apps/skype.fc
create mode 100644 policy/modules/apps/skype.if
create mode 100644 policy/modules/apps/skype.te
diff --git a/policy/modules/apps/skype.fc b/policy/modules/apps/skype.fc
new file mode 100644
index 0000000..a802960
--- /dev/null
+++ b/policy/modules/apps/skype.fc
@@ -0,0 +1,3 @@
+/usr/bin/skype -- gen_context(system_u:object_r:skype_exec_t,s0)
+/opt/skype/skype -- gen_context(system_u:object_r:skype_exec_t,s0)
+HOME_DIR/\.Skype(/.*)? gen_context(system_u:object_r:skype_home_t,s0)
diff --git a/policy/modules/apps/skype.if b/policy/modules/apps/skype.if
new file mode 100644
index 0000000..f72c534
--- /dev/null
+++ b/policy/modules/apps/skype.if
@@ -0,0 +1,51 @@
+## <summary>Skype softphone.</summary>
+
+#######################################
+## <summary>
+## Role access for the skype module.
+## </summary>
+## <param name="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(`skype_role',`
+ gen_require(`
+ type skype_t, skype_exec_t, skype_tmpfs_t, skype_home_t;
+ ')
+
+ #######################################
+ #
+ # Declarations
+ #
+
+ role $1 types skype_t;
+
+ ############################
+ #
+ # Policy
+ #
+ allow $2 skype_t:process { ptrace signal_perms };
+ dontaudit skype_t $2:unix_stream_socket { connectto };
+
+ domtrans_pattern($2, skype_exec_t, skype_t)
+
+ # Allow the user to manage the skype configuration files in his home
+ # directory
+ manage_dirs_pattern($2, skype_home_t, skype_home_t)
+ manage_files_pattern($2, skype_home_t, skype_home_t)
+ manage_lnk_files_pattern($2, skype_home_t, skype_home_t)
+
+ # Allow the user to relabel files from/to skype_home_t
+ relabel_dirs_pattern($2, skype_home_t, skype_home_t)
+ relabel_files_pattern($2, skype_home_t, skype_home_t)
+ relabel_lnk_files_pattern($2, skype_home_t, skype_home_t)
+
+ ps_process_pattern($2, skype_t)
+')
diff --git a/policy/modules/apps/skype.te b/policy/modules/apps/skype.te
new file mode 100644
index 0000000..0e0ca86
--- /dev/null
+++ b/policy/modules/apps/skype.te
@@ -0,0 +1,99 @@
+policy_module(skype, 0.0.2)
+
+############################
+#
+# Declarations
+#
+
+type skype_t;
+type skype_exec_t;
+application_domain(skype_t, skype_exec_t)
+can_exec(skype_t, skype_exec_t)
+
+type skype_home_t;
+
+type skype_tmpfs_t;
+files_tmpfs_file(skype_tmpfs_t)
+ubac_constrained(skype_tmpfs_t)
+
+############################
+#
+# Policy
+#
+
+allow skype_t self:process { getsched setsched execmem signal };
+allow skype_t self:fifo_file rw_fifo_file_perms;
+allow skype_t self:unix_stream_socket create_socket_perms;
+allow skype_t self:sem create_sem_perms;
+allow skype_t self:tcp_socket create_stream_socket_perms;
+
+# Allow skype to work with its ~/.skype location
+manage_dirs_pattern(skype_t, skype_home_t, skype_home_t)
+manage_files_pattern(skype_t, skype_home_t, skype_home_t)
+manage_lnk_files_pattern(skype_t, skype_home_t, skype_home_t)
+
+# Needed for supporting X11 & shared memory
+manage_files_pattern(skype_t, skype_tmpfs_t, skype_tmpfs_t)
+manage_lnk_files_pattern(skype_t, skype_tmpfs_t, skype_tmpfs_t)
+manage_fifo_files_pattern(skype_t, skype_tmpfs_t, skype_tmpfs_t)
+manage_sock_files_pattern(skype_t, skype_tmpfs_t, skype_tmpfs_t)
+fs_tmpfs_filetrans(skype_t, skype_tmpfs_t, { file lnk_file sock_file fifo_file })
+
+
+## Kernel layer calls
+#
+kernel_dontaudit_search_sysctl(skype_t)
+kernel_read_system_state(skype_t)
+
+corecmd_exec_bin(skype_t)
+corecmd_exec_shell(skype_t)
+
+corenet_all_recvfrom_netlabel(skype_t)
+corenet_all_recvfrom_unlabeled(skype_t)
+corenet_sendrecv_http_client_packets(skype_t)
+corenet_tcp_bind_generic_node(skype_t)
+corenet_tcp_bind_generic_port(skype_t)
+corenet_tcp_connect_generic_port(skype_t)
+corenet_tcp_connect_http_port(skype_t)
+corenet_tcp_sendrecv_http_port(skype_t)
+corenet_udp_bind_generic_node(skype_t)
+corenet_udp_bind_generic_port(skype_t)
+
+dev_dontaudit_search_sysfs(skype_t)
+dev_read_sound(skype_t)
+dev_read_video_dev(skype_t)
+dev_write_sound(skype_t)
+dev_write_video_dev(skype_t)
+
+# Needed to debug skype (start through commandline)
+domain_use_interactive_fds(skype_t)
+
+files_read_etc_files(skype_t)
+files_read_usr_files(skype_t)
+
+fs_dontaudit_getattr_xattr_fs(skype_t)
+
+## System layer calls
+#
+auth_use_nsswitch(skype_t)
+miscfiles_dontaudit_setattr_fonts_dirs(skype_t)
+miscfiles_read_localization(skype_t)
+userdom_manage_user_home_content_dirs(skype_t)
+userdom_manage_user_home_content_files(skype_t)
+userdom_use_user_terminals(skype_t)
+userdom_user_home_dir_filetrans(skype_t, skype_home_t, dir)
+userdom_user_home_content(skype_home_t)
+
+## Other calls
+#
+xserver_user_x_domain_template(skype, skype_t, skype_tmpfs_t)
+
+optional_policy(`
+ alsa_read_rw_config(skype_t)
+')
+
+optional_policy(`
+ dbus_system_bus_client(skype_t)
+ dbus_session_bus_client(skype_t)
+')
+
diff --git a/policy/modules/roles/staff.te b/policy/modules/roles/staff.te
index 2be17d2..92dc0a5 100644
--- a/policy/modules/roles/staff.te
+++ b/policy/modules/roles/staff.te
@@ -141,6 +141,10 @@ ifndef(`distro_redhat',`
')
optional_policy(`
+ skype_role(staff_r, staff_t)
+ ')
+
+ optional_policy(`
spamassassin_role(staff_r, staff_t)
')
diff --git a/policy/modules/roles/sysadm.te b/policy/modules/roles/sysadm.te
index e14b961..c7880dd 100644
--- a/policy/modules/roles/sysadm.te
+++ b/policy/modules/roles/sysadm.te
@@ -307,6 +307,10 @@ optional_policy(`
')
optional_policy(`
+ skype_role(sysadm_r, sysadm_t)
+')
+
+optional_policy(`
spamassassin_role(sysadm_r, sysadm_t)
')
diff --git a/policy/modules/roles/unprivuser.te b/policy/modules/roles/unprivuser.te
index e5bfdd4..1b50f42 100644
--- a/policy/modules/roles/unprivuser.te
+++ b/policy/modules/roles/unprivuser.te
@@ -118,6 +118,10 @@ ifndef(`distro_redhat',`
')
optional_policy(`
+ skype_role(user_r, user_t)
+ ')
+
+ optional_policy(`
spamassassin_role(user_r, user_t)
')
--
1.7.3.4
On 07/24/11 11:38, Sven Vermeulen wrote:
> The skype application is a popular voice and video chat application.
> This patch adds preliminary support for skype on SELinux.
>
> This is currently a "one patch" offer, so I'd like to know if it is okay
> when adding new applications to refpolicy like this to use a single patch
> (as long as it isn't too complicated)?
Yes, its fine, as log as it isn't too complicated.
> Also a quick review on the policy wouldn't hurt ;-) Feedback always
> appreciated.
>
> Signed-off-by: Sven Vermeulen <[email protected]>
> ---
> policy/modules/apps/skype.fc | 3 +
> policy/modules/apps/skype.if | 51 ++++++++++++++++++
> policy/modules/apps/skype.te | 99 ++++++++++++++++++++++++++++++++++++
> policy/modules/roles/staff.te | 4 ++
> policy/modules/roles/sysadm.te | 4 ++
> policy/modules/roles/unprivuser.te | 4 ++
> 6 files changed, 165 insertions(+), 0 deletions(-)
> create mode 100644 policy/modules/apps/skype.fc
> create mode 100644 policy/modules/apps/skype.if
> create mode 100644 policy/modules/apps/skype.te
>
> diff --git a/policy/modules/apps/skype.fc b/policy/modules/apps/skype.fc
> new file mode 100644
> index 0000000..a802960
> --- /dev/null
> +++ b/policy/modules/apps/skype.fc
> @@ -0,0 +1,3 @@
> +/usr/bin/skype -- gen_context(system_u:object_r:skype_exec_t,s0)
> +/opt/skype/skype -- gen_context(system_u:object_r:skype_exec_t,s0)
> +HOME_DIR/\.Skype(/.*)? gen_context(system_u:object_r:skype_home_t,s0)
> diff --git a/policy/modules/apps/skype.if b/policy/modules/apps/skype.if
> new file mode 100644
> index 0000000..f72c534
> --- /dev/null
> +++ b/policy/modules/apps/skype.if
> @@ -0,0 +1,51 @@
> +## <summary>Skype softphone.</summary>
> +
> +#######################################
> +## <summary>
> +## Role access for the skype module.
> +## </summary>
> +## <param name="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(`skype_role',`
> + gen_require(`
> + type skype_t, skype_exec_t, skype_tmpfs_t, skype_home_t;
> + ')
> +
> + #######################################
> + #
> + # Declarations
> + #
> +
> + role $1 types skype_t;
> +
> + ############################
> + #
> + # Policy
> + #
> + allow $2 skype_t:process { ptrace signal_perms };
> + dontaudit skype_t $2:unix_stream_socket { connectto };
> +
> + domtrans_pattern($2, skype_exec_t, skype_t)
> +
> + # Allow the user to manage the skype configuration files in his home
> + # directory
> + manage_dirs_pattern($2, skype_home_t, skype_home_t)
> + manage_files_pattern($2, skype_home_t, skype_home_t)
> + manage_lnk_files_pattern($2, skype_home_t, skype_home_t)
> +
> + # Allow the user to relabel files from/to skype_home_t
> + relabel_dirs_pattern($2, skype_home_t, skype_home_t)
> + relabel_files_pattern($2, skype_home_t, skype_home_t)
> + relabel_lnk_files_pattern($2, skype_home_t, skype_home_t)
> +
> + ps_process_pattern($2, skype_t)
> +')
> diff --git a/policy/modules/apps/skype.te b/policy/modules/apps/skype.te
> new file mode 100644
> index 0000000..0e0ca86
> --- /dev/null
> +++ b/policy/modules/apps/skype.te
> @@ -0,0 +1,99 @@
> +policy_module(skype, 0.0.2)
> +
> +############################
> +#
> +# Declarations
> +#
> +
> +type skype_t;
> +type skype_exec_t;
> +application_domain(skype_t, skype_exec_t)
> +can_exec(skype_t, skype_exec_t)
> +
> +type skype_home_t;
> +
> +type skype_tmpfs_t;
> +files_tmpfs_file(skype_tmpfs_t)
> +ubac_constrained(skype_tmpfs_t)
> +
> +############################
> +#
> +# Policy
> +#
> +
> +allow skype_t self:process { getsched setsched execmem signal };
> +allow skype_t self:fifo_file rw_fifo_file_perms;
> +allow skype_t self:unix_stream_socket create_socket_perms;
> +allow skype_t self:sem create_sem_perms;
> +allow skype_t self:tcp_socket create_stream_socket_perms;
> +
> +# Allow skype to work with its ~/.skype location
> +manage_dirs_pattern(skype_t, skype_home_t, skype_home_t)
> +manage_files_pattern(skype_t, skype_home_t, skype_home_t)
> +manage_lnk_files_pattern(skype_t, skype_home_t, skype_home_t)
> +
> +# Needed for supporting X11 & shared memory
> +manage_files_pattern(skype_t, skype_tmpfs_t, skype_tmpfs_t)
> +manage_lnk_files_pattern(skype_t, skype_tmpfs_t, skype_tmpfs_t)
> +manage_fifo_files_pattern(skype_t, skype_tmpfs_t, skype_tmpfs_t)
> +manage_sock_files_pattern(skype_t, skype_tmpfs_t, skype_tmpfs_t)
> +fs_tmpfs_filetrans(skype_t, skype_tmpfs_t, { file lnk_file sock_file fifo_file })
> +
> +
> +## Kernel layer calls
> +#
Needs some whitespace and unnecessary comments removal here and below
> +kernel_dontaudit_search_sysctl(skype_t)
> +kernel_read_system_state(skype_t)
> +
> +corecmd_exec_bin(skype_t)
> +corecmd_exec_shell(skype_t)
> +
> +corenet_all_recvfrom_netlabel(skype_t)
> +corenet_all_recvfrom_unlabeled(skype_t)
> +corenet_sendrecv_http_client_packets(skype_t)
> +corenet_tcp_bind_generic_node(skype_t)
> +corenet_tcp_bind_generic_port(skype_t)
> +corenet_tcp_connect_generic_port(skype_t)
> +corenet_tcp_connect_http_port(skype_t)
> +corenet_tcp_sendrecv_http_port(skype_t)
> +corenet_udp_bind_generic_node(skype_t)
> +corenet_udp_bind_generic_port(skype_t)
> +
> +dev_dontaudit_search_sysfs(skype_t)
> +dev_read_sound(skype_t)
> +dev_read_video_dev(skype_t)
> +dev_write_sound(skype_t)
> +dev_write_video_dev(skype_t)
> +
> +# Needed to debug skype (start through commandline)
> +domain_use_interactive_fds(skype_t)
> +
> +files_read_etc_files(skype_t)
> +files_read_usr_files(skype_t)
> +
> +fs_dontaudit_getattr_xattr_fs(skype_t)
> +
> +## System layer calls
> +#
> +auth_use_nsswitch(skype_t)
> +miscfiles_dontaudit_setattr_fonts_dirs(skype_t)
> +miscfiles_read_localization(skype_t)
> +userdom_manage_user_home_content_dirs(skype_t)
> +userdom_manage_user_home_content_files(skype_t)
Is this really necessary since there is skype_home_t?
> +userdom_use_user_terminals(skype_t)
> +userdom_user_home_dir_filetrans(skype_t, skype_home_t, dir)
> +userdom_user_home_content(skype_home_t)
This like usually goes up with the decl
> +
> +## Other calls
> +#
> +xserver_user_x_domain_template(skype, skype_t, skype_tmpfs_t)
> +
> +optional_policy(`
> + alsa_read_rw_config(skype_t)
> +')
> +
> +optional_policy(`
> + dbus_system_bus_client(skype_t)
> + dbus_session_bus_client(skype_t)
> +')
> +
> diff --git a/policy/modules/roles/staff.te b/policy/modules/roles/staff.te
> index 2be17d2..92dc0a5 100644
> --- a/policy/modules/roles/staff.te
> +++ b/policy/modules/roles/staff.te
> @@ -141,6 +141,10 @@ ifndef(`distro_redhat',`
> ')
>
> optional_policy(`
> + skype_role(staff_r, staff_t)
> + ')
> +
> + optional_policy(`
> spamassassin_role(staff_r, staff_t)
> ')
>
> diff --git a/policy/modules/roles/sysadm.te b/policy/modules/roles/sysadm.te
> index e14b961..c7880dd 100644
> --- a/policy/modules/roles/sysadm.te
> +++ b/policy/modules/roles/sysadm.te
> @@ -307,6 +307,10 @@ optional_policy(`
> ')
>
> optional_policy(`
> + skype_role(sysadm_r, sysadm_t)
> +')
> +
> +optional_policy(`
> spamassassin_role(sysadm_r, sysadm_t)
> ')
>
> diff --git a/policy/modules/roles/unprivuser.te b/policy/modules/roles/unprivuser.te
> index e5bfdd4..1b50f42 100644
> --- a/policy/modules/roles/unprivuser.te
> +++ b/policy/modules/roles/unprivuser.te
> @@ -118,6 +118,10 @@ ifndef(`distro_redhat',`
> ')
>
> optional_policy(`
> + skype_role(user_r, user_t)
> + ')
> +
> + optional_policy(`
> spamassassin_role(user_r, user_t)
> ')
>
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
On Fri, Jul 29, 2011 at 08:59:33AM -0400, Christopher J. PeBenito wrote:
> On 07/24/11 11:38, Sven Vermeulen wrote:
> > The skype application is a popular voice and video chat application.
> > This patch adds preliminary support for skype on SELinux.
[...]
> > +userdom_manage_user_home_content_dirs(skype_t)
> > +userdom_manage_user_home_content_files(skype_t)
>
> Is this really necessary since there is skype_home_t?
Depends on the use case, but Skype can be used to send and receive files, so
skype_t needs to be able to manage the users' home directory content.
Not that I'm happy with that, but it seems to be how most applications
handle this. I personally prefer a specific type for interacting with the
"outside" world (user_download_t or so) and have the apps be able to manage
that type rather than user_home_t. But that does make it more difficult to
explain to users (not really userfriendly).
Thanks for the feedback (also on the other RFC mail)!
Wkr,
Sven Vermeulen
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/03/2011 09:42 AM, Sven Vermeulen wrote:
> On Fri, Jul 29, 2011 at 08:59:33AM -0400, Christopher J. PeBenito
> wrote:
>> On 07/24/11 11:38, Sven Vermeulen wrote:
>>> The skype application is a popular voice and video chat
>>> application. This patch adds preliminary support for skype on
>>> SELinux.
> [...]
>>> +userdom_manage_user_home_content_dirs(skype_t)
>>> +userdom_manage_user_home_content_files(skype_t)
>>
>> Is this really necessary since there is skype_home_t?
>
> Depends on the use case, but Skype can be used to send and receive
> files, so skype_t needs to be able to manage the users' home
> directory content.
>
> Not that I'm happy with that, but it seems to be how most
> applications handle this. I personally prefer a specific type for
> interacting with the "outside" world (user_download_t or so) and have
> the apps be able to manage that type rather than user_home_t. But
> that does make it more difficult to explain to users (not really
> userfriendly).
>
> Thanks for the feedback (also on the other RFC mail)!
>
> Wkr, Sven Vermeulen _______________________________________________
> refpolicy mailing list refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
Can skype work fine without this ability? I would think you could add a
boolean and for most people who only do Video or phone calls would not
need the ability to read/write user_home_t.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk45U3QACgkQrlYvE4MpobMbjACeO3zyW/RffRO13e2EjiZ7LaIL
234AoNAjmoQ8gFTgJpx4jN6fzytmSbGs
=1T/u
-----END PGP SIGNATURE-----
On Wed, 2011-08-03 at 15:42 +0200, Sven Vermeulen wrote:
> On Fri, Jul 29, 2011 at 08:59:33AM -0400, Christopher J. PeBenito wrote:
> > On 07/24/11 11:38, Sven Vermeulen wrote:
> > > The skype application is a popular voice and video chat application.
> > > This patch adds preliminary support for skype on SELinux.
> [...]
> > > +userdom_manage_user_home_content_dirs(skype_t)
> > > +userdom_manage_user_home_content_files(skype_t)
> >
> > Is this really necessary since there is skype_home_t?
>
> Depends on the use case, but Skype can be used to send and receive files, so
> skype_t needs to be able to manage the users' home directory content.
>
> Not that I'm happy with that, but it seems to be how most applications
> handle this. I personally prefer a specific type for interacting with the
> "outside" world (user_download_t or so) and have the apps be able to manage
> that type rather than user_home_t. But that does make it more difficult to
> explain to users (not really userfriendly).
>
> Thanks for the feedback (also on the other RFC mail)!
Its pretty much me against the world but i will say it anyway:
In my experience one should not block access to generic user content but
rather prevent user agents from creating content with the generic user
content type, if it is not generic user content (e.g if it is a
communication channel, configuration, cache or any other kind of file
that is needed for the program to run).
So a program like skype should be able to manage user_home_t just fine.
Thats not the issue the issue is that i dont want it to have access to
protected files that are needed to make some user agent run properly
(atleast not if they dont need that access). (ssh_home_t, gpg_secret_t,
"any user app config files", gnome keyring db
etc, etc, etc.
Im my view we should be trying to improve the integrity of the user
applications their content. Not user content.
So what is generic user content then? Well for example the content of
~/Pictures, Music, Documents, Video, Pictures and any content in ~ that
is not configuration/cache etc content of some user application.
If that is implemented, then you can achieve pretty solid user space
integrity whilst keeping things practical.
Stuff i focussed on when confining user space was the above and
labelling the communication between user agents.
So when you see dbus chat by a user domain or you see a user domain
connecttingto a unix_stream_socket and writing to a sock file with a
user type then you should confine that agent as well and make sure it
objects get a private type itself.
> Wkr,
> Sven Vermeulen
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110803/f4ea11dc/attachment.bin
On 08/03/11 09:56, Daniel J Walsh wrote:
> On 08/03/2011 09:42 AM, Sven Vermeulen wrote:
>> On Fri, Jul 29, 2011 at 08:59:33AM -0400, Christopher J. PeBenito
>> wrote:
>>> On 07/24/11 11:38, Sven Vermeulen wrote:
>>>> The skype application is a popular voice and video chat
>>>> application. This patch adds preliminary support for skype on
>>>> SELinux.
>> [...]
>>>> +userdom_manage_user_home_content_dirs(skype_t)
>>>> +userdom_manage_user_home_content_files(skype_t)
>>>
>>> Is this really necessary since there is skype_home_t?
>
>> Depends on the use case, but Skype can be used to send and receive
>> files, so skype_t needs to be able to manage the users' home
>> directory content.
>
>> Not that I'm happy with that, but it seems to be how most
>> applications handle this. I personally prefer a specific type for
>> interacting with the "outside" world (user_download_t or so) and have
>> the apps be able to manage that type rather than user_home_t. But
>> that does make it more difficult to explain to users (not really
>> userfriendly).
>
>> Thanks for the feedback (also on the other RFC mail)!
>
> Can skype work fine without this ability? I would think you could add a
> boolean and for most people who only do Video or phone calls would not
> need the ability to read/write user_home_t.
Agreed. I'd prefer it this way, if possible.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
On Thu, 4 Aug 2011, Dominick Grift <[email protected]> wrote:
> In my experience one should not block access to generic user content but
> rather prevent user agents from creating content with the generic user
> content type, if it is not generic user content (e.g if it is a
> communication channel, configuration, cache or any other kind of file
> that is needed for the program to run).
>
> So a program like skype should be able to manage user_home_t just fine.
> Thats not the issue the issue is that i dont want it to have access to
> protected files that are needed to make some user agent run properly
> (atleast not if they dont need that access). (ssh_home_t, gpg_secret_t,
> "any user app config files", gnome keyring db
> etc, etc, etc.
If skype_t can write to user_home_t then it can change files such as .bashrc
such that at the next shell invocation bash will change files such as
ssh_home_t for it.
Now if you are proposing separate types for .bash* files etc then it might be
more reliable.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
On Thu, 2011-08-04 at 09:04 +1000, Russell Coker wrote:
> Now if you are proposing separate types for .bash* files etc then it might be
> more reliable.
I guess .bash.* (and others) are configuration files etc of the (bash)
shell which i guess in a way is a user agent. The only difference is
that the shell does, and is supposed to run in the user domain and that
these files are copied from /etc/skel. Fortunately the named file
transition functionality can help overcome this issue.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110804/32ff3d49/attachment.bin
On Thu, 4 Aug 2011, Dominick Grift <[email protected]> wrote:
> On Thu, 2011-08-04 at 09:04 +1000, Russell Coker wrote:
> > Now if you are proposing separate types for .bash* files etc then it
> > might be more reliable.
>
> I guess .bash.* (and others) are configuration files etc of the (bash)
> shell which i guess in a way is a user agent.
As the shell is started by the system on behalf of the user before anything
else happens it is the ultimate user agent. Note that there are more than a
few shells available which use different configuration files.
> The only difference is
> that the shell does, and is supposed to run in the user domain and that
> these files are copied from /etc/skel. Fortunately the named file
> transition functionality can help overcome this issue.
Yes, named file transition is necessary if we want to solve that by using a
different type for the shell config files.
But these aren't the only such files. I'm sure that there are other files
that may be executable by common programs that run as user_t. Making a
comprehensive list will be difficult. Also there are lots of local config
files that don't get fuzz testing because writing to them requires equivalent
privs to messing with the application directly.
The assumption all along was that user_home_t was in most ways the most
privileged of all types for files under the user home directory (with the
possible exception of gpg_secret_t). Changing this assumption isn't going to
be easy.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
On Thu, 2011-08-04 at 19:00 +1000, Russell Coker wrote:
> But these aren't the only such files. I'm sure that there are other files
> that may be executable by common programs that run as user_t. Making a
> comprehensive list will be difficult. Also there are lots of local config
> files that don't get fuzz testing because writing to them requires equivalent
> privs to messing with the application directly.
>
In a pretty much perfect confined user environment those are the only
files that come to mind here atleast.
The implementation would rely heavily on name file transition
functionality and/or the presence of restorecond -u running in the
session.
> The assumption all along was that user_home_t was in most ways the most
> privileged of all types for files under the user home directory (with the
> possible exception of gpg_secret_t). Changing this assumption isn't going to
> be easy.
>
Agreed there. For this to work, basically everything in the user
environment needs to be confined. Starting with the layer between the
user and the system (the desktop environment)
Unfortunately it is not going to happen. At least not any time soon.
I can understand that for this reason (currently too much work, too
difficult to maintain) but i do not understand that reference policy
accepts a workaround like the one that is proposed for skype.
Tool little benefit and an endorsement that we should accept workarounds
like these. what if i propose a similar patch for lets say Ekiga (what
about empathy (insert the next gui app here)), are we going to implement
a boolean for its file sharing functionality to? where is it going to
end?
Might as well ignore the GUI environment altogether until we find a
solution that actually deals with integrity issues in a more credible
way.
end of rant.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110804/7da143d2/attachment.bin
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/04/2011 05:34 AM, Dominick Grift wrote:
>
>
> On Thu, 2011-08-04 at 19:00 +1000, Russell Coker wrote:
>
>> But these aren't the only such files. I'm sure that there are
>> other files that may be executable by common programs that run as
>> user_t. Making a comprehensive list will be difficult. Also there
>> are lots of local config files that don't get fuzz testing because
>> writing to them requires equivalent privs to messing with the
>> application directly.
>>
>
> In a pretty much perfect confined user environment those are the
> only files that come to mind here atleast.
>
> The implementation would rely heavily on name file transition
> functionality and/or the presence of restorecond -u running in the
> session.
>
>> The assumption all along was that user_home_t was in most ways the
>> most privileged of all types for files under the user home
>> directory (with the possible exception of gpg_secret_t). Changing
>> this assumption isn't going to be easy.
>>
>
> Agreed there. For this to work, basically everything in the user
> environment needs to be confined. Starting with the layer between
> the user and the system (the desktop environment)
>
> Unfortunately it is not going to happen. At least not any time soon.
>
> I can understand that for this reason (currently too much work, too
> difficult to maintain) but i do not understand that reference policy
> accepts a workaround like the one that is proposed for skype.
>
> Tool little benefit and an endorsement that we should accept
> workarounds like these. what if i propose a similar patch for lets
> say Ekiga (what about empathy (insert the next gui app here)), are we
> going to implement a boolean for its file sharing functionality to?
> where is it going to end?
>
> Might as well ignore the GUI environment altogether until we find a
> solution that actually deals with integrity issues in a more
> credible way.
>
> end of rant.
>
>
>
> _______________________________________________ refpolicy mailing
> list refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
Best solution would be to have a helper File Selector app that does the
opening of files from the file manager and then passes the open file
descriptor to the application. That way you could prevent the random
opening of files in the homedir, while allowing apps to read/write any
passed in file descriptors.
But alas this is not the way it works...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk46qw4ACgkQrlYvE4MpobPVZACgqiwfrOMQMj0nv4rEzc9Xafrh
Oj8AoJreyxS3uu73wchry90kgDX2G0Cv
=B8M1
-----END PGP SIGNATURE-----