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>
Cc:     refpolicy <selinux-refpolicy@vger.kernel.org>
Subject: Re: Are we on the wrong track?
Date:   Fri, 12 Jun 2020 22:53:33 +1000
Message-ID: <3403154.DDNKOWLi4p@liv>
In-Reply-To: <ypjl5zbwpj0k.fsf@defensec.nl>
References: <3243717.6S2XvbbdUs@liv> <11621688.XNj53QmPYG@liv> <ypjl5zbwpj0k.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 10:26:35 PM AEST Dominick Grift wrote:
> Russell Coker <russell@coker.com.au> 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)

What exactly are you saying could be automated?

> >> >> 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 just noticed that user_wm_t policy is in Debian/Buster, but I never noticed 
it because the type label for KDE wasn't setup.

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

Why be so different?  Why not system_u:system_r:base_sys_t: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)

There is the argument about minimum privs.  The minimum privilege extremists 
want to have things like compilers locked away, I disagree with that as a 
hostile party probably would have their own binaries ready.  But restricting 
who can run the package manager to install things seems useful, more useful 
than having 32 different executable types as parts of systemd (not kidding, I 
ran wc).

Most of my refpolicy development time is spent adding rules for extra domains 
that people have added and for extra systemd features.

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