#452 Crypto policies packaging guideline
Closed: Fixed None Opened 9 years ago by nmav.

Since Fedora 21 (http://fedoraproject.org/wiki/Changes/CryptoPolicy) there are policies for the usage of SSL and TLS cryptographic protocols that are enforced system-wide. Each application being added in Fedora must be checked to comply with the policies and the following URL contains the guidelines to adhere to these policies.

https://fedoraproject.org/wiki/User:Nmav/CryptoPolicies


The FPC discussed this among four of nine members today. They were not entirely onboard with making packagers and reviewers try to modify config (and potentially code) in this case because they are unlikely to understand what they are doing, simply following a recipe. What about some rule like:

'''MUST''' Packages which make use of the OpenSSL library or GNUTLS library must be vetted by the security team for correct selection of allowed ciphers.

This would require that the security team is willing to perform this vetting. Please check with them if this is the route you're going to pursue.

This would require that the security team is willing to perform this vetting.

This in fact cancels the change request. There cannot be any security team, that can review and modify all packages present and future, not only because such a process cannot scale, but because there cannot be a small team that will know the special needs of each and every package (not all packages need to follow the policy). The change request depends on each maintainer ensuring the crypto policy is followed. This is no different than any other policy (filesystem etc.).

They were not entirely onboard with making packagers and reviewers try to modify config (and potentially code) in this case because they are unlikely to understand what they are doing, simply following a recipe.

If they follow the recipe they don't need to understand what they are doing. This is the reason for the recipe. There is no decision they need to take, they just need to ensure the package conforms to the policy, which is a configuration issue, as any other configuration issue. The fact that this affects crypto doesn't make it different than any other configuration issue. In the worst case the maintainer wouldn't know what to do, and in that case the recipe could mention that he should contact the security team. However, addressing this issue by fully assigning to the security team is going to kill the feature.

I think the mindset that packagers should just follow recipe without having an understanding of what they are doing is pretty dangerous in general and especially when it has a security impact. If you want mindless changes, just automate the process as much as you can.

I don't believe I follow what you propose.

The mindset that I propose is that the maintainer should be responsible for his package to follow the Fedora crypto policies. The recipe there is to help maintainers to change that policy; I don't see how removing the recipe is going to help them. If what you actually mean, is that a maintainer may not know despite the recipe what to do in order change the crypto settings of his package, he can seek for help upstream or at the fedora security.

We had a bunch of questions/etc. from todays meeting (https://lists.fedoraproject.org/pipermail/packaging/2014-September/010270.html), summary is:

  • 452 Crypto policies packaging guideline (geppetto, 16:17:20)

  • LINK: https://fedorahosted.org/fpc/ticket/452 (geppetto, 16:17:25)
  • Need more info. about the configuration files, what they look like,
    where they'd be located, etc. (geppetto, 16:28:00)
  • We need some kind of number on how many packages this would affect.
    6 affected would be different than 666. (geppetto, 16:55:18)
  • Worries that if security team can't be the gatekeepers, then random
    reviewers wouldn't be good gatekeepers either. (geppetto, 16:56:00)
  • Also, as a quick example, PHP seems non-trivial to make compliant
    with this proposal … and it's not obvious how upstream would react
    if it was changed. (geppetto, 16:56:43)

Replying to [comment:5 james]:

We had a bunch of questions/etc. from todays meeting (https://lists.fedoraproject.org/pipermail/packaging/2014-September/010270.html), summary is:

  • 452 Crypto policies packaging guideline (geppetto, 16:17:20)

  • LINK: https://fedorahosted.org/fpc/ticket/452 (geppetto, 16:17:25)
  • Need more info. about the configuration files, what they look like,
    where they'd be located, etc. (geppetto, 16:28:00)

I'm not sure I understand which configuration files are meant here. Each application has its own configuration file. Apache for example has /etc/httpd/conf/httpd.conf. There are no additional configuration files involved.
[[BR]]
[[BR]]

  • We need some kind of number on how many packages this would affect.
    6 affected would be different than 666. (geppetto, 16:55:18)

All packages that use openssl or gnutls for TLS and SSL. An indication of the number can be seen using
{{{
repoquery --whatrequires openssl-libs
repoquery --whatrequires gnutls
}}}
[[BR]]

  • Worries that if security team can't be the gatekeepers, then random
    reviewers wouldn't be good gatekeepers either. (geppetto, 16:56:00)

That's true for everything the random reviewers do. That's not specific to security. We don't have a file system team to handle the filesystem compliance policies on every package, the random reviewers do that.
[[BR]]
[[BR]]

  • Also, as a quick example, PHP seems non-trivial to make compliant
    with this proposal … and it's not obvious how upstream would react
    if it was changed. (geppetto, 16:56:43)

Could you elaborate on the issues PHP has to be made compliant with the policy? In any case discussion about specific packages could be moved off-line, unless there is some pattern to be seen.

Replying to [comment:6 nmav]:

Replying to [comment:5 james]:

We had a bunch of questions/etc. from todays meeting (https://lists.fedoraproject.org/pipermail/packaging/2014-September/010270.html), summary is:

  • 452 Crypto policies packaging guideline (geppetto, 16:17:20)

  • LINK: https://fedorahosted.org/fpc/ticket/452 (geppetto, 16:17:25)
  • Need more info. about the configuration files, what they look like,
    where they'd be located, etc. (geppetto, 16:28:00)

I'm not sure I understand which configuration files are meant here. Each application has its own configuration file. Apache for example has /etc/httpd/conf/httpd.conf. There are no additional configuration files involved.

No, the crypto configuration. Eg this is from the proposed policy:

In OpenSSL the cipher string "PROFILE=SYSTEM" will be used to specify the system ciphers. Any applications not explicitly specifying ciphers will use the system ciphers.

...this is instead of specifying ciphers directly. But what does this mean? Where is the configuration for this "system", can the sysadmin specify different "system" ciphers for different applications?

Replying to [comment:7 james]:

I'm not sure I understand which configuration files are meant here. Each application has its own configuration file. Apache for example has /etc/httpd/conf/httpd.conf. There are no additional configuration files involved.

No, the crypto configuration. Eg this is from the proposed policy:
In OpenSSL the cipher string "PROFILE=SYSTEM" will be used to specify the system ciphers. Any applications not explicitly specifying ciphers will use the system ciphers.

Ah ok. No there are no other ciphersuite options in Fedora. There is only PROFILE=SYSTEM and the plan is to keep it that way. The name of the "PROFILE=SYSTEM" string is such because of openssl upstream needed to support more options. In Fedora there is only one.

Is there any update on that? This is an F21 Change so it has to be handled one way or another before F21 is released. If it is unacceptable for FPC to have such rules, it should be removed from the features of F21. Keeping it but not updating the FPC is pointless.

http://fedoraproject.org/wiki/Changes/CryptoPolicy

We discussed this again at the meeting on the 2nd (http://meetbot.fedoraproject.org/fedora-meeting-1/2014-10-02/fpc.2014-10-02-16.00.txt):

  • 452 Crypto policies packaging guideline (geppetto, 16:52:21)

  • LINK: https://fedorahosted.org/fpc/ticket/452 (geppetto, 16:52:30)
  • ACTION: Need different policy that's easier to comply to or just
    advice, all reviewers/packagers aren't C programers and there are a
    lot of openssl using packages. (geppetto, 17:23:14)

...also note that Remi replied on the list stating that PHP now complies with this (uses system algos.), so at least some of the worry that packages wouldn't be able to comply is gone. Maybe worth creating some simple bash scripts for check-openssl-algos which can be given a source dir?
Also can you clarify again what you meant by saying it's not configurable? The original policy implies that the system ciphers are configurable, but your reply suggests not. What happens if a packager/upstream says "I really need to use cipher XYZ, so following the rules in this policy will break my package" ... is there anyway they can comply at the code level but change config. files to make sure they have their specific algo?

And we discussed it again at todays meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2014-10-16/fpc.2014-10-16-16.00.txt):

  • 452 Crypto policies packaging guideline (geppetto, 16:15:36)

  • LINK: https://fedorahosted.org/fpc/ticket/452 (geppetto, 16:15:41)
  • Would be helpful for policy to at least mention other languages, Eg.
    python/ruby, and what any calls there should look like. (geppetto,
    16:30:34)
  • ACTION: Highlight all function names in a single part of the policy
    (geppetto, 16:32:07)
  • ACTION: Current policy just says "other crypto. libs. do not
    adhere." Give some more info. for at least NSS, are changes coming,
    are packages advise to move away from NSS, something else?
    (geppetto, 16:33:25)

...hopefully the summary, and discussion, can give you some tips on how to improve the policy and we can vote it in next week or so.

Point 1: I've asked for help in Fedora-devel for ruby/python as I don't know how they work.

Point 2: That's a bit tricky. I like the separation into libraries, as it would require the maintainer to read less text. However, I can modify rpmlint to warn if these functions are used and the default policy string isn't mentioned in the application (let me know if that's acceptable so I can send a patch to fedora rpmlint maintainers).

Point 3: Added the status of NSS and mentioned that when there is choice one of these libraries should be used, and preferrably the upstream endorsed version.

A change to rpmlint can be reasonable done:
http://people.redhat.com/nmavrogi/fedora/rpmlint-crypto-policies.patch

Running the patched rpmlint on software that doesn't comply with the system wide crypto policies would output:
{{{
httpress.x86_64: W: bin-possibly-uses-non-default-crypto /usr/bin/httpress gnutls_priority_init
}}}

This got approved at this weeks meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2014-10-23/fpc.2014-10-23-16.01.txt):

...although it'd be nice to collect some info. on ruby/python/java.

Thank you. I've submitted an initial rpmlint patch [0], but it would require the URL of
https://fedoraproject.org/wiki/User:Nmav/CryptoPolicies
to be modified to the intended one (as far as I understand should be Packaging:CryptoPolicies).

[0]. https://bugzilla.redhat.com/show_bug.cgi?id=1156313

I moved the draft into the Packaging hierarchy (https://fedoraproject.org/wiki/Packaging:CryptoPolicies) and added a new section to the main guidelines (https://fedoraproject.org/wiki/Packaging:Guidelines#System_cryptographic_policies).

Announcement text:

Guidelines were added for packages which make use of the SSL and TLS cryptographic protocols: https://fedoraproject.org/wiki/Packaging:CryptoPolicies

Login to comment on this ticket.

Metadata