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:     Dac Override <dac.override@gmail.com>
Cc:     refpolicy <selinux-refpolicy@vger.kernel.org>
Subject: Re: Are we on the wrong track?
Date:   Fri, 12 Jun 2020 19:54:35 +1000
Message-ID: <3179073.KMaz8WPbdX@liv>
In-Reply-To: <CAJVWAV1oKcSB9dxFPD3As9-78JW4uSAcCN9jY8zsZdvspEC9aQ@mail.gmail.com>
References: <3243717.6S2XvbbdUs@liv> <CAJVWAV1oKcSB9dxFPD3As9-78JW4uSAcCN9jY8zsZdvspEC9aQ@mail.gmail.com>
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 6:02:15 PM AEST Dac Override wrote:
> 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).

As Topi noted there are ways of reducing the binary size.  But that was the 
minor part of my message.

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

Yes.

I just did some policy searches and found the following allowing access to 
init_runtime_t.  This probably isn't what we want.

allow ftpd_t non_auth_file_type:file { append create getattr ioctl link lock 
open read rename setattr unlink write }; [ allow_ftpd_full_access ]:True
allow nfsd_t non_auth_file_type:file { append create getattr ioctl link lock 
open read rename setattr unlink write }; [ nfs_export_all_rw ]:True
allow nmbd_t non_auth_file_type:file { append create getattr ioctl link lock 
open read rename setattr unlink write }; [ samba_export_all_rw ]:True
allow puppet_t non_auth_file_type:file { append create getattr ioctl link lock 
open read rename setattr unlink write }; [ puppet_manage_all_files ]:True
allow sftpd_t non_auth_file_type:file { append create getattr ioctl link lock 
open read rename setattr unlink write }; [ sftpd_full_access ]:True
allow smbd_t non_auth_file_type:file { append create getattr ioctl link lock 
open read rename setattr unlink write }; [ samba_export_all_rw ]:True

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

Are you saying we should remove the staff_wm_t?

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

That sounds great, we can remove a bunch of policy for dbus stuff then.

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

I think roles could have always been used for that.  But adding lots of roles 
used to be a lot easier.

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.

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

We are trying to write policy that is generally usable.

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

If the reasons I listed are a sufficient disincentive to contributing towards 
the refpolicy then it can limit the future of refpolicy.

Things currently aren't working well.  I'm thinking of just making changes 
similar to what I describe above and letting refpolicy upstream decide whether 
they want to do something compatible or whether we go separate ways.

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

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

Sounds interesting.

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