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:     Chris PeBenito <pebenito@ieee.org>
Cc:     selinux-refpolicy@vger.kernel.org
Subject: Re: Are we on the wrong track?
Date:   Fri, 12 Jun 2020 23:02:55 +1000
Message-ID: <2469682.qIgoumM3a6@liv>
In-Reply-To: <578d7c7c-cb41-b224-2758-144aa9b5c1ad@ieee.org>
References: <3243717.6S2XvbbdUs@liv> <578d7c7c-cb41-b224-2758-144aa9b5c1ad@ieee.org>
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 10:52:56 PM AEST Chris PeBenito wrote:
> > 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.

OK, I'll submit a patch for that.

> > 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.

I had some of that in the Debian policy, it's a pain to maintain.

> >  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.

The user identity has a permitted list of roles, you can have users who are 
permitted user_r and sysadm_r and users who are only permitted user_r.  The 
original benefit of staff_r was to protect staff from attacks by user_r 
accounts, but we can do that protection with the identity based constraints.

> > 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.

Experience playing games isn't really required.  The situation is we have 
games_t assigned to a bunch of programs that come from the distribution and 
therefore meet certain minimum quality checks (which probably give the 
binaries in question a range of integrity that overlaps the contents of /usr/
sbin).  We also have games downloaded from steam which don't have source 
available and can't be reviewed for quality.  Also steam games are probably 
going to need DRI access which makes it extra exciting.

> > 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.

I have commented on some of these things in the past (I rejected *_cronjob_t 
for Debian).  We can deal with some inefficiency, but it builds up and now is 
at the stage where I think we have to revisit some assumptions that were made 
years ago.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/