Bug 868519

Proposed F18-Beta blocker:

1. Users may not know /root/anaconda-ks.cfg exists, so they may not know to remove it or edit it.
2. Cannot be fixed with an update.
3. F18-Beta users who upgrade to F18-Final without reformatting or changing their LUKS passphrase have an ongoing vulnerability.
4. Anyone with root access or physical access can mount '/home' in the scenario where '/' is not encrypted and '/home' is encrypted. Verified by booting from the installer DVD in rescue mode.

There do not appear to be any criteria covering user secrets, such as passphrases:

"User secrets in plaintext are not written to a filesystem or transmitted across a network without informed user consent."

See also:
Bug 868509 - LUKS passphrase exposed in storage.log attached to bug report

/root/anaconda-ks.cfg is meant to accurately reflect the choices you made during installation so you can reuse it in the future.  We make the permissions on this file closed by default, and only root has access to them.  This is working as we intend it.

If that were true, you would include my partitioning choices too:

# Partition clearing information
clearpart --none --initlabel --drives=sda

The "it is secure because only root can read it" argument is specious. If that were a valid argument, user passwords would not need to be hashed and salted in /etc/shadow. Why not write the root password in plaintext too?

# Root password
rootpw --iscrypted $6$Z3eXI72W4PuNkDSH$WPwo7r6de3LXkGGfJmuZzMDcY5UCzWCJMHAFTrnZkCJXXcV7HY.DyO9yHAQKCSNCRumR9.ULVsWOPpIQLjDuA0

Adam: I'm adding you, because I believe a release criterion may be needed to help protect the security of user passwords.

kickstart does not allow for expressing encrypted passphrases, and we have no plans to add that.  Your argument that "all my partitioning isn't listed, thus this needs to be fixed" does not follow in the least.

(In reply to comment #3)
> /root/anaconda-ks.cfg is meant to accurately reflect the choices you made
> during installation so you can reuse it in the future.
...

You said the file would "accurately reflect the choices" I made, but it does not, because it does not say what partitioning choices I made. Why not?

(In reply to comment #5)
> kickstart does not allow for expressing encrypted passphrases, and we have
> no plans to add that.  Your argument that "all my partitioning isn't listed,
> thus this needs to be fixed" does not follow in the least.

Why does kickstart support encrypted root passwords? If root-only permissions are so secure, why not save the root password in plaintext?

My suggestion was to *obfuscate* the LUKS passphrase, not encrypt it. That would be trivial to implement.

For reference, here is a link to the kickstart documentation:

rootpw [options] <password>
--iscrypted|--plaintext 

http://fedoraproject.org/wiki/Anaconda/Kickstart#rootpw

"Never store passwords as plaintext. This feels like security 101 ..."

You're Probably Storing Passwords Incorrectly
by Jeff Atwood
September 16, 2007
http://www.codinghorror.com/blog/2007/09/youre-probably-storing-passwords-incorrectly.html

Lax Security at LinkedIn Is Laid Bare
By NICOLE PERLROTH
Published: June 10, 2012 
http://www.nytimes.com/2012/06/11/technology/linkedin-breach-exposes-light-security-even-at-data-companies.html

"Last week, hackers breached the site and stole more than six million of its customers’ passwords, which had been only lightly encrypted."
...
'“If they had consulted with anyone that knows anything about password security, this would not have happened,” said Paul Kocher, president of Cryptography Research, a San Francisco computer security firm.'

(In reply to comment #3)
> /root/anaconda-ks.cfg is meant to accurately reflect the choices you made
> during installation so you can reuse it in the future.  We make the
> permissions on this file closed by default, and only root has access to
> them.  This is working as we intend it.

"reuse it in the future"

Computer Security 101: Do not reuse passwords.

This is security bug, how could one argue it's not?

(In reply to comment #3)
> /root/anaconda-ks.cfg is meant to accurately reflect the choices you made
> during installation so you can reuse it in the future.  We make the
> permissions on this file closed by default, and only root has access to
> them.  This is working as we intend it.

You missed the point that closed permissions don't help when you have physical access in the case described by Steve:

(In reply to comment #1)
> 4. Anyone with root access or physical access can mount '/home' in the
> scenario where '/' is not encrypted and '/home' is encrypted. Verified by
> booting from the installer DVD in rescue mode.

Throwing the Security keyword on here to get an evaluation from someone with a clue. On the face of it, I agree with Volker and Steve that there appear to be concerns here.

Steve's arguments about partitioning seem specious, I'd agree with Chris that that's a blind alley. Just consider the issue of whether anaconda should write a file that exposes the encryption passphrase for any partitions encrypted as part of the install in plain text. Thanks.

Chris, can you not re-close this until security folks take a look at it? Thanks.

Yeah, this needs to be fixed.

There is an obvious deficiency if we're encrypting root's password (which is obvious looking at the log) and then turning around and not encrypting the LUKS password.

The re-use of passwords is a non-argument.  The real issue is we are conscious enough to not put root's password in plaintext, and then shortly after we put the LUKS password in plaintext.  Permissions on the file don't really matter either (well, they do, but...).

This certainly isn't a huge security issue, but it _is_ a security issue and it needs to be corrected.  And fixing it prior to F18 GA should be a priority.

How was this handled in F17?  Is the password in plaintext there as well, or was the call to LUKS not stored at all?  Looking at mine here (although I did use whole-disk encryption), I see nothing in my kickstart config about LUKS at all.

Not sure how to set this bug as a blocker, but it should be a blocker.

(In reply to comment #15)
> Not sure how to set this bug as a blocker, but it should be a blocker.

Thanks, Vincent. This bug is already a proposed F18 blocker:

Fedora 18 Beta Blocker Bugs
http://qa.fedoraproject.org/blockerbugs/milestone/18/beta/buglist

To propose a blocker, add the appropriate alias: "Blocks: F18Beta".
http://fedoraproject.org/wiki/BugZappers/HouseKeeping/Trackers

Oh, ok, perfect.  Thanks, Steve.

For the record, a better reference for how to propose blockers...we have a whole SOP on the blocker process:

https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process

Discussed at the 2012-10-24 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-10-24/f18beta-blocker-review-5.2012-10-24-16.01.log.txt .

We agreed in principle that, roughly, security bugs that can't be fixed with updates (e.g. in the anaconda path) ought to be fixed by Final. We'll flesh out the details in the test list, but on that principle, this bug is accepted as a Final blocker and Beta NTH, but not Beta blocker.

(In reply to comment #19)
> Discussed at the 2012-10-24 blocker review meeting:
> http://meetbot.fedoraproject.org/fedora-qa/2012-10-24/f18beta-blocker-review-
> 5.2012-10-24-16.01.log.txt .
> 
> We agreed in principle that, roughly, security bugs that can't be fixed with
> updates (e.g. in the anaconda path) ought to be fixed by Final. We'll flesh
> out the details in the test list, but on that principle, this bug is
> accepted as a Final blocker and Beta NTH, but not Beta blocker.

Thanks, Adam. That all sounds good. AIUI, the release criteria are based on actual examples. This bug and Bug 868509 would be covered by a more specific criterion:

"User secrets in plaintext are not written to a filesystem or transmitted across a network without informed user consent."

It's a bit of a side alley, but I *really* don't want to get into the business of reinventing the definition of security bugs in the Fedora release criteria. It seems more practical to me simply to say 'all issues that would be considered security issues of severity level XX according to Secunia are blockers', or something like that - you get the idea. defining what is a security issue and how severe various types of issue are is a) complex and b) something that several groups already have considerable experience at, so we should really take advantage of that and not re-invent it.

anaconda team is apparently still not convinced that this ought to be 'fixed', I've been discussing this with dcantrell. The idea is that the kickstart ought to be an exact reproduction of the installation. But I just don't think it's really valid to reproduce the encryption passphrase used during installation. Anyone going to the trouble of encrypting a partition is presumably doing it for security reasons. I can't see any valid case for re-using the kickstart with the same encryption passphrase, that just doesn't seem like a good idea for any user from any angle. Speaking entirely personally, my preferred option would be not to write the passphrase to the kickstart at all; presumably in this case anaconda would prompt for it if you ran an install from the kickstart without editing one in first.

We are just going to blank out the passphrases for anaconda-ks.cfg.  Any bugs opened about the passphrases not existing, thus the kickstart files doesn't match what you did during installation, will be closed WONTFIX.

[PATCH] Blank out passphrases from /root/anaconda-ks.cfg (#868519).
https://lists.fedorahosted.org/pipermail/anaconda-patches/2012-October/001829.html

Thanks, Chris.

anaconda-18.22-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/anaconda-18.22-1.fc18

Package anaconda-18.22-1.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing anaconda-18.22-1.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-17432/anaconda-18.22-1.fc18
then log in and leave karma (feedback).

anaconda-18.23-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/anaconda-18.23-1.fc18

anaconda-18.24-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/anaconda-18.24-1.fc18

anaconda-18.25-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/anaconda-18.25-1.fc18

anaconda-18.26-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/anaconda-18.26-1.fc18

18.26 went stable. Closing. (Bodhi closing of bugs when updates go stable is currently broken).