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;
MIME-Version: 1.0
References: <3243717.6S2XvbbdUs@liv>
In-Reply-To: <3243717.6S2XvbbdUs@liv>
From:   Dac Override <dac.override@gmail.com>
Date:   Fri, 12 Jun 2020 10:02:15 +0200
Message-ID: <CAJVWAV1oKcSB9dxFPD3As9-78JW4uSAcCN9jY8zsZdvspEC9aQ@mail.gmail.com>
Subject: Re: Are we on the wrong track?
To:     Russell Coker <russell@coker.com.au>
Cc:     refpolicy <selinux-refpolicy@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: selinux-refpolicy-owner@vger.kernel.org
Precedence: bulk

On Fri, Jun 12, 2020 at 2:16 AM Russell Coker <russell@coker.com.au> wrote:
>
> The reference policy is getting an increasing number of domains and types with
> an O(N^2) level of complexity for writing policy and an O(N^2) size of the
> binary policy.  In 2012 the binary policy on my machines was 560k, now it's
> over 2M.

The number of domains available by default should not be a problem if
you can easily select which modules you want to use.
with module policy this is not as easy as with CIL as the modular
nature of module policy makes it harder to resolve dependencies
(almost impractical). The human readable nature of CIL and iits "feels
like modular but is really just monolithic" nature makes dependency
resolving at runtime with CIL generall much easier (but there are
still limitations).

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

When push comes to shove, generators are just short-running services
(ie its code run by systemd) generally (unit) generators do some
enumeration and then create a runtime unit accordingly.but there have
already been instances where this functionality has been "abused" (the
dbus -> dbus-broker migration in fedora). In the end though, it might
not be worth the trouble to target them. If you're allowed to write to
the systemd runtime generator dir then you can drop a script , run
systemd daemon-reload, and systemd will run that code.

> 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?  Why is staff_wm_t needed when we no
> longer have staff_gpg_t?  Does staff_r even make sense when you could just use
> different MCS categories for different users?

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)

The derived types concept, originallly, i think, tackled the scenario
where something needs to run either a shell or a cmmand on behalf of
the caller and still run with private rules. This was quite an isssue
in the recent past (for example pulseaudio clients would run
pulseaudio on demand, pulse audio would run dbus on demand (i believe)
and dbus would run potentially anything on demand (dbus activated
services). So there was a dependency chain there to ensure some
consistency.

Nowaday/s thats all gone, pulseaudio is systemd socket activated, dbus
is system socket activated, and dbus activation is really just dbus
telling systemd to start something (rather than dbus running the dbus
activated command itself)

Another side effect of derived types is that it can be used for
isolation of users sessions. Nowaday's roles can be used for this.

Derived types, in practice, are bad because you cannot declare types
reliably in optional policy. In effect that means that you cannot
reliably use derived types for types that may be optional.

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

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

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

the derived cronjob domains (with the exception of system_cronjob_t)
are conditional. This functionality can be tuned and i think it's
disabled by default.

There will always be legacy to carry, things change all the time. It
is give and take. I don't think refpolicy has much of a future to
forward to but not for the reasons above.

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

DSSP3 is my vision of what a modern policy should look like (except
that it doesn't support enforcement of confidentiality)
Eventually though DSSP3 will grow legacy just like refpolicy, I do not
pretend otherwise.
But a lot has changed and DSSP3 took the opportunity to rebuild for the new new.

Also with DSSP3 i learned from the bloat lesson. DSSP3 itself is
intentionally kept small and concise.I acknowledge that  policy has to
be maintained over time and so if you limit yourself to a relatively
small set of types/roes/id etc and you focus on the quality of that
then you make life easier.

I do have a "DSSP3 constrib" and this repository can and will has as
many modules as needed (of course the quality of those modules cannot
be vouched for) but they're all optional and self-contained (to the
extent possible)

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