Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C00A1C43387 for ; Sat, 12 Jan 2019 22:55:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8F66320836 for ; Sat, 12 Jan 2019 22:55:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726569AbfALWzz (ORCPT ); Sat, 12 Jan 2019 17:55:55 -0500 Received: from mx1.polytechnique.org ([129.104.30.34]:38650 "EHLO mx1.polytechnique.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726566AbfALWzz (ORCPT ); Sat, 12 Jan 2019 17:55:55 -0500 Received: from mail-oi1-f180.google.com (mail-oi1-f180.google.com [209.85.167.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id 92D88564756 for ; Sat, 12 Jan 2019 23:55:51 +0100 (CET) Received: by mail-oi1-f180.google.com with SMTP id i6so15136618oia.6 for ; Sat, 12 Jan 2019 14:55:51 -0800 (PST) X-Gm-Message-State: AJcUukdrWgOEpj1Lj+ZqOAgNYnEPc2Jwoq8p4G5/tHx16HYxGo6IQnD/ U27vwbOiNxBtPPAgKzAD6pzlu42RBGZG8hj8xxs= X-Google-Smtp-Source: ALg8bN7b+ffnCzrJPh+vBvBCg61MSbzDeTtz8lvt7mDW8eQOM8v7N5GNvdldXt4derc9Th01tMo5VTbv5TADOxUJrHk= X-Received: by 2002:aca:e142:: with SMTP id y63mr11881380oig.314.1547333750516; Sat, 12 Jan 2019 14:55:50 -0800 (PST) MIME-Version: 1.0 References: <20190112051909.GA7745@xev> <20190112073320.GA40543@baraddur.perfinion.com> <9e966272-1e72-c250-bfb6-0f3b8bd07931@ieee.org> In-Reply-To: <9e966272-1e72-c250-bfb6-0f3b8bd07931@ieee.org> From: Nicolas Iooss Date: Sat, 12 Jan 2019 23:55:38 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] s/mozilla/webbrowser/g To: Chris PeBenito Cc: Jason Zaman , Russell Coker , "selinux-refpolicy@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Sat Jan 12 23:55:52 2019 +0100 (CET)) X-Org-Mail: nicolas.iooss.2010@polytechnique.org Sender: selinux-refpolicy-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: selinux-refpolicy@vger.kernel.org On Sat, Jan 12, 2019 at 9:05 PM Chris PeBenito wrote: > > On 1/12/19 2:33 AM, Jason Zaman wrote: > > On Sat, Jan 12, 2019 at 04:19:09PM +1100, Russell Coker wrote: > >> This patch as requested renames mozilla to webbrowser and adds appropriate > >> typealias rules. > > > > Hm. the mozilla and chrome policies are pretty different tho. I dont > > like this merging thing, I think we should keep mozilla_t and chromium_t > > separate. I'm fixing up the gentoo chromium policy and i'll send it in a > > couple hrs. > > The chromium policy Jason posted is indeed slimmer than the current > mozilla policy (see Jason's thread), which would seem to indicate > keeping them separate. However, the mozilla policy is so big because > it's been around for a long time and has built up all of the various > odds and ends that a browser brings in, which could possibly be missing > from the chromium policy. > > I am on the fence. I could see going either way. Even though Mozilla browsers and Chrome/Chromium are both web browsers with Javascript engines, plugins, etc. they have strong differences. If I remember correctly: - Chromium uses a sandbox (which is labelled differently) contrary to Firefox ; - Chromium can interact with Multicast DNS (it listens on UDP port 5353 on my system, I guess for feature likes Chromecast) and I do not whether Firefox or Epiphany can do something similar, and I do not expect them to. Moreover some developers package apps with Electron, which uses a runtime based on Chromium (according to https://electronjs.org/docs/tutorial/about). Having a separate chromium policy might help creating a policy for such an app, though I am not sure about this. About the fact that mozilla policy has been around for a long time contrary to this new chromium policy, if it is an issue, it should be possible to compare Gentoo's policy with Fedora's one: it has a chrome module in contrib/ that has been around for a least 6 years according to https://github.com/fedora-selinux/selinux-policy-contrib/commits/rawhide?path%5B%5D=chrome.te . All of this remain my humble opinion on this subject and I am sharing it in order to help making a choice. I will of course understand if the choice of merging everything into a single web-browser module is being made (for example to ease the maintenance of the policy or to avoid introducing many types in the policy). Cheers, Nicolas