From: guido@trentalancia.com (Guido Trentalancia) Date: Wed, 08 Nov 2017 18:02:23 +0100 Subject: [refpolicy] Refpolicy and gdm/gnome? In-Reply-To: References: <3D043CE5-0E5B-40DD-A0D3-CC08F61E0AFC@trentalancia.com> Message-ID: <0B3603D8-AEBB-4A00-BE81-6ADB31F8672E@trentalancia.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com Hello again. After looking a bit more closely to the permissions that you report (apart from those related to systemd that I don't use), most of them don't look too suspicious. So that is the good news, just I can't explain why xserver_t needs to read staff_t files, which might leak privileged data. Considering that you are reporting more than one labeling error, although it's probably just a sort of systemd or distribution bug, I would recommend a full filesystem relabel before doing anything else... The following ones are a bit odd: allow xdm_t self:capability net_admin; allow xdm_t staff_t:key { link search write }; allow xdm_t sysctl_crypto_t:dir search; allow xdm_t sysctl_crypto_t:file { getattr open read }; allow xdm_t xdm_tmp_t:file execute; You might want to try running the system without the above risky permissions (especially the last one). At the end, if I am running the system without them, then there are good chances you are able to do the same. On the 8th of November 2017 17:32:37 CET, David Sugar via refpolicy wrote: >It doesn't appear that anyone has the ability to remove systemd form >CentOS (or RHEL/Fedora). So I think that is a non-starter. As much as >I agree with you that systemd adds a lot of complexity, I'm in an >environment where I am stuck with it. What distribution are you >running? > >I will begin working on policy for these denials and submit patches >back to the list as I get things working. > >Thanks, >Dave > >> -----Original Message----- >> From: refpolicy-bounces at oss.tresys.com [mailto:refpolicy- >> bounces at oss.tresys.com] On Behalf Of Guido Trentalancia via refpolicy >> Sent: Wednesday, November 08, 2017 9:36 AM >> To: refpolicy at oss.tresys.com >> Subject: Re: [refpolicy] Refpolicy and gdm/gnome? >> >> I forgot to add something... See below. >> >> On the 8th of November 2017 04:04:15 CET, David Sugar via refpolicy >> wrote: >> >I'm setting up a CentOS 7.3 (soon to be 7.4) system with refpolicy >and >> >trying to start GDM/Gnome. While in permissive I'm seeing a bunch >of >> >denials related to xdm_t (enforcing the greeter never starts). I'm >> >happy to go through and fix these things to get stuff working. I >just >> >want to make sure that before I begin adding additional rules to >allow >> >the items I'm seeing that I'm not just missing something (a boolean >set >> >incorrectly or a missing module or something else?). I was kind of >> >assuming that this would just work but maybe that isn't the case. >> > >> >Here are the denials I'm seeing. Any thoughts? >> > >> >#============= colord_t ============== >> >allow colord_t systemd_sessions_var_run_t:file { getattr open read >}; >> >allow colord_t xdm_t:dir search; allow colord_t xdm_t:file { getattr >> >open read }; >> > >> >#============= init_t ============== >> >allow init_t xdm_t:dbus send_msg; >> > >> >#============= initrc_t ============== >> >allow initrc_t xdm_t:dbus send_msg; >> >allow initrc_t xdm_t:process getsched; >> > >> >#============= systemd_locale_t ============== allow >systemd_locale_t >> >xdm_t:dbus send_msg; >> > >> >#============= systemd_logind_t ============== allow >systemd_logind_t >> >crond_t:dbus send_msg; allow systemd_logind_t crond_t:dir search; >allow >> >systemd_logind_t crond_t:file { getattr open read }; allow >> >systemd_logind_t init_t:service stop; allow systemd_logind_t >> >init_var_run_t:service { start status }; allow systemd_logind_t >> >tmpfs_t:dir { remove_name write }; >> > >> >#!!!! The file '/run/user/42' is mislabeled on your system. >> >#!!!! Fix with $ restorecon -R -v /run/user/42 >> >> You should fix the above labels. As far as I know, systemd is >supposed >> to relabel /run/user/, but eventually something didn't work on your >> system, so you should find another way to relabel, especially if as >> suggested you are going to run without systemd. >> >> >allow systemd_logind_t user_runtime_root_t:dir mounton; allow >> >systemd_logind_t user_tmpfs_t:dir { remove_name rmdir write }; allow >> >systemd_logind_t user_tmpfs_t:file unlink; allow systemd_logind_t >> >xdm_tmpfs_t:dir { getattr open read remove_name rmdir write }; allow >> >systemd_logind_t xdm_tmpfs_t:file unlink; allow systemd_logind_t >> >xdm_tmpfs_t:sock_file unlink; >> > >> >#============= systemd_sessions_t ============== >> > >> >#!!!! The file '/run/systemd/journal/socket' is mislabeled on your >> >system. >> >#!!!! Fix with $ restorecon -R -v /run/systemd/journal/socket allow >> >systemd_sessions_t kernel_t:unix_dgram_socket sendto; >> > >> >#============= xdm_t ============== >> >allow xdm_t dbusd_exec_t:file { execute execute_no_trans open read >}; >> >allow xdm_t init_t:dbus send_msg; allow xdm_t init_t:system status; >> >allow xdm_t initrc_t:dbus send_msg; >> > >> >#!!!! The file '/run/systemd/journal/stdout' is mislabeled on your >> >system. >> >#!!!! Fix with $ restorecon -R -v /run/systemd/journal/stdout allow >> >xdm_t kernel_t:unix_stream_socket connectto; allow xdm_t >> >self:capability net_admin; allow xdm_t >> >self:netlink_kobject_uevent_socket { bind create getattr read setopt >}; >> >allow xdm_t self:netlink_selinux_socket { bind create }; allow xdm_t >> >self:process setcap; allow xdm_t sound_device_t:chr_file { ioctl >open >> >read write }; allow xdm_t staff_t:key { link search write }; allow >> >xdm_t sysctl_crypto_t:dir search; allow xdm_t sysctl_crypto_t:file { >> >getattr open read }; allow xdm_t sysctl_vm_overcommit_t:file { open >> >read }; allow xdm_t sysctl_vm_t:dir search; allow xdm_t >> >systemd_locale_t:dbus send_msg; allow xdm_t >> >systemd_logind_var_run_t:dir read; allow xdm_t >> >systemd_logind_var_run_t:fifo_file write; allow xdm_t >> >systemd_machined_var_run_t:dir read; allow xdm_t >> >systemd_sessions_var_run_t:dir { open read }; allow xdm_t >> >systemd_sessions_var_run_t:file { getattr open read }; allow xdm_t >> >udev_var_run_t:file { getattr open read }; >> > >> >#!!!! This avc can be allowed using the boolean >> >'allow_polyinstantiation' >> >allow xdm_t user_home_dir_t:dir create; allow xdm_t >> >user_home_dir_t:file { append create open read setattr write }; >allow >> >xdm_t wm_exec_t:file { execute execute_no_trans getattr open read }; >> >allow xdm_t xdm_tmp_t:file execute; allow xdm_t xkb_var_lib_t:dir >> >search; allow xdm_t xkb_var_lib_t:file { getattr open read }; >> > >> >#============= xserver_t ============== allow xserver_t >self:capability >> >sys_ptrace; allow xserver_t staff_t:file { open read }; allow >xserver_t >> >staff_t:lnk_file read; allow xserver_t xdm_t:file { open read }; >allow >> >xserver_t xdm_t:lnk_file read; >> > >> > >> >Thanks, >> >Dave Syugar >> >dsugar at tresys.com Regards, Guido