The easiest way to explain this is as follows.
Consider this scenario:
# seinfo -xuwheel.id
Users: 1
user wheel.id roles wheel.role level s0 range s0;
# selinuxconlist wheel.id sys.id:sys.role:sys.isid:s0
wheel.id:wheel.role:user.systemd.subj:s0
Now consider this scenario:
# echo '(userrole wheel.id sys.role)' > hack.cil && semodule -i hack.cil
# seinfo -xuwheel.id
Users: 1
user wheel.id roles { wheel.role sys.role } level s0 range s0;
Here is the issue:
# selinuxconlist wheel.id sys.id:sys.role:sys.isid:s0
wheel.id:sys.role:sys.isid:s0
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.
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.
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.
--
gpg --locate-keys dominick.grift@xxxxxxxxxxx
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098
Dominick Grift
Attachment:
signature.asc
Description: PGP signature
