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 ECCE1C433E0 for ; Fri, 12 Jun 2020 12:26:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C15AB2081A for ; Fri, 12 Jun 2020 12:26:45 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=defensec.nl header.i=@defensec.nl header.b="aHxV5Eqc" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726024AbgFLM0p (ORCPT ); Fri, 12 Jun 2020 08:26:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36932 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725886AbgFLM0p (ORCPT ); Fri, 12 Jun 2020 08:26:45 -0400 Received: from agnus.defensec.nl (agnus.defensec.nl [IPv6:2001:985:d55d::711]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 2A4CDC03E96F for ; Fri, 12 Jun 2020 05:26:45 -0700 (PDT) Received: from brutus (brutus.lan [IPv6:2001:985:d55d::438]) by agnus.defensec.nl (Postfix) with ESMTPSA id 967DC2A0F46; Fri, 12 Jun 2020 14:26:42 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 agnus.defensec.nl 967DC2A0F46 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=defensec.nl; s=default; t=1591964802; bh=B92Qs0hEXFwYAlWAHEWGkWkVFqFGEEYCk5ojv3VIxsM=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=aHxV5Eqclwm4Pp9zwMaDnBK9Ji91EMMcIDgdBRADy5lawsZ6xj1GCdB3ot30hmfvj hkQfjt8vttJbaJ75m2HuuJE2/BjYDlN+MkY/qWUKoR0I3aqd4/9+wHaqVG2lMaUPWE XeZYdmQaULWsVon3xucx8BMJaN5DbMCfNWKRb4hA= From: Dominick Grift To: Russell Coker Cc: refpolicy Subject: Re: Are we on the wrong track? References: <3243717.6S2XvbbdUs@liv> <3179073.KMaz8WPbdX@liv> <11621688.XNj53QmPYG@liv> Date: Fri, 12 Jun 2020 14:26:35 +0200 In-Reply-To: <11621688.XNj53QmPYG@liv> (Russell Coker's message of "Fri, 12 Jun 2020 22:05:45 +1000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: selinux-refpolicy-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: selinux-refpolicy@vger.kernel.org Russell Coker writes: > 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. Yes, Its a bit easier with CIL policy and maybe could even be automated in an environment that leverages CIL (although not sure if that would be worth the overhead) > >> >> 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 its subjective. Maybe there no longer is a need to derive wm_t. We would need to identity why wm_t was derived in the first place. Maybe its worth it to make a distinction between X window managers and Wayland window managers (although its not as simple i guess due to the Xwayland compatibility layer) I guess I will just admit that I don't feel qualified to answer this question. >> > 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. > That was before my time (at least I cannot remember), but I have my doubts. >> > 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? Stuff that runs in "the system" context (is trusted): sys.id:sys.role:sys.isid:s0 1. systemd --system (pid1) 2. systemd-tmpfiles --system 3. dbus --system 4. default login shells 5. package managers 6. unknown system services (i might have overlooked some) > > 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. > Take for example my mutt and gnus configuration. You can GPG encrypt the passwords, then use your smartcard to decrypt the passwords on demand (your smartcard requires a pin and a hardware token) I also do similar with my borg backup config: export BORG_PASSCOMMAND='pass show borgbackup' where pass is a shell script that basically leverages gpg/smartcard to decrypt passwords on the fly. (You need a PIN and a smartcard) >> >> 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. -- gpg --locate-keys dominick.grift@defensec.nl Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098 https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098 Dominick Grift