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