Portage related updates
cover Portage related updates
Please find in the next few mails four patches related to Gentoo portage.
1/ Support for layman (with the feedback received earlier incorporated) 2/ Support emerge-webrsync through portage domain
3/ Allow emerge-webrsync to copy extracted files
4/ Allow gpg to search through portage' configuration files
Wkr,
Sven Vermeulen
PATCH 1/4 Support layman through its own domain
The layman utility is used by Gentoo to manage additional overlays. The application manages files in /var/lib/layman (which are the various overlays) and is able to update them using utilities like rsync, svn, git, ...
Previously, layman was just ran within the domain of the caller (which was usually sysadm_t). However, when using automated methods like updating the trees through cron or puppet, this fails since these domains do not hold the necessary privileges. By putting the necessary privileges in a separate domain, we can assign this domain to the appropriate roles.
Since layman and portage (emerge) are very closely related, we manage the necessary domtrans rules through the portage_domtrans() method. There is hardly any point to make this a separate interface.
--- policy/modules/admin/portage.fc | 2 + policy/modules/admin/portage.if | 6 +++- policy/modules/admin/portage.te | 60 +++++++++++++++++++++++++++++++++++++++ 3 files changed, 67 insertions(+), 1 deletions(-)
policy/modules/admin/portage.fc +2 -0
@@ -3,6 +3,7 @@ /etc/portage(/.*)? gen_context(system_u:object_r:portage_conf_t,s0) /usr/bin/gcc-config -- gen_context(system_u:object_r:gcc_config_exec_t,s0) +/usr/bin/layman -- gen_context(system_u:object_r:layman_exec_t,s0) /usr/bin/sandbox -- gen_context(system_u:object_r:portage_exec_t,s0) /usr/lib(64)?/portage/bin/ebuild -- gen_context(system_u:object_r:portage_exec_t,s0)
@@ -19,6 +20,7 @@ /var/log/emerge\.log.* -- gen_context(system_u:object_r:portage_log_t,s0) /var/log/emerge-fetch.log -- gen_context(system_u:object_r:portage_log_t,s0) /var/log/portage(/.*)? gen_context(system_u:object_r:portage_log_t,s0) +/var/lib/layman(/.*)? gen_context(system_u:object_r:layman_var_lib_t,s0) /var/lib/portage(/.*)? gen_context(system_u:object_r:portage_cache_t,s0) /var/tmp/portage(/.*)? gen_context(system_u:object_r:portage_tmp_t,s0) /var/tmp/portage-pkg(/.*)? gen_context(system_u:object_r:portage_tmp_t,s0)
policy/modules/admin/portage.if +5 -1
@@ -16,6 +16,7 @@ interface(`portage_domtrans',` gen_require(` type portage_t, portage_exec_t; + type layman_t, layman_exec_t; ') files_search_usr($1)
@@ -23,6 +24,8 @@ interface(`portage_domtrans',` # transition to portage domtrans_pattern($1, portage_exec_t, portage_t) + # transition to layman + domtrans_pattern($1, layman_exec_t, layman_t) ') ########################################
@@ -45,10 +48,11 @@ interface(`portage_domtrans',` interface(`portage_run',` gen_require(` type portage_t, portage_fetch_t, portage_sandbox_t; + type layman_t; ') portage_domtrans($1) - role $2 types { portage_t portage_fetch_t portage_sandbox_t }; + role $2 types { portage_t portage_fetch_t portage_sandbox_t layman_t }; ') ########################################
policy/modules/admin/portage.te +60 -0
72 lines not on this page · raw message
Signature · 1 line
1.7.3.4
PATCH 1/4 Support layman through its own domain
Quoted 10 lines · Sven Vermeulen
The layman utility is used by Gentoo to manage additional overlays. The application manages files in
/var/lib/layman(which are the various overlays) and is able to update them using utilities like rsync, svn, git, ...Previously, layman was just ran within the domain of the caller (which was usually
sysadm_t). However, when using automated methods like updating the trees through cron or puppet, this fails since these domains do not hold the necessary privileges. By putting the necessary privileges in a separate domain, we can assign this domain to the appropriate roles.
Quoted 3 lines
Since layman and portage (emerge) are very closely related, we manage the necessary domtrans rules through the
portage_domtrans()method. There is hardly any point to make this a separate interface.
Have you considered transitioning to portage_fetch_t for the fetch? Since there already is SELinux aware code in portage, it seems like it would be easy to get that into layman, especially if layman uses portage libraries (I don't know if it does). Alternatively, you could try transitioning to portage_fetch_t when running layman; its been a while since I used it, so I'm not completely sure if that makes sense.
Quoted 139 lines
Signed-off-by Sven Vermeulen<[email protected]>--- policy/modules/admin/portage.fc | 2 + policy/modules/admin/portage.if | 6 +++- policy/modules/admin/portage.te | 60 +++++++++++++++++++++++++++++++++++++++ 3 files changed, 67 insertions(+), 1 deletions(-)policy/modules/admin/portage.fc +2
-0@@ -3,6 +3,7 @@ /etc/portage(/.*)? gen_context(system_u:object_r:portage_conf_t,s0) /usr/bin/gcc-config -- gen_context(system_u:object_r:gcc_config_exec_t,s0) +/usr/bin/layman -- gen_context(system_u:object_r:layman_exec_t,s0) /usr/bin/sandbox -- gen_context(system_u:object_r:portage_exec_t,s0) /usr/lib(64)?/portage/bin/ebuild -- gen_context(system_u:object_r:portage_exec_t,s0)@@ -19,6 +20,7 @@ /var/log/emerge\.log.* -- gen_context(system_u:object_r:portage_log_t,s0) /var/log/emerge-fetch.log -- gen_context(system_u:object_r:portage_log_t,s0) /var/log/portage(/.*)? gen_context(system_u:object_r:portage_log_t,s0) +/var/lib/layman(/.*)? gen_context(system_u:object_r:layman_var_lib_t,s0) /var/lib/portage(/.*)? gen_context(system_u:object_r:portage_cache_t,s0) /var/tmp/portage(/.*)? gen_context(system_u:object_r:portage_tmp_t,s0) /var/tmp/portage-pkg(/.*)? gen_context(system_u:object_r:portage_tmp_t,s0)policy/modules/admin/portage.if +5
-1@@ -16,6 +16,7 @@ interface(`portage_domtrans',` gen_require(` type portage_t, portage_exec_t; + type layman_t, layman_exec_t; ') files_search_usr($1)@@ -23,6 +24,8 @@ interface(`portage_domtrans',` # transition to portage domtrans_pattern($1, portage_exec_t, portage_t) + # transition to layman + domtrans_pattern($1, layman_exec_t, layman_t) ') ########################################@@ -45,10 +48,11 @@ interface(`portage_domtrans',` interface(`portage_run',` gen_require(` type portage_t, portage_fetch_t, portage_sandbox_t; + type layman_t; ') portage_domtrans($1) - role $2 types { portage_t portage_fetch_t portage_sandbox_t }; + role $2 types { portage_t portage_fetch_t portage_sandbox_t layman_t }; ') ########################################policy/modules/admin/portage.te +60
-0@@ -9,6 +9,16 @@ type gcc_config_t; type gcc_config_exec_t; application_domain(gcc_config_t, gcc_config_exec_t) +type layman_t; +type layman_exec_t; +application_domain(layman_t, layman_exec_t) + +type layman_tmp_t; +files_tmp_file(layman_tmp_t) + +type layman_var_lib_t; +files_type(layman_var_lib_t) + # constraining type type portage_t; type portage_exec_t;@@ -115,6 +125,56 @@ optional_policy(` ######################################## # +# Layman local policy +# +allow layman_t self:process signal; +allow layman_t self:fifo_file rw_fifo_file_perms; + +# Manage layman var/lib files +manage_files_pattern(layman_t, layman_var_lib_t, layman_var_lib_t) +manage_dirs_pattern(layman_t, layman_var_lib_t, layman_var_lib_t) +manage_lnk_files_pattern(layman_t, layman_var_lib_t, layman_var_lib_t) + +# Manage layman tmp files (needed in case of subversion) +manage_dirs_pattern(layman_t, layman_tmp_t, layman_tmp_t) +manage_files_pattern(layman_t, layman_tmp_t, layman_tmp_t) +files_tmp_filetrans(layman_t, layman_tmp_t, { file dir }) + + +kernel_dontaudit_read_system_state(layman_t) +kernel_dontaudit_request_load_module(layman_t) + +corecmd_exec_bin(layman_t) +corecmd_exec_shell(layman_t) + +corenet_sendrecv_generic_client_packets(layman_t) +corenet_sendrecv_git_client_packets(layman_t) +corenet_sendrecv_http_client_packets(layman_t) +corenet_sendrecv_rsync_client_packets(layman_t) +corenet_tcp_connect_generic_port(layman_t) +corenet_tcp_connect_git_port(layman_t) +corenet_tcp_connect_http_port(layman_t) +corenet_tcp_connect_rsync_port(layman_t) + +domain_use_interactive_fds(layman_t) + +files_read_etc_files(layman_t) +files_read_etc_runtime_files(layman_t) +files_read_usr_files(layman_t) +files_search_var_lib(layman_t) + + +logging_list_logs(layman_t) +miscfiles_read_localization(layman_t) +sysnet_dns_name_resolve(layman_t) +userdom_dontaudit_list_user_home_dirs(layman_t) +userdom_use_user_terminals(layman_t) + + +rsync_exec(layman_t) + +######################################## +# # Portage Merging Rules #
Signature · 3 lines
Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com
PATCH 1/4 Support layman through its own domain
Quoted 6 lines · Christopher J. PeBenito
Have you considered transitioning to
portage_fetch_tfor the fetch? Since there already is SELinux aware code in portage, it seems like it would be easy to get that into layman, especially if layman uses portage libraries (I don't know if it does). ?Alternatively, you could try transitioning toportage_fetch_twhen running layman; its been a while since I used it, so I'm not completely sure if that makes sense.
We tried launching layman within portage_fetch_t, but that required too many additions to the portage_fetch_t domain itself. We might be able to make layman SELinux-aware and transition from layman_t to portage_fetch_t, but that will take some time (layman is developed by other developers than Portage and I'm not sure who to contact for adding SELinux support within the application - I'm myself not experienced enough to take that on me, I'm just a policy writer ;-)
Wkr,
Sven Vermeulen
PATCH 1/4 Support layman through its own domain
Quoted 7 lines · Sven Vermeulen
We tried launching layman within
portage_fetch_t, but that required too many additions to theportage_fetch_tdomain itself. We might be able to make layman SELinux-aware and transition fromlayman_ttoportage_fetch_t, but that will take some time (layman is developed by other developers than Portage and I'm not sure who to contact for adding SELinux support within the application - I'm myself not experienced enough to take that on me, I'm just a policy writer ;-)
Well, considering that we will need to take a stab at putting emerge-webrsync in portage_fetch_t too, I'll see if I can make it so that layman works within that domain as well.
Wkr,
Sven Vermeulen
PATCH 2/4 Support emerge-webrsync through portage domain
In reply to Sven VermeulenThe emerge-webrsync application fetches snapshots (archives), extracts them and then synchronizes the local tree with the snapshot. It uses portage code (and libraries) to do so, but is implemented as a wrapper as it also offers the possibility of verifying the GPG signature of the snapshot first.
By putting emerge-webrsync in portage' domain, it is handled through the regular portage_run() and portage_domtrans() methods. It is also necessary to put it in this domain for unattended/automated calls, such as through cron and puppet.
--- policy/modules/admin/portage.fc | 2 ++ policy/modules/admin/portage.te | 4 ++++ 2 files changed, 6 insertions(+), 0 deletions(-)
policy/modules/admin/portage.fc +2 -0
@@ -8,6 +8,7 @@ /usr/lib(64)?/portage/bin/ebuild -- gen_context(system_u:object_r:portage_exec_t,s0) /usr/lib(64)?/portage/bin/emerge -- gen_context(system_u:object_r:portage_exec_t,s0) +/usr/lib(64)?/portage/bin/emerge-webrsync -- gen_context(system_u:object_r:portage_exec_t,s0) /usr/lib(64)?/portage/bin/quickpkg -- gen_context(system_u:object_r:portage_exec_t,s0) /usr/lib(64)?/portage/bin/ebuild\.sh -- gen_context(system_u:object_r:portage_exec_t,s0) /usr/lib(64)?/portage/bin/regenworld -- gen_context(system_u:object_r:portage_exec_t,s0)
@@ -22,5 +23,6 @@ /var/log/portage(/.*)? gen_context(system_u:object_r:portage_log_t,s0) /var/lib/layman(/.*)? gen_context(system_u:object_r:layman_var_lib_t,s0) /var/lib/portage(/.*)? gen_context(system_u:object_r:portage_cache_t,s0) +/var/tmp/emerge-webrsync(/.*)? gen_context(system_u:object_r:portage_tmp_t,s0) /var/tmp/portage(/.*)? gen_context(system_u:object_r:portage_tmp_t,s0) /var/tmp/portage-pkg(/.*)? gen_context(system_u:object_r:portage_tmp_t,s0)
policy/modules/admin/portage.te +4 -0
@@ -239,6 +239,10 @@ optional_policy(` ') optional_policy(` + gpg_domtrans(portage_t) +') + +optional_policy(` modutils_domtrans_depmod(portage_t) modutils_domtrans_update_mods(portage_t) #dontaudit update_modules_t portage_tmp_t:dir search_dir_perms;
Signature · 1 line
1.7.3.4
PATCH 2/4 Support emerge-webrsync through portage domain
Quoted 9 lines · Sven Vermeulen
The emerge-webrsync application fetches snapshots (archives), extracts them and then synchronizes the local tree with the snapshot. It uses portage code (and libraries) to do so, but is implemented as a wrapper as it also offers the possibility of verifying the GPG signature of the snapshot first.
By putting emerge-webrsync in portage' domain, it is handled through the regular
portage_run()andportage_domtrans()methods. It is also necessary to put it in this domain for unattended/automated calls, such as through cron and puppet.
It seems like we would want this to run in portage_fetch_t instead.
Quoted 40 lines
Signed-off-by Sven Vermeulen<[email protected]>--- policy/modules/admin/portage.fc | 2 ++ policy/modules/admin/portage.te | 4 ++++ 2 files changed, 6 insertions(+), 0 deletions(-)policy/modules/admin/portage.fc +2
-0@@ -8,6 +8,7 @@ /usr/lib(64)?/portage/bin/ebuild -- gen_context(system_u:object_r:portage_exec_t,s0) /usr/lib(64)?/portage/bin/emerge -- gen_context(system_u:object_r:portage_exec_t,s0) +/usr/lib(64)?/portage/bin/emerge-webrsync -- gen_context(system_u:object_r:portage_exec_t,s0) /usr/lib(64)?/portage/bin/quickpkg -- gen_context(system_u:object_r:portage_exec_t,s0) /usr/lib(64)?/portage/bin/ebuild\.sh -- gen_context(system_u:object_r:portage_exec_t,s0) /usr/lib(64)?/portage/bin/regenworld -- gen_context(system_u:object_r:portage_exec_t,s0)@@ -22,5 +23,6 @@ /var/log/portage(/.*)? gen_context(system_u:object_r:portage_log_t,s0) /var/lib/layman(/.*)? gen_context(system_u:object_r:layman_var_lib_t,s0) /var/lib/portage(/.*)? gen_context(system_u:object_r:portage_cache_t,s0) +/var/tmp/emerge-webrsync(/.*)? gen_context(system_u:object_r:portage_tmp_t,s0) /var/tmp/portage(/.*)? gen_context(system_u:object_r:portage_tmp_t,s0) /var/tmp/portage-pkg(/.*)? gen_context(system_u:object_r:portage_tmp_t,s0)policy/modules/admin/portage.te +4
-0@@ -239,6 +239,10 @@ optional_policy(` ') optional_policy(` + gpg_domtrans(portage_t) +') + +optional_policy(` modutils_domtrans_depmod(portage_t) modutils_domtrans_update_mods(portage_t) #dontaudit update_modules_t portage_tmp_t:dir search_dir_perms;
Signature · 3 lines
Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com
PATCH 3/4 Allow emerge-webrsync to copy extracted files to the tree
In reply to Sven VermeulenThe emerge-webrsync application, part of Portage, is responsible for fetching a tree snapshot, having it extracted in a temporary location (portage_tmp_t) and then copied over to the main portage tree. However, its domain (portage_fetch_t) has no read rights on the temporary location.
To allow this, we need to define an interface (portage_read_tmp_files) since we need to allow this both to portage_fetch_t (the emerge-webrsync application) as well as gpg (to verify the GnuPG signature of the downloaded snapshot).
Also, portage_read_tmp_files doesn't use read_files_pattern since the read-permission on the dir class is needed too.
--- policy/modules/admin/portage.if | 19 +++++++++++++++++++ policy/modules/admin/portage.te | 3 +++ policy/modules/apps/gpg.te | 4 ++++ 3 files changed, 26 insertions(+), 0 deletions(-)
policy/modules/admin/portage.if +19 -0
@@ -250,6 +250,25 @@ interface(`portage_run_gcc_config',` ######################################## ## <summary> +## Allow a domain to read portage_tmp_t files +## </summary> +## <param name="domain"> +## <summary> +## Domain to allow search privileges +## </summary> +## </param> +# +interface(`portage_read_tmp_files',` + gen_require(` + type portage_tmp_t; + ') + + allow $1 portage_tmp_t:dir list_dir_perms; + allow $1 portage_tmp_t:file read_file_perms; +') + +######################################## +## <summary> ## Do not audit attempts to search the ## portage temporary directories. ## </summary>
policy/modules/admin/portage.te +3 -0
@@ -322,6 +322,9 @@ sysnet_dns_name_resolve(portage_fetch_t) userdom_use_user_terminals(portage_fetch_t) userdom_dontaudit_read_user_home_content_files(portage_fetch_t) + +portage_read_tmp_files(portage_fetch_t) + ifdef(`hide_broken_symptoms',` dontaudit portage_fetch_t portage_cache_t:file read; ')
policy/modules/apps/gpg.te +4 -0
@@ -147,6 +147,10 @@ optional_policy(` ') optional_policy(` + portage_read_tmp_files(gpg_t) +') + +optional_policy(` xserver_use_xdm_fds(gpg_t) xserver_rw_xdm_pipes(gpg_t) ')
Signature · 1 line
1.7.3.4
PATCH 4/4 Allow gpg to search through portage configuration files
In reply to Sven VermeulenWhen working with signed snapshots, the GnuPG keystore is usually stored in /etc/portage/gpg. Although the location itself can (and through this patch is) labeled as gpg_secret_t, gpg does need search privileges to the parent directories (in this case, /etc/portage as /etc is already implied through gpg policy).
We create an interface called portage_search_conf which grants exactly these privileges and assign it to gpg_t.
--- policy/modules/admin/portage.if | 21 +++++++++++++++++++++ policy/modules/apps/gpg.fc | 2 ++ policy/modules/apps/gpg.te | 1 + 3 files changed, 24 insertions(+), 0 deletions(-)
policy/modules/admin/portage.if +21 -0
@@ -269,6 +269,27 @@ interface(`portage_read_tmp_files',` ######################################## ## <summary> +## Allow a domain search privileges through portage_conf_t +## </summary> +## <param name="domain"> +## <summary> +## Domain to allow search privileges +## </summary> +## </param> +# +interface(`portage_search_conf',` + gen_require(` + type portage_conf_t; + ') + + allow $1 portage_conf_t:dir search_dir_perms; +') + + + + +######################################## +## <summary> ## Do not audit attempts to search the ## portage temporary directories. ## </summary>
policy/modules/apps/gpg.fc +2 -0
@@ -1,5 +1,7 @@ HOME_DIR/\.gnupg(/.+)? gen_context(system_u:object_r:gpg_secret_t,s0) +/etc/portage/gpg(/.*)? gen_context(system_u:object_r:gpg_secret_t,s0) + /usr/bin/gpg(2)? -- gen_context(system_u:object_r:gpg_exec_t,s0) /usr/bin/gpg-agent -- gen_context(system_u:object_r:gpg_agent_exec_t,s0) /usr/bin/kgpg -- gen_context(system_u:object_r:gpg_exec_t,s0)
policy/modules/apps/gpg.te +1 -0
@@ -148,6 +148,7 @@ optional_policy(` optional_policy(` portage_read_tmp_files(gpg_t) + portage_search_conf(gpg_t) ') optional_policy(`
Signature · 1 line
1.7.3.4