From: sven.vermeulen@siphos.be (Sven Vermeulen) Date: Wed, 3 Oct 2012 20:16:38 +0200 Subject: [refpolicy] [REVIEW REQUEST] Changes to the gnome policy module In-Reply-To: <1349277155-3545-1-git-send-email-dominick.grift@gmail.com> References: <1349277155-3545-1-git-send-email-dominick.grift@gmail.com> Message-ID: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On Wed, Oct 3, 2012 at 5:12 PM, Dominick Grift wrote: > Creating new types for ~/.cache, ~/.config, ~/.local/share and various generic gstreamer content ( see the HOME_DIR file contexts ) > These types arent specific to gnome but Fedora threats the gnome module as if it were a module for any desktop environment. > > The config, cache and data types are from the freedesktop specification and are used by any desktop ( at least that is the idea behind this standard ) [...] I would rather see them being either separate (like the xdg patches I suggested twice on the mailinglist) or part of userdom. But with great preference to separate. I don't see a reason to put it in a module that might not always be loaded, nor am I a proponent of having modules named one thing and meaning something else (gnome versus "any desktop related stuff", or apache versus "any web server stuff"). In the XDG policy we use in Gentoo, we have xdg_cache_home_t, xdg_config_home_t, xdg_data_home_t and xdg_runtime_home_t (for /run/user/USER stuff). It also supports file transitions for applications that make specific locations therein (like ~/.config/chromium, ~/.config/epdfview, ...) as to isolate (confine) the applications more. I'm even going as far as providing user location types (that, if the sysadmin wants, the user can label his content with) for downloads (xdg_downloads_home_t), documents, music, pictures and videos (I don't see the need for documents yet, the rest allows me to confine the user apps pretty good). Of course, not all administrators want this granularity of MAC so a few booleans suffice to stay with the standard "all user content" privileges. Still, I see a definite need for decent user application confinement. Many attacks are targeting user applications (the browser is one of the prime examples, but don't forget the adobe flash vulnerabilities and so on). For browsers alone I am already happy that my browsers both have their own domain and are not allowed to read any of my files beyond their own xdg-related locations and, for browser, the xdg_downloads_home_t stuff. > I also created interfaces that should be called in the user domain, to allow users to create generic gnome content with the proper file transition and to allow them to relabel and manage the content > > gnome_manage_all_generic_home_content > gnome_relabel_all_generic_home_content > gnome_filetrans_all_generic_home > > These are supposed to end up in the userdom_manage_home_role ( in a optional policy block) Shouldn't those be "userdom_manage_all_generic_home_content" instead? Also, I think it would be wise to use an attribute to label the user home content with, and work on the attribute. Newly created types (like specific ~/.config/* stuff) can then be marked as such as well and automatically take part in the privilege setting. [...] > There is one big difference between fedora and refpolicy. Fedora wants selinux to make unconfined users run their dbus session in the unconfined_dbusd_t domain. > Refpolicy allows unconfined users to run their dbus session in the unconfined_t domain > > I favor refpolicies solution as i believe that ideally unconfined_t should never transition out of unconfined_t. ( the argument that unconfined_t needs to transition in order to be able to create files with the proper type is not longer valid since we now have named file transitions) I find unconfined confusing exactly for that reason: when to transition away from an unconfined setting? Never seems like a valid choice (and is at least simple to understand ;-) However, don't mind me on this part - I do not use unconfined domains.