https://tracker.ceph.com/https://tracker.ceph.com/favicon.ico2020-02-21T12:11:25ZCeph Dashboard - Bug #44237: mgr/dashboard: security: some system roles allow accessing sensitive informationhttps://tracker.ceph.com/issues/44237?journal_id=1592162020-02-21T12:11:25ZErnesto Puerta
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/159216/diff?detail_id=163118">diff</a>)</li></ul> Dashboard - Bug #44237: mgr/dashboard: security: some system roles allow accessing sensitive informationhttps://tracker.ceph.com/issues/44237?journal_id=1592172020-02-21T12:11:43ZErnesto Puerta
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/159217/diff?detail_id=163119">diff</a>)</li></ul> Dashboard - Bug #44237: mgr/dashboard: security: some system roles allow accessing sensitive informationhttps://tracker.ceph.com/issues/44237?journal_id=1593432020-02-24T08:47:28ZVolker Theile
<ul></ul><p>I had a similar problem implementing <a class="external" href="https://github.com/ceph/ceph/pull/32680">https://github.com/ceph/ceph/pull/32680</a>. There was a need to get some settings exposed to the UI but for users without configOpts privileges. I enhanced the already existing /ui-api/standard_settings endpoint (see <a class="external" href="https://github.com/ceph/ceph/pull/32680/files#diff-c3a875d99d1cd079a9e1f9b86dbe8195R92">https://github.com/ceph/ceph/pull/32680/files#diff-c3a875d99d1cd079a9e1f9b86dbe8195R92</a>), but this would not fit in the future when there is the need to expose more settings in such a case. Currently i do not have any idea how to improve the privilege model, but i have the strong feeling that it requires some refactoring.</p> Dashboard - Bug #44237: mgr/dashboard: security: some system roles allow accessing sensitive informationhttps://tracker.ceph.com/issues/44237?journal_id=1594032020-02-24T10:25:58ZLenz Grimmer
<ul></ul><p>Good observation; thanks for bringing this up!</p>
<p>About your first suggestion: I think the term <code>guest</code> is too generic and may leave users confused about what this could be used for.</p>
<p>The original intention of the <code>readonly</code> role was being able to have these user to log into the dashboard and to view that cluster's health state and current configuration (e.g. Pools and services), which includes it's config settings, but does not allow making any changes to any object or entity of the cluster. But there's indeed a potential risk that this gives these users a way to obtain credentials that would allow them to elevate their privileges for certain services outside of using the dashboard.</p>
<p>Renaming a role during an upgrade may be more complicated than simply updating it's privileges. I'm fine with revoking access to <code>configOpts</code> in general for the <code>readonly</code> role, otherwise we'd end up with maintaining black/whitelists of which config options should be accessible (but maybe such a black/whitelist filter for config options would be desirable?)</p>
<p>I also agree to your other two suggested next steps:</p>
<ul>
<li>Make <code>pool-form</code> get <code>osd_pool_default_pg_autoscale_mode</code> from <code>/pool/_info</code>.</li>
<li>Remove <code>configOpt</code> read perm (and test) in all other roles.</li>
</ul> Dashboard - Bug #44237: mgr/dashboard: security: some system roles allow accessing sensitive informationhttps://tracker.ceph.com/issues/44237?journal_id=1594042020-02-24T10:27:59ZLenz Grimmer
<ul><li><strong>Target version</strong> set to <i>v15.0.0</i></li></ul> Dashboard - Bug #44237: mgr/dashboard: security: some system roles allow accessing sensitive informationhttps://tracker.ceph.com/issues/44237?journal_id=1594062020-02-24T10:28:53ZLenz Grimmer
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-5 priority-4 priority-default closed child" href="/issues/24672">Feature #24672</a>: mgr/dashboard: Prevent user from accessing unallowed pages</i> added</li></ul> Dashboard - Bug #44237: mgr/dashboard: security: some system roles allow accessing sensitive informationhttps://tracker.ceph.com/issues/44237?journal_id=1594082020-02-24T10:29:47ZLenz Grimmer
<ul><li><strong>Tags</strong> set to <i>administration, security</i></li></ul> Dashboard - Bug #44237: mgr/dashboard: security: some system roles allow accessing sensitive informationhttps://tracker.ceph.com/issues/44237?journal_id=1594142020-02-24T13:20:59ZTatjana Dehler
<ul></ul><p>Lenz Grimmer wrote:</p>
<blockquote>
<p>..., otherwise we'd end up with maintaining black/whitelists of which config options should be accessible (but maybe such a black/whitelist filter for config options would be desirable?)</p>
</blockquote>
<p>I'm not sure if there is a way around it. As Volker already wrote, we do have some config options that are required by any user to be able to log into the dashboard (for example the password expiration date). We currently have a "workaround" by using the /ui-api/standard_settings API endpoint. I fully agree with Volker that's not the right way going forward.</p> Dashboard - Bug #44237: mgr/dashboard: security: some system roles allow accessing sensitive informationhttps://tracker.ceph.com/issues/44237?journal_id=1594342020-02-24T16:18:12ZErnesto Puerta
<ul></ul><p>Thanks @Lenz, @Volker and @Tatjana!</p>
Summarizing the proposals here:
<ul>
<li>Embedding all required config setting info in <code>ui-api/</code> helper endpoints:
<ul>
<li><b>Pros</b>: existing approach (proven), easier to implement (already there) and keeps complexity/hides Ceph specifics in the back-end.</li>
<li><b>Cons</b>: these endpoints are usually pre-fetched on component loading and never refreshed. It makes harder to react to live changes.</li>
</ul>
</li>
<li>Providing fine-grained permissions at config setting-level:
<ul>
<li><b>Pros</b>: more extensible, and forms might react dynamically to changes.</li>
<li><b>Cons</b>: requires changes to config controller, it might be harder to extend/maintain and track security issues, and brings complexity to front-end (routing single front-end component to multiple back-end endpoints).</li>
</ul></li>
</ul>
<p>I personally prefer the latter approach, as it'd be really easy to implement if all Ceph config options would have their corresponding service tags, as we could reuse that info for automatically tagging scopes per cluster config option:<br /><pre><code class="cpp syntaxhl"><span class="CodeRay"><span class="comment">//src/common/options.h</span>
<span class="keyword">struct</span> Option {
...
<span class="comment">// Items like mon, osd, rgw, rbd, ceph-fuse. This is advisory metadata </span>
<span class="comment">// for presentation layers (like web dashboards, or generated docs), so that </span>
<span class="comment">// they know which options to display where. </span>
<span class="comment">// Additionally: "common" for settings that exist in any Ceph code. Do </span>
<span class="comment">// not use common for settings that are just shared some places: for those </span>
<span class="comment">// places, list them. </span>
std::vector<<span class="directive">const</span> <span class="predefined-type">char</span>*> services;
</span></code></pre></p>
<p>However, for this specific case, we may see that there's no match between our <code>pool-manager</code> role and any Ceph service (<code>rbd</code>, <code>rgw</code>, ...).</p>
<pre><code class="diff syntaxhl"><span class="CodeRay"> Option("osd_pool_default_pg_autoscale_mode", Option::TYPE_STR, Option::LEVEL_ADVANCED)
.set_default("on")
.set_flag(Option::FLAG_RUNTIME)
.set_enum_allowed({"off", "warn", "on"})
.set_description("Default PG autoscaling behavior for new pools"),
<span class="line insert"><span class="insert">+</span> .add_service("pool") // weird. Instead: rbd + cephfs + rgw</span>
</span></code></pre>
<p>IMHO this is an indication that the <code>pool</code> scope and <code>pool-manager</code> role are not very meaningful <em>per se</em>. Instead we should probably remove <code>pool-manager</code> and <code>pool</code> scope and only allow <code><service>-manager</code> to create/edit/delete pools with application tag <code><service></code> (let <code><service></code> be <code>rgw</code>, <code>cephfs</code> or <code>rbd</code>).</p> Dashboard - Bug #44237: mgr/dashboard: security: some system roles allow accessing sensitive informationhttps://tracker.ceph.com/issues/44237?journal_id=1595172020-02-25T13:15:58ZAlfonso Martínezalmartin@redhat.com
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li><li><strong>Assignee</strong> set to <i>Alfonso Martínez</i></li></ul> Dashboard - Bug #44237: mgr/dashboard: security: some system roles allow accessing sensitive informationhttps://tracker.ceph.com/issues/44237?journal_id=1601542020-03-03T11:37:55ZAlfonso Martínezalmartin@redhat.com
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Fix Under Review</i></li><li><strong>Pull request ID</strong> set to <i>33690</i></li></ul> Dashboard - Bug #44237: mgr/dashboard: security: some system roles allow accessing sensitive informationhttps://tracker.ceph.com/issues/44237?journal_id=1602342020-03-04T12:55:09ZKefu Chaitchaikov@gmail.com
<ul><li><strong>Status</strong> changed from <i>Fix Under Review</i> to <i>Pending Backport</i></li></ul> Dashboard - Bug #44237: mgr/dashboard: security: some system roles allow accessing sensitive informationhttps://tracker.ceph.com/issues/44237?journal_id=1603022020-03-05T08:37:50ZAlfonso Martínezalmartin@redhat.com
<ul><li><strong>Copied to</strong> <i><a class="issue tracker-9 status-3 priority-4 priority-default closed" href="/issues/44435">Backport #44435</a>: nautilus: mgr/dashboard: security: some system roles allow accessing sensitive information</i> added</li></ul> Dashboard - Bug #44237: mgr/dashboard: security: some system roles allow accessing sensitive informationhttps://tracker.ceph.com/issues/44237?journal_id=1621122020-03-31T09:59:18ZNathan Cutlerncutler@suse.cz
<ul><li><strong>Status</strong> changed from <i>Pending Backport</i> to <i>Resolved</i></li></ul><p>While running with --resolve-parent, the script "backport-create-issue" noticed that all backports of this issue are in status "Resolved" or "Rejected".</p> Dashboard - Bug #44237: mgr/dashboard: security: some system roles allow accessing sensitive informationhttps://tracker.ceph.com/issues/44237?journal_id=1767852020-10-06T10:45:18ZErnesto Puerta
<ul><li><strong>Parent task</strong> set to <i>#47765</i></li></ul> Dashboard - Bug #44237: mgr/dashboard: security: some system roles allow accessing sensitive informationhttps://tracker.ceph.com/issues/44237?journal_id=1772292020-10-13T15:10:47ZAlfonso Martínezalmartin@redhat.com
<ul><li><strong>% Done</strong> changed from <i>0</i> to <i>100</i></li></ul> Dashboard - Bug #44237: mgr/dashboard: security: some system roles allow accessing sensitive informationhttps://tracker.ceph.com/issues/44237?journal_id=1909392021-04-15T17:20:22ZErnesto Puerta
<ul><li><strong>Project</strong> changed from <i>mgr</i> to <i>Dashboard</i></li><li><strong>Category</strong> changed from <i>150</i> to <i>Component - Users & Roles</i></li></ul>