Ceph : Issueshttps://tracker.ceph.com/https://tracker.ceph.com/favicon.ico2020-01-15T12:59:37ZCeph
Redmine 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 - Bug #43262 (New): mgr/dashboard: security: upgrade serialize-javascripthttps://tracker.ceph.com/issues/432622019-12-11T16:38:46ZErnesto Puerta
<p><a href="https://github.com/advisories/GHSA-h9rv-jmmf-4pgx" class="external">GHSA-h9rv-jmmf-4pgx</a>. Seems it might have no impact on dashboard, as it's a dependency of webpack, and hence used only at build time.</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 - Bug #41990 (Resolved): mgr/dashboard: hide Python tracebacks in response errorshttps://tracker.ceph.com/issues/419902019-09-23T09:57:58ZErnesto Puerta
<p>Currently all errors handled by Cherrypy tools result in Python traceback including sensitive context information (Python version, file locations, packages, etc).</p>
<p>This does not only pose a security risk, but also pollutes logs with traceback lines, which makes it really hard to find where an unexpected traceback happened.</p>
<p>This could be easily fixed by setting Cherrypy environment to <a href="https://docs.cherrypy.org/en/latest/config.html#environments" class="external"><code>production</code></a></p> Dashboard - Bug #41320 (Resolved): mgr/dashboard: passwords and other sensitive information is wr...https://tracker.ceph.com/issues/413202019-08-16T17:56:29ZErnesto Puerta
<p>Currently dashboard is storing in plain text logs the following sentitive information:</p>
<p>- <del>Dashboard user names, passwords and roles.</del> -> handled in <a class="issue tracker-1 status-3 priority-4 priority-default closed parent" title="Bug: Audit log: mgr module passwords set on CLI written as plaintext in log files (Resolved)" href="https://tracker.ceph.com/issues/37503">#37503</a></p>
<blockquote>
<p><del>log_channel(audit) log [DBG] : from='client.4126 -' entity='client.admin' cmd=[{"username": "admin", "rolename": "administrator", "prefix": "dashboard ac-user-create", "password": "admin"}]</del></p>
</blockquote>
<p>- RGW API keys:</p>
<blockquote>
<p>cmd=[{"prefix": "dashboard set-rgw-api-access-key", "target": ["mgr", ""], "value": "<real_key>"}]<br />cmd=[{"prefix": "dashboard set-rgw-api-secret-key", "target": ["mgr", ""], "value": "<real_key>"}]:</p>
</blockquote>
<p>- JWT tokens:</p>
<blockquote>
<p>"JWT Token: <real_token>"</p>
</blockquote>
<p>This information should be redacted from the logs. While access to logs could be limited to privileged users, this is considered insecure (even with hashed passwords).</p> 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 - Feature #39999 (Resolved): mgr/dashboard: Prevent brute-force/dictionary attacks agai...https://tracker.ceph.com/issues/399992019-05-22T13:11:54ZLenz Grimmer
<p>If passwords are used as an authentication feature (no SSO enabled), there must be protection against dictionary and brute force attacks, to make it more difficult to guess passwords.</p>
<p>Dictionary and brute force attacks aim to guess passwords of user and machine accounts by automated testing. To prevent this, various measures or a combination of such measures can be implemented.</p>
<ul>
<li>Increasing time delay (e.g. doubling the waiting time for each attempt) for re-entering a password after an unsuccessful attempt.</li>
<li>Locking the user account after a specified number of failed attempts (typically 5). However, with this solution it should be remembered that this requires an unlocking process and that an attacker can use this to lock accounts and make them unusable.</li>
<li>Use of CAPTCHA to prevent automated probing (often used in web applications)</li>
</ul>
<p>In order to achieve a higher level of safety, it often makes sense to combine two or more of the above measures.</p>
<p>Motivation: Without appropriate protection, an attacker can attempt to determine a password by simply trying out dictionary lists or automatically generated character combinations in order to misuse the corresponding user account.</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 - Feature #24655 (Closed): mgr/dashboard: Enforce password change upon first loginhttps://tracker.ceph.com/issues/246552018-06-25T15:44:08ZLenz Grimmer
<p>For local user accounts, it should be possible to enforce a password change upon the first login to the dashboard. This could be determined by either having a flag associated with the user (e.g. "reset_password"), or by checking a "last login" timestamp (which would also make it possible to enforce a password change after a certain period of time). With regards to issue <a class="issue tracker-2 status-6 priority-4 priority-default closed" title="Feature: mgr/dashboard: Allow user to reset a forgotten password (Rejected)" href="https://tracker.ceph.com/issues/24654">#24654</a> it might actually be feasible to have the "reset_password" flag as well.</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>