Bug 1225792 - kerberos should follow the policies of system-wide crypto policy
Summary: kerberos should follow the policies of system-wide crypto policy
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: krb5
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Robbie Harwood
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: fedora-crypto-policies 1267266 1297684
TreeView+ depends on / blocked
 
Reported: 2015-05-28 09:15 UTC by Nikos Mavrogiannopoulos
Modified: 2016-06-20 12:59 UTC (History)
8 users (show)

Fixed In Version: 1.13.2-7.fc23 krb5-1.13.2-7.fc22
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-10-20 00:11:57 UTC
Type: Bug


Attachments (Terms of Use)

Description Nikos Mavrogiannopoulos 2015-05-28 09:15:20 UTC
As it is now kerberos' configuration is hard coded and the administrator is responsible for doing any changes to it, and in case of software upgrades to keep up-to-date the list of ciphers allowed, parameters etc.

It would be simpler for Kerberos to follow the system-wide crypto policy [0] by default and unless the administrator changes the configuration the policies will be kept up to date and will be consistent with the policies followed in other parts of the system.

The simplest approach for that would be for Kerberos to be able to include a file in its default configuration files, and thus include a file which has been auto-generated.

That would also simplify an administrators job by not requiring to review configuration settings as recommended by: https://bettercrypto.org/static/applied-crypto-hardening.pdf

[This is a proposal for collaboration, please let me know whether that can be done in our current setup of kerberos and how, and if not the steps that are required to achieve that goal]

[0]. http://fedoraproject.org/wiki/Changes/CryptoPolicy

Comment 1 Jan Kurik 2015-07-15 14:05:43 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.

(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23

Comment 3 Fedora Admin XMLRPC Client 2015-09-01 21:35:35 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 4 Robbie Harwood 2015-09-10 18:03:49 UTC
I am absolutely in favor of this.  One thing that I will be doing soon (if only based on the number of open bugs it would resolve) is to add a default include directory to the krb5.conf we ship.  An autogenerated file could be dropped there, which should take care of any issues I think.

Comment 5 Nikos Mavrogiannopoulos 2015-09-11 06:54:28 UTC
(In reply to Robbie Harwood from comment #4)
> I am absolutely in favor of this.  One thing that I will be doing soon (if
> only based on the number of open bugs it would resolve) is to add a default
> include directory to the krb5.conf we ship.  An autogenerated file could be
> dropped there, which should take care of any issues I think.

That would be ideal. Which fedora version do you think that could be included in? In any case let me know when that feature is on.

Comment 6 Fedora Update System 2015-09-11 20:12:41 UTC
krb5-1.13.2-7.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-15661

Comment 7 Fedora Update System 2015-09-11 20:12:41 UTC
krb5-1.13.2-6.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2015-15660

Comment 8 Robbie Harwood 2015-09-11 20:15:32 UTC
Rawhide - right now.  fc23 and fc22 - when there's enough karma on the bodhi.  fc21 - probably never; the version of krb5 there wasn't even rebased to 1.13.

Apologies for the delay, I had to make it build again (some RPM verification has changed since we last touched the version in Fedora, it seems).

Comment 9 Fedora Update System 2015-09-12 21:25:05 UTC
krb5-1.13.2-7.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 krb5'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-15661

Comment 10 Fedora Update System 2015-09-13 04:20:08 UTC
krb5-1.13.2-6.fc22 has been pushed to the Fedora 22 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 krb5'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-15660

Comment 11 Nikos Mavrogiannopoulos 2015-09-16 13:42:49 UTC
Hi,
 I'm thinking how this could with crypto-policies dropping a file in the krb5.d directory. The issues that I see are:
1. Who owns the file?
2. What happens if libkrb5 is not installed? Should the directory belong to crypto-policies?

We could solve it by giving that directory to some OS component. What do you think?

Comment 12 Robbie Harwood 2015-09-16 15:07:01 UTC
For 1, I would think that crypto-policies would own the file.

For 2, I think the directory belonging to crypto-policies in that case is fine; I believe RPM is okay with this.  Going forward, my understanding is that it will become increasingly difficult to have a system installation without libkrb5, and so at some point it would no longer be a problem.

Comment 13 Nikos Mavrogiannopoulos 2015-09-17 09:00:29 UTC
(In reply to Robbie Harwood from comment #12)
> For 1, I would think that crypto-policies would own the file.
> For 2, I think the directory belonging to crypto-policies in that case is
> fine; I believe RPM is okay with this.  Going forward, my understanding is

So if I understand your suggestion is for crypto-policies package to own '/etc/krb5.conf.d/' and for the kerberos packages to depend on crypto policies?

While that work and solve this particular problem, it would be problematic to handle when a 3rd package would need to drop a file there. It would have to depend on crypto-policies which is quite weird. 


> that it will become increasingly difficult to have a system installation
> without libkrb5, and so at some point it would no longer be a problem.

There are certainly systems without libkrb5 and crypto-policies should be able to work without it. Docker systems for example don't pull all the desktop or server dependencies.

Comment 14 Robbie Harwood 2015-09-17 18:46:13 UTC
(In reply to Nikos Mavrogiannopoulos from comment #13)
> (In reply to Robbie Harwood from comment #12)
> > For 1, I would think that crypto-policies would own the file.
> > For 2, I think the directory belonging to crypto-policies in that case is
> > fine; I believe RPM is okay with this.  Going forward, my understanding is
> 
> So if I understand your suggestion is for crypto-policies package to own
> '/etc/krb5.conf.d/' and for the kerberos packages to depend on crypto
> policies?
> 
> While that work and solve this particular problem, it would be problematic
> to handle when a 3rd package would need to drop a file there. It would have
> to depend on crypto-policies which is quite weird. 

I believe it is permitted for multiple RPMs to create this directory?

Comment 15 Nikos Mavrogiannopoulos 2015-09-17 20:19:00 UTC
Yes, it seems that is the case [0]. There is an example with gtk-doc and evolution. So that would be the solution. Let's put F24 (rawhide) as target, and make crypto-policies install the config file in the shared directory, and libkrb5 (or whoever owns the directory) to depend on crypto-policies. Does it sound reasonable?

[0]. https://fedoraproject.org/wiki/Packaging:Guidelines#File_and_Directory_Ownership

Comment 16 Robbie Harwood 2015-09-17 20:39:51 UTC
I'm confused, sorry.  Why does libkrb5 need to depend on crypto-policies?

My reading of your link is that this case falls under the bash-completion vs. git+bzr case.  Multiple applications will be placing files here, not just crypto-policies, and crypto-policies will not be depending on libkrb5.

What do you think?

Comment 17 Fedora Update System 2015-09-19 18:54:39 UTC
krb5-1.13.2-7.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

Comment 18 Nikos Mavrogiannopoulos 2015-09-21 07:26:26 UTC
If we go on the path of libkrb5 using the policies that are set by crypto-policies it has to Require that package. Otherwise there can be scenarios under which libkrb5 doesn't follow the policy.

Comment 19 Robbie Harwood 2015-09-21 18:36:10 UTC
Isn't that the desired case if crypto-policies is not installed, though?  Or is crypto-policies going to be a package present on all Fedora systems?

Comment 20 Nikos Mavrogiannopoulos 2015-09-22 07:54:40 UTC
(In reply to Robbie Harwood from comment #19)
> Isn't that the desired case if crypto-policies is not installed, though? 

I am not sure I follow you. The goal is to have the crypto policies applied when libkrb5 is present. That is why libkrb5 should Require the crypto policies. Does that make sense?

It is the same approach we used in gnutls, openssl, and the other packages that adhere to policy. We either have packages that follow the policy or not. We will not have packages that may or may not follow the policy depending on crypto-policies presence. If we go that way it would be a nightmare to figure the state of the system.

Comment 21 Nikos Mavrogiannopoulos 2015-09-22 09:40:13 UTC
I've updated policies to generate a file with the "permitted_enctypes". You can view the available options for LEGACY, DEFAULT and FUTURE policies at:
https://github.com/nmav/fedora-crypto-policies/tree/master/profiles

What I forgot to ask is whether the user will be able to override them (e.g., by modifying the krb5.conf directly?). If that's possible and you have no objections, then I think that is complete, and I'll commit it to rawhide.

Comment 22 Robbie Harwood 2015-09-23 14:23:14 UTC
Okay, I did some digging and it's not possible to have a fedora system without crypto-policies (trying to `dnf erase` them would remove protected packages dnf and systemd).  Apologies for the misunderstanding; the picture was the wrong way in my head.  I think I see what you're saying now.

Regarding overriding: yes, override is possible.  Based on the other bug reports requesting includedir support, I've actually included two locations in krb5.conf: one of them is the /etc/krb5.conf.d/ (to be owned by crypto-polocies) mentioned above, and the other is /usr/share/krb5.conf.d/ which is the preferred location for user snippets and will be owned by krb5.

Starting with fc24 - and fc24 only - I've dropped ownership of /etc/krb5.conf.d and started depending on crypto-policies instead.  (I believe this is what you asked for - please correct me if that's not right.)

Comment 23 Fedora Update System 2015-09-23 17:03:52 UTC
krb5-1.13.2-7.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2015-16547

Comment 24 Nikos Mavrogiannopoulos 2015-09-24 12:35:58 UTC
I'm reopening as the feature is not yet complete. Let's close when both libkrb5 and crypto-policies provide that feature. I'll take care of it.

Comment 25 Vít Ondruch 2015-09-24 20:01:41 UTC
I would appreciate if you revert the [1] or include /etc/krb5.conf.d in the crypto-policies package, which is not the case at the moment:

# rpm -q crypto-policies
crypto-policies-20150518-2.gitffe885e.fc23.noarch

# rpm -ql crypto-policies
/etc/crypto-policies
/etc/crypto-policies/config
/usr/bin/update-crypto-policies
/usr/share/crypto-policies
/usr/share/crypto-policies/profiles
/usr/share/crypto-policies/profiles/DEFAULT-F21.settings
/usr/share/crypto-policies/profiles/DEFAULT-F22.settings
/usr/share/crypto-policies/profiles/DEFAULT.settings
/usr/share/crypto-policies/profiles/EMPTY.settings
/usr/share/crypto-policies/profiles/FUTURE-F21.settings
/usr/share/crypto-policies/profiles/FUTURE-F22.settings
/usr/share/crypto-policies/profiles/FUTURE.settings
/usr/share/crypto-policies/profiles/LEGACY-F21.settings
/usr/share/crypto-policies/profiles/LEGACY-F22.settings
/usr/share/crypto-policies/profiles/LEGACY.settings
/usr/share/licenses/crypto-policies
/usr/share/licenses/crypto-policies/COPYING.LESSER
/usr/share/man/man8/update-crypto-policies.8.gz

since this effectively breaks my system:

# LANG=en_US systemctl status gssproxy.service 
* gssproxy.service - GSSAPI Proxy Daemon
   Loaded: loaded (/usr/lib/systemd/system/gssproxy.service; disabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Thu 2015-09-24 21:22:30 CEST; 38min ago
  Process: 3544 ExecStart=/usr/sbin/gssproxy -D (code=exited, status=1/FAILURE)

Sep 24 21:22:30 localhost systemd[1]: Starting GSSAPI Proxy Daemon...
Sep 24 21:22:30 localhost gssproxy[3544]: Error reading configuration -1429577696: Unknown error -1429577696
Sep 24 21:22:30 localhost systemd[1]: gssproxy.service: Control process exited, code=exited status=1
Sep 24 21:22:30 localhost systemd[1]: Failed to start GSSAPI Proxy Daemon.
Sep 24 21:22:30 localhost systemd[1]: gssproxy.service: Unit entered failed state.
Sep 24 21:22:30 localhost systemd[1]: gssproxy.service: Failed with result 'exit-code'.

Going to downgrade to krb5-1.13.2-8.fc24 which hopefully resolves the issue for the moment.


[1] http://pkgs.fedoraproject.org/cgit/krb5.git/commit/?id=65ce267be1061e6349bb5f566b7abef0c48d7492

Comment 26 Nikos Mavrogiannopoulos 2015-09-25 08:12:37 UTC
Is the problem the "%dir /etc/krb5.conf.d"? I think that based on the previous discussion it can be present in both crypto-policies and libkrb5. So instead of reverting the whole change which is correct, adding this should solve the issue.

Comment 27 Vít Ondruch 2015-09-25 08:53:45 UTC
The thing is that gssproxy does not create the directory anymore while crypto-policies does not create the directory yet. I am just user and I don't care in this case who owns what as long as my system works, which is not the case for krb5-1.13.2-8.fc24+.

Comment 28 Vít Ondruch 2015-09-25 09:52:20 UTC
(In reply to Vít Ondruch from comment #27)
> gssproxy does not create the directory

I meant krb5 of course.

Comment 29 Robbie Harwood 2015-09-25 17:03:41 UTC
What is the timeframe for crypto-policies owning this directory in Fedora?

Comment 30 Fedora Update System 2015-09-25 21:21:03 UTC
krb5-1.13.2-7.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
$ su -c 'dnf --enablerepo=updates-testing update krb5'
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-16547

Comment 31 Robbie Harwood 2015-09-29 14:00:40 UTC
So my reading of earlier comments suggested that crypto-policies should own krb5.conf.d and that libkrb5 should not.

Vit, I apologize for the delay in fixing your issue here; I know that it's a problem, but I need to make krb5 build from source in rawhide again before I can revert the change.

Comment 32 Vít Ondruch 2015-09-30 09:00:00 UTC
(In reply to Robbie Harwood from comment #31)
> Vit, I apologize for the delay in fixing your issue here; I know that it's a
> problem, but I need to make krb5 build from source in rawhide again before I
> can revert the change.

NP, I saw the build failure and I am happy with the older version so far.

Comment 33 Robbie Harwood 2015-10-01 19:48:55 UTC
Vit, the version in rawhide should fix the problem.  Thanks for being patient!

Comment 34 Fedora Update System 2015-10-03 21:14:20 UTC
krb5-1.13.2-7.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.

Comment 35 Vít Ondruch 2015-10-04 19:56:00 UTC
(In reply to Robbie Harwood from comment #33)
> Vit, the version in rawhide should fix the problem.  Thanks for being
> patient!

I can confirm that the recent update:

$ rpm -q krb5-libs 
krb5-libs-1.13.2-12.fc24.x86_64

works just fine. Thank you.

Comment 41 Robbie Harwood 2015-10-20 00:11:57 UTC
It should be so in rawhide as of version krb5-1.14-beta1-3.

Comment 42 Lukas Slebodnik 2015-10-23 08:19:37 UTC
Nikos,
Could you explain why krb5.conf from crypto-policies cannot be stored in /etc/krb5_conf.d/ ?

I read the packaging guidelines[1] and I cannot see any violation.
It says:
"
In this context, a package's "natural dependency chain" is defined as the set of packages necessary for that package to function normally. To be specific, you do not need to require a package for the sole fact that it happens to own a directory that your package places files in
"

So crypto-policies needn't require krb5-libs to store file in /etc/krb5.conf.d/
i would say it's similar case as with logrotate:
[root@55e16868112e /]# rpm -qf /etc/logrotate.d/
logrotate-3.9.1-2.fc23.x86_64

[root@55e16868112e /]# rpm -qf /etc/logrotate.d/*
chrony-2.2-1.fc24.x86_64
corosync-2.3.5-1.fc23.x86_64
cups-2.1.0-1.fc24.x86_64
dnf-conf-1.1.3-1.fc24.noarch
iscsi-initiator-utils-iscsiuio-6.2.0.873-29.git4c9d6f9.fc24.x86_64
krb5-server-1.14-3.fc24.x86_64
krb5-server-1.14-3.fc24.x86_64
numad-0.5-20.20150602git.fc23.x86_64
psacct-6.6.2-3.fc23.x86_64
rpmorphan-1.15-1.fc24.noarch
sssd-common-1.13.1-2.fc24.x86_64
rsyslog-8.12.0-2.fc24.x86_64
wpa_supplicant-2.4-5.fc24.x86_64
yum-3.4.3-508.fc24.noarch[root@55e16868112e /]# rpm -qf /etc/logrotate.d/
logrotate-3.9.1-2.fc23.x86_64
[root@55e16868112e /]# rpm -qf /etc/logrotate.d/*
chrony-2.2-1.fc24.x86_64
corosync-2.3.5-1.fc23.x86_64
cups-2.1.0-1.fc24.x86_64
dnf-conf-1.1.3-1.fc24.noarch
iscsi-initiator-utils-iscsiuio-6.2.0.873-29.git4c9d6f9.fc24.x86_64
krb5-server-1.14-3.fc24.x86_64
krb5-server-1.14-3.fc24.x86_64
numad-0.5-20.20150602git.fc23.x86_64
psacct-6.6.2-3.fc23.x86_64
rpmorphan-1.15-1.fc24.noarch
sssd-common-1.13.1-2.fc24.x86_64
rsyslog-8.12.0-2.fc24.x86_64
wpa_supplicant-2.4-5.fc24.x86_64
yum-3.4.3-508.fc24.noarch

https://fedoraproject.org/wiki/Packaging:Guidelines#File_and_Directory_Ownership


BTW: there is also packaging bug in crypto-policies because the file /etc/crypto-policies/back-ends/krb5.config should be at least marked as ghost if it is generated and not part of rpm. I might file a separate bug If we agree that drop in file from crypto policies should be stored in /etc/krb5.conf.d/

Comment 43 Nikos Mavrogiannopoulos 2015-10-23 08:37:01 UTC
The reason it is not stored there is to allow an administrator to disable crypto policies for kerberos (by removing the link file). This should be documented somewhere in kerberos doc (or at least in the spec file).

Comment 44 Nikos Mavrogiannopoulos 2015-10-23 09:22:42 UTC
About the %ghost directive please open a new bug on crypto policies.


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