On Wed, Mar 4, 2020 at 2:30 AM Dominick Grift <dominick.grift@xxxxxxxxxxx> wrote: > Some semi irrelevant background: > > I am designing an improved "targeted" policy. Common targeted policies > are inefficient because they have several "unconfined" domains. > Unconfined domains are expensive because they have a lot of rules associated with them. > They're essentially all the same. Just duplicates. Why can't you just define a single unconfined attribute with associated allow rules, and then define multiple domains that have that attribute? Where is the duplication occurring? Name-based type transitions? IMHO, those should be used far more sparsely than they are presently in Fedora and there has been some optimization recently in how they are internally represented. > I decided to have just one unconfined domain: "the system", and everything that is not targeted ends up in the system domain. > So now I want to have a confined login shell with role access to the system a'la: staff_u:staff_r:staff_t -> staff_u:unconfined_r:unconfined_t > pam_selinux seemingly cannot deal with this scenario as shown above. pam_selinux has many other issues. One of them is its concept of > "default_type". There is no such thing as a "default_type" and implying that there is a "default_type" causes issues. default_type was to support providing a default type to use when only a role was specified to e.g. newrole or pam_selinux. Not sure that's a problem. > There are other issues related to this as well: the env_params option depends on the "context contains" access vector being present. > It will not work even if you have handle_unknown=allow set. Probably needs to be converted to using selinux_check_access().
