From: domg472@gmail.com (Dominick Grift) Date: Tue, 14 Sep 2010 15:22:43 +0200 Subject: [refpolicy] Policy for Konqueror and KDE v8 In-Reply-To: <201009141418.42992.Nicky726@gmail.com> References: <201009011924.20507.Nicky726@gmail.com> <1284132209.1749.22.camel@jeremy-ubuntu> <201009141418.42992.Nicky726@gmail.com> Message-ID: <4C8F7723.6080205@gmail.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 09/14/2010 02:18 PM, Nicky726 wrote: > Hello, > > first of all thanx for comments, I have incorporated some of them and have a > few questions to others. > > > Dne P? 10. z??? 2010 17:23:29 Jeremy Solt napsal(a): >>> interface(`kde_read_home_files',` >>> >>> gen_require(` >>> >>> type kde_home_t; >>> >>> ') >>> >>> allow $1 kde_home_t:file read_file_perms; >>> allow $1 kde_home_t:dir list_dir_perms; >>> userdom_search_user_home_dirs($) >>> >>> ') >> >> You should use read_files_pattern here, unless list is really needed. > > Correct me if I am wrong, but as kde_home_t files are inside of (one or even > more) kde_home_t directories, the list permission is needed to access them > (directory has to be listed first). list means reading the directory file. The "access" as you put it is done with the search permission, which is included in the read_files_pattern() >>> # Now KDE temp stuff is created with user_tmp_t with more KDE aps >>> confined it'll have the right context. For now grant minimal necessary >>> access to usr temp >> >>> +userdom_read_user_tmp_files(konqueror_t) >>> +userdom_write_user_tmp_files(konqueror_t) >>> +userdom_manage_user_tmp_sockets(konqueror_t) >> >> kde_tmp_t is declared but not used in kde.te, is this the reason for >> these calls? > > Well I came to feeling that the way KDE apps access temp is pretty messed up. > There are at least two types of temp files: those only one application > accesses and those more KDE apps access. None of those has to actually be > there and are created by the first application which needs them. I didn't > realised the troubles with it when developing Konqueror policy, but now as I > try to confine KMail for my diploma paper, I've been quickly hit by them. If > it is Konqueror, which creates shared temp files, they are labelled > konqueror_tmp_t and KMail cannot access them. As there is no guarantee which > application creates those files, I cannot find a way how to classify them in > SELinux. The only working solution I came with is to use only kde_tmp_t type > for all confined KDE apps with full rights to it and at least read/write > access to user_tmp_t. That just doesn't feel right to me though. And moreover > due to xserver_user_x_domain_template needs application tmp type I cannot even > ditch the application tmp types. > > If somebody sees better way out of it, I'd be glad. > Confining the user space (kde/gnome etc) is pretty hard to do. I am not familair with kde so i am not sure how to go about that. I am however familair with gnome and i have gnome confined myself. I think konqueror is a file manager if i am not mistaken so i guess it can be compared to nautilus. I have nautilus confined and it basically needs full access to all user content atleast. You might want to use the file manager to manage files in tmp, tmpfs (less obvious) and user home. In my policy for nautilus is is not nautilus that creates file in tmp, it only uses gconf to create a sock file in /tmp/orbit. Nautilus can be used to start programs which creates files in tmp. So you would allow a prefixed nautilus domain to transition to a prefix application domain. For example i have totem confined. If i click a audio file in my home directory via the file manager (nautilus) then i must make sure nautilus domain transitions to the prefixed totem domain. THen totem will create its files in tmp with the totem tmp file type. Again *really* confining the user space really requires hacks and can become rather complex. I do not think that upstream will adopt the hacks required to achieve a fully confined user space. You will have to set some goals for yourself. How far do you want to go? What is important for you to protect? I have some experience with this and as said my user space is pretty much confined: staff_u:staff_r:staff_t:s0-s0:c0.c1023 360 ? S 0:00 /bin/sh /usr/bin/eclipse staff_u:staff_r:staff_t:s0-s0:c0.c1023 361 ? S 0:00 /usr/lib64/eclipse/eclipse staff_u:staff_r:staff_java_t:s0-s0:c0.c1023 376 ? Sl 18:15 /usr/bin/java -Xms128m -Xmx512m -Dorg.eclipse.equinox.p2.reconciler.dropins.directory=/usr/share/eclipse/dropins -XX:CompileCommand=exclude,org/eclipse/core/internal/dtree/DataTreeNode,forwardDeltaWith -XX:CompileCommand=exclude,org/eclipse/jdt/internal/compiler/lookup/ParameterizedMethodBinding, -XX:CompileCommand=exclude,org/eclipse/cdt/internal/core/dom/parser/cpp/semantics/CPPTemplates,instantiateTemplate -XX:CompileCommand=exclude,org/eclipse/cdt/internal/core/pdom/dom/cpp/PDOMCPPLinkage,addBinding -XX:CompileCommand=exclude,org/python/pydev/editor/codecompletion/revisited/PythonPathHelper,isValidSourceFile -XX:CompileCommand=exclude,org/python/pydev/ui/filetypes/FileTypesPreferencesPage,getDottedValidSourceFiles -XX:MaxPermSize=256m -jar /usr/lib64/eclipse//plugins/org.eclipse.equinox.launcher_1.0.201.201004121546.jar -os linux -ws gtk -arch x86_64 -showsplash -launcher /usr/lib64/eclipse/eclipse -name Eclipse --launcher.library /usr/lib64/eclipse//plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.0.200.201004121546/eclipse_1208.so -startup /usr/lib64/eclipse//plugins/org.eclipse.equinox.launcher_1.0.201.201004121546.jar -exitdata 145000d -vm /usr/bin/java -vmargs -Xms128m -Xmx512m -Dorg.eclipse.equinox.p2.reconciler.dropins.directory=/usr/share/eclipse/dropins -XX:CompileCommand=exclude,org/eclipse/core/internal/dtree/DataTreeNode,forwardDeltaWith -XX:CompileCommand=exclude,org/eclipse/jdt/internal/compiler/lookup/ParameterizedMethodBinding, -XX:CompileCommand=exclude,org/eclipse/cdt/internal/core/dom/parser/cpp/semantics/CPPTemplates,instantiateTemplate -XX:CompileCommand=exclude,org/eclipse/cdt/internal/core/pdom/dom/cpp/PDOMCPPLinkage,addBinding -XX:CompileCommand=exclude,org/python/pydev/editor/codecompletion/revisited/PythonPathHelper,isValidSourceFile -XX:CompileCommand=exclude,org/python/pydev/ui/filetypes/FileTypesPreferencesPage,getDottedValidSourceFiles -XX:MaxPermSize=256m -jar /usr/lib64/eclipse//plugins/org.eclipse.equinox.launcher_1.0.201.201004121546.jar staff_u:staff_r:staff_t:s0-s0:c0.c1023 2097 ? Ssl 0:06 gnome-session staff_u:staff_r:staff_t:s0-s0:c0.c1023 2107 ? S 0:00 dbus-launch --sh-syntax --exit-with-session staff_u:staff_r:staff_dbusd_t:s0-s0:c0.c1023 2108 ? Ssl 2:11 /bin/dbus-daemon --fork --print-pid 5 --print-address 9 --session staff_u:staff_r:gconfd_t:s0-s0:c0.c1023 2178 ? S 1:49 /usr/libexec/gconfd-2 staff_u:staff_r:gnomesettingsd_t:s0-s0:c0.c1023 2185 ? Ssl 1:56 /usr/libexec/gnome-settings-daemon staff_u:staff_r:gnomekeyringd_t:s0-s0:c0.c1023 2186 ? SLl 0:02 /usr/bin/gnome-keyring-daemon --start --components=pkcs11 staff_u:staff_r:staff_gvfsd_t:s0-s0:c0.c1023 2190 ? S 0:00 /usr/libexec/gvfsd staff_u:staff_r:staff_gvfsd_t:s0-s0:c0.c1023 2198 ? Ssl 0:00 /usr/libexec//gvfs-fuse-daemon /home/dgrift/.gvfs staff_u:staff_r:staff_gnomeshell_t:s0-s0:c0.c1023 2204 ? S 0:00 /usr/bin/python /usr/bin/gnome-shell staff_u:staff_r:gnomesettingsd_t:s0-s0:c0.c1023 2216 ? S> Are you planning on submitting this for inclusion in refpolicy? If so, >> you may want to take a look at the style guide here: >> http://oss.tresys.com/projects/refpolicy/wiki/StyleGuide > > Well that is definitely my long-term goal to get this policy to refpolicy, if > you guys think that it is ready, that is. Thanx to point the Style Guide out. My personal opinion is that this is far from ready and that confining kde / konqueror requires some hacks that may never make it upstream. I might be able to help you achieve what you want and share some of my experiences with you as well as my policy (that you maybe able to use as an example) If you drop by #selinux or #fedora-selinux we can discuss the problems/ possibilities in more depth. > Thats all for now, will send the code latter, when it is according to the Style > Guide and when I have the recent tmp change more tested. > > Ondrej Vadinsky > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20100914/c2339865/attachment.bin