On Mon, Sep 26, 2016 at 10:20:12AM -0400, 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. > > 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, > (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), > (3) via UBAC and the use of SELinux user identities on objects to > represent roles. > > 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. > > CIL apparently doesn't support (1), so that's broken regardless. > > 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. > > 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? >
Another likely issue is also with sudo. An unprivileged user (staff_u) runs sudo to change to root/sysadm_r in order to create a file that should be accessible system wide. The file he created will end up with staff_u identity and IBACSEP constrained processes might not be able to access it. This wouldnt be an issue with RBACSEP because the role is changed to sysadm_r, which is not RBACSEP constrained. (no "privileged" roles are constrained) This IBACSEP sudo issue can be avoided by using: `machinectl shell .host` instead. which will change the context fully to sysadm_u:sysadm_r:sysadm_t However that is more difficult to configure and depends on systemd -- 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: PGP 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.
