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:   Dominick Grift <dominick.grift@defensec.nl>
To:     Russell Coker <russell@coker.com.au>
Cc:     Dac Override <dac.override@gmail.com>,
        refpolicy <selinux-refpolicy@vger.kernel.org>
Subject: Re: Are we on the wrong track?
References: <3243717.6S2XvbbdUs@liv>
        <CAJVWAV1oKcSB9dxFPD3As9-78JW4uSAcCN9jY8zsZdvspEC9aQ@mail.gmail.com>
        <3179073.KMaz8WPbdX@liv>
Date:   Fri, 12 Jun 2020 12:15:34 +0200
In-Reply-To: <3179073.KMaz8WPbdX@liv> (Russell Coker's message of "Fri, 12 Jun
        2020 19:54:35 +1000")
Message-ID: <ypjleeqkpp2x.fsf@defensec.nl>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Sender: selinux-refpolicy-owner@vger.kernel.org
Precedence: bulk

Russell Coker <russell@coker.com.au> writes:

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

What was the main part of your message than? The complexity involved
with removing modules you do not need in any given configuration?

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

I am just sharing my knowledge. I will leave that decision to others.

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

No, the defaultrole functionality is relatively new.

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

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

I dont think games should have access to MUA

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

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

I guess the question is whether it is worth the investment. I will leave
that decision to others.

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

-- 
gpg --locate-keys dominick.grift@defensec.nl
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098
Dominick Grift