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;
From:   Russell Coker <russell@coker.com.au>
To:     Dominick Grift <dominick.grift@defensec.nl>,
        refpolicy <selinux-refpolicy@vger.kernel.org>
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: <ypjleeqkpp2x.fsf@defensec.nl>
References: <3243717.6S2XvbbdUs@liv> <3179073.KMaz8WPbdX@liv> <ypjleeqkpp2x.fsf@defensec.nl>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Sender: selinux-refpolicy-owner@vger.kernel.org
Precedence: bulk

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/