Russell Coker <russell@xxxxxxxxxxxx> writes: > On Friday, 12 June 2020 10:26:35 PM AEST Dominick Grift wrote: >> 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) > > What exactly are you saying could be automated? Its not practical but consider this: After every semodule transaction, code is run that looks at the cil filecons in the module store. if none of the filecons exist on the system the module gets marked disabled and is not compiled/loaded. You could i guess implement a similar trigger in the package manager that whenever you do a transaction it runs that same code to determine which modules are applicable and compile those in, disable the remainder. In practice that would be a pretty hefty operation, so might not be feasible to do this all the time .... > >> >> >> 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 just noticed that user_wm_t policy is in Debian/Buster, but I never noticed > it because the type label for KDE wasn't setup. > >> >> 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 > > Why be so different? Why not system_u:system_r:base_sys_t:s0? DSSP3 is a research project into leveraging CIL. CIL namespaces are therefore leveraged to the fullest. (not to mention that they rock) > >> 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) > > There is the argument about minimum privs. The minimum privilege extremists > want to have things like compilers locked away, I disagree with that as a > hostile party probably would have their own binaries ready. But restricting > who can run the package manager to install things seems useful, more useful > than having 32 different executable types as parts of systemd (not kidding, I > ran wc). I would agree that one should not install a compiler unless really needed. Defense in depth and all. As for the package manager: yes but you have to see this in context. I do leverage confined shells, and confined login shells as well. So even though by default all users can run the package manager, that is obviously not encouraged. One should instead at least use confined login shells for unpriv users. In DSSP3 is also confines most of the individual systemd components (even the clients for confined shells). systemd can leverage polkit (i am not a big fan of polkit) and DSSP3 supports that scenario as well. Thats actually one of the relatively few ascpects targeted in DSSP3.... DSSP3 is open by default (but looks deceive) on the other side it allows one locks it down quite a bit. It is just not treating the owner as a child. DSSP3 is a policy that "just works (most of the time)" for reactive users, and provides a nice framework to work with for proactive users. Theres really quite a bit of contrast there, some of it might not make a whole lot of sense to you. Then again, i do this for fun and dssp3 is a research project into leveraging CIL, and just a toy to tinker with. > > Most of my refpolicy development time is spent adding rules for extra domains > that people have added and for extra systemd features. -- 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
