On Friday, 12 June 2020 8:15:34 PM AEST Dominick Grift wrote: > What was the main part of your message than? The complexity involved > with removing modules you do not need in any given configuration? The difficulty in managing it all and the limited benefit in trying to do it. > >> 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. To know how something it works is to know whether it works well enough or should be improved. > > 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. Before modular policy when the entire policy was compiled in m4 on every system it was very easy to change roles. > > 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) So you have init, getty, and syslogd all running in the same context? https://en.wikipedia.org/wiki/Biba_Model I've been considering how we might make a usable system that includes Biba. > >> > 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 Yes. But if we have game data stored in the same places as MUA data then it happens. A policy to make warzone2100 work in Debian allows games_t to access MUA data. > >> 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. What's a good way of setting up TFA with IMAP on both client and server? With most systems that have TFA you have a single password for IMAP and TFA for the management (changing calendar, plugins, etc). If MUA is too controversial I could find some other example of something under ~/.local that games probably shouldn't access. > >> 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. I think the decision might be whether it's worth continuing to maintain refpolicy or whether it should be obsoleted. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
