Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp445497ybg; Fri, 12 Jun 2020 05:53:35 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwqaiQHo31zwEC3Ek8GjB46EFwTrczDkAuB287Vvxwa4AP8mQnMeXoABinu/gsioDyZtimH X-Received: by 2002:a50:f983:: with SMTP id q3mr12157132edn.259.1591966415718; Fri, 12 Jun 2020 05:53:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591966415; cv=none; d=google.com; s=arc-20160816; b=gzcSAkaEEgU2cAFVDQx3In4ZI7Xh3Lyvnlxy41a93Kezg/V7BZ/8xt6eAWiNlaLaah FFnxec60Vrq+TOGDZkRKuW2zYZ34dW75siXhQTV7EY9lNLUYrIS2fZLhZ8zRT2UA8dzt FTalUM1JiAUnhcDuXFnWGvzUICMsW08VHKACX48oqQ5+KOvMYZLk5QgSESgFtgqwaIHo SNypAb4JweZcYBKExmPIKvuCTAbo1PVNGG/RK7JqEmo8XFNhZfm7hu7rJt7Wlzj9GfxM mriaixGb3xUGM2xBJQuWP10JGR++0kWraeLiuptOBq4YmkfmaqDcSFGuX31dvplFVgaV mp1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:to:subject:dkim-signature; bh=MA1TeaZWCIYODPvklwKdEvXxqwjvuEB73Mp4xgFejFA=; b=R5eE8EefucEtZ48OHlZRlCDFXmrB6Kq8pya/0TUbZhlpVZ57JYzokiW7goHPxfTOt+ HxwBYuEW1Cr84mp+LqPhvqpKSLHNaGCknyQThkA/Xr5saPeqzvQObZaSvsreuKnHLIVc n/+i7HAnjBRUAPI2rEbCL+QtaWNdGRzTV9TkoCq6mqYnwA0oTyuCNHXdbELEuyMPwqAS 5iHWTsSPhQ0Xb4CcAJPLr5wYAJNR6FG2CN0Fs7NMVoDQtoL/UK5f0LnlHkh23exPLmpy N2Jx3r84N64y6ZTUykrdsTSQdc1RYqtC8y2+yP0MAFpOao/Cal3uyKx3pEODlR/dgKN5 ew7g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ieee.org header.s=google header.b=dJxOxt03; spf=pass (google.com: domain of selinux-refpolicy-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=selinux-refpolicy-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ieee.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b5si4349204edz.386.2020.06.12.05.53.30; Fri, 12 Jun 2020 05:53:35 -0700 (PDT) Received-SPF: pass (google.com: domain of selinux-refpolicy-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@ieee.org header.s=google header.b=dJxOxt03; spf=pass (google.com: domain of selinux-refpolicy-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=selinux-refpolicy-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ieee.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726286AbgFLMxB (ORCPT + 15 others); Fri, 12 Jun 2020 08:53:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40948 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726085AbgFLMxB (ORCPT ); Fri, 12 Jun 2020 08:53:01 -0400 Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1AB1FC03E96F for ; Fri, 12 Jun 2020 05:53:01 -0700 (PDT) Received: by mail-qv1-xf2a.google.com with SMTP id y9so4281195qvs.4 for ; Fri, 12 Jun 2020 05:53:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee.org; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=MA1TeaZWCIYODPvklwKdEvXxqwjvuEB73Mp4xgFejFA=; b=dJxOxt038F1Z5XQav9X+IoKhQ/CrfWV5FqqKoUN4qphJCIy6z2we4qTQbijUmOonmq etopUu5oU5zUnARt3tGJDl9BaDyAAnAtujSLHnhHi5hvDtQaUCPmxnrivS6XbmLxQRkF dDmhhsL2HOFuLVBhiqwAyALvWiKfoBO6R09Pk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=MA1TeaZWCIYODPvklwKdEvXxqwjvuEB73Mp4xgFejFA=; b=ZD79YgSO+WGFtUL30NbQxLqpKoMS1GLqYrIqBp5Ek9cSUTd4lmk7Xm00d+r/AB/ghB UcY1Ug6NiwyhUtXj/j6cwnk9kAh7Cc6K8UNSPLxrSy8vO42Qr2X72yPvRmf5xY0eqQmK hdoaDVTfWASiZB9xVxF6wiAqM5ZteAvCsPO+MwCAhPKAynwTwtZ2oKcBcMmA4k/rdf6v DmMCdzG+ZaNFzJtAAo7KD/GoOzyvRjpqsaIvv/OpL/li9Iv9EFIid4HxDhET9BLBAlWt GjMsimsJMvyOxBs6h2y1QALYMN3nlD5/6bvgyO6cSs4seNiwFeRChs0Wooz7R6Lvfszc yWMQ== X-Gm-Message-State: AOAM531CY3E/dsUHBMeEpXShV8xy6oNzQ+dtmEp8QHCgp4PPB7SoGVyH yVpiHOAb9/AdVNWMO+Cf0dKNON5naiE= X-Received: by 2002:a0c:f447:: with SMTP id h7mr6739429qvm.198.1591966379630; Fri, 12 Jun 2020 05:52:59 -0700 (PDT) Received: from fedora.pebenito.net (pool-108-15-23-247.bltmmd.fios.verizon.net. [108.15.23.247]) by smtp.gmail.com with ESMTPSA id y19sm4269634qki.19.2020.06.12.05.52.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 12 Jun 2020 05:52:59 -0700 (PDT) Subject: Re: Are we on the wrong track? To: Russell Coker , selinux-refpolicy@vger.kernel.org References: <3243717.6S2XvbbdUs@liv> From: Chris PeBenito Message-ID: <578d7c7c-cb41-b224-2758-144aa9b5c1ad@ieee.org> Date: Fri, 12 Jun 2020 08:52:56 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <3243717.6S2XvbbdUs@liv> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: selinux-refpolicy-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: selinux-refpolicy@vger.kernel.org On 6/11/20 8:03 PM, Russell Coker wrote: > 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? I find this a valid criticism and reason enough to at least collapse them into a single domain. The original intent was to constrain the special access they use, but you are correct, a compromised generator could do mostly do all the bad things anyway since it can write unit files. > 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? Yes. > Why is staff_wm_t needed when we no > longer have staff_gpg_t? Sounds like a gpg change that should be reverted. > Does staff_r even make sense when you could just use > different MCS categories for different users? Yes, as user_r cannot reach admin roles whereas staff_r can. > 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. I'm a bit hazy on the details you're referring to but you're right that games_t may not be too impactful. Dominick's flatpak/sandbox/container approach may make more sense. I don't have any recent Linux gaming experience (with Steam or otherwise) to judge. > 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? I'd be fine dropping the instantiaton of *_cronjob_t (except system_cronjob_t) but not removal of the template, for the few instances that users need it. My question to you is why aren't you commenting on these changes as they are submitted, instead of unloading on the changes years after the fact? You've been around the SELinux community longer than I have. These changes aren't merged in secrecy. -- Chris PeBenito