From: domg472@gmail.com (Dominick Grift) Date: Sat, 29 Jan 2011 09:31:33 +0100 Subject: [refpolicy] [PATCH/RFC 8/19]: patch set to update the git reference policy In-Reply-To: <1296272982.3054.33.camel@tesla.lan> 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> <1296264740.3113.16.camel@tesla.lan> <4D42F677.2060805@gmail.com> <1296239917.3070.14.camel@tesla.lan> <4D430F5C.4090700@gmail.com> <1296272982.3054.33.camel@tesla.lan> Message-ID: <4D43D065.9030200@gmail.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/29/2011 04:49 AM, Guido Trentalancia wrote: > On Fri, 28/01/2011 at 19.47 +0100, Dominick Grift wrote: >> On 01/28/2011 07:38 PM, Guido Trentalancia wrote: >>> On Fri, 28/01/2011 at 18.01 +0100, Dominick Grift wrote: >>>> On 01/29/2011 02:32 AM, Guido Trentalancia wrote: >>>>> 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. >>>>> >>>> >>>> We need to figure out what exactly runs this file "SystemToolsBack" and >>>> SystemTooBackend.pl. If it is really dbus like the avc denial above >>>> suggest then we should confine it (make a dbus_system_domain). >> >> any news on this? > > Oops, sorry, forgot to reply on that. SystemToolsBackend.pl is a perl > script being run by dbus after the latter has read the relative .service > files which are generally placed in /usr/share/dbus-1/system-services > > Dbus might also run the binary > executable /usr/sbin/system-tools-backends which at the moment is > labelled generically bin_t so needs corecmd_exec_bin call. We need to create a new module/domain for this suite in my biew > I don't think a dbus_system_domain() call is possible at the moment > because there is no module (and no domain, no contexts) for s-t-b (let's > call system-tools-backends that way for short). > > This will be probably carried out in a future set of patches which aim > to target less essential things. For the moment, I would just drop any > support for s-t-b as corecmd_exec_{bin,shell} for DBus might not be > desirable for everyone and s-t-b is not essential for running X and > gnome. > >>>>> 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) >>>> >>>> What is this file exaclty? >>> >>> Stuff in /var/lib/polkit-1 is all labelled generic var_lib_t. >>> >> >> so that is obviously mislabeled. and this this should not be allowed. >> >> /var/lib/polkit-1(/.*)? >> gen_context(system_u:object_r:policykit_var_lib_t,s0) > > Indeed ! > > --- refpolicy-git-24012011/policy/modules/services/policykit.fc 2011-01-08 19:07:21.280747356 +0100 > +++ refpolicy-git-24012011-new/policy/modules/services/policykit.fc 2011-01-29 03:56:39.452384582 +0100 > @@ -11,5 +11,6 @@ > /var/lib/misc/PolicyKit.reload gen_context(system_u:object_r:policykit_reload_t,s0) > /var/lib/PolicyKit(/.*)? gen_context(system_u:object_r:policykit_var_lib_t,s0) > /var/lib/PolicyKit-public(/.*)? gen_context(system_u:object_r:policykit_var_lib_t,s0) > +/var/lib/polkit-1(/.*)? gen_context(system_u:object_r:policykit_var_lib_t,s0) > /var/run/PolicyKit(/.*)? gen_context(system_u:object_r:policykit_var_run_t,s0) > > Hmm. Refpolicy will look much better after all this work ! > >>>>> 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) >>>> >>>> Which file/dirs is it reading exactly? >>> >>> Just HOME_DIR/.config/user-dirs.* so far. I don't think it won't ever >>> need to read anything else. >>> >>>> This (~/.config) is not really gnome owned. It is XDG freedesktop base >>>> directory standard. Also used by KDE etc (not gnome specific) >>>> >>>> Either leave that labelled user_home_t or implement it in a more neutral >>>> way. (i added a new xdg module which can be used even if gnome /or gnome >>>> module is not installed (example kde or whatever other gui) >>>> >>>>> +') >>>>> + >>>>> +optional_policy(` >>>>> + xserver_read_xdm_files(policykit_t) >>>> >>>> it probably also need xserver_append_xdm_home_files() altough that might >>>> currently be dontaudited in refpolicy >>>> >>>>> + xserver_xdm_dbus_send(policykit_t) >>>> >>>> You will probably want to nest this optional policy block in the >>>> optional_policy block that has the dbus_system_domain call. >>>> >>>> example: >>>> >>>> optional_policy(` >>>> dbus_system_domain(policykit_t, policykit_exec_t) >>>> >>>> optional_policy(` >>>> xserver_read_xdm_files(policykit_t) >>>> xserver_xdm_dbus_send(policykit_t) >>>> ') >>>> ') >>>> Or somthing like this >>> >>> Yes, will look into that possibility. Are you sure that PolicyKit cannot >>> be used with X independently of DBus (apart from the messaging thing) ? >> >> you could also try this: >> >> optional_policy(` >> xserver_read_xdm_files(policykit_t) >> >> optional_policy(` >> xserver_xdm_dbus_send(policykit_t) >> ') >> ') >> >> Athough in these simple cases nesting optionals is often not really >> needed. Yet its good to do it right anyway. > > Hold on a second. But the inner nesting sounds useless to me because > both options are triggered by the presence of the xserver module. optional policy can be confusing and complex issue believe me. But it is important to do it right. I admit that i am also sometimes confused by it so i usually just test and see what works. But my policy is much more complex in many cases and so i often hit optional policy issues. > > Not that it's not going to work, but the above appears to me equivalent > to: > > optional_policy(` > xserver_read_xdm_files(policykit_t) > xserver_xdm_dbus_send(policykit_t) > ') I do not think (but forgive me if i am wrong) that the above is the same. You can have xserver installed and not dbus. for policy kit both may be equally optional. even if you have xserver installed you may still not have dbus installed. > > and so I suppose it will be expanded the same in all possible cases (in > particular the case xserver=module and dbus=off doesn't seem to break > the build). but does it install as well? i guess it just may because the dbus class is in the access vectors file, but if you would remove it also there them it will not work i guess. Anyways this is tough matter. Ive some experience with the complexity of optional policy and so i do what i think is right, to keep stuff as modular as possible. but i admit that i also make errors wrt this. so i may just be wrong. What ever you do make sure it stays as modular as possible. Meaning in this care. would it still work if you do semodule -d dbus? > >>>> Because if dbus_system_domain is unavailable (e.g. if dbus is not >>>> installed or dbus module is disabled), then xserver_xdm_dbus_send wont >>>> be working/or available either. >>>> >>>>> +') >>>>> + >>>>> ######################################## >>>>> # >>>>> # 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) >>>> >>>> ~/.config is not specific to gnome >>>> >>>>> 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). >>> >>> There is a package named xdg-user-dirs-gtk which is in gnome.org. The >>> rest (xdg-user-dirs and utils) is from freedesktop.org. >>> >>> Yes initially my idea was to create something like xdg_config_t. That >>> can still be done, but in gnome.fc as for the first set of patches there >>> is not much time to create extra modules. >> >> Just leave it user_home_t for now. Because we need consensus about this >> first. > > Well we need consensus about everything in this patch set as we cannot > commit ourselves anyway and because, of course, everybody needs to be > happy with it. > > But I bet in this case it will just be a matter of chosing a name... > what else could be argued ? You'd be surprised about all the things that can be argued about. But sure, go ahead and implement what you think is right. I did so as well in my branch. >>> Leaving the whole HOME_DIR/.config as generic home_t doesn't sound quite >>> right to me. One could just relabel what is needed by xdg (user-dirs.*, >>> see above) but then that would still be suboptimal because there is >>> other stuff (from gnome-session, ibus, gnome-disk-utility and so on) >>> which clearly is not generic home content. >>> >>> So shall I go for relabelling the parent dir as xdg_config_t, perhaps >>> leave gtk subdir as gnome_home_t and just default anything else to >>> xdg_config_t ? >>> >>>> i implemented it as a seperate module called xdg. Not just for ~/.config >>>> (config_home_t), but also ~/.cache (cache_home_t) and ~/.local/share >>>> (data_home_t) as per xdg freedesktop base directory specification. >>>> >>>> We need consensus about how to best implement support for XDG. But i >>>> personally do not believe it is a good idea to tie this to gnome. >>>> Because its not gnome specific. >>> >>> Yes, that's fine to me. I am even more happy actually. Does xdm_config_t >>> sound reasonable to you (see above) ? >>> >>>> see my xdg module here: >>>> >>>> http://fedorapeople.org/gitweb?p=domg472/public_git/refpolicy.git;a=tree;f=policy/modules/apps;h=3260ad02daa84f2823b3f063066bd9b02c239498;hb=HEAD >>>> >>>>> 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 ? >>>> >>>> I am not a good writer. I can be a "technical editor" but i am not a >>>> writer. I need someone with documentation experience to collaborate with me. > > Regards, > > Guido > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk1D0GUACgkQMlxVo39jgT+jEACeP9GJcWRP6Ah5ixu/EWcVBc7+ mvEAn2rOQc2IdAmI4uNI8wOPMtIqTYhD =8C5j -----END PGP SIGNATURE-----