On Tue, Sep 27, 2016 at 09:39:49AM -0400, Stephen Smalley wrote:
> On 09/27/2016 03:44 AM, Dominick Grift wrote:
> > 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
>
> Ok, so let's drop the unrelated change from the patch, resolve whether
> we want this to be enabled through semanage.conf or some other means,
> and get a final patch for it. And then look in the future toward
> renaming things in a backward-compatible manner.
An issue with the semanage.conf option is that switching from an RBACSEP
policy to a non-RBACSEP policy (or vice versa) could result in no
homedir contexts being generated if semanage.conf isn't updated to
reflect that. This was raised by one of the Gentoo guys r.e. users
installing policy packages.
So, thinking about the semanage.conf option with refactoring prefix to
something more suitable in the future in mind I came up with the
following:
We can drop the option and treat the "prefix" as a homedir role,
regardless of whether the policy implements RBACSEP or not. In the
future this could either be object_r, or a RBACSEP constrained role (or
even an object role defined in policy with an identifier other than
object_r). This way we can do the following checks before trying to
write out contexts to preserve backwards compatability:
1. Check if the given prefix is a valid role in the policy.
2. Check that the users list of roles contains the prefix, or that the
role is object_r.
3. Start writing contexts out as normal but with fixed roles. If an
error is encountered with a generated context we can issue a warning
about it and skip that entry, preserving genhomedircons current behavior
(it's unlikely that we did not intend to use RBACSEP if we got this far,
since a users prefix typically wouldn't be the identifier of a valid
role).
If any of the checks leading up to 3 fail, we just write out the
contexts as we usually would without fixing the role. This would
preserve backwards compatability and allow the old privsep model to work
just based on string substitution.
This approach also makes toggling RBACSEP support for homedirs from the
policy very easy with just a tunable:
(block user
(user id)
(role role)
(userrole id role)
(tunableif enable_rbacsep
(true
(userprefix id role)) # (userhomerole id role) ?
(false
(userprefix id object_r))))
I'm respinning my patch to see how that goes and will get it up later
today.
--
Gary Tierney
GPG fingerprint: 412C 0EF9 C305 68E6 B660 BDAF 706E D765 85AA 79D8
https://sks-keyservers.net/pks/lookup?op=get&search=0x706ED76585AA79D8
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.
