Re: [PATCH 1/1] genhomedircon: support policies using RBACSEP

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

Attachment: signature.asc
Description: PGP signature

_______________________________________________
Selinux mailing list
Selinux@xxxxxxxxxxxxx
To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.

[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux