From: guido@trentalancia.com (Guido Trentalancia)
Date: Wed, 26 Jan 2011 01:41:55 +0100
Subject: [refpolicy] [PATCH/RFC 8/19]: patch set to update the git
 reference policy
In-Reply-To: <4D3F2245.9090606@gmail.com>
References: <1295829851.3862.67.camel@tesla.lan>
	<4D3D8703.8040308@gmail.com> <1295982348.11770.16.camel@tesla.lan>
	<4D3F2245.9090606@gmail.com>
Message-ID: <1296002515.16768.18.camel@tesla.lan>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

Hello Dominick !

On Tue, 25/01/2011 at 20.19 +0100, Dominick Grift wrote:
> 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

Yes, that was completely mistaken. Polkitd has now been labeled
correctly and all those weird permissions have been removed from the
dbus module.

However, I had to create an interface policykit_can_execute() and a call
to it from dbus.te so that dbus can still execute polkitd.

> This depends on what dbus is doing with policykit

I think D-Bus is starting polkitd. If that doesn't happen, it would not
be possible to log onto the graphical interface.
polkitd runs in the system_dbusd_t domain. What does refpolicy expect in
this regard from the generic system it targets ?

> >>> +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?

It belongs to system-tools-backends (version 2.10.1), see above.

Yes, I could write more policy, but I would first prefer to get this
committed, otherwise it's pointless and too much stuff at the same time
can be confusing and in turn this could lead to mistakes.

> > 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.

In any case, I had re-invented the wheel with those files_*_var_log_*
interfaces. They are already available in the logging module, so all of
them have now disappeared.

Regards,

Guido