From: dac.override@gmail.com (Dominick Grift) Date: Tue, 16 Aug 2016 21:30:57 +0200 Subject: [refpolicy] [PATCH] Update for the gnome policy and file contexts In-Reply-To: <1471375587.19940.13.camel@trentalancia.net> References: <1471099545.21480.27.camel@trentalancia.net> <227506330.956594.1471212830732.JavaMail.open-xchange@popper08.register.it> <88196c62-5651-c914-d3a5-8a0f5e9f2ff9@gmail.com> <1471375587.19940.13.camel@trentalancia.net> Message-ID: <61e8ec31-f484-a798-920b-a51d2822350c@gmail.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 08/16/2016 09:26 PM, Guido Trentalancia wrote: > 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 ? > I can't be much more specific. I think that allowing a process associated with type gconfd_t to maintain a socket with type user_tmp_t is a bad idea. Anyway's, I will leave this to others to decide. >>>> 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 > -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 Dominick Grift -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 648 bytes Desc: OpenPGP digital signature Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20160816/73f3ff93/attachment.bin