From mboxrd@z Thu Jan 1 00:00:00 1970
From: guido@trentalancia.com (Guido Trentalancia)
Date: Sat, 29 Jan 2011 02:32:20 +0100
Subject: [refpolicy] [PATCH/RFC 8/19]: patch set to update the git
reference policy
In-Reply-To: <4D41D8AA.2020707@gmail.com>
References: <1295829851.3862.67.camel@tesla.lan>
<4D3D8703.8040308@gmail.com> <1295982348.11770.16.camel@tesla.lan>
<4D3F2245.9090606@gmail.com> <1296002515.16768.18.camel@tesla.lan>
<4D3FD8B5.9030306@gmail.com> <1296062881.3028.18.camel@tesla.lan>
<4D405B81.9050608@gmail.com> <1296088632.15344.34.camel@tesla.lan>
<4D4137E9.9050805@gmail.com> <1296160570.12677.7.camel@tesla.lan>
<4D41D8AA.2020707@gmail.com>
Message-ID: <1296264740.3113.16.camel@tesla.lan>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com
Hi Dominick !
Thanks so much for getting again back to me with your comments and much
valuable suggestions !
On Thu, 27/01/2011 at 21.42 +0100, Dominick Grift wrote:
> >>>>>>> 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 ?
> >>>>>>>
> >>>>>>
> >>>>>> I guess you need to add this to policykit module:
> >>>>>>
> >>>>>> dbus_system_domain(policykit_t, policykit_exec_t)
> >>>>>
> >>>>> I am now going to test what you propose as an alternative to using a
> >>>>> policykit_can_execute() interface.
> >>>>>
> >>>>>>>>>>> +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.
> >>>>>>
> >>>>>> Yes but if you write policy for this then we may not need to allow dbus
> >>>>>> access to execute generic bin files.
> >>>>>>
> >>>>>> Although eventually we will probably have to allow it that anyways
> >>>>>
> >>>>> Yes. The DBus module needs { read open execute } permissions for
> >>>>> executing python in the system_dbusd_t domain. And that is bin_t:file,
> >>>>> so there is little it can be done to get around this issue.
> >
> > What do you say about the latest issue mentioned above ? Apparently
> > execute_no_trans in not enough for dbus to execute python. It is also
> > requiring the execute permission. So I thought domain transition could
> > help.
>
> i do not think dbusd_system_t needs access to either execute bin_t files
> or shell_exec_t files. I think that issue may or may not be caused when
> you ran policy kit or system_tools in the dbusd_system_t domain.
No, DBus doesn't need to execute bin_t and shell_exec_t files, but this
is required by system-tools-backed (see this piece of audit):
type=AVC msg=audit(1296262894.482:20): avc: denied { execute } for
pid=2933 comm="SystemToolsBack" name="bash" dev=dm-1 ino=208876
scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:shell_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1296262894.482:20): arch=40000003 syscall=11
success=no exit=-13 a0=b772fded a1=bfae4d9c a2=9d50d38 a3=10 items=0
ppid=2924 pid=2933 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0
egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="SystemToolsBack"
exe="/usr/bin/perl" subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
key=(null)
type=AVC msg=audit(1296262894.494:21): avc: denied { execute } for
pid=2934 comm="SystemToolsBack" name="bash" dev=dm-1 ino=208876
scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:shell_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1296262894.494:21): arch=40000003 syscall=11
success=no exit=-13 a0=b7709ded a1=bf912e8c a2=88fcd38 a3=10 items=0
ppid=2925 pid=2934 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0
egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="SystemToolsBack"
exe="/usr/bin/perl" subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
key=(null)
We had agreed that the SystemTooBackend.pl script had to be labelled
bin_t, so that's what happens next.
Otherwise, since a specific module for system-tools-backends is not
present in refpolicy and since it is auxiliary, then the best thing to
do is to probably drop all of this from the changes.
Executing polkitd with a domain transition led to the need of writing
changes for the policykit module. This is the best solution. Briefly,
here is what changed there:
--- refpolicy-git-24012011/policy/modules/services/policykit.te 2011-01-08 19:07:21.281747514 +0100
+++ refpolicy-git-24012011-new/policy/modules/services/policykit.te 2011-01-29 02:06:11.984160210 +0100
@@ -35,8 +35,8 @@ files_pid_file(policykit_var_run_t)
# policykit local policy
#
-allow policykit_t self:capability { setgid setuid };
-allow policykit_t self:process getattr;
+allow policykit_t self:capability { setgid setuid sys_ptrace };
+allow policykit_t self:process { getattr getsched signal };
allow policykit_t self:fifo_file rw_file_perms;
allow policykit_t self:unix_dgram_socket create_socket_perms;
allow policykit_t self:unix_stream_socket create_stream_socket_perms;
@@ -57,9 +57,11 @@ manage_files_pattern(policykit_t, policy
files_pid_filetrans(policykit_t, policykit_var_run_t, { file dir })
kernel_read_kernel_sysctls(policykit_t)
+kernel_read_system_state(policykit_t)
files_read_etc_files(policykit_t)
files_read_usr_files(policykit_t)
+files_read_var_lib_files(policykit_t)
auth_use_nsswitch(policykit_t)
@@ -69,6 +71,23 @@ miscfiles_read_localization(policykit_t)
userdom_read_all_users_state(policykit_t)
+optional_policy(`
+ consolekit_read_pid_files(policykit_t)
+')
+
+optional_policy(`
+ dbus_system_domain(policykit_t, policykit_exec_t)
+')
+
+optional_policy(`
+ gnome_read_config(policykit_t)
+')
+
+optional_policy(`
+ xserver_read_xdm_files(policykit_t)
+ xserver_xdm_dbus_send(policykit_t)
+')
+
########################################
#
# polkit_auth local policy
--- refpolicy-git-24012011/policy/modules/services/policykit.if 2011-01-08 19:07:21.281747514 +0100
+++ refpolicy-git-24012011-new/policy/modules/services/policykit.if 2011-01-28 09:08:23.971309454 +0100
@@ -2,6 +2,26 @@
########################################
##
+## Send a dbus message to
+## policykit.
+##
+##
+##
+## Domain allowed access.
+##
+##
+#
+interface(`policykit_dbus_send',`
+ gen_require(`
+ type policykit_t;
+ class dbus send_msg;
+ ')
+
+ allow $1 policykit_t:dbus send_msg;
+')
+
+########################################
+##
## Send and receive messages from
## policykit over dbus.
##
--- refpolicy-git-24012011/policy/modules/apps/gnome.fc 2011-01-08 19:07:21.179731404 +0100
+++ refpolicy-git-24012011-new/policy/modules/apps/gnome.fc 2011-01-28 10:00:28.356571615 +0100
@@ -1,4 +1,4 @@
-HOME_DIR/\.config/gtk-.* gen_context(system_u:object_r:gnome_home_t,s0)
+HOME_DIR/\.config(/.*)? gen_context(system_u:object_r:gnome_home_t,s0)
HOME_DIR/\.gconf(d)?(/.*)? gen_context(system_u:object_r:gconf_home_t,s0)
HOME_DIR/\.gnome2(/.*)? gen_context(system_u:object_r:gnome_home_t,s0)
With the addition of policykit_dbus_send(xdm_t) as optional policy in
xserver.te (because I am splitting the send_msg permission).
What do you think ? For example, relabelling of the whole
HOME_DIR/.config directory to something other than generic home_t sounds
quite nice to me, as home_t might include personal data of the user and
configuration should not mixed up with that. Now to the best of my
knowledge that .config directory is only used by gnome (and mainly
xdg-user-dirs from freedesktop.org to be more precise).
By the way, I couldn't watch your blog presentations because they
require high-bandwidth from youtube and at the moment I am connected
with just a UMTS mobile phone. Why don't you write up a text document as
PDF or something else that can also be searched and used as a
reference ?
Regards,
Guido