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@xxxxxxxxxxxx> 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/
