Ceph : Issueshttps://tracker.ceph.com/https://tracker.ceph.com/favicon.ico2022-03-16T10:59:51ZCeph
Redmine RADOS - Feature #54580 (New): common/options: add FLAG_SECURE to Ceph optionshttps://tracker.ceph.com/issues/545802022-03-16T10:59:51ZErnesto Puerta
<a name="Context"></a>
<h3 >Context<a href="#Context" class="wiki-anchor">¶</a></h3>
<p>It has been reported by several users that <code>ceph config dump</code> and <code>ceph config-key dump</code> may expose sensitive information (Grafana admin password, RGW API keys, RBD mirror secrets, etc.). These users would prefer to have a dump that omits or redacts the secrets from that output (in a similar way as password inputs mask the remembered passwords).</p>
<pre>
# ceph config-key dump
...
"config-history/xx/+mgr/mgr/dashboard/RGW_API_ACCESS_KEY": "12345679ABCDEF",
...
</pre>
<a name="Implementation-proposal"></a>
<h3 >Implementation proposal<a href="#Implementation-proposal" class="wiki-anchor">¶</a></h3>
<p>Ceph options support <a href="https://github.com/ceph/ceph/blob/cac29ca70a76ddf7a04ee12aaf7ed2012cd12f22/src/common/options.h#L119-L127" class="external">flags</a>, so a new flag (e.g.: <code>FLAG_SECRET</code>) could be used to hint that a given option contains sensitive information and it therefore shouldn't be reproduced by default.</p>
<p>In order to still allow users to perform a complete dump of settings, a new command option should be specified (e.g.: @ceph config-key dump --include-secrets).</p>
<p><strong>Before:</strong><br /><pre>
# ceph config-key dump
...
"config-history/xx/+mgr/mgr/dashboard/RGW_API_ACCESS_KEY": "*****************",
...
</pre></p>
<p><strong>After:</strong><br /><pre>
# ceph config-key dump --secrets
...
"config-history/xx/+mgr/mgr/dashboard/RGW_API_ACCESS_KEY": "12345679ABCDEF",
...
</pre></p>
<h3>References
<ul>
<li><a class="external" href="https://tracker.ceph.com/issues/37503">https://tracker.ceph.com/issues/37503</a></li>
<li><a href="https://kubernetes.io/docs/tasks/configmap-secret/managing-secret-using-kubectl/" class="external">Kubernetes secrets</a></li>
</ul></h3> Dashboard - Cleanup #50963 (Resolved): mgr/dashboard: stop polling when page is not visiblehttps://tracker.ceph.com/issues/509632021-05-24T18:47:23ZErnesto Puerta
<p>Modern browsers provide support to detect whether a page is visible by the user or not (<a class="external" href="https://www.w3.org/TR/page-visibility/">https://www.w3.org/TR/page-visibility/</a>).</p>
<p>We should rely on that to only poll the back-end when the browser tab is visible. That way we'd heavily reduce the load generated from the front-end. That might have an impact, for example, if a user has many Dashboard tabs opened, which would multiply the number of HTTP requests to the back-end.</p> Dashboard - Bug #47356 (Resolved): mgr/dashboard: some nfs-ganesha endpoints are not in correct s...https://tracker.ceph.com/issues/473562020-09-08T08:11:20ZKiefer Chang
<p>The <a href="https://github.com/ceph/ceph/blob/056d8776ce1133928f4473a2f63e4537cecec5f2/src/pybind/mgr/dashboard/controllers/nfsganesha.py#L271-L311" class="external">endpoints</a> in the <code>/ui-api/ganesha-nfs</code> and <code>/api/ganesha-nfs/daemons</code> paths need to be scoped.</p> Dashboard - Bug #44591 (Resolved): CVE-2020-27839: mgr/dashboard: The ceph dashboard is vulnerabl...https://tracker.ceph.com/issues/445912020-03-13T07:49:08ZAnonymous
<p>To authenticate the user with the ceph dashboard the user can exchange a username and password for a jwt token. This token will be stored inside the users browser. On every request, the ceph dashboard attaches this token to the 'Authorization' header to get access to the api.<br />The problem is how we store this token. Currently, we just save it inside the local storage of the browser which makes it vulnerable to XSS attacks. If any of our npm dependencies is compromised, an attacker could steal the token of a user and use it. I also tried to inject malicious code into the translation files, we host on transifex. I did not manage to attack the dashboard with that approach, because the angular i18n compiler rejected all script tags, but that does not mean that it is not possible. <br />Keeping the npm packages up to date is very important, but doesn't fix the problem either. Not anyone, who is running a ceph cluster, is going to update it on a regular basis (every week or two).</p>
Currently I see three solutions:
<ul>
<li>Critical actions should always ask for user credentials<br />What are critical actions? From my point of view, at least all user management actions. Changing the role of a user or en- and disabling an account of another user should not be possible without entering the password of the current user.</li>
</ul>
<ul>
<li>2FA<br />Using two factor authentication will mitigate attacks. At least the attacker cannot request a token with just the username and password. The XSS problem would still exist.</li>
</ul>
<ul>
<li>Double submitted cookies<br />Storing the jwt token in a httpOnly cookie prevents XSS attacks, but opens the door for csrf attacks. With sending two coockies, one containing the jwt header and payload (httpOnly disabled), and one containing the signature, could be a solution. JavaScript can not read the content of httpOnly cookies, but the content of cookies without httpOnly. So, our frontend could read the header.payload and sends it with every request, inside a meta tag. The backend could then reconstruct the token.</li>
</ul>
<p>Please see: <a class="external" href="https://medium.com/lightrail/getting-token-authentication-right-in-a-stateless-single-page-application-57d0c6474e3">https://medium.com/lightrail/getting-token-authentication-right-in-a-stateless-single-page-application-57d0c6474e3</a> for more details</p> Dashboard - Bug #44237 (Resolved): mgr/dashboard: security: some system roles allow accessing sen...https://tracker.ceph.com/issues/442372020-02-21T12:11:04ZErnesto Puerta
<p>Some system roles (<code>pool-manager</code>, <code>cephfs-manager</code>, <code>ganesha-manager</code> etc) have the <code>configOpt</code> read permissions enabled, which allows to read all cluster config options and manager module config options. The latter includes RGW keys or Grafana user/admin, plus any sensitive information used by existing or new modules. As dashboard cannot control what new information is exposed by these modules, the suggestion is to remove that read permission from all system roles except the specific management ones (<code>adminstrator</code> and <code>cluster-manager</code>).</p>
The reason why configOpts was added to those roles is that at some point they require access to some cluster configuration settings:
<ul>
<li><b><code>pool-manager</code></b>: checks <code>/api/cluster_conf/osd_pool_default_pg_autoscale_mode</code>. This parameter could/should also be exposed via <code>/api/pools/_info</code>, which already returns other ceph config params (e.g.: <code>bluestore_compression_algorithm</code>).</li>
<li><b><code>ganesha-manager</code>, <code>cephfs-manager</code>, <code>rgw-manager</code></b>: I couldn't find any direct dependency with cluster config options.</li>
</ul>
<p>different case is the <code>read-only</code> role. While it initially makes sense to allow <code>configOpt</code> read permission, dashboard administrator might guess that <code>read-only</code> perfectly fits for a <code>guest</code>/low-privileged user. On the contrary, a <code>read-only</code> user has access to the same sensitive data as mentioned above.</p>
Suggested next steps:
<ul>
<li>Discuss and agree on <code>read-only</code> user with/without access to <code>configOpts</code>. This could improve by splitting it into 2: <code>administrator-read-only</code> and <code>guest</code> (without the read permission on sensitive data). As I'm against adding more roles, I'd simply leave the low-privilege <code>guest</code> one.</li>
<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 #43607 (Resolved): mgr/dashboard: fix improper URL checkinghttps://tracker.ceph.com/issues/436072020-01-15T12:59:37ZErnesto Puerta
<p>From <a class="external" href="https://github.com/rook/rook/issues/4635">https://github.com/rook/rook/issues/4635</a></p>
<p>Only release 14.2.5 and above show this behaviour (including master) introduced in <a class="external" href="https://github.com/ceph/ceph/pull/30694">https://github.com/ceph/ceph/pull/30694</a>.</p>
<p>Assigned CVE-2020-1699</p>
<p><a href="https://cwe.mitre.org/data/definitions/22.html" class="external">CWE-22</a></p> Dashboard - Documentation #42165 (New): mgr/dashboard: Document new password requirements in the ...https://tracker.ceph.com/issues/421652019-10-02T13:45:17ZLenz Grimmer
<p>Starting with Ceph Octopus, the Dashboard supports enforcing some minimum password complexity rules. These limitations should be documented, so users are aware when creating new user accounts. In particular, it should be noted that a password:</p>
<ul>
<li>Must contain at least 8 characters</li>
<li>Cannot contain username</li>
<li>Cannot contain any keyword used in Ceph, e.g. "osd", "host", "dashboard", "pool", "block", "nfs", "ceph", "monitors", "gateway", "logs", "crush", "maps" </li>
<li>Cannot contain any repetitive characters e.g. "aaa" </li>
<li>Cannot contain any sequencial characters e.g. "abc" </li>
<li>Must consist of characters from the following groups:
<ul>
<li>alphabetic a-z, A-Z</li>
<li>numbers 0-9</li>
<li>special chars: !"#$%& \'()*+,-./:;<=>?@[]^_`|~</li>
<li>any other characters (signs)</li>
</ul></li>
</ul> Dashboard - Feature #40329 (Closed): mgr/dashboard: It should be possible to set an expiration da...https://tracker.ceph.com/issues/403292019-06-13T12:29:48ZTiago Melo
<p>As as admin I should be able to set a TTL for the password to expire.<br />It should be a cluster wide configuration.<br />p.e.: every user should change his password every 3 months.</p>
<p>Further questions:</p>
<ul>
<li>admin password expiry: Should it be possible to set an expiry date for the admin password as well? Or only if there is at least another admin account? If it should not be possible to set expiry date prevent the user from doing so.</li>
<li>disabled users password expiry: Should it be possible to set/have an expiry date for disabled users?</li>
<li>'ac_user_create_cmd' requires timestamp as 'pwd_expiry_date': The function (ac_user_create_cmd) to create a user on the command line requires a timestamp as 'pwd_expiry_date' at the moment. Do we want to keep it or change the behavior here?</li>
<li>recalculate password expiry date: issue <a class="external" href="https://tracker.ceph.com/issues/40329">https://tracker.ceph.com/issues/40329</a> introduces a default expiry span (USER_PWD_DEFAULT_EXPIRY_SPAN) for the user passwords and adds a password expiry date field (pwd_expiry_date) to the User class. If the administrator edits the USER_PWD_DEFAULT_EXPIRY_SPAN variable the password expiry dates need to be re-calculated.</li>
<li>update password expiry date (which is set manually): If the 'USER_PWD_DEFAULT_EXPIRY_SPAN' is set and the user changes the password, it's easy to update the expiry date to the next date. But what happens if 'USER_PWD_DEFAULT_EXPIRY_SPAN' is not set and the password expiry date was entered manually?</li>
</ul> Dashboard - Feature #40248 (Closed): mgr/dashboard: As a user, I want to change my passwordhttps://tracker.ceph.com/issues/402482019-06-10T21:41:00ZRicardo Marquesrimarques@suse.com
<p>Ceph Dashboard must have a page where the logged in user can change his own password.</p> Dashboard - Bug #37379 (New): mgr/dashboard: User can see previous user's notification.https://tracker.ceph.com/issues/373792018-11-23T12:50:47ZTina Kallio
<p>If a user log in to the same browser after another user, all events listed in "Recent notifications" from previous user are displayed, see image. Note! This is not a problem when using a new browser.<br /><img src="https://tracker.ceph.com/attachments/download/3826/recent%20notifications.png" alt="" /></p> Dashboard - Feature #25232 (Closed): mgr/dashboard: Support minimum password complexity rules https://tracker.ceph.com/issues/252322018-08-02T03:14:10ZPaul Cuzner
<p>For local accounts, password should adhere to some basic complexity rules</p>
<p>Suggested rules;<br />- at least 6 chars in length<br />- must not be the same as the user account name<br />- consist of characters from the following groups<br /> - alphabetic a-z, A-Z<br /> - numbers 0-9<br /> - special chars: !_@<br />- must use at least 1 special char</p> Dashboard - Feature #25229 (Closed): mgr/dashboard: Provide user enable/disable capabilityhttps://tracker.ceph.com/issues/252292018-08-02T02:40:40ZPaul Cuzner
<p>By adding a user enable/disable feature, the dashboard supports temporarily revoking access to the management UI</p>
This is useful in the following scenarios:
<ul>
<li>new users can have their accounts set up in advance and then enabled</li>
<li>users absent from work for a vacation can have their account disabled to prevent others using it</li>
</ul>
<p>The admin account should be excluded from this feature.</p> Dashboard - Feature #24672 (Closed): mgr/dashboard: Prevent user from accessing unallowed pageshttps://tracker.ceph.com/issues/246722018-06-27T07:48:54ZVolker Theile
<p>After the role management is available in Ceph Dashboard we should add a UI route guard to prevent the user from reaching pages that requires privileges that the user does not have.</p>
<p>Example:<br />If a user is configured with read-only access and navigate to the URL <a class="external" href="http://&lt;HOST&gt;:&lt;PORT&gt;/#/rgw/user/add">http://&lt;HOST&gt;:&lt;PORT&gt;/#/rgw/user/add</a>, then a warning message/page should be displayed.</p> Dashboard - Feature #24662 (Resolved): mgr/dashboard: SSL-enabled dashboard does not play nicely ...https://tracker.ceph.com/issues/246622018-06-26T12:48:02ZFlorian Haas
<p><a class="external" href="http://docs.ceph.com/docs/master/mgr/dashboard/#reverse-proxies">http://docs.ceph.com/docs/master/mgr/dashboard/#reverse-proxies</a> talks about running the ceph-mgr dashboard behind a reverse proxy, so I am assuming that that is a deployment scenario that is at least meant to be supported. Unfortunately, I'm not quite sure how that would work, the way the dashboard is currently wired (in Mimic).</p>
<p>Consider the following scenario:</p>
<ul>
<li>I have three mgr instances, `daisy`, `eric`, and `frank`.</li>
<li>The dashboard module is enabled and is configured to listen on port 8443.</li>
</ul>
<p>I now have the following HAproxy configuration, which exposes the dashboard on the frontend's port 443.</p>
<pre>
frontend dashboard_front
bind 0.0.0.0:80
redirect scheme https code 301 if !{ ssl_fc }
frontend dashboard_front_ssl
mode tcp
bind 0.0.0.0:443
default_backend dashboard_back_ssl
backend dashboard_back_ssl
mode tcp
balance source
stick-table type ip size 200k expire 30m
stick on src
server daisy 192.168.122.114:8443 check
server eric 192.168.122.115:8443 check
server frank 192.168.122.116:8443 check
</pre>
<p>From the HAproxy side of things this is working perfectly fine. However, consider what happens if I issue a `curl` request against the HTTP frontend:</p>
<pre>
curl -k -IL http://[frontend HAproxy IP]
HTTP/1.1 301 Moved Permanently
Content-length: 0
Location: https://[frontend HAproxy IP]/
Connection: close
HTTP/1.1 303 See Other
Date: Tue, 26 Jun 2018 12:40:19 GMT
Content-Length: 108
Content-Type: text/html;charset=utf-8
Location: https://daisy.example.com:8443/
Server: CherryPy/3.5.0
curl: (6) Could not resolve host: daisy.example.com
</pre>
<p>Since the redirect from CherryPy includes not only the name, but also the port of the backend server, it would seem to me that this means that a remote client can't possibly connect unless the internal hostname is resolvable via the DNS, <strong>and</strong> the frontend proxy is configured to listen on the same port as the backend host.</p>
<p>The <code>url_prefix</code> configuration option is not of much help here, because it is merely appended to the backend host's IP address (or hostname) and port. Would it perhaps make sense to introduce a <code>url_alias</code> option, allowing users to override what CherryPy sets for the redirect's <code>Location</code> attribute?</p>
<p>Or is there a better way to do this?</p> Dashboard - Bug #24453 (Resolved): mgr/dashboard: Manager should complain about wrong dashboard c...https://tracker.ceph.com/issues/244532018-06-08T11:56:44ZMomcilo Medic
<p>Configuring the dashboard and selecting certificates didn't work as intended.<br />Dashboard wouldn't load (it didn't even listen on any ports).<br />When reverted to using self-signed certificates, dashboard suddenly works.</p>
<p>Expected behaviour: if, for whatever reason, certificates are wrong (format, type, ...) mgr should throw an error in log.<br />Actual behaviour: manager was silently failing to display dashboard</p>
<p>Logs from mgr are attached.</p>