From: domg472@gmail.com (Dominick Grift) Date: Tue, 25 Jan 2011 20:19:33 +0100 Subject: [refpolicy] [PATCH/RFC 8/19]: patch set to update the git reference policy In-Reply-To: <1295982348.11770.16.camel@tesla.lan> References: <1295829851.3862.67.camel@tesla.lan> <4D3D8703.8040308@gmail.com> <1295982348.11770.16.camel@tesla.lan> Message-ID: <4D3F2245.9090606@gmail.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/25/2011 08:05 PM, Guido Trentalancia wrote: > Hi Dominick, > > finally I am managing to get into this... > > On Mon, 24/01/2011 at 15.04 +0100, Dominick Grift wrote: >> On 01/24/2011 01:44 AM, Guido Trentalancia wrote: >>> --- refpolicy-git-18012011-dbus-messaging/policy/modules/services/dbus.te 2011-01-23 23:13:48.168284256 +0100 >>> +++ refpolicy-git-18012011-dbus/policy/modules/services/dbus.te 2011-01-23 23:11:46.430346876 +0100 >>> @@ -52,7 +52,7 @@ ifdef(`enable_mls',` >>> >>> # dac_override: /var/run/dbus is owned by messagebus on Debian >>> # cjp: dac_override should probably go in a distro_debian >>> -allow system_dbusd_t self:capability { dac_override setgid setpcap setuid }; >>> +allow system_dbusd_t self:capability { dac_override setgid setpcap setuid sys_ptrace }; >>> dontaudit system_dbusd_t self:capability sys_tty_config; >>> allow system_dbusd_t self:process { getattr getsched signal_perms setpgid getcap setcap }; >>> allow system_dbusd_t self:fifo_file rw_fifo_file_perms; >>> @@ -111,13 +111,20 @@ auth_read_pam_console_data(system_dbusd_ >>> corecmd_list_bin(system_dbusd_t) >>> corecmd_read_bin_pipes(system_dbusd_t) >>> corecmd_read_bin_sockets(system_dbusd_t) >>> +# needed for system-tools-backends >>> +corecmd_exec_shell(system_dbusd_t) >>> >>> domain_use_interactive_fds(system_dbusd_t) >>> domain_read_all_domains_state(system_dbusd_t) >>> >>> +files_search_default(system_dbusd_t) >> >> There should not be able default_t type directories. Thus this shouldnt >> be allowed > > Apparently, I am no longer able to find the relative log. Best thing to > do in this case is to remove and test again. > >>> +files_read_default_files(system_dbusd_t) >> >> there should not be any default_t type files. Thus this shouldnt be allowed > > Same as above. Hopefully, we'll be able to get rid of that... > >>> files_read_etc_files(system_dbusd_t) >>> files_list_home(system_dbusd_t) >>> -files_read_usr_files(system_dbusd_t) >>> +files_exec_bin_files(system_dbusd_t) >> >> Which bin_t files is it executing? > > I think dbus-daemon-launch-helper is executing polkitd which is labelled > bin_t: > > type=AVC msg=audit(1294683706.729:33): avc: denied > { execute_no_trans } for pid=2718 comm="dbus-daemon-lau" > path="/usr/libexec/polkit-1/polkitd" dev=dm-1 ino=396675 > scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 > tcontext=system_u:object_r:bin_t:s0 tclass=file > /usr/libexec/polkit-1/polkitd is labelled policykit_exec_t here. Then one should decide whether to allow system_dbusd_t to run it in the system_dbusd_t domain or to allow it to domain transition to policykit_t This depends on what dbus is doing with policykit >>> +files_exec_usr_files(system_dbusd_t) >> >> Which usr_t files is it executing? > > It's needed to execute a perl script from system-tools-backends (version > 2.10.1) which is located at: > > /usr/share/system-tools-backends-2.0/scripts/SystemToolsBackends.pl > This could be labelled bin_t. Maybe even write policy for it if applicable (probably a good idea so that we do not have to allow system_dbusd_t to run bin_t files (corecmd_exec_bin) What package does this file belong to? > and this is the log: > > type=AVC msg=audit(1294879948.810:42): avc: denied { execute } for > pid=2966 comm="dbus-daemon-lau" name="SystemToolsBackends.pl" dev=dm-1 > ino=442334 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 > tcontext=system_u:object_r:usr_t:s0 tclass=file > > for the moment I have just written a comment in the TE file. Otherwise, > we should relabel the perl script. What do you suggest ? > >>> +files_read_var_lib_files(system_dbusd_t) >>> +files_var_log_append(system_dbusd_t) >> >> Which log is it appending to? > > Can't find the logs. Again, I can remove and test again, so we might get > a better insight. Will let you know shortly. > >>> init_use_fds(system_dbusd_t) >>> init_use_script_ptys(system_dbusd_t) >>> @@ -141,6 +148,7 @@ optional_policy(` >>> ') >>> >>> optional_policy(` >>> + consolekit_read_pid_files(system_dbusd_t) >>> consolekit_dbus_send(system_dbusd_t) >>> ') > > Regards, > > Guido > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk0/IkUACgkQMlxVo39jgT9oIQCdF6EErCKBCYLjcYRDetjiqeqz 4zoAoKLxifXrpJ/SDGxPotOeeGstD1Uc =g4hH -----END PGP SIGNATURE-----