> >> Liane Praza wrote:
> >>> 3.2 New privileges
> >>>
> >>> In order to be able to reliably identify a process contract based
> >>> on the service FMRI value, we will require privilege to set the
> >>> term in the process contract template. There is no current
> >>> privilege that could be leveraged for the purpose of contract
> >>> identification. Thus, we introduce a new privilege,
> >>> {PRIV_CONTRACT_IDENTITY}, that will be required of processes that
> >>> set the Service FMRI term.
> >> I'm assuming this applies to both the "Service FMRI" and the "Creator
> >> Auxiliary" information. This means that end users using ctrun(1) won't
> >> be able to setup contract identities that seems a shame since they can
> >> create new contracts.
> >>
> >> Would it be sufficient that the privilege is needed only to change the
> >> stored identity information if it is already set or be required only to
> >> set the "Service FMRI" and to change the aux information (if already set).
> Actually the privilege is required only for setting the "Service FMRI".
> The man pages diffs should better clarify that the privilege is required
> for ctrun -F and ct_pr_tmpl_set_svc_fmri().
>
> >>
> >> This looks like great stuff and I'd like to see it get as much scope for
> >> use. I can see that setting a service FMRI as an end user could be seen
> >> as a bad thing because it could confuse analysis tools but I'm not sure
> >> I see the security risk in doing so, is there one ?
> There is no security vulnerability in not requiring privilege to set the
> "Service FMRI". Requiring privilege has the goal of making the term
> "Service FMRI" a trusted, system-wide name for observability purposes.
> Just as the SMF service FMRI is today.
Hummm, is that really worth adding a privilege and requiring
ctrun to be called with that privilege? What's the risk of
the FMRI being spoofed on a contract?
What Rights Profile is being proposed to grant ctrun privilege?
And who should be granted this profile?
Gary..
> We don't require the privilege for term "Creator Auxiliary" so that
> unprivileged processes can differentiate contracts they spawn. After
> all, the contracts created by an unprivileged process would all have the
> same inherited "Service FMRI".
>
> >
> >
> > I would expect you would need to "own" the contract in question or
> > be able to control it in order to set the identity.
> The terms of a contract cannot be changed after it is created.
> Therefore, when a process owns a contract, it cannot change the
> contract's identity terms.
