Russell Coker <russell@xxxxxxxxxxxx> writes: > 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. Yes, Its a bit easier with CIL policy and maybe could even be automated in an environment that leverages CIL (although not sure if that would be worth the overhead) > >> >> 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 its subjective. Maybe there no longer is a need to derive wm_t. We would need to identity why wm_t was derived in the first place. Maybe its worth it to make a distinction between X window managers and Wayland window managers (although its not as simple i guess due to the Xwayland compatibility layer) I guess I will just admit that I don't feel qualified to answer this question. >> > 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. > That was before my time (at least I cannot remember), but I have my doubts. >> > 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? Stuff that runs in "the system" context (is trusted): sys.id:sys.role:sys.isid:s0 1. systemd --system (pid1) 2. systemd-tmpfiles --system 3. dbus --system 4. default login shells 5. package managers 6. unknown system services (i might have overlooked some) > > 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. > Take for example my mutt and gnus configuration. You can GPG encrypt the passwords, then use your smartcard to decrypt the passwords on demand (your smartcard requires a pin and a hardware token) I also do similar with my borg backup config: export BORG_PASSCOMMAND='pass show borgbackup' where pass is a shell script that basically leverages gpg/smartcard to decrypt passwords on the fly. (You need a PIN and a smartcard) >> >> 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. -- gpg --locate-keys dominick.grift@xxxxxxxxxxx Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098 https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098 Dominick Grift
