nnd/selinux-refpolicy
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
a0647afa0c
selinux-refpolicy/policy/modules/apps/gnome.if

195 lines
4.4 KiB
Plaintext
Raw Normal View History

This patch adds a GConf policy to refpolicy. This policy is much tighter than the GConf policy from the old example policy. It only allows gconfd to access configuration data stored by GConf. Users can modify configuration data using gconftool-2 or gconf-editor, both of which use gconfd. GConf manages multiple configuration sources, so gconfd should be used to make any changes anyway. Normal users who aren't trying to directly edit the configuration data of GConf won't notice anything different. There is also a difference between this policy and the old example policy in handling directories in /tmp. The old example policy labeled /tmp/gconfd-USER with ROLE_gconfd_tmp_t, but, since there was no use of the file_type_auto_trans macro, if that directory was deleted gconfd would create one labeled as tmp_t. This policy uses the files_tmp-filetrans macro to cause a directory in /tmp created by gconfd to be labeled as $1_tmp_t. It is not labeled with $1_gconf_tmp_t, because if /tmp/orbit-USER is deleted, gconfd will create it (through use of ORBit) and it would get the $1_gconf_tmp_t label. By having gconfd create $1_tmp_t directories in /tmp and $1_gconf_tmp_t files and directories in directories labeled with $1_tmp_t, it can control its data without requiring any future bonobo or Gnome policies to have access to $1_gconf_tmp_t. This patch is related to work that I am doing in making gconfd an userspace object manager. If any user program can modify the configuration data that GConf stores, than making gconfd an userspace object manager would be useless. Signed-off-by: James Carter <jwcart2@tycho.nsa.gov>
2006-10-02 15:22:48 +00:00
## <summary>GNU network object model environment (GNOME)</summary>
########################################
## <summary>
## The per role template for the gnome module.
## </summary>
## <desc>
## <p>
## This template creates a derived domain which is used
## for gconf sessions.
## </p>
## <p>
## This template is invoked automatically for each role, and
## generally does not need to be invoked directly
## by policy writers.
## </p>
## </desc>
## <param name="userdomain_prefix">
## <summary>
## The prefix of the user domain (e.g., user
## is the prefix for user_t).
## </summary>
## </param>
## <param name="user_domain">
## <summary>
## The type of the user domain.
## </summary>
## </param>
## <param name="user_role">
## <summary>
## The role associated with the user domain.
## </summary>
## </param>
#
template(`gnome_per_role_template',`
gen_require(`
type gconfd_exec_t;
patch from dan, Thu, 2007-01-25 at 08:12 -0500
2007-02-16 23:01:42 +00:00
attribute gnomedomain;
This patch adds a GConf policy to refpolicy. This policy is much tighter than the GConf policy from the old example policy. It only allows gconfd to access configuration data stored by GConf. Users can modify configuration data using gconftool-2 or gconf-editor, both of which use gconfd. GConf manages multiple configuration sources, so gconfd should be used to make any changes anyway. Normal users who aren't trying to directly edit the configuration data of GConf won't notice anything different. There is also a difference between this policy and the old example policy in handling directories in /tmp. The old example policy labeled /tmp/gconfd-USER with ROLE_gconfd_tmp_t, but, since there was no use of the file_type_auto_trans macro, if that directory was deleted gconfd would create one labeled as tmp_t. This policy uses the files_tmp-filetrans macro to cause a directory in /tmp created by gconfd to be labeled as $1_tmp_t. It is not labeled with $1_gconf_tmp_t, because if /tmp/orbit-USER is deleted, gconfd will create it (through use of ORBit) and it would get the $1_gconf_tmp_t label. By having gconfd create $1_tmp_t directories in /tmp and $1_gconf_tmp_t files and directories in directories labeled with $1_tmp_t, it can control its data without requiring any future bonobo or Gnome policies to have access to $1_gconf_tmp_t. This patch is related to work that I am doing in making gconfd an userspace object manager. If any user program can modify the configuration data that GConf stores, than making gconfd an userspace object manager would be useless. Signed-off-by: James Carter <jwcart2@tycho.nsa.gov>
2006-10-02 15:22:48 +00:00
')
##############################
#
# Declarations
#
patch from dan, Thu, 2007-01-25 at 08:12 -0500
2007-02-16 23:01:42 +00:00
type $1_gconfd_t, gnomedomain;
trunk: add application module
2007-07-19 18:57:48 +00:00
application_domain($1_gconfd_t, gconfd_exec_t)
This patch adds a GConf policy to refpolicy. This policy is much tighter than the GConf policy from the old example policy. It only allows gconfd to access configuration data stored by GConf. Users can modify configuration data using gconftool-2 or gconf-editor, both of which use gconfd. GConf manages multiple configuration sources, so gconfd should be used to make any changes anyway. Normal users who aren't trying to directly edit the configuration data of GConf won't notice anything different. There is also a difference between this policy and the old example policy in handling directories in /tmp. The old example policy labeled /tmp/gconfd-USER with ROLE_gconfd_tmp_t, but, since there was no use of the file_type_auto_trans macro, if that directory was deleted gconfd would create one labeled as tmp_t. This policy uses the files_tmp-filetrans macro to cause a directory in /tmp created by gconfd to be labeled as $1_tmp_t. It is not labeled with $1_gconf_tmp_t, because if /tmp/orbit-USER is deleted, gconfd will create it (through use of ORBit) and it would get the $1_gconf_tmp_t label. By having gconfd create $1_tmp_t directories in /tmp and $1_gconf_tmp_t files and directories in directories labeled with $1_tmp_t, it can control its data without requiring any future bonobo or Gnome policies to have access to $1_gconf_tmp_t. This patch is related to work that I am doing in making gconfd an userspace object manager. If any user program can modify the configuration data that GConf stores, than making gconfd an userspace object manager would be useless. Signed-off-by: James Carter <jwcart2@tycho.nsa.gov>
2006-10-02 15:22:48 +00:00
role $3 types $1_gconfd_t;
type $1_gconf_home_t;
patch from dan, Thu, 2007-01-25 at 08:12 -0500
2007-02-16 23:01:42 +00:00
userdom_user_home_content($1, $1_gconf_home_t)
type $1_gnome_home_t;
userdom_user_home_content($1, $1_gnome_home_t)
This patch adds a GConf policy to refpolicy. This policy is much tighter than the GConf policy from the old example policy. It only allows gconfd to access configuration data stored by GConf. Users can modify configuration data using gconftool-2 or gconf-editor, both of which use gconfd. GConf manages multiple configuration sources, so gconfd should be used to make any changes anyway. Normal users who aren't trying to directly edit the configuration data of GConf won't notice anything different. There is also a difference between this policy and the old example policy in handling directories in /tmp. The old example policy labeled /tmp/gconfd-USER with ROLE_gconfd_tmp_t, but, since there was no use of the file_type_auto_trans macro, if that directory was deleted gconfd would create one labeled as tmp_t. This policy uses the files_tmp-filetrans macro to cause a directory in /tmp created by gconfd to be labeled as $1_tmp_t. It is not labeled with $1_gconf_tmp_t, because if /tmp/orbit-USER is deleted, gconfd will create it (through use of ORBit) and it would get the $1_gconf_tmp_t label. By having gconfd create $1_tmp_t directories in /tmp and $1_gconf_tmp_t files and directories in directories labeled with $1_tmp_t, it can control its data without requiring any future bonobo or Gnome policies to have access to $1_gconf_tmp_t. This patch is related to work that I am doing in making gconfd an userspace object manager. If any user program can modify the configuration data that GConf stores, than making gconfd an userspace object manager would be useless. Signed-off-by: James Carter <jwcart2@tycho.nsa.gov>
2006-10-02 15:22:48 +00:00
type $1_gconf_tmp_t;
files_tmp_file($1_gconf_tmp_t)
##############################
#
# Local Policy
#
allow $1_gconfd_t self:process getsched;
patch from dan, Thu, 2007-01-25 at 08:12 -0500
2007-02-16 23:01:42 +00:00
allow $1_gconfd_t self:fifo_file rw_fifo_file_perms;
This patch adds a GConf policy to refpolicy. This policy is much tighter than the GConf policy from the old example policy. It only allows gconfd to access configuration data stored by GConf. Users can modify configuration data using gconftool-2 or gconf-editor, both of which use gconfd. GConf manages multiple configuration sources, so gconfd should be used to make any changes anyway. Normal users who aren't trying to directly edit the configuration data of GConf won't notice anything different. There is also a difference between this policy and the old example policy in handling directories in /tmp. The old example policy labeled /tmp/gconfd-USER with ROLE_gconfd_tmp_t, but, since there was no use of the file_type_auto_trans macro, if that directory was deleted gconfd would create one labeled as tmp_t. This policy uses the files_tmp-filetrans macro to cause a directory in /tmp created by gconfd to be labeled as $1_tmp_t. It is not labeled with $1_gconf_tmp_t, because if /tmp/orbit-USER is deleted, gconfd will create it (through use of ORBit) and it would get the $1_gconf_tmp_t label. By having gconfd create $1_tmp_t directories in /tmp and $1_gconf_tmp_t files and directories in directories labeled with $1_tmp_t, it can control its data without requiring any future bonobo or Gnome policies to have access to $1_gconf_tmp_t. This patch is related to work that I am doing in making gconfd an userspace object manager. If any user program can modify the configuration data that GConf stores, than making gconfd an userspace object manager would be useless. Signed-off-by: James Carter <jwcart2@tycho.nsa.gov>
2006-10-02 15:22:48 +00:00
merge policy patterns to trunk
2006-12-12 20:08:08 +00:00
manage_dirs_pattern($1_gconfd_t,$1_gconf_home_t,$1_gconf_home_t)
manage_files_pattern($1_gconfd_t,$1_gconf_home_t,$1_gconf_home_t)
This patch adds a GConf policy to refpolicy. This policy is much tighter than the GConf policy from the old example policy. It only allows gconfd to access configuration data stored by GConf. Users can modify configuration data using gconftool-2 or gconf-editor, both of which use gconfd. GConf manages multiple configuration sources, so gconfd should be used to make any changes anyway. Normal users who aren't trying to directly edit the configuration data of GConf won't notice anything different. There is also a difference between this policy and the old example policy in handling directories in /tmp. The old example policy labeled /tmp/gconfd-USER with ROLE_gconfd_tmp_t, but, since there was no use of the file_type_auto_trans macro, if that directory was deleted gconfd would create one labeled as tmp_t. This policy uses the files_tmp-filetrans macro to cause a directory in /tmp created by gconfd to be labeled as $1_tmp_t. It is not labeled with $1_gconf_tmp_t, because if /tmp/orbit-USER is deleted, gconfd will create it (through use of ORBit) and it would get the $1_gconf_tmp_t label. By having gconfd create $1_tmp_t directories in /tmp and $1_gconf_tmp_t files and directories in directories labeled with $1_tmp_t, it can control its data without requiring any future bonobo or Gnome policies to have access to $1_gconf_tmp_t. This patch is related to work that I am doing in making gconfd an userspace object manager. If any user program can modify the configuration data that GConf stores, than making gconfd an userspace object manager would be useless. Signed-off-by: James Carter <jwcart2@tycho.nsa.gov>
2006-10-02 15:22:48 +00:00
userdom_user_home_dir_filetrans($1, $1_gconfd_t, $1_gconf_home_t, dir)
merge policy patterns to trunk
2006-12-12 20:08:08 +00:00
manage_dirs_pattern($1_gconfd_t,$1_gconf_tmp_t,$1_gconf_tmp_t)
manage_files_pattern($1_gconfd_t,$1_gconf_tmp_t,$1_gconf_tmp_t)
This patch adds a GConf policy to refpolicy. This policy is much tighter than the GConf policy from the old example policy. It only allows gconfd to access configuration data stored by GConf. Users can modify configuration data using gconftool-2 or gconf-editor, both of which use gconfd. GConf manages multiple configuration sources, so gconfd should be used to make any changes anyway. Normal users who aren't trying to directly edit the configuration data of GConf won't notice anything different. There is also a difference between this policy and the old example policy in handling directories in /tmp. The old example policy labeled /tmp/gconfd-USER with ROLE_gconfd_tmp_t, but, since there was no use of the file_type_auto_trans macro, if that directory was deleted gconfd would create one labeled as tmp_t. This policy uses the files_tmp-filetrans macro to cause a directory in /tmp created by gconfd to be labeled as $1_tmp_t. It is not labeled with $1_gconf_tmp_t, because if /tmp/orbit-USER is deleted, gconfd will create it (through use of ORBit) and it would get the $1_gconf_tmp_t label. By having gconfd create $1_tmp_t directories in /tmp and $1_gconf_tmp_t files and directories in directories labeled with $1_tmp_t, it can control its data without requiring any future bonobo or Gnome policies to have access to $1_gconf_tmp_t. This patch is related to work that I am doing in making gconfd an userspace object manager. If any user program can modify the configuration data that GConf stores, than making gconfd an userspace object manager would be useless. Signed-off-by: James Carter <jwcart2@tycho.nsa.gov>
2006-10-02 15:22:48 +00:00
userdom_user_tmp_filetrans($1,$1_gconfd_t,$1_gconf_tmp_t,{ dir file })
domain_auto_trans($2, gconfd_exec_t, $1_gconfd_t)
allow $1_gconfd_t $2:fd use;
allow $1_gconfd_t $2:fifo_file write;
allow $1_gconfd_t $2:unix_stream_socket connectto;
allow $1_gconfd_t gconf_etc_t:dir list_dir_perms;
merge policy patterns to trunk
2006-12-12 20:08:08 +00:00
read_files_pattern($1_gconfd_t,gconf_etc_t,gconf_etc_t)
This patch adds a GConf policy to refpolicy. This policy is much tighter than the GConf policy from the old example policy. It only allows gconfd to access configuration data stored by GConf. Users can modify configuration data using gconftool-2 or gconf-editor, both of which use gconfd. GConf manages multiple configuration sources, so gconfd should be used to make any changes anyway. Normal users who aren't trying to directly edit the configuration data of GConf won't notice anything different. There is also a difference between this policy and the old example policy in handling directories in /tmp. The old example policy labeled /tmp/gconfd-USER with ROLE_gconfd_tmp_t, but, since there was no use of the file_type_auto_trans macro, if that directory was deleted gconfd would create one labeled as tmp_t. This policy uses the files_tmp-filetrans macro to cause a directory in /tmp created by gconfd to be labeled as $1_tmp_t. It is not labeled with $1_gconf_tmp_t, because if /tmp/orbit-USER is deleted, gconfd will create it (through use of ORBit) and it would get the $1_gconf_tmp_t label. By having gconfd create $1_tmp_t directories in /tmp and $1_gconf_tmp_t files and directories in directories labeled with $1_tmp_t, it can control its data without requiring any future bonobo or Gnome policies to have access to $1_gconf_tmp_t. This patch is related to work that I am doing in making gconfd an userspace object manager. If any user program can modify the configuration data that GConf stores, than making gconfd an userspace object manager would be useless. Signed-off-by: James Carter <jwcart2@tycho.nsa.gov>
2006-10-02 15:22:48 +00:00
patch from dan, Thu, 2007-01-25 at 08:12 -0500
2007-02-16 23:01:42 +00:00
ps_process_pattern($2,$1_gconfd_t)
This patch adds a GConf policy to refpolicy. This policy is much tighter than the GConf policy from the old example policy. It only allows gconfd to access configuration data stored by GConf. Users can modify configuration data using gconftool-2 or gconf-editor, both of which use gconfd. GConf manages multiple configuration sources, so gconfd should be used to make any changes anyway. Normal users who aren't trying to directly edit the configuration data of GConf won't notice anything different. There is also a difference between this policy and the old example policy in handling directories in /tmp. The old example policy labeled /tmp/gconfd-USER with ROLE_gconfd_tmp_t, but, since there was no use of the file_type_auto_trans macro, if that directory was deleted gconfd would create one labeled as tmp_t. This policy uses the files_tmp-filetrans macro to cause a directory in /tmp created by gconfd to be labeled as $1_tmp_t. It is not labeled with $1_gconf_tmp_t, because if /tmp/orbit-USER is deleted, gconfd will create it (through use of ORBit) and it would get the $1_gconf_tmp_t label. By having gconfd create $1_tmp_t directories in /tmp and $1_gconf_tmp_t files and directories in directories labeled with $1_tmp_t, it can control its data without requiring any future bonobo or Gnome policies to have access to $1_gconf_tmp_t. This patch is related to work that I am doing in making gconfd an userspace object manager. If any user program can modify the configuration data that GConf stores, than making gconfd an userspace object manager would be useless. Signed-off-by: James Carter <jwcart2@tycho.nsa.gov>
2006-10-02 15:22:48 +00:00
dev_read_urand($1_gconfd_t)
files_read_etc_files($1_gconfd_t)
libs_use_ld_so($1_gconfd_t)
libs_use_shared_libs($1_gconfd_t)
miscfiles_read_localization($1_gconfd_t)
logging_send_syslog_msg($1_gconfd_t)
userdom_manage_user_tmp_sockets($1, $1_gconfd_t)
userdom_manage_user_tmp_dirs($1,$1_gconfd_t)
userdom_tmp_filetrans_user_tmp($1,$1_gconfd_t,dir)
gnome_stream_connect_gconf_template($1,$2)
optional_policy(`
nscd_dontaudit_search_pid($1_gconfd_t)
')
optional_policy(`
xserver_use_xdm_fds($1_gconfd_t)
xserver_rw_xdm_pipes($1_gconfd_t)
')
')
########################################
## <summary>
## gconf connection template.
## </summary>
## <param name="userdomain_prefix">
## <summary>
## The prefix of the user domain (e.g., user
## is the prefix for user_t).
## </summary>
## </param>
## <param name="user_domain">
## <summary>
## The type of the user domain.
## </summary>
## </param>
#
template(`gnome_stream_connect_gconf_template',`
gen_require(`
type $1_gconfd_t;
type $1_gconf_tmp_t;
')
patch from dan, Thu, 2007-01-25 at 08:12 -0500
2007-02-16 23:01:42 +00:00
read_files_pattern($2,$1_gconf_tmp_t,$1_gconf_tmp_t)
This patch adds a GConf policy to refpolicy. This policy is much tighter than the GConf policy from the old example policy. It only allows gconfd to access configuration data stored by GConf. Users can modify configuration data using gconftool-2 or gconf-editor, both of which use gconfd. GConf manages multiple configuration sources, so gconfd should be used to make any changes anyway. Normal users who aren't trying to directly edit the configuration data of GConf won't notice anything different. There is also a difference between this policy and the old example policy in handling directories in /tmp. The old example policy labeled /tmp/gconfd-USER with ROLE_gconfd_tmp_t, but, since there was no use of the file_type_auto_trans macro, if that directory was deleted gconfd would create one labeled as tmp_t. This policy uses the files_tmp-filetrans macro to cause a directory in /tmp created by gconfd to be labeled as $1_tmp_t. It is not labeled with $1_gconf_tmp_t, because if /tmp/orbit-USER is deleted, gconfd will create it (through use of ORBit) and it would get the $1_gconf_tmp_t label. By having gconfd create $1_tmp_t directories in /tmp and $1_gconf_tmp_t files and directories in directories labeled with $1_tmp_t, it can control its data without requiring any future bonobo or Gnome policies to have access to $1_gconf_tmp_t. This patch is related to work that I am doing in making gconfd an userspace object manager. If any user program can modify the configuration data that GConf stores, than making gconfd an userspace object manager would be useless. Signed-off-by: James Carter <jwcart2@tycho.nsa.gov>
2006-10-02 15:22:48 +00:00
allow $2 $1_gconfd_t:unix_stream_socket connectto;
patch from dan, Thu, 2007-01-25 at 08:12 -0500
2007-02-16 23:01:42 +00:00
')
########################################
## <summary>
## Run gconfd in the role-specific gconfd domain.
## </summary>
## <desc>
## <p>
## Run gconfd in the role-specfic gconfd domain.
## </p>
## <p>
## This is a templated interface, and should only
## be called from a per-userdomain template.
## </p>
## </desc>
## <param name="userdomain_prefix">
## <summary>
## The prefix of the user domain (e.g., user
## is the prefix for user_t).
## </summary>
## </param>
## <param name="domain">
## <summary>
## Domain allowed access.
## </summary>
## </param>
#
template(`gnome_domtrans_user_gconf',`
gen_require(`
type $1_gconfd_t, gconfd_exec_t;
')
domtrans_pattern($2,gconfd_exec_t,$1_gconfd_t)
')
########################################
## <summary>
## manage gnome homedir content (.config)
## </summary>
## <param name="userdomain_prefix">
## <summary>
## The prefix of the user domain (e.g., user
## is the prefix for user_t).
## </summary>
## </param>
## <param name="user_domain">
## <summary>
## The type of the user domain.
## </summary>
## </param>
#
template(`gnome_manage_user_gnome_config',`
gen_require(`
type $1_gnome_home_t;
')
allow $2 $1_gnome_home_t:dir manage_dir_perms;
allow $2 $1_gnome_home_t:file manage_file_perms;
This patch adds a GConf policy to refpolicy. This policy is much tighter than the GConf policy from the old example policy. It only allows gconfd to access configuration data stored by GConf. Users can modify configuration data using gconftool-2 or gconf-editor, both of which use gconfd. GConf manages multiple configuration sources, so gconfd should be used to make any changes anyway. Normal users who aren't trying to directly edit the configuration data of GConf won't notice anything different. There is also a difference between this policy and the old example policy in handling directories in /tmp. The old example policy labeled /tmp/gconfd-USER with ROLE_gconfd_tmp_t, but, since there was no use of the file_type_auto_trans macro, if that directory was deleted gconfd would create one labeled as tmp_t. This policy uses the files_tmp-filetrans macro to cause a directory in /tmp created by gconfd to be labeled as $1_tmp_t. It is not labeled with $1_gconf_tmp_t, because if /tmp/orbit-USER is deleted, gconfd will create it (through use of ORBit) and it would get the $1_gconf_tmp_t label. By having gconfd create $1_tmp_t directories in /tmp and $1_gconf_tmp_t files and directories in directories labeled with $1_tmp_t, it can control its data without requiring any future bonobo or Gnome policies to have access to $1_gconf_tmp_t. This patch is related to work that I am doing in making gconfd an userspace object manager. If any user program can modify the configuration data that GConf stores, than making gconfd an userspace object manager would be useless. Signed-off-by: James Carter <jwcart2@tycho.nsa.gov>
2006-10-02 15:22:48 +00:00
')
Reference in New Issue Copy Permalink