From: guido@trentalancia.net (Guido Trentalancia) Date: Tue, 16 Aug 2016 21:26:27 +0200 Subject: [refpolicy] [PATCH] Update for the gnome policy and file contexts In-Reply-To: References: <1471099545.21480.27.camel@trentalancia.net> <227506330.956594.1471212830732.JavaMail.open-xchange@popper08.register.it> <88196c62-5651-c914-d3a5-8a0f5e9f2ff9@gmail.com> Message-ID: <1471375587.19940.13.camel@trentalancia.net> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com Hello Dominick. Late reply to this... On Mon, 15/08/2016 at 10.29 +0200, Dominick Grift wrote: > On 08/15/2016 08:00 AM, Dominick Grift wrote: > > On 08/15/2016 12:13 AM, Guido Trentalancia wrote: > > > Hello Dominick ! > > > > > > > On 08/13/2016 04:45 PM, Guido Trentalancia wrote: > > > > > Update for the gnome module: > > > > > > > > > > - a new gstreamer_orcexec_t type and file context is > > > > > introduced > > > > > ? to support the OIL Runtime Compiler (ORC) optimized code > > > > > ? execution (used for example by pulseaudio); > > > > > - add support for more permissions needed in gconfd_t and > > > > > gnome > > > > > ? keyring domains; > > > > > - add support for a few needed fs and kernel permissions.? > > > > > > > > > > This patch should be applied before applying the pulseaudio > > > > > patch. > > > > > > > > > > Signed-off-by: Guido Trentalancia > > > > > --- > > > > > ?policy/modules/contrib/gnome.fc |????7 ++ > > > > > ?policy/modules/contrib/gnome.if |???99 > > > > > +++++++++++++++++++++++++++++++++++++++- > > > > > ?policy/modules/contrib/gnome.te |????8 +++ > > > > > ?3 files changed, 112 insertions(+), 2 deletions(-) > > > > > > [...] > > > > > > > > + > > > > > ?############################## > > > > > ?# > > > > > ?# Common local Policy > > > > > @@ -87,8 +90,13 @@ manage_dirs_pattern(gconfd_t, gconf_tmp_ > > > > > ?manage_files_pattern(gconfd_t, gconf_tmp_t, gconf_tmp_t) > > > > > ?userdom_user_tmp_filetrans(gconfd_t, gconf_tmp_t, { dir file > > > > > }) > > > > > ? > > > > > +kernel_dontaudit_read_system_state(gconfd_t) > > > > > + > > > > > +fs_getattr_xattr_fs(gconfd_t) > > > > > + > > > > > ?userdom_manage_user_tmp_dirs(gconfd_t) > > > > > ?userdom_tmp_filetrans_user_tmp(gconfd_t, dir) > > > > > +userdom_manage_user_tmp_sockets(gconfd_t) > > > > > > > > What is going on there and why did you choose this? > > > > > > Other applications (such as firefox) need to write those sockets, > > > therefore the > > > policy you suggested in a previous message is not feasible. > > > > > > > How do you figure that? > > > > Let me just expand on this a little. I might be wrong on some of the > following but i have in the past targeted gnome2 so i do have a > little > experience with dealing with orbit > > There are many sockets in orbit-USER. Every application that relies > on > that functionality maintains its own socket in there. It is the PRE- > dbus > way of communications. I have now dropped the support for ORBit-2 in the latest version of this patch. At the end, it is an obsolete library/framework. Sooner or later, we shall remove any remaining support for GConf and the rest of the Gnome2 file contexts and stuff. It's pointless and risky to keep obsolete stuff for long. In general, security goes hand in hand with keeping software up to date. > gconfd maintains a socket in there. It was in the past decided to > target > gconfd. We should now also be consistent and just finish what we > started. > > Besides even if you leave that socket type user_tmp_t that still will > leave you with the "gconfd_t:unix_stream_socket connectto" since the > gconfd process does have a private type. > > If you start saying we will target this part of gconfd but not the > other > part of gconfd then you might as well not target it at all. It may > not > be as black-and-white as that, but it essentially boils down to that. > > Also beware to not let your desire to "make things work" make you > forget > about why were doing this in the first place: to enforce integrity. > > Things like these are essentially why I can't use refpolicy. Because > there are too many compromises like these in there. Where it was I am not following you anymore... What compromises are you talking about ? The system needs to be usable, at least to a minimum level. Otherwise, the policy itself is useless. If there are permissions or interfaces that are dangerous from a security standpoint and removing them does not affect a minimum level of usability, then we should surely make any effort to remove them from the policy ! Please be more specific ! If there is something that is of your concern in the actual policy, please let me know and I will try to test if removing it affects usability, then we can proceed to get rid of it. This is very important. We need an updated tight policy that provides a minimum (eventually tunable) level of usability. > forgotten what the purpose is of confined user domains, and where the > desire to just produce something that "works" basically blurred our > vision. Well, it needs to work in the first place, otherwise there is no point of supporting a given module, we can just remove the support instead of providing a broken one. Something of my concern, for example, is too much unnecessary freedom for applications to read or manage the user_home_t files when they can be assigned their own private types instead (see for example, my recent pulseaudio patch). What specifically concerns you most ? > > > In other words those sockets should be created as user_tmp_t and > > > not as a > > > private gconf_tmp_t. > > > > > > > > ?userdom_user_runtime_filetrans_user_tmp(gconfd_t, dir) > > > > > ? > > > > > ?optional_policy(` Regards, Guido