On 09/26/2016 04:34 PM, Dominick Grift wrote: > On 09/26/2016 04:20 PM, Stephen Smalley wrote: >> On 09/24/2016 04:26 AM, Dominick Grift wrote: >>> On 09/23/2016 09:36 PM, Stephen Smalley wrote: >>>> On 09/23/2016 10:28 AM, Gary Tierney wrote: >>>>> Introduces support for generating homedir/user contexts for >>>>> policies that implement RBACSEP. The support works by taking >>>>> the prefix of a logins seuser and replacing the role field in >>>>> their context specifications with the prefix. A new option >>>>> "genhomedircon-rbacsep" was added to /etc/selinux/semanage.conf >>>>> to allow toggling this behavior. >>>> >>>> The user prefix was previously used as a prefix for types, e.g. >>>> you could have: HOME_DIR/\.gnupg(/.+)? >>>> system_u:object_r:ROLE_gpg_secret_t and get it replaced with: >>>> /home/[^/]+/\.gnupg(/.+)? >>>> system_u:object_r:user_gpg_secret_t /root/\.gnupg(/.+)? >>>> system_u:object_r:sysadm_gpg_secret_t >>>> >>>> So I guess you could use it for the role field too, but for >>>> consistency you would want it to be: HOME_DIR/\.gnupg(/.+)? >>>> system_u:ROLE_r:ROLE_gpg_secret_t >>>> >>>> and the prefix would still just be "user". >>> >>> No one is actually using that privsep functionality anymore. >>> Reference policy removed support for it. >>> >>> Can we not instead just re-use that code for rbacsep? >>> >>> The alternative would be to add code similar to the privsep code >>> but then for rbacsep. >>> >>> Then we will have the issue that we can't reasonably rely on the >>> userprefix and prefix statements for rbacsep, because they might be >>> used for privsep (in theory at least) >>> >>> I other words if we were to implement rbacsep code similar to the >>> privsep code, then we would need a new policy statement similar to >>> userprefix and prefix. >>> >>> It seems much easier to me to just re-use the privsep code. >>> >>> rbacsep is the successor to privsep after all. >> >> First, I'm not sure what you mean by privsep; usually that term refers >> to privilege separation as in openssh. > > with privsep i mean prefixed user (home) content file contexts generated > by genhomedircon. > >> >> There are at least three ways of implementing "role" separation for >> objects in SELinux: >> (1) via TE and the use of derived types on objects e.g. ROLE_home_t, >> ROLE_devpts_t, etc, > > I wouldn't compare the two as ROLE_home_t is generated by genhomedircon > and ROLE_devpts_t is not > >> (2) via RBAC and the use of roles on objects (originally problematic >> because it required a set of changes to the kernel to support roles on >> objects, but that's all history now), > > This is the way forward IMHO > >> (3) via UBAC and the use of SELinux user identities on objects to >> represent roles. > > UBAC or more accurately IBACSEP is inadequate because you cannot > implement automatic identity transitions as you can automatic role > transitions. > >> >> refpolicy started with (1), experimented with (2) and seems to have >> settled on (3), likely because (2) wasn't fully supported in the >> kernel or userspace for a long time. I guess libsemanage / >> genhomedircon already support (3) adequately. > > 1. was removed (i think due to redhat objecting to it). 2. refpolicy > settled on 3 because at that time 2 was not an option (defaultrole did > not exist). libsemanage supports 3 out of the box yes but we dont have > automatic identity transitions and this makes RBACSEP a more flexible > alternative. we need to be able to deal with instances where a automatic > role transition is desired. > >> >> CIL apparently doesn't support (1), so that's broken regardless. > > (1) is currently "broken", yes or legacy > >> >> So I guess reusing the prefix for RBACSEP won't break any existing >> users. That said, it is clearly confusing to use something identified >> in the policy language and documentation as a "prefix" for the purpose >> of a "default role". So maybe we should look to rename it in the >> language and code, with backward compatibility. That can be done as a >> separate set of changes. That might also help us with a different >> problem - obsoleting security_compute_user() aka /sys/fs/selinux/user >> and taking the get_default_context() logic to userspace. >> > > The name prefix, and userprefix would indeed ideally need to be changed > by I would say that this would be a second step. > >> Has anyone compared UBAC vs RBAC now that the kernel and policy >> support roles on objects? Is there a strong reason for refpolicy to >> stay with (3) other than compatibility with older distributions and >> this genhomedircon issue? > > IBACSEP is not flexible enough mainly because we cannot define automatic > identity transitions. > > Also until recently we did not have user attributes. but now we do so > that is no longer an issue. > >> > >
Here is one example of how i think automatic role transitions help a little Example: sudo Whoever runs sudo first on the the system gets to create /var/run/sudo/lectured Imagine two selinux users associated with types that need to be able to run sudo (joe_u/jane_u) A user associated with joe_u runs sudo first, thus /var/run/sudo/lectured gets associated with the joe_u identity. Now the user associated with jane_u gets lectured all the time because the users sudo instance cannot access /var/run/sudo/leactured. With a automatic role transition we can tell SELinux to automatically role transition to system_r on sudo_var_run_t type dirs. This way RBACSEP constrained roles can access /var/run/sudo/lectured An alternative approach would be to lift the RBACSEP constraint from sudo_var_run_t, but that does not take away the argument that automatic role transitions make RBACSEP a more flexible alternative It makes RBACSEP just a small fraction more flexible than IBACSEP. (ideally the issue would be resolved with a tempfiles.d snippet for /run/sudo and /run/sudo/lectured (which is implemented on my request) -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 Dominick Grift
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
