Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 2019-11-25 at 16:25 -0500, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/DisallowEmptyPasswordsByDefault
> 
> == Summary ==
> Remove ''nullok'' parameter from pam_unix module in default PAM
> configuration in order to disallow authentication with empty password.
> 
> == Owner ==
> * Name: [[User:pbrezina| Pavel Březina]]
> * Email: <pbrezina@xxxxxxxxxx>
> 
> == Detailed Description ==
> 
> Current default configuration allows users to login with an empty
> password by setting nullok parameter to pam_unix module. This affects
> only logins to local machine, it does not affect ssh logins as this
> must be explicitly allowed in sshd_config. We want to disallow empty
> password by default for local logins as well to improve system
> hardening.
> 
> Note: It is possible to disallow empty passwords with authselect call
> (authselect enable-feature without-nullok) or by removing nullok
> manually, however it creates possible issues in other components that
> must be addressed.
> 
> === Affected Components ===
> * '''passwd''' - calling passwd -d to remove users password must be
> denied if empty passwords are disallowed otherwise the user will be
> locked out of the system
> * '''AccountService''' - D-Bus methods ''SetPassword'' and
> ''SetPasswordMode'' on ''org.freedesktop.Accounts.User'' interface can
> remove user’s password and lock the user out of the system if empty
> password is disallowed. These calls must be denied in this case.
> Additionally, these methods can be run by normal users as opposed to
> ''passwd -d'' and ''chage -d 0'' which can be run only by root.
> Therefore only root should be able to call these methods.
> * '''Gnome’s Control Center''' - when creating new users, it provides
> an option to “require password to be set on first login” which creates
> user with expired empty password. This would again lock the user out
> of the system.
> * '''Other Desktop Environments''' - may have the same issue as Gnome
> Control Center
This would definitely also affect the installation, unless we want to create user accounts
that can't log in.

So the list of affected components should include also Anaconda and Gnome Initial Setup.

> 
> === Solution Step by Step ===
> 
> ==== Step 1) Provide a unified way to read if nullok is enabled or not ====
> 
> We will create an authselect library call that would parse existing
> PAM configuration (not necessarily generated by authselect) and return
> list of enabled/disabled features. We will implement only ''nullok''
> feature in the scope of this change but if needed it can be extended
> in the future.
> 
> ==== Step 2) Fix passwd -d ====
> Calling ''passwd -d'' to remove user's password will fail if
> ''nullok'' is disabled.
> 
> ==== Step 3) Fix AccountService ====
> These methods on ''org.freedesktop.Accounts.User'' D-Bus interface
> will be callable only by ''root'' and must return an error if
> ''nullok'' is disabled.
> 
>   SetPasswordMode
>   SetPassword(“”, hint)
> 
> ==== Step 4) Fix Desktop Environments ====
> “Require password change on next login” must keep working. This
> feature currently relies on setting an empty password. A new option
> ''nullresetok'' will be implemented for ''pam_unix'' module that will
> allow user to authenticate with empty password only if a password
> change for this user is enforced upon login. Authentication with empty
> passwords which are not expired will be prohibited (unless ''nullok''
> is set).
> 
> ==== Step 5) Update PAM configuration to disable nullok by default ====
> In authselect and pam components for new installations. Upgrading from
> older systems will keep nullok present.
> 
> == Benefit to Fedora ==
> 
> Changes in described components (Step 1 - Step 4) are necessary to
> implement in order to make sure that user accounts and tools works
> correctly when authentication with empty password is disabled by
> system administrator. Changing system default to disallow
> authentication with empty passwords (Step 5) improves system
> hardening.
> 
> == Scope ==
> * Proposal owners: Coordinate the work. Make sure all required changes
> are implemented.
> * Other developers: All affected component must be fixed. Changes are
> described in ''Detailed Description''
> * Release engineering: [https://pagure.io/releng/issue/9038 #9038] (a
> check of an impact with Release Engineering is needed) <!-- REQUIRED
> FOR SYSTEM WIDE CHANGES -->
> <!-- Does this feature require coordination with release engineering
> (e.g. changes to installer image generation or update package
> delivery)?  Is a mass rebuild required?  include a link to the releng
> issue.
> The issue is required to be filed prior to feature submission, to
> ensure that someone is on board to do any process development work and
> testing, and that all changes make it into the pipeline; a bullet
> point in a change is not sufficient communication -->
> 
> * Policies and guidelines: No updates needed.
> * Trademark approval: N/A (not needed for this Change)
> 
> == Upgrade/compatibility impact ==
> This does not affect system upgrades because only new installation
> will have changed default.
> 
> == How To Test ==
> 
> * Calling ''passwd -d user'' as root must fail with default configuration.
> * Calling ''org.freedesktop.Accounts.User.SetPassword("", hint)'' and
> ''org.freedesktop.Accounts.User.SetPasswordMode(x)'' must fail with
> default configuration.
> * "require password reset on first login" must keep working when
> creating users from Desktop Environment's GUI tools
> 
> == User Experience ==
> Users will no longer be able to use empty passwords by default.
> 
> == Dependencies ==
> None.
> 
> == Contingency Plan ==
> * Contingency mechanism: Default behavior will not be changed.
> * Contingency deadline: Beta
> * Blocks release? No
> * Blocks product? No
> 
> == Documentation ==
> 
> 
> -- 
> Ben Cotton
> He / Him / His
> Fedora Program Manager
> Red Hat
> TZ=America/Indiana/Indianapolis
> _______________________________________________
> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux