Bug 1250746 - Adjust anaconda for distro wide password/passphrase policy
Adjust anaconda for distro wide password/passphrase policy
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: David Cantrell
Fedora Extras Quality Assurance
:
: 1230293 1253204 1254620 1263025 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-05 17:40 EDT by Kevin Fenzi
Modified: 2015-09-23 15:46 EDT (History)
12 users (show)

See Also:
Fixed In Version: 1.12.2-1.fc23
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-09-07 12:35:55 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Kevin Fenzi 2015-08-05 17:40:47 EDT
FESCo has ratified https://fedoraproject.org/wiki/Passphrase_policy as the distro wide policy for local passwords/passphrases. 

As such we would like to adjust anacondas setup for this policy. 

I can split this out into seperate bugs or keep everything here as you prefer. 

The changes I think we need: 

* anaconda currently passes:

+pwpolicy root --strict --minlen=8 --minquality=50 --nochanges --emptyok
+pwpolicy user --strict --minlen=8 --minquality=50 --nochanges --emptyok
+pwpolicy luks --strict --minlen=8 --minquality=50 --nochanges --emptyok

It should instead not pass minquality or len, but let libpwquality handle those. 

If the password is unacceptable to libpwquality, it will return an exception, which should be if at all possible passed on to the user. The user should be able to override the exception and use the poor password if they wish, but they should be informed that the password is poor, etc.

Optional changes: 

Show 'score' as a analog meter (low, medium, high)
show password feedback after the first entry field is filled in (but of course they still have to match in the second one before they can be done). 

I'm happy to take any changes or concerns or clarifications back to fesco if needed, just let me know if thats desired. 

Additionally, anyone who doesn't care for this policy should also likewise take it up with FESCo, not you folks.
Comment 1 David Shea 2015-08-11 08:35:53 EDT
*** Bug 1230293 has been marked as a duplicate of this bug. ***
Comment 2 Vojtech Trefny 2015-08-13 05:26:34 EDT
*** Bug 1253204 has been marked as a duplicate of this bug. ***
Comment 3 Chris Lumens 2015-08-18 10:10:54 EDT
*** Bug 1254620 has been marked as a duplicate of this bug. ***
Comment 4 markm 2015-08-18 10:21:03 EDT
I do not get why a person who installs the operating system is forced to use strong passwords? On many occasions it doesn't really matter how strong or weak password is - it does not matter on my VM, which I am using for testing. It does not matter on my desktop computer at home, where I disable password anyway.
This is bad for user experience and is a huge annoyance.
Comment 5 David Shea 2015-08-18 10:23:36 EDT
You realize you can just not use a password, right? There's a checkbox for it!
Comment 6 markm 2015-08-18 10:26:56 EDT
I didn't see any check box there and I don't think there's a check box for root user either.

I just want to use a weak easy to remember password for my desktop computer at home. I don't need Military level security / protection there.
Comment 7 Jeremy Harris 2015-08-18 11:45:23 EDT
There is indeed no checkbox for a root nonpassword account.  So the only way
to create a low-security VM seems to be in Anaconda create a passwordless nonroot
account with admin privs, then *later* set a root password and a password on
this account.

I raised 1253204 about this and it was closed as a dup of this bug, which at
the very least misses the point (and possibly is plain mendacious).  I don't
care what FESCo thinks, you have made my life difficult my making unwarranted
assumptions about my needs any my environment.  It's a bug.
Comment 8 Chris Lumens 2015-08-18 11:51:03 EDT
> I raised 1253204 about this and it was closed as a dup of this bug, which at
> the very least misses the point (and possibly is plain mendacious).
                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This needs to stop, and it needs to stop right now.  First, you need to read the Fedora code of conduct (https://getfedora.org/code-of-conduct).  Second, you need to consider that simply from a selfish standpoint, saying things like that does not motivate people to work on things for you.  It in fact does the opposite.  It makes us far less likely to do much of anything for you in the future.
Comment 9 markm 2015-08-18 12:48:49 EDT
(In reply to Chris Lumens from comment #8)                                 
> This needs to stop, and it needs to stop right now.  First, you need to read
> the Fedora code of conduct (https://getfedora.org/code-of-conduct).  Second,
> you need to consider that simply from a selfish standpoint, saying things
> like that does not motivate people to work on things for you.  It in fact
> does the opposite.  It makes us far less likely to do much of anything for
> you in the future.

I think the problem is spreading from the Gnome Developers - some time ago they have decided not to listen to their users. They've started the trend "we are gods and we know what's best for users" - this has created unnecessary frustration among community. Take a Gnome Shell thingy - I would love to use it on a tablet, but it not working for me on a desktop. I've tried to voice my frustration, but no one would listen and the only response I would get was "go away and use something else". This approach is bad for community - I was happy to contribute to Fedora, but I stopped. I stopped because of developer's arrogance. I've stopped because my bug reports were ignored. Btw: it's good that Fedora now has a Code of Conduct, I find it a little bit funny that now Fedora devs are using Code of Conduct to protect themselves from users and their criticism. 

Back on topic - requiring users to set strong and meaningful password *during* the installation is a really bad idea. Enforcing strong passwords should not be systems responsibility - in most cases strong passwords are unnecessary annoyance and obstruction. If users care about their security, they will set their password strong - in most cases it's not required/necessary.
Comment 10 Kevin Fenzi 2015-08-18 13:43:50 EDT
(In reply to markm from comment #9)

...snip...
> Btw: it's good that Fedora now has a Code of Conduct, I find it a
> little bit funny that now Fedora devs are using Code of Conduct to protect
> themselves from users and their criticism. 

Criticism is fine, but criticize the plan or policy, not people. 
Do not make personal attacks or assume some sinister motives to people disagreeing with you. 

> Back on topic - requiring users to set strong and meaningful password
> *during* the installation is a really bad idea. Enforcing strong passwords
> should not be systems responsibility - in most cases strong passwords are
> unnecessary annoyance and obstruction. If users care about their security,
> they will set their password strong - in most cases it's not
> required/necessary.

Did you read this bug and the FESCo policy?
"The user should be able to override the exception and use the poor password if they wish"

Additionally, if you have issues with the FESCo policy, please direct them to FESCo.
Comment 11 David Shea 2015-08-19 13:21:04 EDT
Kevin,

This may have come up before, but for the sake of a reminder and having it documented here: would it be acceptable if these pwpolicy changes were carried by the fedora-productimg-* packages? These packages already modify the stylesheet and installclass settings provided by anaconda, and they seem to me like a good place to add Fedora-specific settings such as this.

One issue I foresee is that interactive-defaults.ks contains more than just pwpolicy information, and to carry interactive-defaults.ks in the productimg packages would mean also carrying irrelevant settings and possibly diverging from anaconda in the future. To address that, I could add a setting to the installclass to specify the default kickstart file, similar to how the stylesheet is handled now, and then the productimg kickstart file could look something like:

%include /usr/share/anaconda/interactive-defaults.ks

%anaconda
new pwpolicy stuff
%end


How does that sound? If it's too late for F23, would that be acceptable for F24?
Comment 12 Kevin Fenzi 2015-08-19 17:59:34 EDT
I'm not sure I understand, so forgive me for asking this, but by "these pwpolicy changes" you mean the default policy? Or the way to overide that default policy? 

We really prefer to have the default itself be in libpwquality so we have just one place to change things if we need to instead of it being multiple places. 

Does that make sense? or is there some non libpwquality settings that may need to be adjusted on a per image basis?
Comment 13 David Shea 2015-08-19 18:32:30 EDT
I just mean the changes you laid out in the first comment. If the productimg
packages were to install kickstarts overriding interactive-defaults.ks that
included:

%anaconda
pwpolicy root --nochanges --emptyok
pwpolicy user --nochanges --emptyok
pwpolicy luks --nochanges --emptyok
%end

that would configure anaconda as desired, and it would mean that, since
--minlen and --minquality are removed, that the length and quality settings
are entirely dictated by pwquality, and changes in the length and quality
settings can happen in one place: pwquality.

The problem I have is the problem that caused this whole issue in the first
place: removing --strict to restore the double-done weak password behavior.
This behavior is not something controlled by pwquality, but rather a change
that you are asking for in the behavior of anaconda itself.  Simply put, this
is a Fedora configuration, and anaconda upstream is not Fedora. We've provided
the tools to configure this behavior in Fedora, and I'm willing to make more
changes to make that configuration integrate more smoothly with the upstream
configuration, but I do not think that the configuration change itself should
be upstream.

But again, if time is a concern for 23 the change can go on the branch for 23,
like it did for 22, and the rest can be worked out for 24.
Comment 14 Stephen Gallagher 2015-08-20 11:38:35 EDT
(In reply to David Shea from comment #13)
> I just mean the changes you laid out in the first comment. If the productimg
> packages were to install kickstarts overriding interactive-defaults.ks that
> included:
> 

OK, so I think I see where the confusion lies here. interactive-defaults.ks actually affects two different things.

1. It can override the default libpwquality settings
2. It enables or disables the --strict/--non-strict option

Kevin was (I think) confused because he thought you were asking for libpwquality settings to not be added to interactive-defaults.ks, which you are not. Presumably, you will just inherit the defaults for this value from the library and not override them.

The remaining issue then is that the policy as agreed-upon by FESCo includes the phrase "The user should be able to override the exception and use the poor password if they wish". The way this is implemented is by having the the pwpolicy lines include --non-strict.

David is asking whether they could retain --strict (the upstream default) in the Fedora package's interactive-defaults.ks and instead have the individual product install media override this to use --non-strict in the fedora-productimg-$EDITION packages (which already make certain branding changes to Anaconda).

So, assuming I have properly described the problem... here is my response: The productimg packages are only viable for making changes to Edition-branded media. In at least their current incarnation, they cannot affect any live media produced in a non-product manner (such as for KDE or any of the other spins). These spins currently will only inherit the interactive-defaults.ks as shipped by Anaconda. Thus, it is far easier to set a global "Fedora" default in that one single place.

The alternative would be to submit and manage additional fedora-productimg-$SPIN packages that override this value for each and every Spin in the distribution (or just have a fedora-productimg-nonproduct one that all Spins must include). This is non-trivial and would add an easily-forgotten step to Spin creation. So I'd prefer that we not do this.

I realize that part of the concern here is because Anaconda maintains its Fedora specfile upstream and synchronizes it when doing releases, which means that it becomes a bit more difficult to maintain a different set of upstream defaults from downstream ones. However, would it be possible to simply carry a patchfile in a contrib directory and adjust the upstream specfile such that application of that patch would occur if we're running on 'if %{?fedora}>=23'? Could that serve as a reasonable workaround?
Comment 15 David Shea 2015-08-27 10:29:51 EDT
The idea of a contrib patches directory sounds like more trouble than it's worth, so just pushed the pwpolicy change.
Comment 16 Fedora Update System 2015-09-03 15:33:51 EDT
python-blivet-1.12.2-1.fc23 anaconda-23.19.2-1.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-15030
Comment 17 Fedora Update System 2015-09-04 03:33:20 EDT
anaconda-23.19.2-1.fc23, python-blivet-1.12.2-1.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update anaconda python-blivet'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-15030
Comment 18 markm 2015-09-07 09:01:34 EDT
(In reply to Kevin Fenzi from comment #10)
> Did you read this bug and the FESCo policy?
> "The user should be able to override the exception and use the poor password
> if they wish"

Excuse my ignorance, but how do I allow weak passwords during the installation process in anaconda? it forces me to set a strong password. That's a bug to me.

> Additionally, if you have issues with the FESCo policy, please direct them
> to FESCo.

I've found a bug, I reported it here. Requesting user to set a strong password during the installation is a bug to me. How/where do I complain about FESCo policy?
Comment 19 Fedora Update System 2015-09-07 12:35:35 EDT
anaconda-23.19.2-1.fc23, python-blivet-1.12.2-1.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
Comment 20 Kevin Fenzi 2015-09-07 12:42:21 EDT
(In reply to markm from comment #18)
> (In reply to Kevin Fenzi from comment #10)
> > Did you read this bug and the FESCo policy?
> > "The user should be able to override the exception and use the poor password
> > if they wish"
> 
> Excuse my ignorance, but how do I allow weak passwords during the
> installation process in anaconda? it forces me to set a strong password.
> That's a bug to me.

When did you test. If you will note, these changes only just now pushed to stable, so only after today will they be in live media. Yes, it's a bug... this very bug in fact. ;) 

Please test with tomorrow's media. 
> 
> > Additionally, if you have issues with the FESCo policy, please direct them
> > to FESCo.
> 
> I've found a bug, I reported it here. Requesting user to set a strong
> password during the installation is a bug to me. How/where do I complain
> about FESCo policy?

https://fedorahosted.org/fesco/

But you were not actually testing anything that was following the policy at the time... so please retest.
Comment 21 markm 2015-09-08 08:15:45 EDT
(In reply to Kevin Fenzi from comment #20)
> (In reply to markm from comment #18)
> > (In reply to Kevin Fenzi from comment #10)
> > > Did you read this bug and the FESCo policy?
> > > "The user should be able to override the exception and use the poor password
> > > if they wish"
> > 
> > Excuse my ignorance, but how do I allow weak passwords during the
> > installation process in anaconda? it forces me to set a strong password.
> > That's a bug to me.
> 
> When did you test. If you will note, these changes only just now pushed to
> stable, so only after today will they be in live media. Yes, it's a bug...
> this very bug in fact. ;) 

I did test Alpha release, to test this I will probably need to wait for Beta release, right?


> Please test with tomorrow's media. 
> > 
> > > Additionally, if you have issues with the FESCo policy, please direct them
> > > to FESCo.
> > 
> > I've found a bug, I reported it here. Requesting user to set a strong
> > password during the installation is a bug to me. How/where do I complain
> > about FESCo policy?
> 
> https://fedorahosted.org/fesco/
> 
> But you were not actually testing anything that was following the policy at
> the time... so please retest.

I will, thanks.
Comment 22 Vojtech Trefny 2015-09-15 07:43:07 EDT
*** Bug 1263025 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.