From: guido@trentalancia.com (Guido Trentalancia)
Date: Tue, 25 Jan 2011 14:57:45 +0100
Subject: [refpolicy] [PATCH/RFC 8/19]: patch set to update the git
 reference policy
In-Reply-To: <4D3EBC95.1040807@gmail.com>
References: <1295829851.3862.67.camel@tesla.lan>
	<4D3D8703.8040308@gmail.com> <1295913822.1665.28.camel@tesla.lan>
	<4D3E97CF.9090802@gmail.com>  <4D3EBC95.1040807@gmail.com>
Message-ID: <1295963865.1665.65.camel@tesla.lan>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Tue, 25/01/2011 at 13.05 +0100, Dominick Grift wrote:
> On 01/25/2011 10:28 AM, Dominick Grift wrote:
> > On 01/25/2011 01:03 AM, Guido Trentalancia wrote:
> >> Hello Dominick !
> > 
> >> Just a quick comment on the default_t label/permissions, as I still need
> >> to check the rest of this [8/19] comment...
> > 
> >> 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
> >>>
> >>>> +files_read_default_files(system_dbusd_t)
> >>>
> >>> there should not be any default_t type files. Thus this shouldnt be allowed
> > 
> >> The point here is that with the reference policy root's home directory
> >> doesn't get its own label but rather fall back to default_t. This is why
> >> I had created those permissions, although I wasn't completely sure about
> >> it because of course it doesn't appear anywhere else.
> > 
> > 
> > What distro are you testing your policy on? this should not be
> > happening. On non-redhat distros /root should be user_home_dir_t.

It's not a distribution. It's latest Linux components built and
installed by myself.
 
> > It could be that youre using a redhat influence libsemanage. Or maybe
> > that you need to edit semanage,conf

Yes, the latter. Misconfiguration of libsemanage. Should be fixed now. I
will remove all occurrences of default_t permissions.

> > Here is how i solve this issue:
> > 
> > - create a "super user"
> > 
> > useradd $SUPERUSER
> > passwd $SUPERUSER
> > semanage login -a -s staff_u -r s0-s0:c0.c1023 $SUPERUSER
> > 
> > - fix the contexts for /root:
> > 
> > semanage fcontext -a -e /home/$SUPERUSER /root
> > restorecon -R -v /root
> > 
> > - use sudo to get to root shell:
> > 
> > echo "$SUPERUSER ALL=(ALL) ROLE=sysadm_r TYPE=sysadm_t ALL" >
> > /etc/sudoers.d/$SUPERUSER
> > chmod 0440 /etc/sudoers.d/$SUPERUSER

Just restorecon -R /root did the job.

Regards,

Guido