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. > -- 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.
