From mboxrd@z Thu Jan 1 00:00:00 1970 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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no 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 065EDC433E0 for ; Fri, 12 Jun 2020 00:13:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C1CE12078C for ; Fri, 12 Jun 2020 00:13:32 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=coker.com.au header.i=@coker.com.au header.b="1PDtAnsE" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726294AbgFLANc (ORCPT ); Thu, 11 Jun 2020 20:13:32 -0400 Received: from smtp.sws.net.au ([46.4.88.250]:36202 "EHLO smtp.sws.net.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726285AbgFLANc (ORCPT ); Thu, 11 Jun 2020 20:13:32 -0400 X-Greylist: delayed 584 seconds by postgrey-1.27 at vger.kernel.org; Thu, 11 Jun 2020 20:13:31 EDT Received: from liv.localnet (unknown [103.75.204.226]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: russell@coker.com.au) by smtp.sws.net.au (Postfix) with ESMTPSA id 0A076F8C0 for ; Fri, 12 Jun 2020 10:03:44 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coker.com.au; s=2008; t=1591920225; bh=m9DYWEgdBS3r2cpeo85MGKP6dr4UNPgVHe4ACAOToB0=; l=2306; h=From:To:Subject:Date:From; b=1PDtAnsEBBIIOxSqeHK/9QJRxks503XhkA1wzdaujfNu5irXF6wshoAl5N/aD9kfR nGFpDy4UZMpKOZaYoEVeMAhhSdu+rEFIwZlMj16PGQ/q1oR1MRFdBwBCGB/JJ79bcN WWiFSoFBte3mgWuGAnefhwSC/Zv9MYV7pxUUIZ/g= From: Russell Coker To: selinux-refpolicy@vger.kernel.org Subject: Are we on the wrong track? Date: Fri, 12 Jun 2020 10:03:40 +1000 Message-ID: <3243717.6S2XvbbdUs@liv> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: selinux-refpolicy-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: selinux-refpolicy@vger.kernel.org The reference policy is getting an increasing number of domains and types with an O(N^2) level of complexity for writing policy and an O(N^2) size of the binary policy. In 2012 the binary policy on my machines was 560k, now it's over 2M. In recent policy we have 6 different domains for systemd-generators. What benefit are we expecting to get from this? Are we anticipating that one generator will attack another? How would having separate domains for generators do any good when there's no restriction on the contents of the files they generate and nothing to prevent one generator from creating a file of the name that another generator is expected to create? Is it even reasonable to expect that a program that can create a systemd unit file with arbitrary content (IE being able to start any daemon with arbitrary configuration and command-line parameters) would be unable to exploit that for unrestricted root access? We have a new set of domains, user_wm_t, staff_wm_t, etc. What is that for? Is someone using the X controls and in need of a privileged window manager domain to manage the clipboard etc? Why is staff_wm_t needed when we no longer have staff_gpg_t? Does staff_r even make sense when you could just use different MCS categories for different users? We have one games_t domain for games which were packaged by the distribution. Is this possible to give a useful benefit given that they some games the same XDG config directories as more important things. If a game has the file access needed to grab passwords from your MUA and network access to send them out then is there a real benefit in having a separate domain for it? As an aside I think that the ideal thing to do would be to have a SETGID program to manage passwords for email etc that prevents the user from accessing them, it could then proxy IMAP/SMTP connections so the MUA never knows the real passwords. We have special *_cronjob_t domains which in systems that use them (IE not Debian) seem to give the potential for nothing but confusion. The general expectation is that anything which can run as a user login session can also run as a cron job. What benefit is this expected to provide? -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/