Bug 1346379
| Summary: | Command line parameters exposed (too spurious) as well as passwords shown | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Red Hat Storage] Red Hat Storage Console | Reporter: | Ju Lim <julim> | ||||
| Component: | unclassified | Assignee: | Shubhendu Tripathi <shtripat> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Filip Balák <fbalak> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 2 | CC: | fbalak, jefbrown, julim, mkudlej, nthomas, rcyriac, sankarshan, shtripat, sisharma, vsarmila | ||||
| Target Milestone: | --- | ||||||
| Target Release: | 2 | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | rhscon-core-0.0.44-1.el7scon.x86_64, rhscon-ceph-0.0.43-1.el7scon.x86_64 | Doc Type: | If docs needed, set a value | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2016-10-19 15:20:18 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 1357777 | ||||||
| Attachments: |
|
||||||
Configuration is read by the server and passed to providers as command line args, not planning to change the same at the moment. What we do is encrypt the parameters like passwords and pass it to providers. Other parameters like evt configuration will be left as it is(as clear text)
Clear text passwords are are not shown as part of ps output. Output looks as below:
00:03:43 /var/lib/skyring/providers/bigfin eyJjb25maWciOnsiaG9zdCI6IjAuMC4wLjAiLCJodHRwUG9ydCI6ODA4MCwic3NsRW5hYmxlZCI6dHJ1ZSwic3NsUG9ydCI6MTA0NDMsInNzbENlcnQiOiIvZXRjL3BraS90bHMvc2t5cmluZy5jcnQiLCJzc2xLZXkiOiIvZXRjL3BraS90bHMvcHJpdmF0ZS9za3lyaW5nLmtleSIsInN1cHBvcnRlZHZlcnNpb25zIjpbMV19LCJsb2dnaW5nIjp7ImxvZ1RvU3RkZXJyIjpmYWxzZSwiZmlsZW5hbWUiOiIvdmFyL2xvZy9za3lyaW5nL3NreXJpbmcubG9nIiwibGV2ZWwiOjR9LCJub2RlbWFuYWdlbWVudGNvbmZpZyI6eyJtYW5hZ2VybmFtZSI6IlNhbHROb2RlTWFuYWdlciIsImNvbmZpZ2ZpbGVwYXRoIjoiIn0sImRiY29uZmlnIjp7Imhvc3RuYW1lIjoiMTI3LjAuMC4xIiwicG9ydCI6MjcwMTcsImRhdGFiYXNlIjoic2t5cmluZyIsInVzZXIiOiJhZG1pbiIsInBhc3N3b3JkIjoiYWRtaW4ifSwidGltZXNlcmllc2RiY29uZmlnIjp7Imhvc3RuYW1lIjoiMTI3LjAuMC4xIiwicG9ydCI6MTAwODAsImRhdGFQdXNoUG9ydCI6MjAwMywiY29sbGVjdGlvbl9uYW1lIjoiY29sbGVjdGQiLCJ1c2VyIjoiIiwicGFzc3dvcmQiOiIiLCJtYW5hZ2VybmFtZSI6IkdyYXBoaXRlTWFuYWdlciIsImNvbmZpZ2ZpbGVwYXRoIjoiIn0sImF1dGhlbnRpY2F0aW9uIjp7IlByb3ZpZGVyTmFtZSI6ImxvY2FsYXV0aHByb3ZpZGVyIiwiQ29uZmlnRmlsZSI6Ii9ldGMvc2t5cmluZy9hdXRoZW50aWNhdGlvbi5jb25mIn0sInN1bW1hcnkiOnsibmV0U3VtbWFyeUludGVydmFsIjozMDB9LCJwcm92aXNpb25lcnMiOnsiY2VwaCI6eyJwcm92aXNpb25lcm5hbWUiOiJjZXBoLWluc3RhbGxlciIsImNvbmZpZ2ZpbGVwYXRoIjoiIiwicmVkaGF0c3RvcmFnZSI6dHJ1ZSwicmVkaGF0dXNlY2RuIjpmYWxzZX19LCJzeXN0ZW1jYXBhYmlsaXRpZXMiOnsiUHJvZHVjdE5hbWUiOiJTa3lyaW5nIiwiUHJvZHVjdFZlcnNpb24iOiIwLjAuNDIiLCJTdG9yYWdlUHJvdmlkZXJEZXRhaWxzIjp7ImNlcGgiOiIwLjAuNDEifSwiRGJTb2Z0d2FyZSI6Ik1vbmdvIERCIiwiRGJTb2Z0d2FyZVZlcnNpb24iOiIyLjYuMTEiLCJNb25pdG9yaW5nU29mdHdhcmUiOiJHcmFwaGl0ZSIsIk1vbml0b3JpbmdTb2Z0d2FyZVZlciI6IjAuOS4xNSJ9LCJzY2hlZHVsZSI6eyJjbHVzdGVyc1N5bmNJbnRlcnZhbCI6ODY0MDB9fQ== {"ADD_MAIL_NOTIFIER":"Add mail notifier","BLOCK_DEVICVE_CREATED":"Created block device","BLOCK_DEVICVE_REMOVED":"Removed block device","BLOCK_DEVICVE_RESIZE":"Resized block device","CLUSTER_CREATED":"Cluster created","CLUSTER_EXPAND":"Cluster expanded","CLUSTER_FORGOT":"Forgot cluster","CLUSTER_MANAGE":"Cluster managed back","CLUSTER_UNMANAGE":"Cluster unmanaged","CLUSTER_UPDATED":"Cluster updated","CLUSTER_UPDATE_SLU":"Cluster slu updated","COLLECTD_STATE_CHANGED":"Collectd service state changed","CPU":"Cpu Threshold Crossed","DF":"Mount Threshold Crossed","DRIVE_ADD":"Drive Addition","DRIVE_REMOVE":"Drive Removal","GET_DISK_HIERARCHY":"Get disk hierarchy","LDAP_MODIFIED":"LDAP config modified","MEMORY":"Memory Threshold Crossed","NETWORK_THRESHOLD_CROSSED":"Network Threshold Crossed","NODE_ACCEPT":"Node accept","NODE_ADD_AND_ACCEPT":"Node add and aaccept","NODE_DELETE":"Node delete","NODE_INITIALIZE":"Node Initialize","NODE_MODIFIED":"Node Modified","NODE_STATE_CHANGED":"Node connectivity changed","STORAGE_CREATED":"Storage created","STORAGE_DELETED":"Storage deleted","STORAGE_PROFILE_CREATED":"Storage profile create","STORAGE_PROFILE_REMOVED":"Storage profile removed","STORAGE_PROFILE_UPDATED":"Storage profile updated","STORAGE_UPDATED":"Storage updated","SWAP":"Swap Threshold Crossed","TEST_MAIL_NOTIFIER":"Test mail notifier","UPDATE_DISK":"Update disk","UPDATE_MAIL_NOTIFIER":"Update mail notifier","USER_ADDED":"User added","USER_DELETED":"User deleted","USER_LOGGED_IN":"User logged in","USER_LOGGED_OUT":"User logged out","USER_MODIFIED":"User modified","block_device_utilization":"RBD Utilization","calamari_server_changed":"Calamari server changed","cluster_health_changed":"Cluster health changed","cluster_utilization":"Cluster Utilization","mon_state_changed":"MON State changed","osd_added_or_removed":"OSD Added/Removed","osd_state_changed":"OSD State changed","pool_added_or_removed":"Pool Added/Removed","rbd_added_or_removed":"RBD Added/Removed","rbd_resized":"RBD Resized","slu_utilization":"OSD Utilization","storage_profile_utilzation":"Storage Profile Utilization","storage_utilization":"Pool Utilization"} {"provider":{"name":"ceph","binary":"/var/lib/skyring/providers/bigfin","compatible_version":10.1},"routes":null,"provisioner":{"provisionername":"ceph-installer","configfilepath":"","redhatstorage":true,"redhatusecdn":false},"provideroptions":{"max_metadata_on_ssd":4,"min_monitors_in_cluster":3}}
Password is hashed in Base64. It could be decoded by anyone. According to QE it is not right solution for this issue. >>Assigned Now first the configurations are encrypted using a key (AES encryption), and then the data is base64 encoded so that there are no newline chars and could be passed as command line argument to providers. The provider code first base64 decodes the data and using the same key decrypts the configurations to use. Tested with Server: ceph-ansible-1.0.5-34.el7scon.noarch ceph-installer-1.0.15-2.el7scon.noarch graphite-web-0.9.15-1.el7.noarch rhscon-ceph-0.0.43-1.el7scon.x86_64 rhscon-core-0.0.45-1.el7scon.x86_64 rhscon-core-selinux-0.0.45-1.el7scon.noarch rhscon-ui-0.0.59-1.el7scon.noarch and it works as it is expected. --> Verified Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2016:2082 |
Created attachment 1167930 [details] "ps -ef | grep skyring" output Description of problem: It appears that all the parameters are being passed on the command line when starting one of the services. Is this best practice or a don't care when starting these kinds of services? Is this something the service should be reading from parameters file? Version-Release number of selected component (if applicable): How reproducible: During installation and trying to get RHSC2 up, user performs "ps -ef | grep skyring" and see a lot of parameters being passed along with passwords in clear text. Steps to Reproduce: 1. 2. 3. Actual results: See attachment Expected results: root 5277 1 0 08:10 ? 00:00:00 /usr/bin/skyring Additional info: