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,URIBL_BLOCKED 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 C0425C433DF for ; Fri, 12 Jun 2020 12:05:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9B81120792 for ; Fri, 12 Jun 2020 12:05:58 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=coker.com.au header.i=@coker.com.au header.b="ZbVd7WKu" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726255AbgFLMF6 (ORCPT ); Fri, 12 Jun 2020 08:05:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33716 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725791AbgFLMF6 (ORCPT ); Fri, 12 Jun 2020 08:05:58 -0400 X-Greylist: delayed 43325 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Fri, 12 Jun 2020 05:05:56 PDT Received: from smtp.sws.net.au (smtp.sws.net.au [IPv6:2a01:4f8:140:71f5::dada:cafe]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C9A4EC03E96F for ; Fri, 12 Jun 2020 05:05:56 -0700 (PDT) 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 8BCADEF1F; Fri, 12 Jun 2020 22:05:49 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coker.com.au; s=2008; t=1591963552; bh=hkbwWJHqA6SZvYloyhItdj89DyWooWjyALg8A2pyjn8=; l=5270; h=From:To:Subject:Date:In-Reply-To:References:From; b=ZbVd7WKuCJISpedjhCUZtqKPHI3Q/RC9M2D0uAq52MAu2zEkw92RCIKDW9BFdUunO tuXd11ivB3FRb274to7TjhXWgdjdhblRQPG5X0IyoxVsh+CI4sj5kMQs/WPzKv+vi0 aO6kOqjc+T4RTIzG7YdvQ5lhD7EEJaaoSecjy2h8= From: Russell Coker To: Dominick Grift , refpolicy Subject: Re: Are we on the wrong track? Date: Fri, 12 Jun 2020 22:05:45 +1000 Message-ID: <11621688.XNj53QmPYG@liv> In-Reply-To: References: <3243717.6S2XvbbdUs@liv> <3179073.KMaz8WPbdX@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 On Friday, 12 June 2020 8:15:34 PM AEST Dominick Grift wrote: > What was the main part of your message than? The complexity involved > with removing modules you do not need in any given configuration? The difficulty in managing it all and the limited benefit in trying to do it. > >> I suppose it's a generic domain for window managers. It originates > >> from the metacity day's Things changed quite a bit since then (think > >> wayland compositors) > > > > Are you saying we should remove the staff_wm_t? > > I am just sharing my knowledge. I will leave that decision to others. To know how something it works is to know whether it works well enough or should be improved. > > I think roles could have always been used for that. But adding lots of > > roles used to be a lot easier. > > No, the defaultrole functionality is relatively new. Before modular policy when the entire policy was compiled in m4 on every system it was very easy to change roles. > > So I guess we could have 3 base domains for users, user_t, sysadm_t, and > > unconfined_t. We could then have roles user_r and staff_r both suitable > > for user_t and similar domains and have unconfined_r and sysadm_r for > > unconfined_t and sysadm_t respectively. > > > > Another possibility would be to remove unconfined_r, have > > sysadm_r:sysadm_t be for unconfinbed users, it will be literally > > unconfined if the unconfined module is installed and just like sysadm_t > > is now otherwise. > > In dssp3 I take this to another level. The concept of exemption is > embraced, and the need for trust is acknowledged (yes that one was tough to > swallow). > > There is no unconfined_t in dssp3. there is just "the system" and "the > system" is trusted and exempted. This simplifies the policy a great deal > since there isn't a number of unconfined domains by default, there is > just one trusted context by default (you can still make additional > domains unconfined but that is discouraged) So you have init, getty, and syslogd all running in the same context? https://en.wikipedia.org/wiki/Biba_Model I've been considering how we might make a usable system that includes Biba. > >> > 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. > >> > >> That's generalizing. > > > > We are trying to write policy that is generally usable. > > I dont think games should have access to MUA Yes. But if we have game data stored in the same places as MUA data then it happens. A policy to make warzone2100 work in Debian allows games_t to access MUA data. > >> But as for games. Today things like flatpak might be more suitable. > >> Then you can combine SELinux and other kernel tech like namespaces, > >> bind mounts to make stuff inaccessible etc. Theres also steam which > >> essentially is a dumb version of flatpak. I don't think steam would > >> ever need any access to a MUA and any of its assets > > > > Steam needs full network access, graphics, sound, and XDG directory > > access. > > Yes but you were using "passwords" as an argument and then some how put > MUA into the equation (I honestly have no clue why a game would need > access to a MUA). Not to mention that when it comes to passwords (and to > authentication) there are better way's to secure access. Think for example > smartcards, TFA, encryption, etc. What's a good way of setting up TFA with IMAP on both client and server? With most systems that have TFA you have a single password for IMAP and TFA for the management (changing calendar, plugins, etc). If MUA is too controversial I could find some other example of something under ~/.local that games probably shouldn't access. > >> module policy and monolithic policy are just too limited compared to > >> CIL, and refpolicy has some designs centered around things that just > >> don't work (think about the derived types limitation i mentioned above > >> and how that is rooted to the core in refpolicy (example staff_dbusd_t > >> and the dbus_role_template effectively make dbus a hard dependency > >> (effectively nowaday's it is) but this also means that no dbus role > >> templates (and this any dbus interfaces) should ever be in optional > >> blocks > > > > We can change some of these things. > > I guess the question is whether it is worth the investment. I will leave > that decision to others. I think the decision might be whether it's worth continuing to maintain refpolicy or whether it should be obsoleted. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/