Hide Forgot
Description of problem: Root password should be always hashed if written in plaintext in the dialog form and UI should accept hashed password. (Thus there should be difference between plaintext and hashed password, plaintext should show just dots, hashed should show the hash.) Current behavior is unsecure (BZ1034172, BZ1034247). In GNOME normal user can mount cdrom and see plain-text content of generated cdrom which cloud-init uses. cloud-init.noarch 0:0.7.2-2.el6 should hangle hashed passwords. (But it did not work for me, maybe bad luck.) Version-Release number of selected component (if applicable): is25 How reproducible: 100% Steps to Reproduce: 1. run once - cloud-init - root password (put plain-text) 2. install gnome inside guest VM, click there and here to attach cdrom 3. get root password from cdrom 4. run once - cloud-init - root password (put hash[1]) 5. see how is hash displayed in dialog Actual results: 3 - is plaintext, thus leakes to user being able to mount cloud-init medium 5 - dots Expected results: 3 - password should be hashed by engine before making cloud-init medium 5 - should be visible plaintext as it is already hashed Additional info: [1] # python -c 'import crypt; print crypt.crypt("foobar", "$6$6VS92/Ja")' $6$6VS92/Ja$ajQceBAZ673b1WeiQIRqeWDZjwEtd4Ww1nWa4hIbW5Yi.qCM8yLr6NYk5OZkA71ugRAKD4JIqUsOLI1vgkR1R/ what about to get hashed password from rhevm-config and populate it into dialog somehow? that is - define password once, push always (easier for scripted deployement).
Idea: ideally cloud-init should be able to read virtual channel and get its data from there (thus it would need code for this new datasource). RHEVM part would reply to data request on this virtual channel.
Setting urgent priority until analysed
well, not really urgent. The cloud-init cdrom is not attached during regular runs so it should not be exposed at all. The problem with hashing is that as per vfeenstr it's not really much safer as the hashing is too easy to decode I don't see we can do much other than making user aware this is the behavior(and fix those bugs you mention)
Two comments first: * there was a bug in RHEVM which was attaching cloud-init image during every VM run * if you run with Run Once, then cloud-init image is attached, even it is not mounted. But a user can mounted from GNOME. And about hashing... That's nonsense, RHEL uses salted sha512 hashes. If you know how to easy "decode" such password, please share your know-how with world IT community, you would receive big publicity :-) Dictionary attack is off-topic.
(In reply to Jiri Belka from comment #4) > And about hashing... That's nonsense, RHEL uses salted sha512 hashes. If you > know how to easy "decode" such password, please share your know-how with > world IT community, you would receive big publicity :-) Dictionary attack is > off-topic. This is actually nothing new. The point is that you usually have not so easy access to the store, and well a dictionary attach is not really off-topic, that's simply part of the problem: # passwd: The hash -- not the password itself -- of the password you want # to use for this user. You can generate a safe hash via: # mkpasswd --method=SHA-512 --rounds=4096 # (the above command would create from stdin an SHA-512 password hash # with 4096 salt rounds) # # Please note: while the use of a hashed password is better than # plain text, the use of this feature is not ideal. Also, # using a high number of salting rounds will help, but it should # not be relied upon. # # To highlight this risk, running John the Ripper against the # example hash above, with a readily available wordlist, revealed # the true password in 12 seconds on a i7-2620QM. # # In other words, this feature is a potential security risk and is # provided for your convenience only. If you do not fully trust the # medium over which your cloud-config will be transmitted, then you # should use SSH authentication only. Source: http://cloudinit.readthedocs.org/en/latest/topics/examples.html
Jiri, so the image itself is reasonably secured now, what else do you want to do? In the light of the last comment.
Comment #4 says one can attach CI image as normal cdrom on GNOME without any trouble. Enforce hashed passwords, point. If one would accept there's always possibility to crack hashed passwords and do nothing at least to make things harder, then tell me - why do we have /etc/shadow ? Because it's another mitigation protection. But I think to attach CI data as cdrom is stupid anyway. I think the best way would be via virt-channel, so any user by default could not request CI data. Current functionality is wrong by design.
it's not really safer as you can intercept the channel the same way as you can mount a CD. It makes it a bit more difficult to do, though. I'd suggest not to fix this at the moment as the feature is still quite fresh and the added benefit of easier debugging/troubleshooting with CD is quite worth it
this bug won't fit into 3.5 release and is being deferred to a later release. If you deeply care about this bug and deserves to be re-evaluated please let me know
This bug is flagged for 3.6, yet the milestone is for 4.0 version, therefore the milestone has been reset. Please set the correct milestone or add the flag.
Bug tickets must have version flags set prior to targeting them to a release. Please ask maintainer to set the correct version flags and only then set the target milestone.
Jiri, can you please summaries the current status and expected behavior?
Original idea what to hash password by engine before sending them to host and having them as hashed in cloud-init payload. I personally have no use case and I don't know any customer backing this idea. The idea was just based on fact, that any ordinary user can attach cdrom in Linux guest with desktop UI installed. Feel free to close this BZ.
pushed out due to capacity reasons
The bug was not addressed in time for 4.1. Postponing to 4.2
Upstream is looking into supporting setting hashed password for already defined users: https://bugs.launchpad.net/cloud-init/+bug/1570325 Setting hashed password is/was only supported if the user didn't exist previously
Closing since this has been deferred over and over again. If users don't want users to be able to mount random ISOs to view the contents, this can be nailed down using permissions