Re: [Freeipa-devel] KDC proxy URI records
On 2017-04-27 14:00, Martin Bašti wrote: > > > On 26.04.2017 20:41, Simo Sorce wrote: >> On Wed, 2017-04-26 at 12:57 +0200, Martin Bašti wrote: >>> On 25.04.2017 16:57, Martin Bašti wrote: >>>> Hello all, >>>> >>>> I'm going to implement automatic URI records for kdc proxy and I'd >>>> like to clarify if following URI records are the right one. >>>> >>>> >>>> _kerberos-adm.example.com. IN URI 0 >>>> "krb5srv:M:kkdcp:https://ipaserver.example.com/KdcProxy; >>>> >>>> _krb5kdc.example.com. IN URI 0 >>>> "krb5srv:M:kkdcp:https://ipaserver.example.com/KdcProxy; >>>> >>>> _kpasswd.example.com. IN URI 0 >>>> "krb5srv:M:kkdcp:https://ipaserver.example.com/KdcProxy; >>>> >>>> >>>> I assume we want to use "kkdcp" and "https", and "M" flag as all IPA >>>> servers are masters, please confirm. >>>> >>>> >>>> Sources: >>>> >>>> https://k5wiki.kerberos.org/wiki/Projects/KDC_Discovery >>>> >>>> https://tools.ietf.org/id/draft-mccallum-kitten-krb-service-discovery-02.txt >>>> >>>> >>>> >>>> >>>> Thank you >>>> >>> I found out that wiki page differs from the RFC draft and from the >>> source in git >>> >>> There is "_kerberos.REALM" record instead of "_krb5kdc.REALM" >>> >>> >>> And I'm not sure if _kerberos-adm should be included as we don't really >>> support kadmin. >> We shouldn't. >> >> Simo. >> > > I would like to discuss consequences of adding kdc URI records: > > 1. basically all ipa clients enrolled using autodiscovery will use > kdcproxy instead of KDC on port 88, because URI takes precedence over > SRV in KRB5 client implementation. Are we ok with such a big change? Update: It's correct that URI records have a higher priority than SRV records. A client with URI discovery support will never check SRV records when it is able to retrieve URI records. For newer clients we have to include TCP and UDP URI records, too. I did some testing. MIT KRB5 prefers UDP/TCP over MSKKDP for records with same priority. That fact is not stated in the RFC. I'm writing a mail to Nathaniel and Simo to discuss the matter. Christian -- Christian Heimes Senior Software Engineer, Identity Management and Platform Security Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] KDC proxy URI records
On 2017-04-27 16:16, Martin Bašti wrote: > > > On 27.04.2017 14:19, Christian Heimes wrote: >> On 2017-04-27 14:00, Martin Bašti wrote: >>> I would like to discuss consequences of adding kdc URI records: >>> >>> 1. basically all ipa clients enrolled using autodiscovery will use >>> kdcproxy instead of KDC on port 88, because URI takes precedence over >>> SRV in KRB5 client implementation. Are we ok with such a big change? >> Does the client also prefer KKDCP if you give the Kerberos 88/UDP and >> 88/TCP URIs a higher priority than the KKDCP HTTPS URIs? > > It should use 88/TCP, 88/UDP then, it can be a way how to avoid issues > with clients. Small correction: Kerberos should prefer UDP over TCP. Christian -- Christian Heimes Senior Software Engineer, Identity Management and Platform Security Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] KDC proxy URI records
On 2017-04-27 14:00, Martin Bašti wrote: > I would like to discuss consequences of adding kdc URI records: > > 1. basically all ipa clients enrolled using autodiscovery will use > kdcproxy instead of KDC on port 88, because URI takes precedence over > SRV in KRB5 client implementation. Are we ok with such a big change? Does the client also prefer KKDCP if you give the Kerberos 88/UDP and 88/TCP URIs a higher priority than the KKDCP HTTPS URIs? > 2. probably client installer must be updated because currently with > CA-full installation it is not working. > > ipa-client-install (with autodiscovery) failed on kinit, see KRB5_TRACE > bellow that it refuses self signed certificate Actually it is not a self-sigend EE certificate. The validation message is bogus because FreeIPA TLS configuration is slightly buggy. We send the trust anchor (root CA) although a server should not include its trust anchor in its ServerHello message. OpenSSL detects an untrusted root CA in the ServerHello peer chain and emits the message. If I read the 600 lines (!) function ipaclient.install.client._install correctly, then ipa-client-install first attempts to negotiate a TGT and then installs the trust anchor in the global trust store. It should be enough to reverse the order and inject the trust anchor first. Christian -- Christian Heimes Senior Software Engineer, Identity Management and Platform Security Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] make causes unsolicited changes to PO files
Hi, for a while make causes unsolicited modifications to all translation files. I have to reset all PO files a couple of times a day during development: git checkout -- po/*.po It's slowly wearing me off. I opened ticket https://fedorahosted.org/freeipa/ticket/6605 a while ago. It contains more details and a reproducer. Regards, Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Stageuser API
On 2017-01-17 12:56, David Kupka wrote: > Hi Christian, > uniqueness of uid is not checked in staging area on purpose, it may be > changed multiple times before the stageuser is transformed into user > (activated). The uid uniqueness is then checked during activation. > > Third party application that use FreeIPA's LDAP should: > 1) search for users (and usercertificate attribute) only in > cn=users,cn=accounts > 2) respect the value of nsAccountLock that is set to true for all staged > users. > > But it would be nice to have this scenario (stageuser.uid == user.uid) > implemented as a part of [1]. Can we safely assume that all parts of FreeIPA, Kerberos and all 3rd party application *always* use the FreeIPA API or LDAP to validate a user cert? Some applications may just validate the certificate and OCSP/CRL for client cert authentication with e.g. mod_ssl. Consider this scenario: 1) IT issues a smart card for a staging user. The smart card contains a valid private/public key pair for FreeIPA. 2) HR sends the smart card to a new hire. 3) HR creates a standard user with same login as staging user 4) New hire uses the smart card to log into a system that only verifies validity of cert (signature, dates, OCSP status) and uses subject to identify user. Even if we 'fix' the issue with non-unique UIDs in staging, it stays dangerous to hand a valid certificate to a not-yet-valid user. At least we should try to reduce risks with a couple of measures: * Add a "valid from" field to stage users and set the cert's valid from date accordingly. That renders the public key useless until the estimated first day on the job. * Lock the smart card with a PIN and don't release the PIN until the user has been moved from staging area to user area. This arrangement makes the smart card inaccessible. We could use the KRA to store the PIN. Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Stageuser API
On 2017-01-16 15:52, David Kupka wrote:
> Hello everyone!
>
> I've noticed that our API for stageuser is missing some commands that
> user has (stageuser-{add,remove}-{principal,cert}). I was wondering if
> there is reason for it but after asking some fellows developers it seems
> that there's none.
>
> I understand the stageuser area as a place where user entry can be
> created and amended during the hiring process in organization, example:
>
> 1. HR creates the entry with just basic informations (givenname,
> surname, manager)
> 2. IT assigns basic account information (uid, gid)
> 3. based on to-be-employee manager's request IT adds additional group
> membership (memberOf)
> 4. based on to-be-employee request IT adds login alias (krbPrincipalName)
> 5. Security Officer adds certificate from Smart Card assigned to the
> to-be-employee
> 6. HR adds extra information to the account (address, marital status, ...)
> 7. Facilities update work place related information (seat number, phone
> number, ...)
> 8. At the first day IT activates the user account.
>
> Considering this work flow I think it might be useful to have the same
> API for stageuser as for the user.
>
> Does the example work flow make sense?
> Should we provide the same set of commands for user and stageuser?
I see one potential issue in your proposal. A stage user does not
reserve its user name. The unique index on uid excludes the staging user
and deleted user branch. Therefore it is possible to create a user with
the same login name as a staging user.
We either have to ensure that this name clash does not cause any trouble
with certificates or we have to enforce uniqueness of uid across the
whole tree. For FreeIPA it's probably fine because we compare certs
bytes. Third party applications parse the cert subject instead and use
the subject to identify a user.
Christian
signature.asc
Description: OpenPGP digital signature
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [DESIGN] FreeIPA on FIPS + NSS question
On 2016-12-19 15:07, John Dennis wrote: > I'm not a big fan of NSS, it has it's issues. As the author of the > Python binding I'm quite aware of all the nasty behaviors NSS has and > needs to be worked around. I wouldn't be sad to see it go but OpenSSL > has it's own issues too. If you remove NSS you're also removing the > option to support smart cards, HSM's etc. Perhaps before removing > functionality it would be good to assess what the requirements are. When Standa started to work on the PR, I raised similar concerns regarding the feature set of OpenSSL. I asked him to write a design spec to address some of the concerns. HSM and smart card authentication are of no concern. Standa's PR replaces FreeIPA's internal HTTS connection with a OpenSSL based implementation. It's used to communicate from an IPA client to an IPA server or from an IPA server to Dogtag. We don't support client cert auth for client to server. Smart card authentication is performed based on pkinit and Kerberos. Currently just IPA server to Dogtag uses client cert authentication. That part will be replaced with GSSAPI eventually. I'm more concerned that we loose the ability to check revocation state of certificates. Python's ssl module has no support for OCSP. OpenSSL's and Python's CRL capabilities are sub-par compared to NSS. The ssl module can load CRLs but it has no means to retrieve or update a CRL from a remote server. For Fedora 26 we will have to deal with similar concerns for libldap. Fedora has switched from NSS to OpenSSL as TLS backend. Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Anonymous PKINIT and kdcproxy
On 2016-12-12 10:37, Alexander Bokovoy wrote: > On ma, 12 joulu 2016, Alexander Bokovoy wrote: >> On ma, 12 joulu 2016, Christian Heimes wrote: >>> On 2016-12-12 09:54, Alexander Bokovoy wrote: >>>> On ma, 12 joulu 2016, Christian Heimes wrote: >>>>> Hi Simo, >>>>> >>>>> I'm wondering if we need to change kdcproxy for anon pkinit. What kind >>>>> of Kerberos requests are performed by anon pkinit and to establish a >>>>> FAST tunnel? python-kdcproxy allows only request types AS-REQ, TGS-REQ >>>>> and AP-REQ+KRB-PRV. Responses are not filtered. >>>> Anonymous principal as configured in FreeIPA can only be used to obtain >>>> a TGT, nothing else. >>>> >>>> See https://tools.ietf.org/html/rfc6112 for a spec definition. >>> >>> That doesn't answer my question for me. Or does 'only TGT' imply that >>> request types are limited to AS-REQ and TGS-REQ? RFC 6112 just talks >>> about the two request types. >> You can only obtain a TGT and this TGT can only be used for FAST >> channel. You cannot obtain any service ticket with this TGT. > To close the loop, no changes in kdcproxy are needed because PKINIT is a > pre-authentication scheme and it works just fine with kdcproxy as it is. > I just tested this. Alexander, thanks for your tests! I have created an issue to add test cases to kdcproxy to ensure that we stay compatible with PKINIT, https://github.com/latchset/kdcproxy/issues/23 Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Anonymous PKINIT and kdcproxy
On 2016-12-12 09:54, Alexander Bokovoy wrote: > On ma, 12 joulu 2016, Christian Heimes wrote: >> Hi Simo, >> >> I'm wondering if we need to change kdcproxy for anon pkinit. What kind >> of Kerberos requests are performed by anon pkinit and to establish a >> FAST tunnel? python-kdcproxy allows only request types AS-REQ, TGS-REQ >> and AP-REQ+KRB-PRV. Responses are not filtered. > Anonymous principal as configured in FreeIPA can only be used to obtain > a TGT, nothing else. > > See https://tools.ietf.org/html/rfc6112 for a spec definition. That doesn't answer my question for me. Or does 'only TGT' imply that request types are limited to AS-REQ and TGS-REQ? RFC 6112 just talks about the two request types. Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] Anonymous PKINIT and kdcproxy
Hi Simo, I'm wondering if we need to change kdcproxy for anon pkinit. What kind of Kerberos requests are performed by anon pkinit and to establish a FAST tunnel? python-kdcproxy allows only request types AS-REQ, TGS-REQ and AP-REQ+KRB-PRV. Responses are not filtered. Regards, Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Design document: Integration Improvements
On 2016-11-21 14:44, Petr Spacek wrote: >>> 3.3 ipaplatform auto-configuration >>> >>> I'm not sure if guessing platform from ID_LIKE is really a good idea. It >>> might work fine for centos -> rhel, but in general we can't really >>> assume it will always work, as the platforms listed in ID_LIKE might not >>> be similar enough to the one in ID. I would rather add an ipaplatform >>> subpackage for every supported platform (including CentOS) than depend >>> on error-prone guesswork. >> >> Can you show me a real-world example for your statement that ID_LIKE is >> error-prone? >> >> Your proposal doesn't scale. There are tons of Debian spins with their >> own ID. For example my Raspberry Pi has ID=raspbian and ID_LIKE=debian. >> Do you want to maintain an exhaustive list of all Debian and Ubuntu >> variants? > > Can we agree that it would be much better to get rid of platform depedency in > client libraries and be done with this philosophical debate? Yes, that would be my preferable solution, too. But it's a lot of work and I don't have any spare time to work on a redesign of ipaplatform / ipalib. Who is going to do it? Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Design document: Integration Improvements
On 2016-11-21 13:31, Jan Cholasta wrote: > Hi, > > On 11.11.2016 15:25, Christian Heimes wrote: >> Hello, >> >> I have released the first version of a new design document. It describes >> how I'm going to improve integration of FreeIPA's client libraries >> (ipalib, ipapython, ipaclient, ipaplatform) for third party developers. >> >> http://www.freeipa.org/page/V4/Integration_Improvements > > 3.1 API for local configuration directory > > "Both approaches have some disadvantages. A user must repeat the -e > option in every call to ipa or create a shell alias. It's both tedious > and error-prone." > > This is pretty subjective. I don't think it's error-prone at all, since > it is explicit and you always know what confdir value will be used in > the ipa command just by looking at its arguments, as opposed to the > environment variable, which makes the configuration implicit and > depending on *sane* environment and is equivalent to preferring global > variables to function arguments in Python code. It's not implicit. The env var has to be set explicitly just like you have to use -e confdir explicitly in every call. > That being said, this whole section is filled with one-sided "facts" and > simply ignores everything else, which might lead the reader to believe > that the environment variable is something required, while it is in fact > just a nice-to-have convenience feature. A good design should include > both sides of an argument, even if you don't agree with one. > > BTW, shell alias works perfectly fine in your virtualenv example above > in the design. No, it does not work perfectly fine. By default shell aliases are limited to interactive shells. My proposal also works with Python subprocess module, a C program with execve(), Makefile, Ansible local command, non-interactive shell script... > 3.2.1 Build and runtime requirements > > How are we going to detect and report missing runtime dependencies? > Currently if they are not installed, the code will fail at random places > during execution with an often cryptic error message. I think this is > unacceptable, and since there is no way specify external dependencies > using setuptools (right?), it needs to be done in our code during > package import (or other suitable place). Instead of detecting missing dependencies, we document requirements and treat users as adults. Runtime checks are a performance issue. Since wheels don't execute code at installation time, we can't check for missing dependencies during installation. > 3.3 ipaplatform auto-configuration > > I'm not sure if guessing platform from ID_LIKE is really a good idea. It > might work fine for centos -> rhel, but in general we can't really > assume it will always work, as the platforms listed in ID_LIKE might not > be similar enough to the one in ID. I would rather add an ipaplatform > subpackage for every supported platform (including CentOS) than depend > on error-prone guesswork. Can you show me a real-world example for your statement that ID_LIKE is error-prone? Your proposal doesn't scale. There are tons of Debian spins with their own ID. For example my Raspberry Pi has ID=raspbian and ID_LIKE=debian. Do you want to maintain an exhaustive list of all Debian and Ubuntu variants? Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Design document: Integration Improvements
On 2016-11-21 11:38, Jan Cholasta wrote:
> On 21.11.2016 11:04, Christian Heimes wrote:
>> On 2016-11-21 10:46, Jan Cholasta wrote:
>>> On 21.11.2016 10:32, Christian Heimes wrote:
>>>> On 2016-11-21 10:26, Jan Cholasta wrote:
>>>>> On 11.11.2016 18:28, Christian Heimes wrote:
>>>>>> On 2016-11-11 17:46, Martin Basti wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 11.11.2016 15:25, Christian Heimes wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> I have released the first version of a new design document. It
>>>>>>>> describes
>>>>>>>> how I'm going to improve integration of FreeIPA's client libraries
>>>>>>>> (ipalib, ipapython, ipaclient, ipaplatform) for third party
>>>>>>>> developers.
>>>>>>>>
>>>>>>>> http://www.freeipa.org/page/V4/Integration_Improvements
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Christian
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Hello, I have a few questions:
>>>>>>>
>>>>>>> 1) dynamic platform files
>>>>>>>
>>>>>>> Currently all RHEL/fedora-derived platforms work with the same
>>>>>>> rhel/fedora packages. How do you want to achieve this with dynamic
>>>>>>> platform files, do you want to keep mappings between platforms and
>>>>>>> platform file? What about distributions that have in /etc/release
>>>>>>> just mess?
>>>>>>
>>>>>> I don't use /etc/releases but /etc/os-release. There is no mapping
>>>>>> involved. If a distribution has no /etc/os-release or a messed up
>>>>>> /etc/os-release, then it needs to be fixed by the distribution.
>>>>>> It's a
>>>>>> common standard and all relevant distributions support this standard.
>>>>>>
>>>>>> RHEL has ID=rhel and no ID_LIKE -> ipaplatform.rhel
>>>>>>
>>>>>> Fedora has ID=fedora and no ID_LIKE -> ipaplatform.fedora
>>>>>>
>>>>>> CentOS has ID=centos and ID_LIKE="rhel fedora"
>>>>>> -> ipaplatform.rhel
>>>>>>
>>>>>> Even my Raspberry has an /etc/os-release with ID=raspbian and
>>>>>> ID_LIKE=debian -> error, soon ipaplatform.debian
>>>>>
>>>>> There is more to ipaplatform than /etc/os-release offers. How do you
>>>>> differentiate between e.g. "Debian with SysV init" and "Debian with
>>>>> systemd"?
>>>>
>>>> Timo,
>>>>
>>>> do you support FreeIPA on Debian variants with SysV init?
>>>
>>> This is not an issue of what is supported now, but rather what is
>>> supportable in the future. Even if Debian with SysV init is not
>>> supported ATM, someone might want to add support for it in the future,
>>> and the design should not prevent them from doing so.
>>
>> My proposal does not prevent sysv init support. In fact it makes it even
>> easier to support it. In case Debian SysV Init does not have a distinct
>> ID in /etc/os-release, I can easily add some additional check like
>>
>> if platform == 'debian' and os.path.realpath('/sbin/init') !=
>> '/usr/lib/systemd/systemd':
>> platform = 'debian_sysvinit'
>
> I didn't mean to say it does prevent it, just that it should be noted in
> the design page.
I have updated http://www.freeipa.org/page/V4/Integration_Improvements#Scope
Christian
signature.asc
Description: OpenPGP digital signature
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Design document: Integration Improvements
On 2016-11-21 10:46, Jan Cholasta wrote:
> On 21.11.2016 10:32, Christian Heimes wrote:
>> On 2016-11-21 10:26, Jan Cholasta wrote:
>>> On 11.11.2016 18:28, Christian Heimes wrote:
>>>> On 2016-11-11 17:46, Martin Basti wrote:
>>>>>
>>>>>
>>>>> On 11.11.2016 15:25, Christian Heimes wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I have released the first version of a new design document. It
>>>>>> describes
>>>>>> how I'm going to improve integration of FreeIPA's client libraries
>>>>>> (ipalib, ipapython, ipaclient, ipaplatform) for third party
>>>>>> developers.
>>>>>>
>>>>>> http://www.freeipa.org/page/V4/Integration_Improvements
>>>>>>
>>>>>> Regards,
>>>>>> Christian
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> Hello, I have a few questions:
>>>>>
>>>>> 1) dynamic platform files
>>>>>
>>>>> Currently all RHEL/fedora-derived platforms work with the same
>>>>> rhel/fedora packages. How do you want to achieve this with dynamic
>>>>> platform files, do you want to keep mappings between platforms and
>>>>> platform file? What about distributions that have in /etc/release
>>>>> just mess?
>>>>
>>>> I don't use /etc/releases but /etc/os-release. There is no mapping
>>>> involved. If a distribution has no /etc/os-release or a messed up
>>>> /etc/os-release, then it needs to be fixed by the distribution. It's a
>>>> common standard and all relevant distributions support this standard.
>>>>
>>>> RHEL has ID=rhel and no ID_LIKE -> ipaplatform.rhel
>>>>
>>>> Fedora has ID=fedora and no ID_LIKE -> ipaplatform.fedora
>>>>
>>>> CentOS has ID=centos and ID_LIKE="rhel fedora"
>>>> -> ipaplatform.rhel
>>>>
>>>> Even my Raspberry has an /etc/os-release with ID=raspbian and
>>>> ID_LIKE=debian -> error, soon ipaplatform.debian
>>>
>>> There is more to ipaplatform than /etc/os-release offers. How do you
>>> differentiate between e.g. "Debian with SysV init" and "Debian with
>>> systemd"?
>>
>> Timo,
>>
>> do you support FreeIPA on Debian variants with SysV init?
>
> This is not an issue of what is supported now, but rather what is
> supportable in the future. Even if Debian with SysV init is not
> supported ATM, someone might want to add support for it in the future,
> and the design should not prevent them from doing so.
My proposal does not prevent sysv init support. In fact it makes it even
easier to support it. In case Debian SysV Init does not have a distinct
ID in /etc/os-release, I can easily add some additional check like
if platform == 'debian' and os.path.realpath('/sbin/init') !=
'/usr/lib/systemd/systemd':
platform = 'debian_sysvinit'
Christian
signature.asc
Description: OpenPGP digital signature
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Design document: Integration Improvements
On 2016-11-21 10:26, Jan Cholasta wrote: > On 11.11.2016 18:28, Christian Heimes wrote: >> On 2016-11-11 17:46, Martin Basti wrote: >>> >>> >>> On 11.11.2016 15:25, Christian Heimes wrote: >>>> Hello, >>>> >>>> I have released the first version of a new design document. It >>>> describes >>>> how I'm going to improve integration of FreeIPA's client libraries >>>> (ipalib, ipapython, ipaclient, ipaplatform) for third party developers. >>>> >>>> http://www.freeipa.org/page/V4/Integration_Improvements >>>> >>>> Regards, >>>> Christian >>>> >>>> >>>> >>> >>> Hello, I have a few questions: >>> >>> 1) dynamic platform files >>> >>> Currently all RHEL/fedora-derived platforms work with the same >>> rhel/fedora packages. How do you want to achieve this with dynamic >>> platform files, do you want to keep mappings between platforms and >>> platform file? What about distributions that have in /etc/release >>> just mess? >> >> I don't use /etc/releases but /etc/os-release. There is no mapping >> involved. If a distribution has no /etc/os-release or a messed up >> /etc/os-release, then it needs to be fixed by the distribution. It's a >> common standard and all relevant distributions support this standard. >> >> RHEL has ID=rhel and no ID_LIKE -> ipaplatform.rhel >> >> Fedora has ID=fedora and no ID_LIKE -> ipaplatform.fedora >> >> CentOS has ID=centos and ID_LIKE="rhel fedora" >> -> ipaplatform.rhel >> >> Even my Raspberry has an /etc/os-release with ID=raspbian and >> ID_LIKE=debian -> error, soon ipaplatform.debian > > There is more to ipaplatform than /etc/os-release offers. How do you > differentiate between e.g. "Debian with SysV init" and "Debian with > systemd"? Timo, do you support FreeIPA on Debian variants with SysV init? Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Design document: Integration Improvements
On 2016-11-11 18:33, Rob Crittenden wrote: > Martin Basti wrote: >> 2) if I understand correctly, you want to separate client installer code >> and client CLI code. In past we had freeipa-admintools but it was >> removed because it was really tightly bounded to installed client. Do >> you want to revive it and make it independent? > > The admintools package consisted only of the ipa command so I don't see > the relevance. > > This should have no impact on the installers. I think the only proposal > is to ignore the IPA_CONFDIR variable in all installer contexts. I think > I'd prefer it if it were simply wiped from the environment on startup of > *install commands prior to bootstrap so it can't leak it at all. With the latest patch, all installers, updaters and similar tools with an exception when a IPA_CONFDIR env var is present. I have also considered to fail for geteuid() == 0. On the other hand the env var is useful for containered application and people sure love to run all their containers as root. signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Design document: Integration Improvements
On 2016-11-11 17:46, Martin Basti wrote: > > > On 11.11.2016 15:25, Christian Heimes wrote: >> Hello, >> >> I have released the first version of a new design document. It describes >> how I'm going to improve integration of FreeIPA's client libraries >> (ipalib, ipapython, ipaclient, ipaplatform) for third party developers. >> >> http://www.freeipa.org/page/V4/Integration_Improvements >> >> Regards, >> Christian >> >> >> > > Hello, I have a few questions: > > 1) dynamic platform files > > Currently all RHEL/fedora-derived platforms work with the same > rhel/fedora packages. How do you want to achieve this with dynamic > platform files, do you want to keep mappings between platforms and > platform file? What about distributions that have in /etc/release just mess? I don't use /etc/releases but /etc/os-release. There is no mapping involved. If a distribution has no /etc/os-release or a messed up /etc/os-release, then it needs to be fixed by the distribution. It's a common standard and all relevant distributions support this standard. RHEL has ID=rhel and no ID_LIKE -> ipaplatform.rhel Fedora has ID=fedora and no ID_LIKE -> ipaplatform.fedora CentOS has ID=centos and ID_LIKE="rhel fedora" -> ipaplatform.rhel Even my Raspberry has an /etc/os-release with ID=raspbian and ID_LIKE=debian -> error, soon ipaplatform.debian > 2) if I understand correctly, you want to separate client installer code > and client CLI code. In past we had freeipa-admintools but it was > removed because it was really tightly bounded to installed client. Do > you want to revive it and make it independent? My proposal does not affect distribution packaging (rpm, deb) at all. It is purely about Python packaging. The client installer and client CLI code are already separated. The Python wheels will only contain what 'python setup.py bdist_wheel' spits out for ipaclient, ipalib, ipaplatform and ipapython. The 'ipa' CLI is part of the ipaclient Python package. > 3) why instead of environ variable we cannot have specified paths with > priority where IPA config can be located? > For example: > 1) ./.ipa.conf > 2) ~/.ipa.conf > 3) /etc/ipa/default.conf <-- as last resort For Ansible, testing etc. I need an arbitrary amount of config *directories* and full control. I don't like the idea that the current working directory affects how commands work. It has too many security implications, e.g. we have to verify that the file belongs to the current user. The check must be TOCTOU safe, too. Env vars are easier to control, more secure and less fragile. Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] Design document: Integration Improvements
Hello, I have released the first version of a new design document. It describes how I'm going to improve integration of FreeIPA's client libraries (ipalib, ipapython, ipaclient, ipaplatform) for third party developers. http://www.freeipa.org/page/V4/Integration_Improvements Regards, Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0035] Remove Custodia server keys from LDAP
On 2016-08-23 12:42, Petr Vobornik wrote: > On 08/11/2016 04:13 PM, Martin Basti wrote: >> >> >> On 08.08.2016 16:10, Christian Heimes wrote: >>> The server-del plugin now removes the Custodia keys for encryption and >>> key signing from LDAP. >>> >>> https://fedorahosted.org/freeipa/ticket/6015 >>> >>> >> ACK for master >> >> For 4.3, it requires new patch >> >> Martin >> > > bump I haven't worked out a patch for 4.3. The server_del plugin in 4.3 is much simpler than in 4.4. It's not possible to hook the clean-up code to server_del like I did for 4.4. I would have to rewrite and redesign the patch completely which I neither have the time nor resources to at the moment. I vote for WONTFIX for 4.3. Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0034] Secure permissions of Custodia server.keys
On 2016-08-23 12:49, Petr Vobornik wrote: > On 08/09/2016 01:53 PM, Martin Basti wrote: >> >> >> On 08.08.2016 16:09, Christian Heimes wrote: >>> I have split up patch 0032 into two smaller patches. This patch only >>> addresses the server.keys file. >>> >>> Custodia's server.keys file contain the private RSA keys for encrypting >>> and signing Custodia messages. The file was created with permission 644 >>> and is only secured by permission 700 of the directory >>> /etc/ipa/custodia. The installer and upgrader ensure that the file >>> has 600. >>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1353936 >>> https://fedorahosted.org/freeipa/ticket/6056 >>> >>> >> Pylint is running, please wait ... >> * Module ipapython.secrets.kem >> ipapython/secrets/kem.py:147: [E0602(undefined-variable), newServerKeys] >> Undefined variable 'os') >> ipapython/secrets/kem.py:148: [E0602(undefined-variable), newServerKeys] >> Undefined variable 'os') >> * Module ipaserver.install.custodiainstance >> ipaserver/install/custodiainstance.py:77: [E0602(undefined-variable), >> CustodiaInstance.upgrade_instance] Undefined variable 'stat') >> >> >> > > this review looks stuck Thanks, I didn't notice that it was stuck. I have pushed it to github and made a PR: https://github.com/freeipa/freeipa/pull/15 signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCH 0035] Remove Custodia server keys from LDAP
The server-del plugin now removes the Custodia keys for encryption and
key signing from LDAP.
https://fedorahosted.org/freeipa/ticket/6015
From be4d66075d108fd9188a3a0b906bace6f6ea5122 Mon Sep 17 00:00:00 2001
From: Christian Heimes <chei...@redhat.com>
Date: Mon, 8 Aug 2016 16:06:08 +0200
Subject: [PATCH] Remove Custodia server keys from LDAP
The server-del plugin now removes the Custodia keys for encryption and
key signing from LDAP.
https://fedorahosted.org/freeipa/ticket/6015
---
ipalib/constants.py | 1 +
ipaserver/plugins/server.py | 29 +
2 files changed, 30 insertions(+)
diff --git a/ipalib/constants.py b/ipalib/constants.py
index 0574bb3aa457dd79a6d64f6b8a6b57161d32da92..9b351e260f15211330521453b3ffcd41433a04bb 100644
--- a/ipalib/constants.py
+++ b/ipalib/constants.py
@@ -124,6 +124,7 @@ DEFAULT_CONFIG = (
('container_locations', DN(('cn', 'locations'), ('cn', 'etc'))),
('container_ca', DN(('cn', 'cas'), ('cn', 'ca'))),
('container_dnsservers', DN(('cn', 'servers'), ('cn', 'dns'))),
+('container_custodia', DN(('cn', 'custodia'), ('cn', 'ipa'), ('cn', 'etc'))),
# Ports, hosts, and URIs:
('xmlrpc_uri', 'http://localhost:/ipa/xml'),
diff --git a/ipaserver/plugins/server.py b/ipaserver/plugins/server.py
index b245dcf72a2f9f32f52ec9acf68d96c69d6169c5..d62c0232c5e33642e44a088dbfd9f10675d733f4 100644
--- a/ipaserver/plugins/server.py
+++ b/ipaserver/plugins/server.py
@@ -609,6 +609,32 @@ class server_del(LDAPDelete):
message=_("Failed to remove server %(master)s from server "
"list: %(err)s") % dict(master=master, err=e)))
+def _remove_server_custodia_keys(self, ldap, master):
+"""
+Delete all Custodia encryption and signing keys
+"""
+conn = self.Backend.ldap2
+env = self.api.env
+# search for memberPrincipal=*/fqdn@realm
+member_filter = ldap.make_filter_from_attr(
+'memberPrincipal', "/{}@{}".format(master, env.realm),
+exact=False, leading_wildcard=True, trailing_wildcard=False)
+custodia_subtree = DN(env.container_custodia, env.basedn)
+try:
+entries = conn.get_entries(custodia_subtree,
+ ldap.SCOPE_SUBTREE,
+ filter=member_filter)
+for entry in entries:
+conn.delete_entry(entry)
+except errors.NotFound:
+pass
+except Exception as e:
+self.add_message(
+messages.ServerRemovalWarning(
+message=_(
+"Failed to clean up Custodia keys for "
+"%(master)s: %(err)s") % dict(master=master, err=e)))
+
def _remove_server_host_services(self, ldap, master):
"""
delete server kerberos key and all its svc principals
@@ -682,6 +708,9 @@ class server_del(LDAPDelete):
# remove the references to master's ldap/http principals
self._remove_server_principal_references(pkey)
+# remove Custodia encryption and signing keys
+self._remove_server_custodia_keys(ldap, pkey)
+
# finally destroy all Kerberos principals
self._remove_server_host_services(ldap, pkey)
--
2.7.4
signature.asc
Description: OpenPGP digital signature
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCH 0034] Secure permissions of Custodia server.keys
I have split up patch 0032 into two smaller patches. This patch only
addresses the server.keys file.
Custodia's server.keys file contain the private RSA keys for encrypting
and signing Custodia messages. The file was created with permission 644
and is only secured by permission 700 of the directory
/etc/ipa/custodia. The installer and upgrader ensure that the file
has 600.
https://bugzilla.redhat.com/show_bug.cgi?id=1353936
https://fedorahosted.org/freeipa/ticket/6056
From 29cdaa5e27e7b8b3690d222c43eb0edfefdd82ba Mon Sep 17 00:00:00 2001
From: Christian Heimes <chei...@redhat.com>
Date: Mon, 8 Aug 2016 15:05:52 +0200
Subject: [PATCH] Secure permissions of Custodia server.keys
Custodia's server.keys file contain the private RSA keys for encrypting
and signing Custodia messages. The file was created with permission 644
and is only secured by permission 700 of the directory
/etc/ipa/custodia. The installer and upgrader ensure that the file
has 600.
https://bugzilla.redhat.com/show_bug.cgi?id=1353936
https://fedorahosted.org/freeipa/ticket/6056
---
ipapython/secrets/kem.py | 4 +++-
ipaserver/install/custodiainstance.py | 4
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/ipapython/secrets/kem.py b/ipapython/secrets/kem.py
index d45efe8cc4fb63ae9d8c0b2c920fd1f9e5331a9d..9c69adee2d30c246194ac1b05b644f07d365e5af 100644
--- a/ipapython/secrets/kem.py
+++ b/ipapython/secrets/kem.py
@@ -143,7 +143,9 @@ class KEMLdap(iSecLdap):
def newServerKeys(path, keyid):
skey = JWK(generate='RSA', use='sig', kid=keyid)
ekey = JWK(generate='RSA', use='enc', kid=keyid)
-with open(path, 'w+') as f:
+with open(path, 'w') as f:
+os.fchmod(f.fileno(), 0o600)
+os.fchown(f.fileno(), 0, 0)
f.write('[%s,%s]' % (skey.export(), ekey.export()))
return [skey.get_op_key('verify'), ekey.get_op_key('encrypt')]
diff --git a/ipaserver/install/custodiainstance.py b/ipaserver/install/custodiainstance.py
index fd30430bbf9c39e7153986999199474cfca60d09..b2b32a26615539b62de7503b12cd3fb5f3684344 100644
--- a/ipaserver/install/custodiainstance.py
+++ b/ipaserver/install/custodiainstance.py
@@ -73,6 +73,10 @@ class CustodiaInstance(SimpleServiceInstance):
if not sysupgrade.get_upgrade_state("custodia", "installed"):
root_logger.info("Custodia service is being configured")
self.create_instance()
+mode = os.stat(self.server_keys).st_mode
+if stat.S_IMODE(mode) != 0o600:
+root_logger.info("Secure server.keys mode")
+os.chmod(self.server_keys, 0o600)
def create_replica(self, master_host_name):
suffix = ipautil.realm_to_suffix(self.realm)
--
2.7.4
signature.asc
Description: OpenPGP digital signature
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 031] RedHatCAService should wait for local Dogtag instance
On 2016-07-07 14:54, Martin Basti wrote:
> Patch needs changes in ipa-4-3 branch
Here are patches for master and ipa-4-3 branch. I have rebased both
patches to head.
Christian
From e3a99ef8a6245d6e1bca22b3b0cede5d2ff608e8 Mon Sep 17 00:00:00 2001
From: Christian Heimes <chei...@redhat.com>
Date: Fri, 1 Jul 2016 10:21:06 +0200
Subject: [PATCH] RedHatCAService should wait for local Dogtag instance
RedHatCAService.wait_until_running() uses dogtag.ca_status() to make a
HTTP(s) request to Dogtag in order to check if /ca/admin/ca/getStatus
returns OK. The ca_status() function defaults to api.env.ca_host as
host.
On a replica without CA ca_host is a remote host (e.g. master's
FQDN). ipa-ca-install waits for master:8080 instead of replica:8080,
which might be blocked by a firewall.
https://fedorahosted.org/freeipa/ticket/6016
---
ipaplatform/redhat/services.py | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/ipaplatform/redhat/services.py b/ipaplatform/redhat/services.py
index 849737059d54df5af47ae288ef97b933d9e869fe..24325347c7d9183e2ecdd8d00bfa52729463fea3 100644
--- a/ipaplatform/redhat/services.py
+++ b/ipaplatform/redhat/services.py
@@ -199,7 +199,8 @@ class RedHatCAService(RedHatService):
op_timeout = time.time() + timeout
while time.time() < op_timeout:
try:
-status = dogtag.ca_status()
+# check status of CA instance on this host, not remote ca_host
+status = dogtag.ca_status(api.env.host)
except Exception as e:
status = 'check interrupted due to error: %s' % e
root_logger.debug('The CA status is: %s' % status)
--
2.7.4
From d5d1aa26085f8580f483d4790faed94d2886b426 Mon Sep 17 00:00:00 2001
From: Christian Heimes <chei...@redhat.com>
Date: Fri, 1 Jul 2016 10:47:53 +0200
Subject: [PATCH] RedHatCAService should wait for local Dogtag instance
RedHatCAService.wait_until_running() uses dogtag.ca_status() to make a
HTTP(s) request to Dogtag in order to check if /ca/admin/ca/getStatus
returns OK. The ca_status() function defaults to api.env.ca_host as
host.
On a replica without CA ca_host is a remote host (e.g. master's
FQDN). ipa-ca-install waits for master:8080 instead of replica:8080,
which might be blocked by a firewall.
https://fedorahosted.org/freeipa/ticket/6016
---
ipaplatform/redhat/services.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/ipaplatform/redhat/services.py b/ipaplatform/redhat/services.py
index 4774dbf0deb3df50e1a3284353e47b2fb0bebc75..e8ad31b0bbcf2d1441363b49a1e2ef52284a823a 100644
--- a/ipaplatform/redhat/services.py
+++ b/ipaplatform/redhat/services.py
@@ -205,10 +205,10 @@ class RedHatCAService(RedHatService):
#
# status = dogtag.ca_status(use_proxy=use_proxy)
#
+# check status of CA instance on this host, not remote ca_host
port = 8443
-
url = "https://%(host_port)s%(path)s" % {
-"host_port": ipautil.format_netloc(api.env.ca_host, port),
+"host_port": ipautil.format_netloc(api.env.host, port),
"path": "/ca/admin/ca/getStatus"
}
--
2.7.4
signature.asc
Description: OpenPGP digital signature
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0032] Secure permission and cleanup Custodia server.keys
On 2016-07-19 17:03, Martin Basti wrote:
>
>
> On 12.07.2016 16:45, Christian Heimes wrote:
>> Custodia's server.keys file contain the private RSA keys for encrypting
>> and signing Custodia messages. The file was created with permission 644
>> and is only secured by permission 700 of the directory
>> /etc/ipa/custodia. The installer and upgrader ensure that the file
>> has 600.
>>
>> The server.keys file and all keys are now removed when during
>> uninstallation of a server, too.
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1353936
>> https://fedorahosted.org/freeipa/ticket/6015
>> https://fedorahosted.org/freeipa/ticket/6056
>>
>>
> NACK
>
> ipa-server-install --uninstall doesn't work
I fixed it by splitting up uninstallation into two parts:
1) the server_del plugin takes care of the LDAP entries
2) CustodiaInstance.uninstall() removes the local key file
From 77541f4d70e3fa02a058c0812d4062a34e0bebf4 Mon Sep 17 00:00:00 2001
From: Christian Heimes <chei...@redhat.com>
Date: Fri, 8 Jul 2016 20:06:57 +0200
Subject: [PATCH] Secure permission and cleanup Custodia server.keys
Custodia's server.keys file contain the private RSA keys for encrypting
and signing Custodia messages. The file was created with permission 644
and is only secured by permission 700 of the directory
/etc/ipa/custodia. The installer and upgrader ensure that the file
has 600.
The server.keys file and all keys are now removed when during
uninstallation of a server, too.
https://bugzilla.redhat.com/show_bug.cgi?id=1353936
https://fedorahosted.org/freeipa/ticket/6015
https://fedorahosted.org/freeipa/ticket/6056
---
ipalib/constants.py | 1 +
ipapython/secrets/kem.py | 60 +++
ipaserver/install/custodiainstance.py | 25 +++
ipaserver/plugins/server.py | 31 ++
4 files changed, 104 insertions(+), 13 deletions(-)
diff --git a/ipalib/constants.py b/ipalib/constants.py
index 0574bb3aa457dd79a6d64f6b8a6b57161d32da92..9b351e260f15211330521453b3ffcd41433a04bb 100644
--- a/ipalib/constants.py
+++ b/ipalib/constants.py
@@ -124,6 +124,7 @@ DEFAULT_CONFIG = (
('container_locations', DN(('cn', 'locations'), ('cn', 'etc'))),
('container_ca', DN(('cn', 'cas'), ('cn', 'ca'))),
('container_dnsservers', DN(('cn', 'servers'), ('cn', 'dns'))),
+('container_custodia', DN(('cn', 'custodia'), ('cn', 'ipa'), ('cn', 'etc'))),
# Ports, hosts, and URIs:
('xmlrpc_uri', 'http://localhost:/ipa/xml'),
diff --git a/ipapython/secrets/kem.py b/ipapython/secrets/kem.py
index d45efe8cc4fb63ae9d8c0b2c920fd1f9e5331a9d..863234e01bf6226ee5090c76450b0fe25c430ed6 100644
--- a/ipapython/secrets/kem.py
+++ b/ipapython/secrets/kem.py
@@ -15,6 +15,8 @@ from jwcrypto.jwk import JWK
from ipapython.secrets.common import iSecLdap
from binascii import unhexlify
import ldap
+import errno
+import os
IPA_REL_BASE_DN = 'cn=custodia,cn=ipa,cn=etc'
@@ -66,7 +68,7 @@ class KEMLdap(iSecLdap):
'princ': principal})
r = conn.search_s(self.keysbase, scope, ldap_filter)
if len(r) != 1:
-raise ValueError("Incorrect number of results (%d) searching for"
+raise ValueError("Incorrect number of results (%d) searching for "
"public key for %s" % (len(r), principal))
ipa_public_key = r[0][1]['ipaPublicKey'][0]
jwk = self._parse_public_key(ipa_public_key)
@@ -139,11 +141,29 @@ class KEMLdap(iSecLdap):
mods = [(ldap.MOD_REPLACE, 'ipaPublicKey', public_key)]
conn.modify_s(dn, mods)
+def remove_key(self, usage, principal):
+conn = self.connect()
+scope = ldap.SCOPE_SUBTREE
+
+ldap_filter = self.build_filter(IPA_KEYS_QUERY,
+{'usage': RFC5280_USAGE_MAP[usage],
+ 'princ': principal})
+
+r = conn.search_s(self.keysbase, scope, ldap_filter)
+if not r:
+return False
+for entry in r:
+dn = r[0][0]
+conn.delete_s(dn)
+return True
+
def newServerKeys(path, keyid):
skey = JWK(generate='RSA', use='sig', kid=keyid)
ekey = JWK(generate='RSA', use='enc', kid=keyid)
-with open(path, 'w+') as f:
+with open(path, 'w') as f:
+os.fchmod(f.fileno(), 0o600)
+os.fchown(f.fileno(), 0, 0)
f.write('[%s,%s]' % (skey.export(), ekey.export()))
return [skey.get_op_key('verify'), ekey.get_op_key('encrypt')]
@@ -177,6 +197,9 @@ class IPAKEMKeys(KEMKeysStore):
self.ldap_uri = conf.get('global', 'ldap_uri', None)
self._server_keys = None
+def get_principal(self, servicename):
+return '%s/%s@%s' % (servicename, self.host, self.realm)
[Freeipa-devel] [PATCH 33] Correct path to HTTPD's systemd service directory
Ticket #5681 and commit 586fee293f42388510fa5436af19460bbe1fdec5 changed the location of the ipa.conf for Apache HTTPD. The variables SYSTEMD_SYSTEM_HTTPD_D_DIR and SYSTEMD_SYSTEM_HTTPD_IPA_CONF point to the wrong directory /etc/systemd/system/httpd.d/. The path is corrected to /etc/systemd/system/httpd.service.d/. https://fedorahosted.org/freeipa/ticket/6158 https://bugzilla.redhat.com/show_bug.cgi?id=1362537 From c6ab5d9323c1cc389ab221e0fc1c5290cc0075d4 Mon Sep 17 00:00:00 2001 From: Christian Heimes <chei...@redhat.com> Date: Tue, 2 Aug 2016 16:58:07 +0200 Subject: [PATCH] Correct path to HTTPD's systemd service directory Ticket #5681 and commit 586fee293f42388510fa5436af19460bbe1fdec5 changed the location of the ipa.conf for Apache HTTPD. The variables SYSTEMD_SYSTEM_HTTPD_D_DIR and SYSTEMD_SYSTEM_HTTPD_IPA_CONF point to the wrong directory /etc/systemd/system/httpd.d/. The path is corrected to /etc/systemd/system/httpd.service.d/. https://fedorahosted.org/freeipa/ticket/6158 https://bugzilla.redhat.com/show_bug.cgi?id=1362537 Signed-off-by: Christian Heimes <chei...@redhat.com> --- ipaplatform/base/paths.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ipaplatform/base/paths.py b/ipaplatform/base/paths.py index 579ea70d9f0795443aebb5f120d63c8e5289886c..bb0071a8e1a951e8df661d65058584c595c7a23a 100644 --- a/ipaplatform/base/paths.py +++ b/ipaplatform/base/paths.py @@ -126,8 +126,8 @@ class BasePathNamespace(object): SYSCONFIG_PKI_TOMCAT = "/etc/sysconfig/pki-tomcat" SYSCONFIG_PKI_TOMCAT_PKI_TOMCAT_DIR = "/etc/sysconfig/pki/tomcat/pki-tomcat" ETC_SYSTEMD_SYSTEM_DIR = "/etc/systemd/system/" -SYSTEMD_SYSTEM_HTTPD_D_DIR = "/etc/systemd/system/httpd.d/" -SYSTEMD_SYSTEM_HTTPD_IPA_CONF = "/etc/systemd/system/httpd.d/ipa.conf" +SYSTEMD_SYSTEM_HTTPD_D_DIR = "/etc/systemd/system/httpd.service.d/" +SYSTEMD_SYSTEM_HTTPD_IPA_CONF = "/etc/systemd/system/httpd.service.d/ipa.conf" SYSTEMD_CERTMONGER_SERVICE = "/etc/systemd/system/multi-user.target.wants/certmonger.service" SYSTEMD_IPA_SERVICE = "/etc/systemd/system/multi-user.target.wants/ipa.service" SYSTEMD_SSSD_SERVICE = "/etc/systemd/system/multi-user.target.wants/sssd.service" -- 2.7.4 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCH 0032] Secure permission and cleanup Custodia server.keys
Custodia's server.keys file contain the private RSA keys for encrypting
and signing Custodia messages. The file was created with permission 644
and is only secured by permission 700 of the directory
/etc/ipa/custodia. The installer and upgrader ensure that the file
has 600.
The server.keys file and all keys are now removed when during
uninstallation of a server, too.
https://bugzilla.redhat.com/show_bug.cgi?id=1353936
https://fedorahosted.org/freeipa/ticket/6015
https://fedorahosted.org/freeipa/ticket/6056
From de8f0f42f84eb5ce5e3efaf4336cbfab17793d21 Mon Sep 17 00:00:00 2001
From: Christian Heimes <chei...@redhat.com>
Date: Fri, 8 Jul 2016 20:06:57 +0200
Subject: [PATCH] Secure permission and cleanup Custodia server.keys
Custodia's server.keys file contain the private RSA keys for encrypting
and signing Custodia messages. The file was created with permission 644
and is only secured by permission 700 of the directory
/etc/ipa/custodia. The installer and upgrader ensure that the file
has 600.
The server.keys file and all keys are now removed when during
uninstallation of a server, too.
https://bugzilla.redhat.com/show_bug.cgi?id=1353936
https://fedorahosted.org/freeipa/ticket/6015
https://fedorahosted.org/freeipa/ticket/6056
---
ipapython/secrets/kem.py | 58 ++-
ipaserver/install/custodiainstance.py | 25 +++
2 files changed, 70 insertions(+), 13 deletions(-)
diff --git a/ipapython/secrets/kem.py b/ipapython/secrets/kem.py
index d45efe8cc4fb63ae9d8c0b2c920fd1f9e5331a9d..a9238e1f7bf8d8cef393ad6b6d997c5cebea13f4 100644
--- a/ipapython/secrets/kem.py
+++ b/ipapython/secrets/kem.py
@@ -15,6 +15,8 @@ from jwcrypto.jwk import JWK
from ipapython.secrets.common import iSecLdap
from binascii import unhexlify
import ldap
+import errno
+import os
IPA_REL_BASE_DN = 'cn=custodia,cn=ipa,cn=etc'
@@ -66,7 +68,7 @@ class KEMLdap(iSecLdap):
'princ': principal})
r = conn.search_s(self.keysbase, scope, ldap_filter)
if len(r) != 1:
-raise ValueError("Incorrect number of results (%d) searching for"
+raise ValueError("Incorrect number of results (%d) searching for "
"public key for %s" % (len(r), principal))
ipa_public_key = r[0][1]['ipaPublicKey'][0]
jwk = self._parse_public_key(ipa_public_key)
@@ -139,11 +141,29 @@ class KEMLdap(iSecLdap):
mods = [(ldap.MOD_REPLACE, 'ipaPublicKey', public_key)]
conn.modify_s(dn, mods)
+def remove_key(self, usage, principal):
+conn = self.connect()
+scope = ldap.SCOPE_SUBTREE
+
+ldap_filter = self.build_filter(IPA_KEYS_QUERY,
+{'usage': RFC5280_USAGE_MAP[usage],
+ 'princ': principal})
+
+r = conn.search_s(self.keysbase, scope, ldap_filter)
+if not r:
+return False
+for entry in r:
+dn = r[0][0]
+conn.delete_s(dn)
+return True
+
def newServerKeys(path, keyid):
skey = JWK(generate='RSA', use='sig', kid=keyid)
ekey = JWK(generate='RSA', use='enc', kid=keyid)
-with open(path, 'w+') as f:
+with open(path, 'w') as f:
+os.fchmod(f.fileno(), 0o600)
+os.fchown(f.fileno(), 0, 0)
f.write('[%s,%s]' % (skey.export(), ekey.export()))
return [skey.get_op_key('verify'), ekey.get_op_key('encrypt')]
@@ -177,6 +197,9 @@ class IPAKEMKeys(KEMKeysStore):
self.ldap_uri = conf.get('global', 'ldap_uri', None)
self._server_keys = None
+def get_principal(self, servicename):
+return '%s/%s@%s' % (servicename, self.host, self.realm)
+
def find_key(self, kid, usage):
if kid is None:
raise TypeError('Key ID is None, should be a SPN')
@@ -187,7 +210,7 @@ class IPAKEMKeys(KEMKeysStore):
self.generate_keys('host')
def generate_keys(self, servicename):
-principal = '%s/%s@%s' % (servicename, self.host, self.realm)
+principal = self.get_principal(servicename)
# Neutralize the key with read if any
self._server_keys = None
# Generate private key and store it
@@ -197,6 +220,23 @@ class IPAKEMKeys(KEMKeysStore):
ldapconn.set_key(KEY_USAGE_SIG, principal, pubkeys[0])
ldapconn.set_key(KEY_USAGE_ENC, principal, pubkeys[1])
+def remove_server_keys(self):
+self.remove_keys('host')
+
+def remove_keys(self, servicename):
+principal = self.get_principal(servicename)
+self._server_keys = None
+# remove keys from LDAP
+ldapconn = KEMLdap(self.ldap_uri)
+ldapconn.remove_key(KEY_USAGE_SIG, principal)
+ldapconn.remove_key(KEY_USAGE_ENC, principal)
+# remove server.keys file
+try:
+os.unlink(self.config['server_
Re: [Freeipa-devel] [PATCH 031] RedHatCAService should wait for local Dogtag instance
On 2016-07-07 14:54, Martin Basti wrote: > Patch needs changes in ipa-4-3 branch My patch? Do you want me to submit a patch for 4.3 branch? Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 031] RedHatCAService should wait for local Dogtag instance
On 2016-07-01 11:17, Petr Spacek wrote: > On 1.7.2016 11:04, Christian Heimes wrote: >> On 2016-07-01 10:59, Petr Spacek wrote: >>> On 1.7.2016 10:55, Christian Heimes wrote: >>>> On 2016-07-01 10:48, Petr Spacek wrote: >>>>> On 1.7.2016 10:42, Christian Heimes wrote: >>>>>> RedHatCAService.wait_until_running() uses dogtag.ca_status() to make a >>>>>> HTTP(s) request to Dogtag in order to check if /ca/admin/ca/getStatus >>>>>> returns OK. The ca_status() function defaults to api.env.ca_host as >>>>>> host. >>>>>> >>>>>> On a replica without CA ca_host is a remote host (e.g. master's >>>>>> FQDN). ipa-ca-install waits for master:8080 instead of replica:8080, >>>>>> which might be blocked by a firewall. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/6016 >>>>> >>>>> Interesting. How it happens that replica without CA is calling >>>>> RedHatCAService? >>>>> >>>>> Also, why replica should be waiting for CA if it is not installed? >>>>> >>>>> I'm confused. >>>> >>>> There is a hint in the last sentence: ipa-ca-install >>>> >>>> The patch fixes ipa-ca-install on replicas. Right now ipa-ca-install >>>> doesn't wait for the local Dogtag to come up but connects to a remote >>>> Dogtag to check if it's up. It uses 8443 or 8080, which might be >>>> blocked. In my test setup I have both ports blocked so ipa-ca-install >>>> never succeeds. >>> >>> Oh, I missed that, thanks! >>> >>> Isn't the root cause that ipa.env.ca_host does not get updated during >>> ipa-ca-install? >> >> Been there, tried it, didn't work: >> https://fedorahosted.org/freeipa/ticket/6016#comment:1 > > I understand that it does not work right now but it does not mean that it is > an actual problem in api.env :-) > > Anyway, I'm testing your patch but I'm not sure we can get it into 4.4.0 as > Petr^1 is about to push the RELEASE button any minute now. Thanks Petr. I talked to Petr^1 on IRC. Since 4.2 and 4.3 are also affected, it's better not to rush this patch. It won't make it into 4.4.0. Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 031] RedHatCAService should wait for local Dogtag instance
On 2016-07-01 10:48, Petr Spacek wrote: > On 1.7.2016 10:42, Christian Heimes wrote: >> RedHatCAService.wait_until_running() uses dogtag.ca_status() to make a >> HTTP(s) request to Dogtag in order to check if /ca/admin/ca/getStatus >> returns OK. The ca_status() function defaults to api.env.ca_host as >> host. >> >> On a replica without CA ca_host is a remote host (e.g. master's >> FQDN). ipa-ca-install waits for master:8080 instead of replica:8080, >> which might be blocked by a firewall. >> >> https://fedorahosted.org/freeipa/ticket/6016 > > Interesting. How it happens that replica without CA is calling > RedHatCAService? > > Also, why replica should be waiting for CA if it is not installed? > > I'm confused. There is a hint in the last sentence: ipa-ca-install The patch fixes ipa-ca-install on replicas. Right now ipa-ca-install doesn't wait for the local Dogtag to come up but connects to a remote Dogtag to check if it's up. It uses 8443 or 8080, which might be blocked. In my test setup I have both ports blocked so ipa-ca-install never succeeds. Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCH 031] RedHatCAService should wait for local Dogtag instance
RedHatCAService.wait_until_running() uses dogtag.ca_status() to make a
HTTP(s) request to Dogtag in order to check if /ca/admin/ca/getStatus
returns OK. The ca_status() function defaults to api.env.ca_host as
host.
On a replica without CA ca_host is a remote host (e.g. master's
FQDN). ipa-ca-install waits for master:8080 instead of replica:8080,
which might be blocked by a firewall.
https://fedorahosted.org/freeipa/ticket/6016
From 134f639aadad1b63e8715ec05fa06b53a3f12e74 Mon Sep 17 00:00:00 2001
From: Christian Heimes <chei...@redhat.com>
Date: Fri, 1 Jul 2016 10:21:06 +0200
Subject: [PATCH] RedHatCAService should wait for local Dogtag instance
RedHatCAService.wait_until_running() uses dogtag.ca_status() to make a
HTTP(s) request to Dogtag in order to check if /ca/admin/ca/getStatus
returns OK. The ca_status() function defaults to api.env.ca_host as
host.
On a replica without CA ca_host is a remote host (e.g. master's
FQDN). ipa-ca-install waits for master:8080 instead of replica:8080,
which might be blocked by a firewall.
https://fedorahosted.org/freeipa/ticket/6016
---
ipaplatform/redhat/services.py | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/ipaplatform/redhat/services.py b/ipaplatform/redhat/services.py
index 849737059d54df5af47ae288ef97b933d9e869fe..24325347c7d9183e2ecdd8d00bfa52729463fea3 100644
--- a/ipaplatform/redhat/services.py
+++ b/ipaplatform/redhat/services.py
@@ -199,7 +199,8 @@ class RedHatCAService(RedHatService):
op_timeout = time.time() + timeout
while time.time() < op_timeout:
try:
-status = dogtag.ca_status()
+# check status of CA instance on this host, not remote ca_host
+status = dogtag.ca_status(api.env.host)
except Exception as e:
status = 'check interrupted due to error: %s' % e
root_logger.debug('The CA status is: %s' % status)
--
2.7.4
signature.asc
Description: OpenPGP digital signature
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] FreeIPA Sub-CA: certificate subject
On 2016-06-28 12:49, Martin Kosek wrote: > On 06/28/2016 12:49 PM, Jan Cholasta wrote: >> On 28.6.2016 12:33, Martin Kosek wrote: >>> On 06/28/2016 12:23 PM, Fraser Tweedale wrote: On Tue, Jun 28, 2016 at 11:00:17AM +0200, Martin Kosek wrote: > Hi Fraser, > > I was testing FreeIPA Sub-CA feature and setup a Sub-CA: > > CN=Certificate Authority,O=VPN,O=DEMO1.FREEIPA.ORG > > Then I set up ACL and generated a certificate request by: > > $ certutil -R -d . -a -g 2048 -s > 'CN=ipa.demo1.freeipa.org,O=VPN,O=DEMO1.FREEIPA.ORG' -8 > 'ipa.demo1.freeipa.org' > > The resulting certificate is attached. What I pondering about is > > Issuer: O=DEMO1.FREEIPA.ORG, O=VPN, CN=Certificate Authority > ... > Subject: O=DEMO1.FREEIPA.ORG, CN=ipa.demo1.freeipa.org > > Shouldn't the subject have O=VPN in it also? > Hi Martin, (Cc freeipa-devel@ ; this info may be of general interest) The subject is determined by the certificate profile. In the case of caIPAserviceCert, the pattern is: CN=$$request.req_subject_name.cn$$, $SUBJECT_DN_O The CN comes from the CSR, and the Organisation is the IPA certificate subject base (as a literal string in the profile configuration). There are no substitution variables available to say "use such and such from the issuer DN". If the default pattern is not suitable, you can define a profile with the subject DN pattern having exactly the O=... parts of DN you want (and/or other attributes), then associate the profile with the CA through CA ACLs. (This approach is not elegant and does not scale well to many CAs). Hope that my explanation is helpful. >>> >>> The explanation is helpful, I just do not I like the answer :-) What do you >>> think would make most sense for Sub-CA users? >>> >>> I would like to see pattern like "$$issuer.suffix$$" where the Dogtag would >>> fill the non-CN part of issuer DN, i.e. in this case: >>> >>> O=DEMO1.FREEIPA.ORG, O=VPN >>> >>> which would make this profile flexible and usable in any Sub-CA. >> >>> >>> Should I file a ticket? Can you scope if it fits in some FreeIPA 4.4.x and >>> respective Dogtag release? I am just afraid that given we release this >>> feature >>> in 4.4, people would have to very creative and duplicate lot of certificate >>> profiles for different sub-CAs just to workaround the Subject patter >>> limitation, as you mentioned. >> >> What is the use case? > > This is what I am trying to find out. > >> The certificate is equally good with both the current and >> your suggested issuer name. There is no relation between issuer name and >> subject name in general, and AFAIK the current recommendation is to omit >> subject name for end-entity certificate entirely and instead rely on SAN, so >> why should we bother? > > I am aware of the SAN related change, regarding hostnames. So this proposal > would apparently not add that much value in this case. What about user > certificates (S/MIME certs, Smart Card certs), are there cases where admin > would need to get issuer to subject name? In my opinion it makes sense to have an indication of the issuer's purpose and designation in the subject of a EE cert. User's have been complaining about the hard-coded issuer name 'Certificate Authority' in the root CA. They'll do the same for Sub CAs. In my experience the subject DN is often the first string of a certificate that users see in case of an error. Therefore we should avoid naming conflicts, e.g. two certificates with the same subject "O=DEMO1.FREEIPA.ORG, CN=ipa.demo1.freeipa.org", one issued by "O=DEMO1.FREEIPA.ORG, O=VPN, CN=Certificate Authority" and the other issued by "O=DEMO1.FREEIPA.ORG, O=clientauth, CN=Certificate Authority". Technically it's not required to have unique subjects. For users and admins it is much nicer to have clear indicators of the intermediate CA in a subject, too. signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Questions on git
On 2016-05-25 11:46, Martin Kosek wrote: > On 05/25/2016 10:03 AM, Jan Pazdziora wrote: >> On Mon, May 23, 2016 at 04:24:38PM +0200, Florence Blanc-Renaud wrote: >>> >>> - I start working on a specific issue and decide to create a branch on my >>> git repository (on my laptop) >>> git clone git://git.fedorahosted.org/git/freeipa.git >>> git branch -b issue >> >> This likely needs to be >> >> git checkout -b issue >> >>> - When the tests are ok and I want to submit a patch, can I stay on the >>> branch "issue" to create the patch or should I merge first with the main >>> branch? If a merge is required, is it recommended to pull then merge or >>> merge then pull? >> >> As mentioned by Martin, you are looking for rebase, not merge. Rebase >> will re-create commits from the branch on top of other branch (master, >> most likely), omitting changes that got to master in the mean time, >> and giving you chance to resolve conflicts with whatever other changes >> might have gone to master, so that others have as clean experience as >> possible. >> >> If you look at FreeIPA's history (I like gitk for that), you will see >> that merge commits are very rarely used. The reason for keeping the >> history linear (and thus rebasing on master often) is that it forces >> the author to be explicit about the diffs, plus git tools for >> introspecting history often choke on parallel branches that get >> merged. > > +1, we want to keep that. For example, even though we already had some > discussions about adopting github workflow (pull reuqests) as the main vehicle > for patch reviews, we would still prefer to avoid merging and keep rebasing - > the history is much cleaner that way. +1 against merge commits A couple of months ago github introduced a new option. The green merge button can be configured to either do a merge commit, squash all commits in the branch or both. https://help.github.com/articles/about-pull-request-merge-squashing/ I guess we can use squashed merges for the majority of simple PRs. Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0094] Migrate from #ifndef guards to #pragma once
On 2016-05-24 16:29, Nathaniel McCallum wrote: > Using a pragma instead of guards is easier to write, less error prone > and avoids name clashes (a source of very subtle bugs). This pragma > is supported on almost all compilers, including all the compilers we > care about: https://en.wikipedia.org/wiki/Pragma_once#Portability. Good idea! LGTM It's a low risk change. Any issues with pragma once will show up during compilation. Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Should we stop supporting realm != upper(domain) installations?
On 2016-05-06 15:50, Martin Babinsky wrote: > On 05/06/2016 03:43 PM, Petr Spacek wrote: >> Hello, >> >> I wonder if we should stop supporting new installations where >> Kerberos realm != uppercase(primary DNS domain). >> >> It breaks a lot of stuff, is harder to manager and docs are full of >> warnings >> discouraging it anyway. >> >> Do we really need to support it for new installs? >> > > Since many people using such setup are bound to shoot themselves in the > foot at some point I would argue for dropping support for this. > > I even fail to see the use case for having realm different that domain > name. +1 We could consider a --force option to skip the check and allow people to shoot themselves in the knee. Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] V4/RFC 2818 review
Hi Fraser, and now to the review of your design doc for RFC 2818-compliant subject alternative names in certs, http://www.freeipa.org/page/V4/RFC_2818_certificate_compliance 1) RFC 2818 vs. RFC 6125 First I like to address a more general topic. Your design mentions RFC 6125 shortly. IMHO RFC 6125 supersedes 2818 for CN/SAN hostname verification and we should follow the rules in RFC 6125, whenever 2818 lacks specification or there is a conflict between both RFCs. I can tell you some horror stories from Python's ssl module related to both RFCs. https://tools.ietf.org/html/rfc2818, HTTP Over TLS https://tools.ietf.org/html/rfc6125, Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS) As far as I'm familiar with RFC 6125, your proposal doesn't conflict with the more modern RFC. It also makes sense to name the design after the RFC, which has deprecated CN. I still like to check your design against RFC 6125. Fraser, do you agree? 2) SAN validation in ipa cert-request In the paragraph "ipa cert-request changes" you write that the plugin "[...] ensure that one element of the DNS names list matches the principal name". Shouldn't the plugin validate *all* DNS names and verify that the principal is allowed to request a cert for all fields in SAN? 3) Should FreeIPA deprecate cert request without SAN or at least warn the user? IMHO it makes sense to deprecate CN only cert requests. 4) update "Issue New Certificate for Host" dialog and documentation The web UI has an update "Issue New Certificate for Host" dialog which explains how to create a CSR with certutil. This dialog should be updated to explain how to add a SAN DNS field. The option for SAN DNS is '-8 fqdn' or '--extSAN dns:fqdn', e.g. Create a CSR with subject CN=,O=, for example: # certutil -R -d -a -g -s 'CN=client1.ipa.example,O=IPA.EXAMPLE' -8 'client1.ipa.example' Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] V4/Sub-CAs review
Hi Fraser, I'm the reviewer for your Sub-CAs and RFC 2818 designs. Let's start with Sub-CAs first. http://www.freeipa.org/page/V4/Sub-CAs In general the design is well written -- accurate as usual. I didn't want to ACK the design with a simple LGTM, so I put myself in the position of a customer and potential user of Sub-CAs. From the end-users perspective couple of points in the design doc are either unclear or are not addressed details. 1) How can I restrict a Sub-CA to a specific key usage or DNS suffix? The design doc mentions a comment from the puppet community or the possibility to use a SubCA for short-lived certs for VPN authentication. As a customer I would like to restrict the KU, EKU and maybe name constraints, e.g. a SubCA for hosts should be limited to EKU "TLS webserver auth". Would it be possible to use a custom profile to generate a SubCA and let users select the profile in ipa ca-add? 2) What is the relationship between Sub-CAs and profiles? From the design doc it is unclear how cert profiles and Sub-CAs interact. The certificate profile doc has http://www.freeipa.org/page/V4/Certificate_Profiles#Schema_2, but that's too technical. I'm not even sure I fully understand the meaning of the schema and how memberCa affects profiles. 3) How can I make FreeIPA use a specific Sub-CA in a cert request? IMO a 1:n relationship between CAs and profiles would make sense. That way ipa cert-request --profile-id=caVPNCert could automatically select the VPN Sub-CA. 4) Where is the private key of a Sub-CAs stored locally and how is it secured? Customers will like to know where Dogtag keeps its crown jewels and how they are secured. 5) What is the backup and export strategy for a Sub-CA private key? Similar to 4), customers want/should to backup private keys securely. Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] Check if server is fully installed and ready
Hi, while I was working on my Ansible playbook I ran into an issue. It is hard to detect if a FreeIPA server instance is fully installed and all its services are ready to handle requests. It's even harder to check it remotely. I have figured out some heuristics to detect that a sever is *not* fully installed (e.g. /etc/ipa/default.conf is missing or http://ipa-ca.ipa.example/ipa/crl/MasterCRL.bin returns 404). The presence of these resources is no guarantee that all FreeIPA services fully up and running. Two days ago on IRC Jan came up with the same problem with containers. He ran into a problem related to containers and DNS updates. Since I'm no longer alone with the problem and my own workarounds are not completely stable, I like to address the problem in FreeIPA directly. Now you might wonder why it is so hard to check if FreeIPA is ready or why nobody ran into the issue before. Let's start with the second question. A typical admin first installs a FreeIPA server on one machine. It takes a couple of seconds until he notices that the installer has finished. The admin ssh-es into another machine, sudo -s and then runs ipa-client-install with some arguments. It takes a couple of seconds, maybe even a minute. With containers and automation tools it's more like milliseconds. Now for the first question. Under some conditions a FreeIPA service might be started but not yet ready to serve requests or aren't fully operation yet. For example ticket https://fedorahosted.org/freeipa/ticket/5813 is an example of a problem with ipa-kra-install, 389-DS restarts and bind-dyndb-ldap. Proposal 1) A new boolean attribute ipaReady=TRUE/FALSE in cn=$FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX tracks whether or not an FreeIPA instance is ready to handle requests. 2) A new HTTP route http[s]://$FQDN/ipa/ready is added. The route does not need authentication. When ipaReady=TRUE the route simple returns 200 OK with some text like READY. When the attribute is not present or FALSE, it returns an error to the client (412, 408?). 3) All ipa install and upgrade commands set the attribute to FALSE before any tasks. 4) A final step in all ipa install and upgrade commands checks that all services have been started and are ready to handle requests. Eventually the ipaReady attribute is set to true. Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [DESIGN] Sub-CAs; authenticating to Custodia
On 2016-04-07 11:09, Petr Spacek wrote: > On 7.4.2016 08:43, Fraser Tweedale wrote: >> Hi team, >> >> I updated the Sub-CAs design page with more detail for the key >> replication[1]. This part of the design is nearly complete (a large >> patchset is in review over at pki-devel@) but there are various >> options about how to authenticate to Custodia. >> >> [1] http://www.freeipa.org/page/V4/Sub-CAs#Key_replication >> >> In brief, the options are: >> >> 1) authenticate as host principal; install binary setuid >>root:pkiuser to read host keytab and custodia keys. > > Huh, I really do not like this. Host keytab on IPA master is one of the most > sensitive keys we have. > > Maybe gssproxy can be used somehow, but I think it would be better to use > separate key. > > >> 2) authenticate as host principal; copy host keytab and custodia >>keys to location readable by pkiuser. > > No, really, do not copy host keytab anywhere. > > >> 3) create new principal for pkiuser to use, along with custodia keys >>and keytab in location readable by pkiuser. >> >> I prefer option (1) for reasons outlined in the design page. The >> design page goes into quite a bit more detail so please review the >> section linked above and get back to me with your thoughts. > > The only downside of (3) using new keys is: > ... This approach requires the creation of new principals, and Kerberos > keytabs and Custodia keys for those principals, as part of the > installation/upgrade process. > > Compared with additional SUID binary this seems as safer and easier way to go. > FreeIPA installers already create quite a lot of principals and keytabs so > this is well understood task. > > I would do (3). +1 for (3) A SUID binary feels like a dangerous hack. Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Converting plugin output
On 2016-03-21 12:02, Jan Cholasta wrote:
> Hi,
>
> On 18.3.2016 15:26, Christian Heimes wrote:
>> Hi,
>>
>> I'd like to use FreeIPA's RPC interface from Ansible directly. But the
>> output of plugins is rather unfriendly and unpythonic:
>>
>>>>> print(api.Command.dnsconfig_show())
>> {u'result': {u'dn': u'cn=dns,dc=ipa,dc=example', u'idnsallowsyncptr':
>> (u'FALSE',)}, u'value': None, u'summary': None}
>>
>> Please notice (u'FALSE',) instead of False.
>
> This is how the framework does things - there is no internal consistency
> and no singular place where coding of values is handled, lot of the
> output is generated by ad-hoc code somewhere in post_callbacks.
> Unfortunately this is not easily fixable.
Yes, it's a bit unfortunate. FreeIPA has a rich and powerful RPC-API.
The under-documented and nested output makes the RPCs hard to use from
Python code. I'd wish we had something like JSON schema for input and
output documentation.
>> But it is failing for some plugins like user_find(). The plugin returns
>> u'memberof_group': (u'admins', u'trust admins'). However
>> global_output_params defines the value as an optional and single valued
>> string:
>>
>> Str('memberof_group?', label=_('Member of groups')).
>>
>> I think the definition is wrong. memberof_group and some other fields
>> should be defined as optional and multivalued fields insteads. Even the
>> field's label uses a plural form.
>>
>> What do you think?
>
> Yes, the definition is wrong, but I don't think it's worth fixing, since
> you can't rely on a single-value param having a single value in the
> output for any other command and param anyway.
I think it's a low-hanging fruit. All memberof and indirectmemberof
params should be multivalued. That's an easy fix.
Christian
signature.asc
Description: OpenPGP digital signature
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCHES 0442-0449] Pylint: sunday code cleanup
On 2016-03-21 10:29, Petr Spacek wrote: > On 20.3.2016 21:56, Martin Basti wrote: >> Patches attached. > > I do not really like > freeipa-mbasti-0442-pylint-remove-bare-except > because it replaces most of > > try: ... except: > > with > > try: ... except Exception: > > > which AFAIK does not add any value. It would be better to replace Exception > with more specific exception so the code raises an error instead of continuing > when something really unexpected happens. It adds some value. A bare except also excepts signals like KeyboardInterrupt and SystemExit. except Exception doesn't block these exceptions. But yes, more specific exceptions are better. Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] Converting plugin output
Hi,
I'd like to use FreeIPA's RPC interface from Ansible directly. But the
output of plugins is rather unfriendly and unpythonic:
>>> print(api.Command.dnsconfig_show())
{u'result': {u'dn': u'cn=dns,dc=ipa,dc=example', u'idnsallowsyncptr':
(u'FALSE',)}, u'value': None, u'summary': None}
Please notice (u'FALSE',) instead of False.
I have written a simple function that uses the parameter definitions to
convert most values automatically:
def converter(plugin, *args, **kwargs):
response = plugin(*args, **kwargs)
params = {p.name: p for p in plugin.obj.takes_params}
if hasattr(plugin, 'output_params'):
params.update({p.name: p for p in plugin.output_params()})
results = response['result']
if isinstance(results, dict):
results = [results]
for result in results:
for key, value in result.iteritems():
param = params.get(key)
if param is None:
continue
if (value and not param.multivalue and
isinstance(value, (list, tuple))):
if len(value) > 1:
raise ValueError(key, value)
value = value[0]
result[key] = param.convert(value)
return response
It works like a charm for several plugins:
>>> print(converter(api.Command.dnsconfig_show))
{u'result': {u'dn': u'cn=dns,dc=ipa,dc=example', u'idnsallowsyncptr':
False}, u'value': None, u'summary': None}
But it is failing for some plugins like user_find(). The plugin returns
u'memberof_group': (u'admins', u'trust admins'). However
global_output_params defines the value as an optional and single valued
string:
Str('memberof_group?', label=_('Member of groups')).
I think the definition is wrong. memberof_group and some other fields
should be defined as optional and multivalued fields insteads. Even the
field's label uses a plural form.
What do you think?
Christian
signature.asc
Description: OpenPGP digital signature
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0029] Move user/group constants for PKI and DS into ipaplatform
On 2016-03-18 10:22, Martin Basti wrote:
>
>
> On 29.02.2016 16:02, David Kupka wrote:
>> Hello Christian,
>> sorry for letting this patch rot for so long. I've forget about it the
>> minute Fraser replied.
>> To compensate a little I've fixed pep8 error, rebased it and attaching two
>> versions for master and for 4.3 branch.
>> I haven't found any missing cases and it works for me. If you're OK with the
>> modified patches it can be pushed.
>>
>> David
>>
>> - Original Message -
>> From: "Christian Heimes" <chei...@redhat.com>
>> To: "Fraser Tweedale" <ftwee...@redhat.com>
>> Cc: "freeipa-devel" <freeipa-devel@redhat.com>
>> Sent: Wednesday, January 20, 2016 11:57:42 AM
>> Subject: Re: [Freeipa-devel] [PATCH 0029] Move user/group constants for PKI
>> and DS into ipaplatform
>>
>> On 2016-01-20 02:54, Fraser Tweedale wrote:
>>> On Tue, Jan 19, 2016 at 02:20:27PM +0100, Christian Heimes wrote:
>>>> ipaplatform.constants has platform specific names for a couple of system
>>>> users like Apache HTTPD. The user names for PKI_USER, PKI_GROUP, DS_USER
>>>> and DS_GROUP are defined in other modules. Similar to #5587 the patch my
>>>> patch moves the constants into the platform module.
>>>>
>>>> https://fedorahosted.org/freeipa/ticket/5619
>>> I see a few remaining cases:
>>>
>>> ipaserver/install/dsinstance.py
>>> 712:pent = pwd.getpwnam("dirsrv")
>>>
>>> ipatests/test_integration/test_backup_and_restore.py
>>> 167:self.master.run_command(['userdel', 'dirsrv'])
>>> 168:self.master.run_command(['userdel', 'pkiuser'])
>>>
>>> ipaplatform/redhat/tasks.py
>>> 441:if name == 'pkiuser':
>>>
>>> When these are included, ACK.
>> Good catch!
>>
>> My new patch takes care of remaining cases.
>>
>>
>>
>>
>
> Christian do you agree with proposed changes, can we push it?
> Martin^2
Oh, the patch is still open? ACK!
signature.asc
Description: OpenPGP digital signature
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0030] Modernize mod_nss's cipher suites
On 2016-02-11 14:43, Martin Kosek wrote: >> Pushed to: >> master: 5ac3a3cee534a16db86c541b9beff4939f03410e >> ipa-4-3: c3496a4a4893c75789bdf0c617e46923361fb43b >> > > Very cool! Thanks guys! Looking forward to deploying FreeIPA 4.3.1 on the > FreeIPA public demo :-) I have to change the cipher list again in the near future. During DevConf.CZ Bob pointed out some issues with key sizes in post quantum crypto world [1]. Rob and I are working on a patch for mod_nss for finite field ephemeral DH key exchange. Once the patch has landed, I'll update the cipher list to support also kDHE. Christian [1] https://devconfcz2016.sched.org/event/5m21/post-quantum-crypo-what-is-it-and-do-we-need-it signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0030] Modernize mod_nss's cipher suites
On 2016-01-29 15:05, Martin Basti wrote:
>
>
> On 29.01.2016 14:42, Christian Heimes wrote:
>> On 2016-01-28 09:47, Martin Basti wrote:
>>>
>>> On 22.01.2016 12:32, Martin Kosek wrote:
>>>> On 01/21/2016 04:21 PM, Christian Heimes wrote:
>>>>> The list of supported TLS cipher suites in /etc/httpd/conf.d/nss.conf
>>>>> has been modernized. Insecure or less secure algorithms such as RC4,
>>>>> DES and 3DES are removed. Perfect forward secrecy suites with
>>>>> ephemeral
>>>>> ECDH key exchange have been added. IE 8 on Windows XP is no longer
>>>>> supported.
>>>>>
>>>>> The list of enabled cipher suites has been generated with the script
>>>>> contrib/nssciphersuite/nssciphersuite.py.
>>>>>
>>>>> The supported suites are currently:
>>>>>
>>>>> TLS_RSA_WITH_AES_128_CBC_SHA256
>>>>> TLS_RSA_WITH_AES_256_CBC_SHA256
>>>>> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
>>>>> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
>>>>> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
>>>>> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
>>>>> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
>>>>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
>>>>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
>>>>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
>>>>> TLS_RSA_WITH_AES_128_GCM_SHA256
>>>>> TLS_RSA_WITH_AES_128_CBC_SHA
>>>>> TLS_RSA_WITH_AES_256_GCM_SHA384
>>>>> TLS_RSA_WITH_AES_256_CBC_SHA
>>>>>
>>>>> https://fedorahosted.org/freeipa/ticket/5589
>>>> Thanks for the patch! I updated the ticket to make sure this change is
>>>> release notes.
>>>>
>>> Hello,
>>>
>>> I'm not sure if I'm the right person to do review on this, but I will
>>> try :-)
>>>
>>> 1)
>>> Your patch adds whitespace error
>>>
>>> Applying: Modernize mod_nss's cipher suites
>>> /home/mbasti/work/freeipa-devel/.git/rebase-apply/patch:52: new blank
>>> line at EOF.
>>> +
>>> warning: 1 line adds whitespace errors.
>>>
>>>
>>> 2)
>>> +import urllib.request # pylint: disable=E0611
>>>
>>> Please specify pylint disabled check by name
>>>
>>> 3)
>>> +def update_mod_nss_cipher_suite(http):
>>>
>>> in this upgrade, is there any possibility that ciphers might be upgraded
>>> again in future? (IMO yes).
>>>
>>> I think, it can be better to store revision of change instead of boolean
>>>
>>> LAST_REVISION = 1
>>>
>>> if revision >= LAST_REVISION:
>>> return
>>>
>>> sysupgrade.set_upgrade_state('nss.conf', 'cipher_suite_revision',
>>> LAST_REVISION)
>> Thanks for the review. I have addressed the problems. Instead of a
>> revision number I'm using a date string. The sysupgrade module only
>> stores str and bool. With a date-based revision it's easy to see when
>> the cipher suite was checked last time.
>>
>> Christian
>>
>
> Thanks
>
> 1) Pylint :-)
> + with urllib.request.urlopen(SOURCE) as r: # pylint: disable=E1101
Thanks! It was easier to change the import to get rid of the second
pylint stanza.
> 2)
> +if revision == httpinstance.NSS_CIPHER_REVISION:
>
> may happen a case where just comparation with '==' can cause a issues
> (docker world)? Should not be there rather '>='?
Makes sense, I've changed the comparison operator to >=. This may still
override user settings, though.
>
> 3)
> +root_logger.info("Cipher suite already updated")
>
> Sorry that I did not noticed earlier, this should be just debug level,
> IMO this message is not so important, it will cause only mess on output
> (we already have plenty of unneeded info messages in upgrade, they will
> be fixed once)
Fine with me :)
Christian
From c8adc1472e06242d02119b39f3ac94413cab4229 Mon Sep 17 00:00:00 2001
From: Christian Heimes <chei...@redhat.com>
Date: Thu, 21 Jan 2016 16:09:10 +0100
Subject: [PATCH] Modernize mod_nss's cipher suites
The list of supported TLS cipher suites in /etc/httpd/conf.d/nss.conf
has been modernized. Insecure or less secure algorithms such as RC4,
DES and 3DES are removed. Perfect forward secrecy suites with ephemeral
ECDH key exchange have been added. IE 8 on Windows XP is no longer
supported.
The list of enabled cipher suites has been generated with the script
contrib/nssciphersuite/nssciphersuit
Re: [Freeipa-devel] [PATCH 0030] Modernize mod_nss's cipher suites
On 2016-01-28 09:47, Martin Basti wrote:
>
>
> On 22.01.2016 12:32, Martin Kosek wrote:
>> On 01/21/2016 04:21 PM, Christian Heimes wrote:
>>> The list of supported TLS cipher suites in /etc/httpd/conf.d/nss.conf
>>> has been modernized. Insecure or less secure algorithms such as RC4,
>>> DES and 3DES are removed. Perfect forward secrecy suites with ephemeral
>>> ECDH key exchange have been added. IE 8 on Windows XP is no longer
>>> supported.
>>>
>>> The list of enabled cipher suites has been generated with the script
>>> contrib/nssciphersuite/nssciphersuite.py.
>>>
>>> The supported suites are currently:
>>>
>>> TLS_RSA_WITH_AES_128_CBC_SHA256
>>> TLS_RSA_WITH_AES_256_CBC_SHA256
>>> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
>>> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
>>> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
>>> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
>>> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
>>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
>>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
>>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
>>> TLS_RSA_WITH_AES_128_GCM_SHA256
>>> TLS_RSA_WITH_AES_128_CBC_SHA
>>> TLS_RSA_WITH_AES_256_GCM_SHA384
>>> TLS_RSA_WITH_AES_256_CBC_SHA
>>>
>>> https://fedorahosted.org/freeipa/ticket/5589
>>
>> Thanks for the patch! I updated the ticket to make sure this change is
>> release notes.
>>
> Hello,
>
> I'm not sure if I'm the right person to do review on this, but I will
> try :-)
>
> 1)
> Your patch adds whitespace error
>
> Applying: Modernize mod_nss's cipher suites
> /home/mbasti/work/freeipa-devel/.git/rebase-apply/patch:52: new blank
> line at EOF.
> +
> warning: 1 line adds whitespace errors.
>
>
> 2)
> +import urllib.request # pylint: disable=E0611
>
> Please specify pylint disabled check by name
>
> 3)
> +def update_mod_nss_cipher_suite(http):
>
> in this upgrade, is there any possibility that ciphers might be upgraded
> again in future? (IMO yes).
>
> I think, it can be better to store revision of change instead of boolean
>
> LAST_REVISION = 1
>
> if revision >= LAST_REVISION:
> return
>
> sysupgrade.set_upgrade_state('nss.conf', 'cipher_suite_revision',
> LAST_REVISION)
Thanks for the review. I have addressed the problems. Instead of a
revision number I'm using a date string. The sysupgrade module only
stores str and bool. With a date-based revision it's easy to see when
the cipher suite was checked last time.
Christian
From bf5fcde74a7e4af953d4f45538655954d1837a23 Mon Sep 17 00:00:00 2001
From: Christian Heimes <chei...@redhat.com>
Date: Thu, 21 Jan 2016 16:09:10 +0100
Subject: [PATCH] Modernize mod_nss's cipher suites
The list of supported TLS cipher suites in /etc/httpd/conf.d/nss.conf
has been modernized. Insecure or less secure algorithms such as RC4,
DES and 3DES are removed. Perfect forward secrecy suites with ephemeral
ECDH key exchange have been added. IE 8 on Windows XP is no longer
supported.
The list of enabled cipher suites has been generated with the script
contrib/nssciphersuite/nssciphersuite.py.
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_256_CBC_SHA
https://fedorahosted.org/freeipa/ticket/5589
Signed-off-by: Christian Heimes <chei...@redhat.com>
---
contrib/nssciphersuite/README.txt| 37
contrib/nssciphersuite/nssciphersuite.py | 148 +++
ipaserver/install/httpinstance.py| 19
ipaserver/install/server/upgrade.py | 18
4 files changed, 222 insertions(+)
create mode 100644 contrib/nssciphersuite/README.txt
create mode 100755 contrib/nssciphersuite/nssciphersuite.py
diff --git a/contrib/nssciphersuite/README.txt b/contrib/nssciphersuite/README.txt
new file mode 100644
index ..725f2588b7840dc9cc22d9c03d6cb205f5c9fc09
--- /dev/null
+++ b/contrib/nssciphersuite/README.txt
@@ -0,0 +1,37 @@
+Cipher suite for mod_nss
+
+
+The nssciphersuite.py script parses mod_nss' nss_engine_cipher.c file and
+creates a list of secure cipher suites for TLS. The script filters out
+insecure, obsolete and slow ciphers according to some rules.
+
+As of January 2016 and mod_nss 1.0.12 the cipher suite list contains 14
+c
Re: [Freeipa-devel] [PATCH 0406] Exclude o=ipaca from syncrepl
On 2016-01-21 11:29, Martin Basti wrote: > > > On 18.01.2016 17:55, Christian Heimes wrote: >> On 2016-01-18 17:28, Martin Basti wrote: >>> https://fedorahosted.org/freeipa/ticket/5538 >>> >>> Patch attached >> ACK >> >> > Pushed to: > master: 54a91c3ed33c7be54cadb188add802e781893ec9 > ipa-4-3: 89c32f2bdaf53a1408ea67fe19c0033cff202dfc > > Can I revert workaround in tests now? Yes, please give it a try. signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCH 0030] Modernize mod_nss's cipher suites
The list of supported TLS cipher suites in /etc/httpd/conf.d/nss.conf has been modernized. Insecure or less secure algorithms such as RC4, DES and 3DES are removed. Perfect forward secrecy suites with ephemeral ECDH key exchange have been added. IE 8 on Windows XP is no longer supported. The list of enabled cipher suites has been generated with the script contrib/nssciphersuite/nssciphersuite.py. The supported suites are currently: TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_256_CBC_SHA https://fedorahosted.org/freeipa/ticket/5589 From 26d356970ef1f7de7b00fe237f67345c507c7989 Mon Sep 17 00:00:00 2001 From: Christian Heimes <chei...@redhat.com> Date: Thu, 21 Jan 2016 16:09:10 +0100 Subject: [PATCH] Modernize mod_nss's cipher suites The list of supported TLS cipher suites in /etc/httpd/conf.d/nss.conf has been modernized. Insecure or less secure algorithms such as RC4, DES and 3DES are removed. Perfect forward secrecy suites with ephemeral ECDH key exchange have been added. IE 8 on Windows XP is no longer supported. The list of enabled cipher suites has been generated with the script contrib/nssciphersuite/nssciphersuite.py. The supported suites are currently: TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_256_CBC_SHA https://fedorahosted.org/freeipa/ticket/5589 Signed-off-by: Christian Heimes <chei...@redhat.com> --- contrib/nssciphersuite/README.txt| 38 contrib/nssciphersuite/nssciphersuite.py | 147 +++ ipaserver/install/httpinstance.py| 18 ipaserver/install/server/upgrade.py | 14 +++ 4 files changed, 217 insertions(+) create mode 100644 contrib/nssciphersuite/README.txt create mode 100755 contrib/nssciphersuite/nssciphersuite.py diff --git a/contrib/nssciphersuite/README.txt b/contrib/nssciphersuite/README.txt new file mode 100644 index ..89bafff560eb497089474e2d8a0b1b853d5c5bdf --- /dev/null +++ b/contrib/nssciphersuite/README.txt @@ -0,0 +1,38 @@ +Cipher suite for mod_nss + + +The nssciphersuite.py script parses mod_nss' nss_engine_cipher.c file and +creates a list of secure cipher suites for TLS. The script filters out +insecure, obsolete and slow ciphers according to some rules. + +As of January 2016 and mod_nss 1.0.12 the cipher suite list contains 14 +cipher suites for TLS 1.0, 1.1 and 1.2 for RSA and ECDSA certificates. The +cipher suite list also supports Perfect Forward Secrecy with ephemeral ECDH +key exchange. https://www.ssllabs.com/ gives a 'A' grade. + +Note: +No suite is compatible with IE 8 and earlier on Windows XP. If you need IE 8 +support, append "+rsa_3des_sha" to enable TLS_RSA_WITH_3DES_EDE_CBC_SHA. + +# disabled cipher attributes: SSL_3DES, SSL_CAMELLIA, SSL_CAMELLIA128, SSL_CAMELLIA256, SSL_DES, SSL_DSS, SSL_MD5, SSL_RC2, SSL_RC4, SSL_aDSS, SSL_aNULL, SSL_eNULL, SSL_kECDHe, SSL_kECDHr, kECDH +# weak strength: SSL_EXPORT40, SSL_EXPORT56, SSL_LOW, SSL_STRONG_NONE +# enabled cipher suites: +# TLS_RSA_WITH_AES_128_CBC_SHA256 +# TLS_RSA_WITH_AES_256_CBC_SHA256 +# TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 +# TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA +# TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 +# TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA +# TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 +# TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA +# TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 +# TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA +# TLS_RSA_WITH_AES_128_GCM_SHA256 +# TLS_RSA_WITH_AES_128_CBC_SHA +# TLS_RSA_WITH_AES_256_GCM_SHA384 +# TLS_RSA_WITH_AES_256_CBC_SHA +# + +NSSCipherSuite +aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_sha_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha + + diff --git a/contrib/nssciphersuite/nssciphersuite.py b/contrib/nssciphersuite/nssciphersuite.py new file mode 100755 index ..95252512a38d90bbcf
Re: [Freeipa-devel] [PATCH 0029] Move user/group constants for PKI and DS into ipaplatform
On 2016-01-20 02:54, Fraser Tweedale wrote:
> On Tue, Jan 19, 2016 at 02:20:27PM +0100, Christian Heimes wrote:
>> ipaplatform.constants has platform specific names for a couple of system
>> users like Apache HTTPD. The user names for PKI_USER, PKI_GROUP, DS_USER
>> and DS_GROUP are defined in other modules. Similar to #5587 the patch my
>> patch moves the constants into the platform module.
>>
>> https://fedorahosted.org/freeipa/ticket/5619
>
> I see a few remaining cases:
>
> ipaserver/install/dsinstance.py
> 712:pent = pwd.getpwnam("dirsrv")
>
> ipatests/test_integration/test_backup_and_restore.py
> 167:self.master.run_command(['userdel', 'dirsrv'])
> 168:self.master.run_command(['userdel', 'pkiuser'])
>
> ipaplatform/redhat/tasks.py
> 441:if name == 'pkiuser':
>
> When these are included, ACK.
Good catch!
My new patch takes care of remaining cases.
From ed52b83274c7cb70271264c01d25d9571ed48510 Mon Sep 17 00:00:00 2001
From: Christian Heimes <chei...@redhat.com>
Date: Tue, 19 Jan 2016 14:18:30 +0100
Subject: [PATCH] Move user/group constants for PKI and DS into ipaplatform
https://fedorahosted.org/freeipa/ticket/5619
---
install/share/copy-schema-to-ca.py | 8
ipaplatform/base/constants.py| 4
ipaplatform/redhat/tasks.py | 5 +++--
ipaserver/install/cainstance.py | 15 +++
ipaserver/install/dogtaginstance.py | 3 ++-
ipaserver/install/dsinstance.py | 7 ---
ipaserver/install/ipa_backup.py | 4 ++--
ipaserver/install/ipa_restore.py | 16 +---
ipaserver/install/krainstance.py | 8
ipaserver/install/krbinstance.py | 4 ++--
ipaserver/install/server/upgrade.py | 3 ++-
ipatests/test_integration/test_backup_and_restore.py | 5 +++--
12 files changed, 46 insertions(+), 36 deletions(-)
diff --git a/install/share/copy-schema-to-ca.py b/install/share/copy-schema-to-ca.py
index 10fd3d740bb60b9506a233a6aea6c6ac98356c18..c2f070aa29b7abf1cb32c46020ae80450cfd5080 100755
--- a/install/share/copy-schema-to-ca.py
+++ b/install/share/copy-schema-to-ca.py
@@ -19,9 +19,9 @@ from hashlib import sha1
from ipapython import ipautil
from ipapython.ipa_log_manager import root_logger, standard_logging_setup
-from ipaserver.install.dsinstance import DS_USER, schema_dirname
-from ipaserver.install.cainstance import PKI_USER
+from ipaserver.install.dsinstance import schema_dirname
from ipalib import api
+from ipaplatform.constants import constants
try:
from ipaplatform import services
@@ -52,8 +52,8 @@ def _sha1_file(filename):
def add_ca_schema():
"""Copy IPA schema files into the CA DS instance
"""
-pki_pent = pwd.getpwnam(PKI_USER)
-ds_pent = pwd.getpwnam(DS_USER)
+pki_pent = pwd.getpwnam(constants.PKI_USER)
+ds_pent = pwd.getpwnam(constants.DS_USER)
for schema_fname in SCHEMA_FILENAMES:
source_fname = os.path.join(ipautil.SHARE_DIR, schema_fname)
target_fname = os.path.join(schema_dirname(SERVERID), schema_fname)
diff --git a/ipaplatform/base/constants.py b/ipaplatform/base/constants.py
index 50f8a3ed140aca0f6573231f2a7e5b20e2169919..52af12429d090dcc0d7eed14b76e8b651360f283 100644
--- a/ipaplatform/base/constants.py
+++ b/ipaplatform/base/constants.py
@@ -8,9 +8,13 @@ This base platform module exports platform dependant constants.
class BaseConstantsNamespace(object):
+DS_USER = 'dirsrv'
+DS_GROUP = 'dirsrv'
HTTPD_USER = "apache"
IPA_DNS_PACKAGE_NAME = "freeipa-server-dns"
NAMED_USER = "named"
+PKI_USER = 'pkiuser'
+PKI_GROUP = 'pkiuser'
# ntpd init variable used for daemon options
NTPD_OPTS_VAR = "OPTIONS"
# quote used for daemon options
diff --git a/ipaplatform/redhat/tasks.py b/ipaplatform/redhat/tasks.py
index a0b4060cb26bab66248c4397c24b4d58bf1bf8d6..55c840de2be0a8c8308d93c2b533ce2df9f76471 100644
--- a/ipaplatform/redhat/tasks.py
+++ b/ipaplatform/redhat/tasks.py
@@ -44,6 +44,7 @@ import ipapython.errors
from ipalib import x509 # FIXME: do not import from ipalib
+from ipaplatform.constants import constants
from ipaplatform.paths import paths
from ipaplatform.redhat.authconfig import RedHatAuthConfig
from ipaplatform.base.tasks import BaseTaskNamespace
@@ -458,14 +459,14 @@ class RedHatTaskNamespace(BaseTaskNamespace):
This values should be constant and may be hardcoded.
Add other values for other users when needed.
"""
-if name == 'pkiuser':
+if name == constants.PKI_USER:
if uid is None:
uid = 17
if g
Re: [Freeipa-devel] [PATCH] Added kpasswd_server directive in client krb5.conf
On 2016-01-20 12:15, Abhijeet Kasurde wrote: > Hi Christian, > > On 01/20/2016 04:15 PM, Christian Heimes wrote: >> On 2016-01-20 08:30, Abhijeet Kasurde wrote: >>> Ping for review request. >> Hi, >> >> your initial patch has a small problem. Please provide a new patch with >> port 464 instead of 749. >> >> Christian >> >> > Please find the patches for review. ACK signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] Added kpasswd_server directive in client krb5.conf
On 2016-01-20 08:30, Abhijeet Kasurde wrote: > Ping for review request. Hi, your initial patch has a small problem. Please provide a new patch with port 464 instead of 749. Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCH 0029] Move user/group constants for PKI and DS into ipaplatform
ipaplatform.constants has platform specific names for a couple of system users like Apache HTTPD. The user names for PKI_USER, PKI_GROUP, DS_USER and DS_GROUP are defined in other modules. Similar to #5587 the patch my patch moves the constants into the platform module. https://fedorahosted.org/freeipa/ticket/5619 From bd49251543c480ed3d4527b3aeb32f0df6fc9e67 Mon Sep 17 00:00:00 2001 From: Christian Heimes <chei...@redhat.com> Date: Tue, 19 Jan 2016 14:18:30 +0100 Subject: [PATCH] Move user/group constants for PKI and DS into ipaplatform https://fedorahosted.org/freeipa/ticket/5619 --- install/share/copy-schema-to-ca.py | 8 ipaplatform/base/constants.py | 4 ipaserver/install/cainstance.py | 15 +++ ipaserver/install/dogtaginstance.py | 3 ++- ipaserver/install/dsinstance.py | 5 +++-- ipaserver/install/ipa_backup.py | 4 ++-- ipaserver/install/ipa_restore.py| 16 +--- ipaserver/install/krainstance.py| 8 ipaserver/install/krbinstance.py| 4 ++-- ipaserver/install/server/upgrade.py | 3 ++- 10 files changed, 39 insertions(+), 31 deletions(-) diff --git a/install/share/copy-schema-to-ca.py b/install/share/copy-schema-to-ca.py index 10fd3d740bb60b9506a233a6aea6c6ac98356c18..c2f070aa29b7abf1cb32c46020ae80450cfd5080 100755 --- a/install/share/copy-schema-to-ca.py +++ b/install/share/copy-schema-to-ca.py @@ -19,9 +19,9 @@ from hashlib import sha1 from ipapython import ipautil from ipapython.ipa_log_manager import root_logger, standard_logging_setup -from ipaserver.install.dsinstance import DS_USER, schema_dirname -from ipaserver.install.cainstance import PKI_USER +from ipaserver.install.dsinstance import schema_dirname from ipalib import api +from ipaplatform.constants import constants try: from ipaplatform import services @@ -52,8 +52,8 @@ def _sha1_file(filename): def add_ca_schema(): """Copy IPA schema files into the CA DS instance """ -pki_pent = pwd.getpwnam(PKI_USER) -ds_pent = pwd.getpwnam(DS_USER) +pki_pent = pwd.getpwnam(constants.PKI_USER) +ds_pent = pwd.getpwnam(constants.DS_USER) for schema_fname in SCHEMA_FILENAMES: source_fname = os.path.join(ipautil.SHARE_DIR, schema_fname) target_fname = os.path.join(schema_dirname(SERVERID), schema_fname) diff --git a/ipaplatform/base/constants.py b/ipaplatform/base/constants.py index 50f8a3ed140aca0f6573231f2a7e5b20e2169919..52af12429d090dcc0d7eed14b76e8b651360f283 100644 --- a/ipaplatform/base/constants.py +++ b/ipaplatform/base/constants.py @@ -8,9 +8,13 @@ This base platform module exports platform dependant constants. class BaseConstantsNamespace(object): +DS_USER = 'dirsrv' +DS_GROUP = 'dirsrv' HTTPD_USER = "apache" IPA_DNS_PACKAGE_NAME = "freeipa-server-dns" NAMED_USER = "named" +PKI_USER = 'pkiuser' +PKI_GROUP = 'pkiuser' # ntpd init variable used for daemon options NTPD_OPTS_VAR = "OPTIONS" # quote used for daemon options diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py index f3c1bfa361f2627d8e95ad6cb2fa93b4dc41ee38..269d2387db8293b98ef320156690020c540f952f 100644 --- a/ipaserver/install/cainstance.py +++ b/ipaserver/install/cainstance.py @@ -66,8 +66,7 @@ from ipaserver.install import installutils from ipaserver.install import ldapupdate from ipaserver.install import replication from ipaserver.install import service -from ipaserver.install.dogtaginstance import ( -PKI_USER, export_kra_agent_pem, DogtagInstance) +from ipaserver.install.dogtaginstance import export_kra_agent_pem, DogtagInstance from ipaserver.plugins import ldap2 # Python 3 rename. The package is available in "six.moves.http_client", but @@ -279,8 +278,8 @@ def is_ca_installed_locally(): def create_ca_user(): """Create PKI user/group if it doesn't exist yet.""" tasks.create_system_user( -name=PKI_USER, -group=PKI_USER, +name=constants.PKI_USER, +group=constants.PKI_GROUP, homedir=paths.VAR_LIB, shell=paths.NOLOGIN, ) @@ -442,7 +441,7 @@ class CAInstance(DogtagInstance): # Create an empty and secured file (cfg_fd, cfg_file) = tempfile.mkstemp() os.close(cfg_fd) -pent = pwd.getpwnam(PKI_USER) +pent = pwd.getpwnam(constants.PKI_USER) os.chown(cfg_file, pent.pw_uid, pent.pw_gid) # Create CA configuration @@ -511,7 +510,7 @@ class CAInstance(DogtagInstance): cafile = self.pkcs12_info[0] shutil.copy(cafile, paths.TMP_CA_P12) -pent = pwd.getpwnam(PKI_USER) +pent = pwd.getpwnam(constants.PKI_USER) os.chown(paths.TMP_CA_P12, pent.pw_uid, pent.pw_gid) # Security domain registration @@ -606,7 +605,7 @@ class CAInstance(DogtagInstanc
Re: [Freeipa-devel] [PATCH 0407] WIP: make-lint migration to config file and pylint plugin due pylint 1.5.2
On 2016-01-19 13:43, Martin Basti wrote:
> +
> +def fake_class(name_or_class_obj, members=[]):
Please use a non-mutable argument here. members=() will do the job just
fine.
> +if isinstance(name_or_class_obj, scoped_nodes.Class):
> +cl = name_or_class_obj
> +else:
> +cl = scoped_nodes.Class(name_or_class_obj, None)
> +
> +for m in members:
> +if isinstance(m, str):
> +if m in cl.locals:
> +_warning_already_exists(cl, m)
> +else:
> +cl.locals[m] = [scoped_nodes.Class(m, None)]
> +elif isinstance(m, dict):
> +for key, val in m.items():
> +assert isinstance(key, str), "key must be string"
> +if key in cl.locals:
> +_warning_already_exists(cl, key)
> +fake_class(cl.locals[key], val)
> +else:
> +cl.locals[key] = [fake_class(key, val)]
> +else:
> +# here can be used any astroid type
> +if m.name in cl.locals:
> +_warning_already_exists(cl, m.name)
> +else:
> +cl.locals[m.name] = [copy.copy(m)]
> +return cl
...
> +ipa_class_members = {
> +# Python standard library & 3rd party classes
> +'socket._socketobject': ['sendall'],
> +# !!!'datetime.tzinfo': ['houroffset', 'minoffset', 'utcoffset', 'dst'],
> +# !!!'nss.nss.subject_public_key_info': ['public_key'],
> +
> +# IPA classes
> +'ipalib.base.NameSpace': [
> +'add',
> +'mod',
> +'del',
> +'show',
> +'find'
> +],
> +'ipalib.cli.Collector': ['__options'],
> +'ipalib.config.Env': [
> +{'__d': ['get']},
> +{'__done': ['add']},
> +'xmlrpc_uri',
> +'validate_api',
> +'startup_traceback',
> +'verbose'
> +] + LOGGING_ATTRS,
The rules for __options, __d and __done may lead to false detection.
Class member and attribute names with leading double underscore are
mangled, so Collector.__options is turned into __Collector_options.
self.__options works because it's also mangled. But from other classes,
the attribute must be referred to as __Collector_options.
Christian
signature.asc
Description: OpenPGP digital signature
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0406] Exclude o=ipaca from syncrepl
On 2016-01-18 17:28, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/5538 > > Patch attached ACK signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0397] ipapython: Use custom datetime to LDAP generalized time
On 2016-01-15 13:44, Tomas Babej wrote:
> Hi,
>
> For the dates older than 1900, Python is unable to convert the datetime
> representation to string using strftime:
>
> https://bugs.python.org/issue1777412
>
> Work around the issue adding a custom method to convert the datetime
> objects to LDAP generalized time strings.
>
> https://fedorahosted.org/freeipa/ticket/5579
I noticed that all previous strftime() calls and the new code ignore any
time zone information. This isn't an issue for tz-naive datetime object
that don't have any time zone information attached. You can't fix them
anyway and just hope they are always UTC. For tz-aware datetime object
your approach returns the wrong value.
You can use datetime.utctimetuple() instead. The method returns a time
tuple in UTC.
>>> value
datetime.datetime(2016, 1, 18, 8, 2, 49, 646270)
>>>
'{0.tm_year:4d}{0.tm_mon:02d}{0.tm_mday:02d}{0.tm_hour:02d}{0.tm_min:02d}{0.tm_sec:02d}Z'.format(value.utctimetuple())
'20160118080249Z'
https://docs.python.org/2/library/datetime.html#datetime.datetime.utctimetuple
signature.asc
Description: OpenPGP digital signature
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] FreeIPA and modern requirements on certificates
On 2016-01-08 13:26, Martin Kosek wrote: > Hi Fraser and other X.509 SMEs, > > I wanted to check with you on what we have or plan to have with respect to > certificate/cipher strength in FreeIPA. > > When I visit the FreeIPA public demo for example, I usually see following > errors with recent browsers: > > * Your connection to ipa.demo1.freeipa.org is encrypted using obsolete cypher > suite. > - The connection uses TLS 1.2 > - The connection is encrypted ising AES_128_CBC, with HMAC-SHA1 for message > authentication and RSA as the key exchange mechanism > > I usually do not see the common > * Certificate chain contains a certificate signed with SHA-1 > error, but I am not sure if we are covered for this one. > > > When I tested the FreeIPA demo with > https://www.ssllabs.com/ssltest/analyze.html?d=ipa.demo1.freeipa.org > (and ignore the trust issues), we get the mark B with following warnings: > > * This server accepts RC4 cipher, but only with older protocol versions. Grade > capped to B. > > * The server does not support Forward Secrecy with the reference browsers. > > > What do we miss to turn out Grade A, which is obviously something expected > from > security solution like FreeIPA? Is it just about ECC support > (https://fedorahosted.org/freeipa/ticket/3951) or also maybe some change to > our > default certificate profiles? The cert has another issue. It relies on Subject CN for host name verification. This feature has been deprecated by RFC 2818 more than a decade ago. Instead of Subject CN modern certs should use dNSName in SubjectAltName x509v3 extension. https://fedorahosted.org/pki/ticket/1464 https://github.com/shazow/urllib3/issues/497 Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] FreeIPA and modern requirements on certificates
On 2016-01-08 16:49, Petr Spacek wrote: > On 8.1.2016 13:56, Fraser Tweedale wrote: >> On Fri, Jan 08, 2016 at 01:26:57PM +0100, Martin Kosek wrote: Hi Fraser and other X.509 SMEs, I wanted to check with you on what we have or plan to have with respect to certificate/cipher strength in FreeIPA. When I visit the FreeIPA public demo for example, I usually see following errors with recent browsers: * Your connection to ipa.demo1.freeipa.org is encrypted using obsolete cypher suite. - The connection uses TLS 1.2 - The connection is encrypted ising AES_128_CBC, with HMAC-SHA1 for message authentication and RSA as the key exchange mechanism > > HMAC-SHA1 reminded me recently published paper: > http://www.mitls.org/pages/attacks/SLOTH > > It claims that all MD5 and SHA1 uses should be eliminated if feasible. MD5 and SHA-1 should no longer be used for signatures. MACs are a completely different story. HMAC-SHA1 and even HMAC-MD5 are still fine and believed to be secure. https://en.wikipedia.org/wiki/Hash-based_message_authentication_code#Security signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 536] ipapython: remove default_encoding_utf8
On 2016-01-05 11:30, Tomas Babej wrote: > > > On 01/05/2016 08:54 AM, Jan Cholasta wrote: >> Hi, >> >> the attached patch replaces the default_encoding_utf8 binary module with >> 2 lines of equivalent Python code. >> >> Honza >> >> >> > > This looks fine to me, however, I wonder, why this approach was ever > taken? The sys.setdefaultencoding is available in all versions of Python > ever supported by FreeIPA. > > Is it possible we're missing something here? Or was this option simply > overlooked? sys.setdefaultencoding() is not available unless you use a hack and reload the sys module. The function is hidden for a very good reason. It can and will break internal assumption as well as libraries in bad, hard to detect ways. For example it wreaks havoc on hashing for dicts and sets. The blog posting https://anonbadger.wordpress.com/2015/06/16/why-sys-setdefaultencoding-will-break-code/ explains the problem in much greater detail. signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCH 027] Require Dogtag 10.2.6-13 to fix KRA uninstall
The combination of a bug in Dogtag's sslget command and a new feature
in mod_nss causes an incomplete uninstallation of KRA. The bug has been
fixed in Dogtag 10.2.6-13.
https://fedorahosted.org/freeipa/ticket/5469
https://fedorahosted.org/pki/ticket/1704
Signed-off-by: Christian Heimes <chei...@redhat.com>
From 9b3eae352513851be0e32b1e15fb00e8d08f8098 Mon Sep 17 00:00:00 2001
From: Christian Heimes <chei...@redhat.com>
Date: Tue, 5 Jan 2016 12:14:03 +0100
Subject: [PATCH] Require Dogtag 10.2.6-13 to fix KRA uninstall
The combination of a bug in Dogtag's sslget command and a new feature
in mod_nss causes an incomplete uninstallation of KRA. The bug has been
fixed in Dogtag 10.2.6-13.
https://fedorahosted.org/freeipa/ticket/5469
https://fedorahosted.org/pki/ticket/1704
Signed-off-by: Christian Heimes <chei...@redhat.com>
---
freeipa.spec.in | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/freeipa.spec.in b/freeipa.spec.in
index d4e23bce1d8d07bc6dfe550564f3d26be1b52470..7e956538d0f6c24bab636579303e0c7b5eeec199 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -156,8 +156,8 @@ Requires(post): systemd-units
Requires: selinux-policy >= %{selinux_policy_version}
Requires(post): selinux-policy-base >= %{selinux_policy_version}
Requires: slapi-nis >= 0.54.2-1
-Requires: pki-ca >= 10.2.6-12
-Requires: pki-kra >= 10.2.6-12
+Requires: pki-ca >= 10.2.6-13
+Requires: pki-kra >= 10.2.6-13
Requires(preun): python systemd-units
Requires(postun): python systemd-units
Requires: zip
--
2.5.0
signature.asc
Description: OpenPGP digital signature
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Added kpasswd_server directive in client krb5.conf
On 2016-01-04 23:38, Nalin Dahyabhai wrote: > On Mon, Dec 21, 2015 at 12:17:08PM +0530, Abhijeet Kasurde wrote: >> Hi All, >> >> Please review patches attached. > > The port number should probably be changed from 749 to 464. Nalin is correct. kpasswd and admin server use different ports: $ getent services kpasswd kpasswd 464/tcp kpwd $ getent services kerberos-adm kerberos-adm 749/tcp Except for the port number, the patch looks good to me. Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] Retro Changelog for bind-dyndb-ldap
Hi, in ticket https://fedorahosted.org/freeipa/ticket/5538 Ludwig has suggested to exclude Dogtag's o=ipaca tree from the changelog. Sometimes vault-archive fails because of a failed write to the Retro Changelog. The RetroCL was enabled in https://fedorahosted.org/freeipa/ticket/3967 for the bind-dyndb-ldap plugin. Otherwise it is not needed under normal circumstances because 389 doesn't use SyncRepl for replication. In #3967 Nathan has expressed his concerns for possible performance issues, too. Petr, Ludwig, would it makes sense to restrict RetroCL to cn=dns,$SUFFIX rather than excluding o=ipaca? The plugin supports both includes and exclude, http://directory.fedoraproject.org/docs/389ds/design/retrocl-scoping.html. Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0026] Workarounds for SELinux execmem violations in cryptography
On 2015-12-07 19:59, Petr Vobornik wrote: > On 7.12.2015 16:26, Christian Heimes wrote: >> On 2015-12-07 16:17, Alexander Bokovoy wrote: >>> On Mon, 07 Dec 2015, Christian Heimes wrote: >>>> The patch fixes SELinux violations in Fedora 23. >>>> >>>> Background: Recent versions of cryptography cause SELinux violation >>>> which will lead to a segfault, see >>>> https://bugzilla.redhat.com/show_bug.cgi?id=1277224 . The segfault only >>>> occurs in the context of Apache HTTPD (FreeIPA web ui) when >>>> cryptography.hazmat.backends.default_backend() is initialized. I'm >>>> working on a fix for cryptography but it will take a while. First I >>>> have >>>> to wait for a new upstream release of python-cffi. Armin Ronacher plans >>>> to release cffi 1.4 in two weeks. >>>> >>>> >>>> ipaserver.dcerpc uses M2Crypto again on Python 2.7 and Dogtag's >>>> pki.client no longer tries to use PyOpenSSL instead of Python's ssl >>>> module. >>>> >>>> Some dependencies like Dogtag's pki.client library and custodia use >>>> python-requsts to make HTTPS connection. python-requests prefers >>>> PyOpenSSL over Python's stdlib ssl module. PyOpenSSL is build on top >>>> of python-cryptography which trigger a execmem SELinux violation >>>> in the context of Apache HTTPD (httpd_execmem). >>>> When requests is imported, it always tries to import pyopenssl glue >>>> code from urllib3's contrib directory. The import of PyOpenSSL is >>>> enough to trigger the SELinux denial. >>>> A hack in wsgi.py prevents the import by raising an ImportError. >>> ACK. Thanks for these patches. >>> >>> Note to Debian/Ubuntu maintainers: AppArmor 'support' in python-cffi >>> already detects apparmor by looking into /proc and disabling the use of >>> writeable and executable memory. On those platforms I suspect recent >>> enough python-cryptography would work without problem by downgrading own >>> feature set. The code in this patches should be harmless, though. >> >> Cryptography's core depends on dynamic callbacks. There is no "downgrade >> feature-set" feature. >> >> I guess the libffi uses the broken and potential dangerous workaround >> with two shared mmap() with file backend. >> (http://www.akkadia.org/drepper/selinux-mem.html). The approach requires >> a writeable, executable temp file and breaks isolation between a parent >> process and all its forked child processes. >> >> Christian >> > > The patch needs to be rebased to 4-2 branch to be usable on Fedora 23 - > FreeIPA 4.2.3. For FreeIPA 4.2 only the patch in wsgi.py is needed. The older version doesn't use cryptography for RC4. I've attached a patch. Christian From ef68483bb3c9e328e3d65e0c02327cdb5ac9859a Mon Sep 17 00:00:00 2001 From: Christian Heimes <chei...@redhat.com> Date: Tue, 8 Dec 2015 11:18:22 +0100 Subject: [PATCH 26/26] Workarounds for SELinux execmem violations in cryptography Some dependencies like Dogtag's pki.client library and custodia use python-requsts to make HTTPS connection. python-requests prefers PyOpenSSL over Python's stdlib ssl module. PyOpenSSL is build on top of python-cryptography which trigger a execmem SELinux violation in the context of Apache HTTPD (httpd_execmem). When requests is imported, it always tries to import pyopenssl glue code from urllib3's contrib directory. The import of PyOpenSSL is enough to trigger the SELinux denial. A hack in wsgi.py prevents the import by raising an ImportError. --- install/share/wsgi.py | 14 ++ 1 file changed, 14 insertions(+) diff --git a/install/share/wsgi.py b/install/share/wsgi.py index 9f7d3f487dbe07f60b748cfd48d533495de99f2c..ffeb3bb6caea62c82d19e4e772b47efa43cc715f 100644 --- a/install/share/wsgi.py +++ b/install/share/wsgi.py @@ -23,6 +23,20 @@ """ WSGI appliction for IPA server. """ +import sys + +# Some dependencies like Dogtag's pki.client library and custodia use +# python-requsts to make HTTPS connection. python-requests prefers +# PyOpenSSL over Python's stdlib ssl module. PyOpenSSL is build on top +# of python-cryptography which trigger a execmem SELinux violation +# in the context of Apache HTTPD (httpd_execmem). +# When requests is imported, it always tries to import pyopenssl glue +# code from urllib3's contrib directory. The import of PyOpenSSL is +# enough to trigger the SELinux denial. +# This hack prevents the import by raising an ImportError. + +sys.modules['request.packages.urllib3.contrib.pyopenssl'] = None + from ipalib import api from ipalib.config import Env from ipalib.constants import DEFAULT_CONFIG -- 2.5.0 signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCH 0026] Workarounds for SELinux execmem violations in cryptography
The patch fixes SELinux violations in Fedora 23. Background: Recent versions of cryptography cause SELinux violation which will lead to a segfault, see https://bugzilla.redhat.com/show_bug.cgi?id=1277224 . The segfault only occurs in the context of Apache HTTPD (FreeIPA web ui) when cryptography.hazmat.backends.default_backend() is initialized. I'm working on a fix for cryptography but it will take a while. First I have to wait for a new upstream release of python-cffi. Armin Ronacher plans to release cffi 1.4 in two weeks. ipaserver.dcerpc uses M2Crypto again on Python 2.7 and Dogtag's pki.client no longer tries to use PyOpenSSL instead of Python's ssl module. Some dependencies like Dogtag's pki.client library and custodia use python-requsts to make HTTPS connection. python-requests prefers PyOpenSSL over Python's stdlib ssl module. PyOpenSSL is build on top of python-cryptography which trigger a execmem SELinux violation in the context of Apache HTTPD (httpd_execmem). When requests is imported, it always tries to import pyopenssl glue code from urllib3's contrib directory. The import of PyOpenSSL is enough to trigger the SELinux denial. A hack in wsgi.py prevents the import by raising an ImportError. From 5ac052f085c74f058703c5da29d59849c11e571f Mon Sep 17 00:00:00 2001 From: Christian Heimes <chei...@redhat.com> Date: Thu, 3 Dec 2015 14:26:19 +0100 Subject: [PATCH 26/26] Workarounds for SELinux execmem violations in cryptography ipaserver.dcerpc uses M2Crypto again on Python 2.7 and Dogtag's pki.client no longer tries to use PyOpenSSL instead of Python's ssl module. Some dependencies like Dogtag's pki.client library and custodia use python-requsts to make HTTPS connection. python-requests prefers PyOpenSSL over Python's stdlib ssl module. PyOpenSSL is build on top of python-cryptography which trigger a execmem SELinux violation in the context of Apache HTTPD (httpd_execmem). When requests is imported, it always tries to import pyopenssl glue code from urllib3's contrib directory. The import of PyOpenSSL is enough to trigger the SELinux denial. A hack in wsgi.py prevents the import by raising an ImportError. --- freeipa.spec.in | 2 ++ install/share/wsgi.py | 14 ++ ipaserver/dcerpc.py | 32 +++- 3 files changed, 39 insertions(+), 9 deletions(-) diff --git a/freeipa.spec.in b/freeipa.spec.in index a60d9b63f363773b6ca1b0969fa56b369a94092f..4fe8a911f0ae08882287bfea262064f5a2386ec1 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -66,6 +66,7 @@ BuildRequires: python-ldap BuildRequires: python-setuptools BuildRequires: python-nss BuildRequires: python-cryptography +BuildRequires: m2crypto BuildRequires: python-netaddr BuildRequires: python-gssapi >= 1.1.2 BuildRequires: python-rhsm @@ -322,6 +323,7 @@ Requires: keyutils Requires: pyOpenSSL Requires: python-nss >= 0.16 Requires: python-cryptography +Requires: m2crypto Requires: python-lxml Requires: python-netaddr Requires: python-libipa_hbac diff --git a/install/share/wsgi.py b/install/share/wsgi.py index ee9311e4eab8b95b5143170469cac7dc0b8b8e5e..ba42c343228da21f8e2ae9ea717450bada93359d 100644 --- a/install/share/wsgi.py +++ b/install/share/wsgi.py @@ -23,6 +23,20 @@ """ WSGI appliction for IPA server. """ +import sys + +# Some dependencies like Dogtag's pki.client library and custodia use +# python-requsts to make HTTPS connection. python-requests prefers +# PyOpenSSL over Python's stdlib ssl module. PyOpenSSL is build on top +# of python-cryptography which trigger a execmem SELinux violation +# in the context of Apache HTTPD (httpd_execmem). +# When requests is imported, it always tries to import pyopenssl glue +# code from urllib3's contrib directory. The import of PyOpenSSL is +# enough to trigger the SELinux denial. +# This hack prevents the import by raising an ImportError. + +sys.modules['request.packages.urllib3.contrib.pyopenssl'] = None + from ipalib import api from ipalib.config import Env from ipalib.constants import DEFAULT_CONFIG diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py index 2e412861ebc265a9b07c8634068151181a3e9b9e..15d8e192e397868a0bf623d8a23c4a2489126bcb 100644 --- a/ipaserver/dcerpc.py +++ b/ipaserver/dcerpc.py @@ -42,8 +42,6 @@ from samba.ndr import ndr_pack, ndr_print from samba import net import samba import random -from cryptography.hazmat.primitives.ciphers import Cipher, algorithms -from cryptography.hazmat.backends import default_backend try: from ldap.controls import RequestControl as LDAPControl #pylint: disable=F0401 except ImportError: @@ -65,6 +63,29 @@ if six.PY3: unicode = str long = int +# Some versions of python-cryptography depend on python-cffi callbacks which +# are built on top of libffi's closure API. The closures require writeable +# and executable anonymous memory mappings, which violate SELinux execmem +# rules such as 'httpd_execmem'. Prefer M2Cr
Re: [Freeipa-devel] [PATCH 0026] Workarounds for SELinux execmem violations in cryptography
On 2015-12-07 16:17, Alexander Bokovoy wrote: > On Mon, 07 Dec 2015, Christian Heimes wrote: >> The patch fixes SELinux violations in Fedora 23. >> >> Background: Recent versions of cryptography cause SELinux violation >> which will lead to a segfault, see >> https://bugzilla.redhat.com/show_bug.cgi?id=1277224 . The segfault only >> occurs in the context of Apache HTTPD (FreeIPA web ui) when >> cryptography.hazmat.backends.default_backend() is initialized. I'm >> working on a fix for cryptography but it will take a while. First I have >> to wait for a new upstream release of python-cffi. Armin Ronacher plans >> to release cffi 1.4 in two weeks. >> >> >> ipaserver.dcerpc uses M2Crypto again on Python 2.7 and Dogtag's >> pki.client no longer tries to use PyOpenSSL instead of Python's ssl >> module. >> >> Some dependencies like Dogtag's pki.client library and custodia use >> python-requsts to make HTTPS connection. python-requests prefers >> PyOpenSSL over Python's stdlib ssl module. PyOpenSSL is build on top >> of python-cryptography which trigger a execmem SELinux violation >> in the context of Apache HTTPD (httpd_execmem). >> When requests is imported, it always tries to import pyopenssl glue >> code from urllib3's contrib directory. The import of PyOpenSSL is >> enough to trigger the SELinux denial. >> A hack in wsgi.py prevents the import by raising an ImportError. > ACK. Thanks for these patches. > > Note to Debian/Ubuntu maintainers: AppArmor 'support' in python-cffi > already detects apparmor by looking into /proc and disabling the use of > writeable and executable memory. On those platforms I suspect recent > enough python-cryptography would work without problem by downgrading own > feature set. The code in this patches should be harmless, though. Cryptography's core depends on dynamic callbacks. There is no "downgrade feature-set" feature. I guess the libffi uses the broken and potential dangerous workaround with two shared mmap() with file backend. (http://www.akkadia.org/drepper/selinux-mem.html). The approach requires a writeable, executable temp file and breaks isolation between a parent process and all its forked child processes. Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 25] Improve error logging for Dogtag subsystem installation
On 2015-12-03 11:04, Jan Cholasta wrote: > On 2.12.2015 13:44, Petr Spacek wrote: >> On 2.12.2015 13:23, Jan Cholasta wrote: >>> On 2.12.2015 12:54, Petr Spacek wrote: >>>> On 2.12.2015 12:51, Christian Heimes wrote: >>>>> On 2015-12-02 08:37, Petr Spacek wrote: >>>>>> On 1.12.2015 18:42, Christian Heimes wrote: >>>>>>> From 33be1f56a64e53d261a1058c4606a7e48c0aac52 Mon Sep 17 >>>>>>> 00:00:00 2001 >>>>>>> From: Christian Heimes <chei...@redhat.com> >>>>>>> Date: Tue, 1 Dec 2015 15:49:53 +0100 >>>>>>> Subject: [PATCH 25] Improve error logging for Dogtag subsystem >>>>>>> installation >>>>>>> >>>>>>> In the case of a failed installation or uninstallation of a Dogtag >>>>>>> subsystem, the error output of pkispawn / pkidestroyed are now >>>>>>> shown to >>>>>>> the user. It makes it more obvious what went wrong and makes it >>>>>>> easier >>>>>>> to debug a problem. >>>>>>> >>>>>>> The error handler also attempts to get the full name of the >>>>>>> installation >>>>>>> / uninstallation log file from stdout. pkispawn and pkidestroy >>>>>>> print the >>>>>>> absolute name as 'Log file: /path/to/file.log'. The user no >>>>>>> longer has >>>>>>> to guess the right log file. >>>>>>> >>>>>>> Example: >>>>>>> [1/8]: configuring KRA instance >>>>>>> Failed to configure KRA instance: Command ''/usr/sbin/pkispawn' '-s' >>>>>>> 'KRA' '-f' '/tmp/tmp1UpbwF'' returned non-zero exit status 1 >>>>>>> pkispawn: ERROR... PKI subsystem 'KRA' for instance >>>>>>> 'pki-tomcat' already exists! >>>>>>> See the installation logs and the following files/directories for >>>>>>> more >>>>>>> information: >>>>>>> /var/log/pki/pki-tomcat >>>>>>> /var/log/pki/pki-kra-spawn.20151201151735.log >>>>>>> [error] RuntimeError: KRA configuration failed. >>>>>>> >>>>>>> The patch also changes a couple of modules that were using >>>>>>> the CalledProcessError exception object from subprocess instead of >>>>>>> ipautil. >>>>>> >>>>>> I'm wondering if ipautil.run() can log stdout and stderr on log >>>>>> level ERROR >>>>>> when return code is non-zero (and log on level DEBUG as usual when >>>>>> return >>>>>> code >>>>>> is zero). >>>>>> >>>>>> IMHO it would be nicer, universal, and does not require any >>>>>> changes in places >>>>>> calling ipautil.run(). >>>>> >>>>> I think it's a bit confusing to print out stdout and stderr, because >>>>> both streams are captured separately. The output is missing its >>>>> chronological order. subprocess can capture stdout and stderr in the >>>>> same stream, but then we can't distinguish between output and error >>>>> output... >>>> >>>> I do not think it is a problem if these two are clearly marked as such: >>>> standard output: %s (if non-empty) >>>> stanrard error output: %s (if non-empty) >>> >>> We do not want to log with level ERROR by default when rc != 0, >>> because some >>> commands generate a *lot* of output. >> >> I do not agree, but whatever. Somebody needs to review the original >> Christian's patch. > > We had a short discussion about this with Petr offline and we agreed > that a reasonable compromise would be to log the last few lines of > stderr with ERROR level when a command fails. > > This would mean adding custom __str__() to CalledProcessError, so that > the stderr tail is logged when the CalledProcessError is not handled, > and also logging it from ipautil.run() if raiseonerr == False. Yes, that sounds like a reasonable idea. In the default case (raiseonerr == True) ipautil.run() returns a custom CalledProcessError exception that prints the command and the last two or three non-empty lines from stderr. Callers can either log the exception directly or format the out as they see fit. With raiseonerr == False and exit code != 0 the same information is logged with log level ERROR. I can just create the exception object and log its string representation without raising the exception. Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 25] Improve error logging for Dogtag subsystem installation
On 2015-12-02 08:37, Petr Spacek wrote: > On 1.12.2015 18:42, Christian Heimes wrote: >> From 33be1f56a64e53d261a1058c4606a7e48c0aac52 Mon Sep 17 00:00:00 2001 >> From: Christian Heimes <chei...@redhat.com> >> Date: Tue, 1 Dec 2015 15:49:53 +0100 >> Subject: [PATCH 25] Improve error logging for Dogtag subsystem installation >> >> In the case of a failed installation or uninstallation of a Dogtag >> subsystem, the error output of pkispawn / pkidestroyed are now shown to >> the user. It makes it more obvious what went wrong and makes it easier >> to debug a problem. >> >> The error handler also attempts to get the full name of the installation >> / uninstallation log file from stdout. pkispawn and pkidestroy print the >> absolute name as 'Log file: /path/to/file.log'. The user no longer has >> to guess the right log file. >> >> Example: >> [1/8]: configuring KRA instance >> Failed to configure KRA instance: Command ''/usr/sbin/pkispawn' '-s' >> 'KRA' '-f' '/tmp/tmp1UpbwF'' returned non-zero exit status 1 >> pkispawn: ERROR... PKI subsystem 'KRA' for instance >> 'pki-tomcat' already exists! >> See the installation logs and the following files/directories for more >> information: >> /var/log/pki/pki-tomcat >> /var/log/pki/pki-kra-spawn.20151201151735.log >> [error] RuntimeError: KRA configuration failed. >> >> The patch also changes a couple of modules that were using >> the CalledProcessError exception object from subprocess instead of >> ipautil. > > I'm wondering if ipautil.run() can log stdout and stderr on log level ERROR > when return code is non-zero (and log on level DEBUG as usual when return code > is zero). > > IMHO it would be nicer, universal, and does not require any changes in places > calling ipautil.run(). I think it's a bit confusing to print out stdout and stderr, because both streams are captured separately. The output is missing its chronological order. subprocess can capture stdout and stderr in the same stream, but then we can't distinguish between output and error output... In case of Dogtag stderr contains the relevant error message. In order to understand the events, that lead to the particular error, a user has to read the log file anyway -- unless you run pkispawn with '-vv' for extra verbosity. But then you get pages over pages of debug output on *stderr*. It's not helpful either. Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCH 25] Improve error logging for Dogtag subsystem installation
In the case of a failed installation or uninstallation of a Dogtag subsystem, the error output of pkispawn / pkidestroyed are now shown to the user. It makes it more obvious what went wrong and makes it easier to debug a problem. The error handler also attempts to get the full name of the installation / uninstallation log file from stdout. pkispawn and pkidestroy print the absolute name as 'Log file: /path/to/file.log'. The user no longer has to guess the right log file. Example: [1/8]: configuring KRA instance Failed to configure KRA instance: Command ''/usr/sbin/pkispawn' '-s' 'KRA' '-f' '/tmp/tmp1UpbwF'' returned non-zero exit status 1 pkispawn: ERROR... PKI subsystem 'KRA' for instance 'pki-tomcat' already exists! See the installation logs and the following files/directories for more information: /var/log/pki/pki-tomcat /var/log/pki/pki-kra-spawn.20151201151735.log [error] RuntimeError: KRA configuration failed. The patch also changes a couple of modules that were using the CalledProcessError exception object from subprocess instead of ipautil. .freeipa-cheimes-0025-Improve-error-logging-for-Dogtag-subsystem-installat.patch.swp Description: Binary data signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 25] Improve error logging for Dogtag subsystem installation
Now the correct patch file instead of a vim swap file... From 33be1f56a64e53d261a1058c4606a7e48c0aac52 Mon Sep 17 00:00:00 2001 From: Christian Heimes <chei...@redhat.com> Date: Tue, 1 Dec 2015 15:49:53 +0100 Subject: [PATCH 25] Improve error logging for Dogtag subsystem installation In the case of a failed installation or uninstallation of a Dogtag subsystem, the error output of pkispawn / pkidestroyed are now shown to the user. It makes it more obvious what went wrong and makes it easier to debug a problem. The error handler also attempts to get the full name of the installation / uninstallation log file from stdout. pkispawn and pkidestroy print the absolute name as 'Log file: /path/to/file.log'. The user no longer has to guess the right log file. Example: [1/8]: configuring KRA instance Failed to configure KRA instance: Command ''/usr/sbin/pkispawn' '-s' 'KRA' '-f' '/tmp/tmp1UpbwF'' returned non-zero exit status 1 pkispawn: ERROR... PKI subsystem 'KRA' for instance 'pki-tomcat' already exists! See the installation logs and the following files/directories for more information: /var/log/pki/pki-tomcat /var/log/pki/pki-kra-spawn.20151201151735.log [error] RuntimeError: KRA configuration failed. The patch also changes a couple of modules that were using the CalledProcessError exception object from subprocess instead of ipautil. --- ipaplatform/redhat/tasks.py| 3 +-- ipapython/dnssec/bindmgr.py| 1 - ipapython/dnssec/odsmgr.py | 1 - ipapython/ipautil.py | 24 +--- ipaserver/install/dns.py | 4 +--- ipaserver/install/dogtaginstance.py| 28 ++-- ipaserver/install/opendnssecinstance.py| 3 +-- ipaserver/install/server/replicainstall.py | 3 +-- 8 files changed, 31 insertions(+), 36 deletions(-) diff --git a/ipaplatform/redhat/tasks.py b/ipaplatform/redhat/tasks.py index 94d2cb4e906965a20bcfdd55f38854005091c26f..1c502a2c859b23851d3b6101fca31e6cbb75b1eb 100644 --- a/ipaplatform/redhat/tasks.py +++ b/ipaplatform/redhat/tasks.py @@ -31,7 +31,6 @@ import socket import sys import base64 -from subprocess import CalledProcessError from nss.error import NSPRError from pyasn1.error import PyAsn1Error from six.moves import urllib @@ -173,7 +172,7 @@ class RedHatTaskNamespace(BaseTaskNamespace): def reload_systemwide_ca_store(self): try: ipautil.run([paths.UPDATE_CA_TRUST]) -except CalledProcessError as e: +except ipautil.CalledProcessError as e: root_logger.error( "Could not update systemwide CA trust database: %s", e) return False diff --git a/ipapython/dnssec/bindmgr.py b/ipapython/dnssec/bindmgr.py index 1822dacf2535e7c37062e4d639e01289edcf5074..5b1d34135e8e5bd5c135b3d204c8de76531ecd07 100644 --- a/ipapython/dnssec/bindmgr.py +++ b/ipapython/dnssec/bindmgr.py @@ -9,7 +9,6 @@ import os import logging import shutil import stat -import subprocess from ipalib import api import ipalib.constants diff --git a/ipapython/dnssec/odsmgr.py b/ipapython/dnssec/odsmgr.py index efbe16cc6ebf050d9cf347ed97b2b2e4b37c8a6e..a36ed7224a5abeb8c1ee91cc7eb60c048c05d2ed 100644 --- a/ipapython/dnssec/odsmgr.py +++ b/ipapython/dnssec/odsmgr.py @@ -6,7 +6,6 @@ import logging from lxml import etree import dns.name -import subprocess from ipapython import ipa_log_manager, ipautil diff --git a/ipapython/ipautil.py b/ipapython/ipautil.py index 4551ea5c4025223dcff5cdc8998fedeccd14c3c2..ac85cb7b90ebde6f895dc09cae485a95c1c4a28d 100644 --- a/ipapython/ipautil.py +++ b/ipapython/ipautil.py @@ -63,20 +63,14 @@ KRB5_KDC_UNREACH = 2529639068 # Cannot contact any KDC for requested realm KRB5KDC_ERR_SVC_UNAVAILABLE = 2529638941 # A service is not available that is # required to process the request -try: -from subprocess import CalledProcessError -except ImportError: -# Python 2.4 doesn't implement CalledProcessError -class CalledProcessError(Exception): -"""This exception is raised when a process run by check_call() returns -a non-zero exit status. The exit status will be stored in the -returncode attribute.""" -def __init__(self, returncode, cmd, output=None): -self.returncode = returncode -self.cmd = cmd -self.output = output -def __str__(self): -return "Command '%s' returned non-zero exit status %d" % (self.cmd, self.returncode) + +class CalledProcessError(subprocess.CalledProcessError): +"""Custom CalledProcessError with error output +""" +def __init__(self, returncode, cmd, output=None, erroutput=None): +super(CalledProcessError, self).__init__(returncode, cmd, output) +self.erroutput = erroutput + def get_
Re: [Freeipa-devel] [PATCH] 0001 cert-show: Remove check if hostname != CN
On 2015-10-09 15:11, Jan Cholasta wrote: > On 9.10.2015 15:00, Christian Heimes wrote: >> On 2015-10-09 13:21, Jan Orel wrote: >>> Hello, >>> >>> this patch removes (IMHO) redundat check in cert_show, which fails when >>> host tries to re-submit certificate of different host/service which he >>> can manage. >>> >>> I also reported the bug here: >>> https://bugzilla.redhat.com/show_bug.cgi?id=1269089 >>> >>> I tired to run the tests as well and it doesn't seem to break anything. >>> Any feedpack appriciated. >> >> Jan Cholasta, you implemented the check in 2011. What purpose does it >> have? > > I did not, it was added in commit 2e8bae59 by Rob. Sorry, I didn't check the context, just the output of $ git annotate ipalib/plugins/cert.py | grep common_name signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] The Community Auth.NEXT Working Group Inagural Meeting
On 2015-09-30 08:05, Alexander Bokovoy wrote: > On Tue, 29 Sep 2015, Brian Stinson wrote: >> Hi FreeIPA! >> >> We are starting a working group of member projects looking to solve >> problems >> related to Community Authentication. The FreeIPA Community Portal >> feature added >> this summer is one of the important bits we are evaluating. >> >> We are hoping to collaborate on centos-de...@centos.org, and have IRC >> meetings >> in #centos-devel on Freenode every now and then to check in. We >> currently have >> interest from CentOS, Fedora, and a few other projects, and would love to >> invite anyone interested to participate. >> >> Patrick Uiterwijk will be starting a thread soon scheduling our next IRC >> meeting in 2 weeks time. > Thanks, Brian. > > There is also community-auth-next...@lists.fedoraproject.org for the same > purpose around Fedora Project needs. Reading your first meeting notes, > it is unclear why we couldn't use this list and would instead need to > subscribe to centos-devel@ (which I assume has more than this topic to > discuss). Hi Brian, thanks for your mail and for keeping us in the loop. I agree with Alexander's suggestion to use Patrick's new mailing list community-auth-next-wg. The centos-devel mailing list and #centos-devel channel are too busy to follow. For me and the other FreeIPA devs a dedicated mailing list has a better signal to noise ratio. I'm already subscribed to more mailing lists than I'm able to read on a daily bases... About the working-group representative for FreeIPA, I'm probably the best candidate. I'm familiar with the community portal. For the next months I'm busy with another project, but I can spare one to two hours a week to give feedback. I also like to get started on the design process early. Some neessary features and changes belong in the FreeIPA core, e.g. password change or unique email addresses. I like to addresss the modifications in FreeIPA 4.4. Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 494] install: create kdcproxy user during server install
On 2015-09-23 12:40, Jan Cholasta wrote: > On 23.9.2015 11:44, Christian Heimes wrote: >> On 2015-09-23 10:54, Jan Cholasta wrote: >>>> Correction, the HTTP server works, but it spits lots of errors in >>>> error_log about /var/lib/kdcproxy not existing. >>>> >>>> Is the KDCProxy supposed to be installked/enabled on upgrade ? >>>> If not, why not ? >>>> Even if it is not enabled, shouldn't the user be created just in case ? >>> >>> Fixed, patch attached. >> >> I haven't tested the patch yet. It looks like the kdcproxy user doesn't >> own its home directory. Please chown /var/lib/kdcproxy. > > I can't chown it because the user may not exist at RPM install time. It > doesn't matter anyway, since nothing is ever stored in the directory and > KDC proxy works just fine. The same thing is done for the DS user and > nobody complained so far, so I assumed it should be OK for KDC proxy as > well. I think we have a slight misunderstanding here. :) Of course you can't set the owner at RPM install time. I wasn't talking about chown-ing the directory in RPM, but chown-ing the directory after or inside the tasks.create_system_user() call. Sorry for the confusion! AFAIK neither mod_wsgi nor python-kdcproxy need a writeable home directory. It's not guaranteed for eternity, though. Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 494] install: create kdcproxy user during server install
On 2015-09-23 10:54, Jan Cholasta wrote: >> Correction, the HTTP server works, but it spits lots of errors in >> error_log about /var/lib/kdcproxy not existing. >> >> Is the KDCProxy supposed to be installked/enabled on upgrade ? >> If not, why not ? >> Even if it is not enabled, shouldn't the user be created just in case ? > > Fixed, patch attached. I haven't tested the patch yet. It looks like the kdcproxy user doesn't own its home directory. Please chown /var/lib/kdcproxy. Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCH 0024] Handle timeout error in ipa-httpd-kdcproxy
The ipa-httpd-kdcproxy script now handles LDAP timeout errors correctly. A timeout does no longer result into an Apache startup error. https://fedorahosted.org/freeipa/ticket/5292 From 7ae756234534f0c6e750b5820733c6c5cb0682c6 Mon Sep 17 00:00:00 2001 From: Christian Heimes <chei...@redhat.com> Date: Thu, 10 Sep 2015 11:54:32 +0200 Subject: [PATCH] Handle timeout error in ipa-httpd-kdcproxy The ipa-httpd-kdcproxy script now handles LDAP timeout errors correctly. A timeout does no longer result into an Apache startup error. https://fedorahosted.org/freeipa/ticket/5292 --- install/tools/ipa-httpd-kdcproxy | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/install/tools/ipa-httpd-kdcproxy b/install/tools/ipa-httpd-kdcproxy index 60b22f2cc321d416871c74f3b4d580594c186a85..5e9863f8bd82e1628030b0b767a6697ab2a1d7bd 100755 --- a/install/tools/ipa-httpd-kdcproxy +++ b/install/tools/ipa-httpd-kdcproxy @@ -24,6 +24,7 @@ This script creates or removes the symlink from /etc/ipa/ipa-kdc-proxy.conf to /etc/httpd/conf.d/. It's called from ExecStartPre hook in httpd.service. """ import os +import socket import sys from ipalib import api, errors @@ -81,7 +82,7 @@ class KDCProxyConfig(object): # EXTERNAL bind as root user self.con.ldapi = True self.con.do_bind(timeout=self.time_limit) -except errors.NetworkError as e: +except (errors.NetworkError, socket.timeout) as e: msg = 'Unable to connect to dirsrv: %s' % e raise CheckError(msg) except errors.AuthorizationError as e: -- 2.4.3 signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0024] Handle timeout error in ipa-httpd-kdcproxy
On 2015-09-10 14:58, Rob Crittenden wrote: > Christian Heimes wrote: >> The ipa-httpd-kdcproxy script now handles LDAP timeout errors correctly. >> A timeout does no longer result into an Apache startup error. >> >> https://fedorahosted.org/freeipa/ticket/5292 >> >> >> >> > > > Since this is related to IPA not being configured yet would it make > sense to call ipaserver.install.installutils.is_ipa_configured() and > exit early and gracefully, doing no work, if it isn't? IMHO it should > happen before the api is initialized. That sounds like a very good idea! I didn't know about that API function. Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCHES] 0696-0710 More modernization
On 2015-08-21 12:55, Petr Viktorin wrote:
On 08/14/2015 07:44 PM, Petr Viktorin wrote:
Hello,
These patches bring IPA another step towards compatibility with Python 3.
Most of these were made by fixers from the python-modernize tool, but
I reviewed and edited the results.
Here are the patches rebased to current master.
0696.2-Remove-use-of-sys.exc_value
ACK
0697.2-Don-t-use-a-tuple-in-function-arguments
I prefer operator.itemgetter() over the hard-to-read lambda expression
key=lambda k_v: (k_v[1], k_v[0]).
import operator
example = dict(a=3, ba=2, b=2, c=1)
sorted(example.items(), key=operator.itemgetter(1, 0))
[('c', 1), ('b', 2), ('ba', 2), ('a', 3)]
0698.2-Add-python-six-to-dependencies
ACK
0699.2-Remove-the-unused-pygettext-script
ACK
0700.2-Use-six.string_types-instead-of-basestring
LGTM, but I need to have a closer look at some places.
I noticed a couple of asserts that should be if ... raise ValueError
instead. python -o disables asserts.
0701.2-Use-Python3-compatible-dict-method-names
NACK
Why are you replacing iteritems() with items() instead of using
six.iteritems()?
Please use sorted(reference) instead of sorted(reference.keys()),
set(tree) instead of set(tree.keys()) and list(somedict) instead of
list(somedict.keys()), too. The keys() call is unnecessary and frowned upon.
0702.2-Replace-filter-calls-with-list-comprehensions
In Python 2 list comprehensions leak the internal loop variable. It
might be better to write a generator expression with list() instead of
[] list comprehension.
0703.2-Use-six.moves.input-instead-of-raw_input
ACK
The code is fine, but pylint won't like it. For Dogtag I had to disable
pylint warnings W0622 and F0401.
0704.2-Use-six.integer_types-instead-of-long-int
ACK
hint: For type checks you can also use the numbers module.
0705.2-Replace-uses-of-map
See comment for 0702
706.2-Use-next-function-on-iterators
ACK
0707.2-Use-the-print-function
LGTM
There are too many chances to review. Let's hope the automatic
conversion tool did its job correctly.
0708.2-Use-new-style-raise-syntax
ACK
0709.2-Use-six.reraise
ACK
0710.2-Modernize-use-of-range
NACK
Please use six.moves.range. It defaults to xrange() in Python 2. I also
see a couple of additional opportunities for enumerate():
for i in range(len(kw['attrs'])):
kw['attrs'][i] = unicode(kw['attrs'][i])
for i, s in enumerate(kw['attrs']):
kw['attrs'][i] = unicode(s)
0711.2-Convert-zip-result-to-list
ACK
The code isn't beautiful but it's just a test.
signature.asc
Description: OpenPGP digital signature
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 023] Add flag to list all service and user vaults
On 2015-08-19 14:12, Jan Cholasta wrote:
The new flags should be handled in vault_find's pre_callback instead of
vault's get_dn, as they are exclusive to vault_find and worse yet,
conflict with vault_{add,remove}_{owner,member}'s flags, leading to
unwanted behavior:
$ ipa vault-add-member --service testsvc/example.com testvault
--services testsvc/example.com
ipa: ERROR: Service(s), shared, and user(s) options cannot be specified
simultaneously
Here is an updated patch. The new flags are now handled by the
pre_callback method. I have regenerated API.txt, too.
Christian
From a6eb87a73c1462a4de516f19b219b51e415852e5 Mon Sep 17 00:00:00 2001
From: Christian Heimes chei...@redhat.com
Date: Wed, 19 Aug 2015 13:32:01 +0200
Subject: [PATCH] Add flag to list all service and user vaults
The vault-find plugin has two additional arguments to list all
service vaults or user vaults. Since the name of a vault is only unique
for a particular user or service, the commands also print the vault user
or vault service. The virtual attributes were added in rev
01dd951ddc0181b559eb3dd5ff0336c81e245628.
Example:
$ ipa vault-find --users
2 vaults matched
Vault name: myvault
Type: standard
Vault user: admin
Vault name: UserVault
Type: standard
Vault user: admin
Number of entries returned 2
$ ipa vault-find --services
2 vaults matched
Vault name: myvault
Type: standard
Vault service: HTTP/ipatest.freeipa.local@FREEIPA.LOCAL
Vault name: myvault
Type: standard
Vault service: ldap/ipatest.freeipa.local@FREEIPA.LOCAL
Number of entries returned 2
https://fedorahosted.org/freeipa/ticket/5150
---
API.txt | 4 +++-
ipalib/plugins/vault.py | 48 +---
2 files changed, 36 insertions(+), 16 deletions(-)
diff --git a/API.txt b/API.txt
index 4d8d9dc3d3c38d4740bda3574396ecd85877b805..dd6bcc3c39895e6af213fcece85505fa0bd6d2f2 100644
--- a/API.txt
+++ b/API.txt
@@ -5508,7 +5508,7 @@ output: Output('result', type 'dict', None)
output: Output('summary', (type 'unicode', type 'NoneType'), None)
output: ListOfPrimaryKeys('value', None, None)
command: vault_find
-args: 1,13,4
+args: 1,15,4
arg: Str('criteria?', noextrawhitespace=False)
option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui')
option: Str('cn', attribute=True, autofill=False, cli_name='name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=False)
@@ -5518,10 +5518,12 @@ option: Flag('no_members', autofill=True, default=False, exclude='webui')
option: Flag('pkey_only?', autofill=True, default=False)
option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui')
option: Str('service?')
+option: Flag('services?', autofill=True, default=False)
option: Flag('shared?', autofill=True, default=False)
option: Int('sizelimit?', autofill=False, minvalue=0)
option: Int('timelimit?', autofill=False, minvalue=0)
option: Str('username?', cli_name='user')
+option: Flag('users?', autofill=True, default=False)
option: Str('version?', exclude='webui')
output: Output('count', type 'int', None)
output: ListOfEntries('result', (type 'list', type 'tuple'), Gettext('A list of LDAP entries', domain='ipa', localedir=None))
diff --git a/ipalib/plugins/vault.py b/ipalib/plugins/vault.py
index 712e2d5ddfa723eb84b80a261289a7cf1c75674f..83dc085b5aadb4e2878e29d17449f0808cc7a9c2 100644
--- a/ipalib/plugins/vault.py
+++ b/ipalib/plugins/vault.py
@@ -343,21 +343,11 @@ class vault(LDAPObject):
Generates vault DN from parameters.
-
service = options.get('service')
shared = options.get('shared')
user = options.get('username')
-count = 0
-if service:
-count += 1
-
-if shared:
-count += 1
-
-if user:
-count += 1
-
+count = (bool(service) + bool(shared) + bool(user))
if count 1:
raise errors.MutuallyExclusiveError(
reason=_('Service, shared, and user options ' +
@@ -387,8 +377,10 @@ class vault(LDAPObject):
parent_dn = DN(('cn', service), ('cn', 'services'), container_dn)
elif shared:
parent_dn = DN(('cn', 'shared'), container_dn)
-else:
+elif user:
parent_dn = DN(('cn', user), ('cn', 'users'), container_dn)
+else:
+raise RuntimeError
return DN(rdns, parent_dn)
@@ -814,7 +806,16 @@ class vault_del(LDAPDelete):
class vault_find(LDAPSearch):
__doc__ = _('Search for vaults.')
-takes_options = LDAPSearch.takes_options + vault_options
+takes_options = LDAPSearch.takes_options + vault_options + (
+Flag(
+'services?',
+doc
Re: [Freeipa-devel] [PATCH 019] Asymmetric vault: validate public key in client
On 2015-08-13 12:10, Petr Vobornik wrote: On 07/23/2015 08:38 PM, Christian Heimes wrote: The ipa vault commands now load the public keys in order to verify them. The validation also prevents a user from accidentally sending her private keys to the server. The patch fixes #5142 and #5142. $ ./ipa vault-add AsymmetricVault --desc Asymmetric vault --type asymmetric --public-key-file mykey.pem ipa: ERROR: invalid 'ipavaultpublickey': Invalid or unsupported vault public key: Could not unserialize key data. https://fedorahosted.org/freeipa/ticket/5142 https://fedorahosted.org/freeipa/ticket/5143 ACK as fix for 5142. I don't think that it fixes 5143. The traceback is fixed therefore 5143 doesn't occur but if there was other traceback raised by `self.api.Command.vault_archive(*args, **opts)` then the vault added in `response = self.api.Command.vault_add_internal(*args, **options)` would be still created. Yes, that is correct. There aren't any arguments that can lead to an exception. The arguments are either already validated by vault_add() or don't raise an error. Of course there are plenty of opportunities errors. The connection to the IPA or LDAP server could fail, NSS DB could be missing and so on. How should we handle an error in vault_archive? Is there another way then to delete the new vault all along? try: self.api.Command.vault_archive(*args, **opts) except Exception: log_error() self.api.Command.vault_del(*args, **opts) report_error() Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 019] Asymmetric vault: validate public key in client
On 2015-08-13 14:05, Petr Vobornik wrote: On 08/13/2015 12:38 PM, Christian Heimes wrote: On 2015-08-13 12:10, Petr Vobornik wrote: On 07/23/2015 08:38 PM, Christian Heimes wrote: The ipa vault commands now load the public keys in order to verify them. The validation also prevents a user from accidentally sending her private keys to the server. The patch fixes #5142 and #5142. $ ./ipa vault-add AsymmetricVault --desc Asymmetric vault --type asymmetric --public-key-file mykey.pem ipa: ERROR: invalid 'ipavaultpublickey': Invalid or unsupported vault public key: Could not unserialize key data. https://fedorahosted.org/freeipa/ticket/5142 https://fedorahosted.org/freeipa/ticket/5143 ACK as fix for 5142. I don't think that it fixes 5143. The traceback is fixed therefore 5143 doesn't occur but if there was other traceback raised by `self.api.Command.vault_archive(*args, **opts)` then the vault added in `response = self.api.Command.vault_add_internal(*args, **options)` would be still created. Yes, that is correct. There aren't any arguments that can lead to an exception. The arguments are either already validated by vault_add() or don't raise an error. Of course there are plenty of opportunities errors. The connection to the IPA or LDAP server could fail, NSS DB could be missing and so on. How should we handle an error in vault_archive? Is there another way then to delete the new vault all along? try: self.api.Command.vault_archive(*args, **opts) except Exception: log_error() self.api.Command.vault_del(*args, **opts) report_error() Christian Imho this is the way. But it may fail because of the same root cause as vault_archive. That said I don't see #5142 as a priority and would defer it. I'd still like to see my patch for #5142 in RHEL, too. It prevents accidental exposure of private keys, too. In the test case the test uploads his private keys to the server. FreeIPA should not leak a user's private key. My patch prevents that, too. signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCHES] 0691-0695 Modernization
On 2015-08-12 18:10, Tomas Babej wrote: On 08/10/2015 05:39 PM, Petr Viktorin wrote: On 08/03/2015 11:07 AM, Christian Heimes wrote: On 2015-07-31 19:14, Petr Viktorin wrote: Hello, Here is a batch of mostly mechanical changes: removing deprecated features to prepare for Python 3. Out of curiosity, what tool did you use for patch 695-absolute-imports? Python-modernize adds from __future__ import absolute_imports and changes imports to explicit relative imports. I used modernize to find all the occurences, and fixed imports by hand. Most of IPA uses absolute imports, as recommended by PEP 8. In patch 693 you have removed test cases for CIDict.has_key(), but CIDict still provides the function. You should either keep the tests around or remove has_key() from CIDict. I haven't removed them: test_haskey is only skipped under Python 3. I assumed that's enough to verify that `has_key` works well (i.e. the same as `in`), so in the other tests I do use `in` instead. I'm attaching updated patches, under Python 3 they remove CIDict.has_key a bit more formally. They're also rebased. The rest looks good to me, but I haven't studied every change thoroughly. It's just too much. Anything I can do to help? Let's not sit on this for too long, it will a pain to rebase. I went through the gargatuan patches manually and did not discover any issues. Additionally, the patchset introduces no new unit-test failures. So I am inclined to ACK it, unless Christian has any objections. I've skimmed over the patches and didn't find any issues, too. pylint --py3k is going to complain about missing from __future__ import absolute_import lines. We can add them later, though. Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCH 022] make-lint Python 3 porting mode
Python 3 porting mode for make-lint
http://docs.pylint.org/features.html#general-options
From eb0565a16934a85df5075a6389dc49239e08f699 Mon Sep 17 00:00:00 2001
From: Christian Heimes chei...@redhat.com
Date: Mon, 3 Aug 2015 11:18:03 +0200
Subject: [PATCH] make-lint Python 3 porting mode
pylint can check code for Python 3 portability. The new option --py3k
enables the Python 3 porting mode of pylint in make-lint.
---
make-lint | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/make-lint b/make-lint
index 0447985303f485a014fecf7d17d0b1c7eb6137bd..04d7f3644bef7fccba1ce37b9d92e2e1405ffd08 100755
--- a/make-lint
+++ b/make-lint
@@ -220,6 +220,8 @@ def main():
dest='fail', default=True, action='store_false')
optparser.add_option('--enable-noerror', help='enable warnings and other non-error messages',
dest='errors_only', default=True, action='store_false')
+optparser.add_option('--py3k', help='Python 3 porting mode',
+dest='py3k', default=False, action='store_true')
options, args = optparser.parse_args()
cwd = os.getcwd()
@@ -246,7 +248,10 @@ def main():
'{path}:{line}: [{msg_id}({symbol}), {obj}] {msg})')
linter.set_option('reports', False)
linter.set_option('persistent', False)
-linter.set_option('disable', 'python3')
+if options.py3k:
+linter.python3_porting_mode()
+else:
+linter.set_option('disable', 'python3')
linter.check(files)
--
2.4.3
signature.asc
Description: OpenPGP digital signature
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCHES] 0691-0695 Modernization
On 2015-07-31 23:14, Simo Sorce wrote: On Fri, 2015-07-31 at 19:14 +0200, Petr Viktorin wrote: Hello, Here is a batch of mostly mechanical changes: removing deprecated features to prepare for Python 3. Do we have accompanying lint (or similar) tests that will prevent new patches from reintroducing py3 incompatible syntax ? pylint has a Python 3 porting mode. That should help, see patch 022. Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 022] make-lint Python 3 porting mode
On 2015-08-03 11:30, Jan Cholasta wrote: Hi, Dne 3.8.2015 v 11:22 Christian Heimes napsal(a): Python 3 porting mode for make-lint http://docs.pylint.org/features.html#general-options I would rather wait until all the modernization patches are pulled in and then make the porting mode enabled by default. If it's optional, no one will use it. In porting mode the normal checkers aren't executed. In order to enable the porting mode by default, make-lint has to run two passes: one linter instance with and one linter instance without the porting mode. signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCHES] 0691-0695 Modernization
On 2015-07-31 19:14, Petr Viktorin wrote: Hello, Here is a batch of mostly mechanical changes: removing deprecated features to prepare for Python 3. Out of curiosity, what tool did you use for patch 695-absolute-imports? Python-modernize adds from __future__ import absolute_imports and changes imports to explicit relative imports. In patch 693 you have removed test cases for CIDict.has_key(), but CIDict still provides the function. You should either keep the tests around or remove has_key() from CIDict. The rest looks good to me, but I haven't studied every change thoroughly. It's just too much. Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCH 021] Validate vault's file parameters
The patch fixes the issue described in #5155 as well as a couple of more
potential issues. The vault plugin didn't catch IOError on multiple
occasions.
A user can pass file names for password, public and private key files to
the vault plugin. The plugin attempts to read from these files. If any
file can't be, an internal error was raised. The patch wraps all reads
and turns any IOError and UnicodeError into a ValidationError.
https://fedorahosted.org/freeipa/ticket/5155
From 71b3fcd6862bae2bfc6ea3e6fd38014ed77d4bac Mon Sep 17 00:00:00 2001
From: Christian Heimes chei...@redhat.com
Date: Thu, 30 Jul 2015 15:48:40 +0200
Subject: [PATCH] Validate vault's file parameters
A user can pass file names for password, public and private key files to
the vault plugin. The plugin attempts to read from these files. If any
file can't be, an internal error was raised. The patch wraps all reads
and turns any IOError and UnicodeError into a ValidationError.
https://fedorahosted.org/freeipa/ticket/5155
---
ipalib/plugins/vault.py | 59 +++--
1 file changed, 47 insertions(+), 12 deletions(-)
diff --git a/ipalib/plugins/vault.py b/ipalib/plugins/vault.py
index 81197f9328c7ed890fa336f464bfcda475ac6189..423df6b7c0e39c46b20561133be8cd54560bf8b9 100644
--- a/ipalib/plugins/vault.py
+++ b/ipalib/plugins/vault.py
@@ -19,6 +19,7 @@
import base64
import getpass
+import io
import json
import os
import sys
@@ -210,6 +211,33 @@ EXAMPLES:
ipa vault-remove-member name --users usernames
)
+
+def validated_read(argname, filename, mode='r', encoding=None):
+Read file and catch errors
+
+IOError and UnicodeError (for text files) are turned into a
+ValidationError
+
+try:
+with io.open(filename, mode=mode, encoding=encoding) as f:
+data = f.read()
+except IOError as exc:
+raise errors.ValidationError(
+name=argname,
+error=_(Cannot read file '%(filename)s': %(exc)s) % {
+'filename': filename, 'exc': exc[1]
+}
+)
+except UnicodeError as exc:
+raise errors.ValidationError(
+name=argname,
+error=_(Cannot decode file '%(filename)s': %(exc)s) % {
+'filename': filename, 'exc': exc
+}
+)
+return data
+
+
register = Registry()
@@ -591,8 +619,10 @@ class vault_add(PKQuery, Local):
pass
elif password_file:
-with open(password_file, 'rb') as f:
-password = f.read().rstrip('\n').decode('utf-8')
+password = validated_read('password-file',
+ password_file,
+ encoding='utf-8')
+password = password.rstrip('\n')
else:
password = self.obj.get_new_password()
@@ -611,8 +641,9 @@ class vault_add(PKQuery, Local):
pass
elif public_key_file:
-with open(public_key_file, 'rb') as f:
-public_key = f.read()
+public_key = validated_read('public-key-file',
+public_key_file,
+mode='rb')
# store vault public key
options['ipavaultpublickey'] = public_key
@@ -904,8 +935,7 @@ class vault_archive(PKQuery, Local):
reason=_('Input data specified multiple times'))
elif input_file:
-with open(input_file, 'rb') as f:
-data = f.read()
+data = validated_read('in', input_file, mode='rb')
elif not data:
data = ''
@@ -937,8 +967,10 @@ class vault_archive(PKQuery, Local):
pass
elif password_file:
-with open(password_file) as f:
-password = f.read().rstrip('\n').decode('utf-8')
+password = validated_read('password-file',
+ password_file,
+ encoding='utf-8')
+password = password.rstrip('\n')
else:
password = self.obj.get_existing_password()
@@ -1254,8 +1286,10 @@ class vault_retrieve(PKQuery, Local):
pass
elif password_file:
-with open(password_file) as f:
-password = f.read().rstrip('\n').decode('utf-8')
+password = validated_read('password-file',
+ password_file,
+ encoding='utf-8')
+password = password.rstrip('\n')
else:
password = self.obj.get_existing_password()
@@ -1277,8 +1311,9 @@ class vault_retrieve(PKQuery, Local):
pass
elif private_key_file
[Freeipa-devel] CLI parameter: TextFile, BinaryFile and mutually exclusive group
Hello,
While I was working on the ticket
https://fedorahosted.org/freeipa/ticket/5155, I noticed a couple of
additional places that may raise an IOError. Instead of a File()
paramaeter, the vault plugin uses Str() paramater in combination with
open() to read files.
For passwords I can mostly replace the Str() parameter with File().
There is only one minor issue. The File() class has no encoding flag.
ipalib.cli.cli.load_files() uses the encoding of sys.stdin to
determinate the encoding. In some cases the encoding of sys.stdin can be
ASCII. For that reason I like to add an encoding parameter to File().
For public and private key file I can't use File(). File() is a subclass
of Str(), which requires unicode text. The vault code treats public and
private key data as bytes. I assume it wants to support DER encoded key
data, too. I like to introduce a new BinaryFile() parameter, which
subclasses Bytes(). It might make sense to alias File as TextFile and
deprecate the File name.
Finally the vault plugin has several mutually exclusive paramater, e.g.
passsword and password-file. The plugin has seven distinct checks for
mutual exclusion. IMHO this should be better handled by the parameter
parsing code. Python's argparse module has a similar feature:
https://docs.python.org/2/library/argparse.html#mutual-exclusion
I like to handle the case with a mutually_exclusive flag such as:
Str(
'password?',
cli_name='password',
doc=_('Vault password'),
mutually_exclusive='password',
),
File(
'password_file?',
cli_name='password_file',
doc=_('File containing the vault password'),
mutually_exclusive='password',
),
If more than one parameter with the same mutually_exclusive group name
is given, then a MutuallyExclusiveError is raised.
Christian
signature.asc
Description: OpenPGP digital signature
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0002] Port from python-krbV to python-gssapi
On 2015-07-30 15:06, Michael Šimáček wrote: I didn't use ctypes, because it was advised against on this list: https://www.redhat.com/archives/freeipa-devel/2012-February/msg00268.html For the tests it's probably fine, but so is using klist. It would actually help a lot with getting the default realm name, but I'm afraid that the second point about problems with ctypes and SELinux in httpd still holds. Thanks for the pointer to Alexander's posting. I wasn't aware of any issues with ctypes and SELinux. I usually prefer Cython, C or cffi over ctypes myself. For simple tasks ctypes works good enough, though. python-kdcproxy uses ctypes bindings for libkrb5 to parse /etc/krb5.conf. It runs in mod_wsgi, too. I haven't seen or heard about issues with SELinux. Maybe the bug has been resolved? I'll keep an eye open. Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] CLI parameter: TextFile, BinaryFile and mutually exclusive group
On 2015-07-30 14:37, Jan Cholasta wrote:
Hi,
Dne 30.7.2015 v 14:07 Christian Heimes napsal(a):
Hello,
While I was working on the ticket
https://fedorahosted.org/freeipa/ticket/5155, I noticed a couple of
additional places that may raise an IOError. Instead of a File()
paramaeter, the vault plugin uses Str() paramater in combination with
open() to read files.
For passwords I can mostly replace the Str() parameter with File().
There is only one minor issue. The File() class has no encoding flag.
ipalib.cli.cli.load_files() uses the encoding of sys.stdin to
determinate the encoding. In some cases the encoding of sys.stdin can be
ASCII. For that reason I like to add an encoding parameter to File().
For public and private key file I can't use File(). File() is a subclass
of Str(), which requires unicode text. The vault code treats public and
private key data as bytes. I assume it wants to support DER encoded key
data, too. I like to introduce a new BinaryFile() parameter, which
subclasses Bytes(). It might make sense to alias File as TextFile and
deprecate the File name.
Finally the vault plugin has several mutually exclusive paramater, e.g.
passsword and password-file. The plugin has seven distinct checks for
mutual exclusion. IMHO this should be better handled by the parameter
parsing code. Python's argparse module has a similar feature:
https://docs.python.org/2/library/argparse.html#mutual-exclusion
I like to handle the case with a mutually_exclusive flag such as:
Str(
'password?',
cli_name='password',
doc=_('Vault password'),
mutually_exclusive='password',
),
File(
'password_file?',
cli_name='password_file',
doc=_('File containing the vault password'),
mutually_exclusive='password',
),
If more than one parameter with the same mutually_exclusive group name
is given, then a MutuallyExclusiveError is raised.
NACK, instead of having duplicate definitions for a single logical
parameter and dealing with their inherent mutual exclusiveness on the
framework level, this should be handled exclusively by the CLI by
generating multiple command line options for different dispositions of
the logical parameter. If anything, File should be completely removed,
not further extended, as it is inherently broken and never worked properly.
I have an almost working patch which implements this, but I don't think
it's 4.2.1 material, so I would suggest doing a simple fix for #5155 for
now.
I wasn't aware that you have a mostly working patch. In that case I'll
come up with a simple fix. I can take care of a redesign when your patch
has landed in the future.
Thanks for the feedback!
Christian
signature.asc
Description: OpenPGP digital signature
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 017] certprofile-import: do not require profileId in profile data
On 2015-07-24 12:41, Martin Basti wrote: On 24/07/15 05:15, Fraser Tweedale wrote: diff --git a/ipalib/plugins/certprofile.py b/ipalib/plugins/certprofile.py index 5550ed942521dbab2e783fba1570520268f9b378..fe8934690fe09499f0bacb6610d9815a2b4367a4 100644 --- a/ipalib/plugins/certprofile.py +++ b/ipalib/plugins/certprofile.py @@ -233,8 +233,8 @@ class certprofile_import(LDAPCreate): match = self.PROFILE_ID_PATTERN.search(options['file']) if match is None: -raise errors.ValidationError(name='file', -error=_(Profile ID is not present in profile data)) +# no profileId found, use CLI value as profileId. +options['file'] = u'profileId=%s\n%s' % (keys[0], options['file']) NACK This assignment has no external effect; `post_callback' is called with original `options['file']' and dogtag profile import can fail due to missing profileId. The solution is to do the same thing in post_callback; updated patch attached. Thanks, Fraser I dont like to have the same code twice in pre and post callback. Can you use contexmanager to store the right value in pre callback and then use it in post callback? (can find it in dns plugin, search for context) Sounds good to me! Christian PS: Context is a fancy name for a TLS dict. ;) From 1c7a67f331fb7d07f1e306e292e97b1df810958c Mon Sep 17 00:00:00 2001 From: Christian Heimes chei...@redhat.com Date: Thu, 23 Jul 2015 17:48:56 +0200 Subject: [PATCH] certprofile-import: do not require profileId in profile data certprofile-import no longer requires profileId in profile data. Instead the profile ID from the command line is taken and added to the profile data internally. If profileId is set in the profile, then it still has to match the CLI option. https://fedorahosted.org/freeipa/ticket/5090 --- ipalib/plugins/certprofile.py | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/ipalib/plugins/certprofile.py b/ipalib/plugins/certprofile.py index ae75d43d7412d0df7c09a33c16c833995d9a3fe4..658fbca3b4eb851eb5a22190c443044f6ceb8491 100644 --- a/ipalib/plugins/certprofile.py +++ b/ipalib/plugins/certprofile.py @@ -11,6 +11,7 @@ from ipalib.plugins.virtual import VirtualCommand from ipalib.plugins.baseldap import ( LDAPObject, LDAPSearch, LDAPCreate, LDAPDelete, LDAPUpdate, LDAPRetrieve) +from ipalib.request import context from ipalib import ngettext from ipalib.text import _ from ipapython.version import API_VERSION @@ -230,11 +231,12 @@ class certprofile_import(LDAPCreate): def pre_callback(self, ldap, dn, entry, entry_attrs, *keys, **options): ca_enabled_check() +context.profile = options['file'] match = self.PROFILE_ID_PATTERN.search(options['file']) if match is None: -raise errors.ValidationError(name='file', -error=_(Profile ID is not present in profile data)) +# no profileId found, use CLI value as profileId. +context.profile = u'profileId=%s\n%s' % (keys[0], context.profile) elif keys[0] != match.group(1): raise errors.ValidationError(name='file', error=_(Profile ID '%(cli_value)s' does not match profile data '%(file_value)s') @@ -250,7 +252,7 @@ class certprofile_import(LDAPCreate): try: with self.api.Backend.ra_certprofile as profile_api: -profile_api.create_profile(options['file']) +profile_api.create_profile(context.profile) profile_api.enable_profile(keys[0]) except: # something went wrong ; delete entry -- 2.4.3 signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0002] Port from python-krbV to python-gssapi
On 2015-07-29 10:09, Michael Šimáček wrote:
GSSAPI doesn't provide any method (that I'm aware of) to get default
ccache name. In most cases this is not needed as we can simply not pass
any name and it will use the default. The ldap plugin had to be adjusted
for this - the connect method now takes new use_gssapi argument, which
can turn on gssapi support without the need to supply explicit ccache
name. The only place where the ccache name is really needed is the test
server, where I use system klist command to obtain it.
You can use ctypes or cffi for the task, too. It's much faster and more
convenient. Here is a quick example how to use ctypes for the function
calls. kdcproxy uses similar code to parse /etc/krb5.conf.
import ctypes
LIBKRB5 = ctypes.CDLL('libkrb5.so.3')
ctx = ctypes.c_void_p()
ccache = ctypes.c_void_p()
LIBKRB5.krb5_init_context(ctypes.byref(ctx))
0
LIBKRB5.krb5_cc_default(ctx, ctypes.byref(ccache))
0
LIBKRB5.krb5_cc_get_type.restype = ctypes.c_char_p
LIBKRB5.krb5_cc_get_name.restype = ctypes.c_char_p
LIBKRB5.krb5_cc_get_type(ctx, ccache)
'KEYRING'
LIBKRB5.krb5_cc_get_name(ctx, ccache)
'persistent:1000:1000'
LIBKRB5.krb5_cc_close(ctx, ccache)
LIBKRB5.krb5_free_context(ctx)
If you like the approach I can write a more safe implementation with
proper error checking.
Christian
signature.asc
Description: OpenPGP digital signature
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCH 020] Change internal rsa_(public|private)_key variable names
In two places the vault plugin refers to rsa public or rsa private key although the code can handle just any kind of asymmetric algorithms, e.g. ECDSA. The patch just renames the occurences to avoid more confusion in the future. From 1b09967de50aa3c73a9fcab1ff11aa6d1800bae5 Mon Sep 17 00:00:00 2001 From: Christian Heimes chei...@redhat.com Date: Tue, 28 Jul 2015 16:12:40 +0200 Subject: [PATCH] Change internal rsa_(public|private)_key variable names In two places the vault plugin refers to rsa public or rsa private key although the code can handle just any kind of asymmetric algorithms, e.g. ECDSA. The patch just renames the occurences to avoid more confusion in the future. --- ipalib/plugins/vault.py | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/ipalib/plugins/vault.py b/ipalib/plugins/vault.py index 81197f9328c7ed890fa336f464bfcda475ac6189..a2b78f4dec143524d81a1a006733c22db0f90847 100644 --- a/ipalib/plugins/vault.py +++ b/ipalib/plugins/vault.py @@ -469,11 +469,11 @@ class vault(LDAPObject): return fernet.encrypt(data) elif public_key: -rsa_public_key = load_pem_public_key( +public_key_obj = load_pem_public_key( data=public_key, backend=default_backend() ) -return rsa_public_key.encrypt( +return public_key_obj.encrypt( data, padding.OAEP( mgf=padding.MGF1(algorithm=hashes.SHA1()), @@ -496,12 +496,12 @@ class vault(LDAPObject): elif private_key: try: -rsa_private_key = load_pem_private_key( +private_key_obj = load_pem_private_key( data=private_key, password=None, backend=default_backend() ) -return rsa_private_key.decrypt( +return private_key_obj.decrypt( data, padding.OAEP( mgf=padding.MGF1(algorithm=hashes.SHA1()), -- 2.4.3 signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 017] certprofile-import: do not require profileId in profile data
On 2015-07-24 05:15, Fraser Tweedale wrote: diff --git a/ipalib/plugins/certprofile.py b/ipalib/plugins/certprofile.py index 5550ed942521dbab2e783fba1570520268f9b378..fe8934690fe09499f0bacb6610d9815a2b4367a4 100644 --- a/ipalib/plugins/certprofile.py +++ b/ipalib/plugins/certprofile.py @@ -233,8 +233,8 @@ class certprofile_import(LDAPCreate): match = self.PROFILE_ID_PATTERN.search(options['file']) if match is None: -raise errors.ValidationError(name='file', -error=_(Profile ID is not present in profile data)) +# no profileId found, use CLI value as profileId. +options['file'] = u'profileId=%s\n%s' % (keys[0], options['file']) NACK This assignment has no external effect; `post_callback' is called with original `options['file']' and dogtag profile import can fail due to missing profileId. The solution is to do the same thing in post_callback; updated patch attached. Oh, I should have noticed that myself. The options parameter is passed in as **kwargs. The keyword arguments dict is always a flat copy. Thanks! Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] variable name 'rsa_public_key' in vault
Hello, while I was working on https://fedorahosted.org/freeipa/ticket/5142 and patch 019, I noticed the variable names rsa_public_key and rsa_private_key in vault.py. load_pem_public_key() can load and return other key formats (DSA, ECDSA), too. Does vault mean to support the other algorithms? In case vault should support any kind of asymmetric cipher, I'd like to change the variable names. It's confusing. Otherwise we should add a check for RSA and prevent DSA and ECDSA keys. Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCH 017] certprofile-import: do not require profileId in profile data
certprofile-import no longer requires profileId in profile data. Instead the profile ID from the command line is taken and added to the profile data internally. If profileId is set in the profile, then it still has to match the CLI option. https://fedorahosted.org/freeipa/ticket/5090 From 44212c91336f2dfbfdc1b6cefea3f928ba9074e9 Mon Sep 17 00:00:00 2001 From: Christian Heimes chei...@redhat.com Date: Thu, 23 Jul 2015 17:48:56 +0200 Subject: [PATCH] certprofile-import: do not require profileId in profile data certprofile-import no longer requires profileId in profile data. Instead the profile ID from the command line is taken and added to the profile data internally. If profileId is set in the profile, then it still has to match the CLI option. https://fedorahosted.org/freeipa/ticket/5090 --- ipalib/plugins/certprofile.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ipalib/plugins/certprofile.py b/ipalib/plugins/certprofile.py index 5550ed942521dbab2e783fba1570520268f9b378..fe8934690fe09499f0bacb6610d9815a2b4367a4 100644 --- a/ipalib/plugins/certprofile.py +++ b/ipalib/plugins/certprofile.py @@ -233,8 +233,8 @@ class certprofile_import(LDAPCreate): match = self.PROFILE_ID_PATTERN.search(options['file']) if match is None: -raise errors.ValidationError(name='file', -error=_(Profile ID is not present in profile data)) +# no profileId found, use CLI value as profileId. +options['file'] = u'profileId=%s\n%s' % (keys[0], options['file']) elif keys[0] != match.group(1): raise errors.ValidationError(name='file', error=_(Profile ID '%(cli_value)s' does not match profile data '%(file_value)s') -- 2.4.3 signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCH 018] certprofile-import: improve profile format documentation
The certprofile-import plugin expects a raw Dogtag config file. The XML
format is not supported. --help gives a hint about the correct file format.
https://fedorahosted.org/freeipa/ticket/5089
From 1344425af2886797ec9cef40a325e56a8d1752eb Mon Sep 17 00:00:00 2001
From: Christian Heimes chei...@redhat.com
Date: Thu, 23 Jul 2015 18:22:19 +0200
Subject: [PATCH] certprofile-import: improve profile format documentation
The certprofile-import plugin expects a raw Dogtag config file. The XML
format is not supported. --help gives a hint about the correct file format.
https://fedorahosted.org/freeipa/ticket/5089
---
ipalib/plugins/certprofile.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ipalib/plugins/certprofile.py b/ipalib/plugins/certprofile.py
index 5550ed942521dbab2e783fba1570520268f9b378..ae75d43d7412d0df7c09a33c16c833995d9a3fe4 100644
--- a/ipalib/plugins/certprofile.py
+++ b/ipalib/plugins/certprofile.py
@@ -220,7 +220,7 @@ class certprofile_import(LDAPCreate):
msg_summary = _('Imported profile %(value)s')
takes_options = (
File('file',
-label=_('Filename'),
+label=_('Filename of a raw profile. The XML format is not supported.'),
cli_name='file',
flags=('virtual_attribute',),
),
--
2.4.3
signature.asc
Description: OpenPGP digital signature
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCH 019] Asymmetric vault: validate public key in client
The ipa vault commands now load the public keys in order to verify them.
The validation also prevents a user from accidentally sending her
private keys to the server. The patch fixes #5142 and #5142.
$ ./ipa vault-add AsymmetricVault --desc Asymmetric vault --type
asymmetric --public-key-file mykey.pem
ipa: ERROR: invalid 'ipavaultpublickey': Invalid or unsupported vault
public key: Could not unserialize key data.
https://fedorahosted.org/freeipa/ticket/5142
https://fedorahosted.org/freeipa/ticket/5143
From fd380c4539fdd18a7d10786230c15a259b097af6 Mon Sep 17 00:00:00 2001
From: Christian Heimes chei...@redhat.com
Date: Thu, 23 Jul 2015 20:30:21 +0200
Subject: [PATCH] Asymmetric vault: validate public key in client
The ipa vault commands now load and validate the public key for
asymmetric encryption, before sending it to the server. This prevents
invalid vaults and prohibits accidental exposure of private key
material.
https://fedorahosted.org/freeipa/ticket/5142
https://fedorahosted.org/freeipa/ticket/5143
---
ipalib/plugins/vault.py | 13 +
1 file changed, 13 insertions(+)
diff --git a/ipalib/plugins/vault.py b/ipalib/plugins/vault.py
index 81197f9328c7ed890fa336f464bfcda475ac6189..5d493ae183da48412a38e7074b88ec0ab4402311 100644
--- a/ipalib/plugins/vault.py
+++ b/ipalib/plugins/vault.py
@@ -622,6 +622,19 @@ class vault_add(PKQuery, Local):
name='ipavaultpublickey',
error=_('Missing vault public key'))
+# validate public key and prevent users from accidentally
+# sending a private key to the server.
+try:
+load_pem_public_key(
+data=public_key,
+backend=default_backend()
+)
+except ValueError as e:
+raise errors.ValidationError(
+name='ipavaultpublickey',
+error=_('Invalid or unsupported vault public key: %s') % e,
+)
+
# create vault
response = self.api.Command.vault_add_internal(*args, **options)
--
2.4.3
signature.asc
Description: OpenPGP digital signature
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0014] [py3] Replace M2Crypto RC4 with python-cryptography ARC4
On 2015-07-23 11:06, Alexander Bokovoy wrote: On Thu, 23 Jul 2015, Christian Heimes wrote: This patch removes the dependency on M2Crypto in favor for cryptography. Cryptography is more strict about the key size and doesn't support non-standard key sizes: from M2Crypto import RC4 from ipaserver.dcerpc import arcfour_encrypt RC4.RC4(b'key').update(b'data') 'o\r@\x8c' arcfour_encrypt(b'key', b'data') Traceback (most recent call last): ... ValueError: Invalid key size (24) for RC4. Standard key sizes 40, 56, 64, 80, 128, 192 and 256 are supported: arcfour_encrypt(b'key12', b'data') '\xcd\xf80d' RC4.RC4(b'key12').update(b'data') '\xcd\xf80d' Note that we are using NTLMv2 or Kerberos user session keys which are 128 bit long in this context. And please rework the spec file change as Honza noted. Thanks for the feedback regarding the key size, 128bit works. Is RC4 really the only supported algorithm for session keys? RC4 is insecure, especially the first few bytes have a high bias. It may not be much of an issue for short-lived session keys, though. Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0014] [py3] Replace M2Crypto RC4 with python-cryptography ARC4
On 2015-07-23 10:54, Jan Cholasta wrote:
Hi,
Dne 23.7.2015 v 10:43 Christian Heimes napsal(a):
This patch removes the dependency on M2Crypto in favor for cryptography.
Cryptography is more strict about the key size and doesn't support
non-standard key sizes:
from M2Crypto import RC4
from ipaserver.dcerpc import arcfour_encrypt
RC4.RC4(b'key').update(b'data')
'o\r@\x8c'
arcfour_encrypt(b'key', b'data')
Traceback (most recent call last):
...
ValueError: Invalid key size (24) for RC4.
Standard key sizes 40, 56, 64, 80, 128, 192 and 256 are supported:
arcfour_encrypt(b'key12', b'data')
'\xcd\xf80d'
RC4.RC4(b'key12').update(b'data')
'\xcd\xf80d'
http://cryptography.readthedocs.org/en/latest/hazmat/primitives/symmetric-encryption/#cryptography.hazmat.primitives.ciphers.algorithms.ARC4
https://fedorahosted.org/freeipa/ticket/5148
NACK on the spec file change. There is a BuildRequires and Requires on
m2crypto, replace them with BuildRequires and Requires on
python-cryptography.
Argh, m2crypto ... I was looking for M2Crypto (case sensitive). Here is
an updated patch.
An additional Requires: python-cryptography is not required.
server-trust-ad depends on ipa-server which depends on the ipa-python
package. The ipa-python package already has Requires: python-cryptography.
Christian
From d0a6ab9f9c0723af7ca027fd3522a063428b7f34 Mon Sep 17 00:00:00 2001
From: Christian Heimes chei...@redhat.com
Date: Tue, 21 Jul 2015 15:18:40 +0200
Subject: [PATCH] [py3] Replace M2Crypto RC4 with python-cryptography ARC4
This patch removes the dependency on M2Crypto in favor for cryptography.
Cryptography is more strict about the key size and doesn't support
non-standard key sizes:
from M2Crypto import RC4
from ipaserver.dcerpc import arcfour_encrypt
RC4.RC4(b'key').update(b'data')
'o\r@\x8c'
arcfour_encrypt(b'key', b'data')
Traceback (most recent call last):
...
ValueError: Invalid key size (24) for RC4.
Standard key sizes 40, 56, 64, 80, 128, 192 and 256 are supported:
arcfour_encrypt(b'key12', b'data')
'\xcd\xf80d'
RC4.RC4(b'key12').update(b'data')
'\xcd\xf80d'
http://cryptography.readthedocs.org/en/latest/hazmat/primitives/symmetric-encryption/#cryptography.hazmat.primitives.ciphers.algorithms.ARC4
https://fedorahosted.org/freeipa/ticket/5148
---
freeipa.spec.in | 2 --
ipaserver/dcerpc.py | 15 ++-
2 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/freeipa.spec.in b/freeipa.spec.in
index fef20e1f7e6fde9b90851a2686e515a6a779f954..bf04582de949e6fe8ae34ea5a96f32598247aa7e 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -84,7 +84,6 @@ BuildRequires: python-lxml
BuildRequires: python-pyasn1 = 0.0.9a
BuildRequires: python-qrcode-core = 5.0.0
BuildRequires: python-dns = 1.11.1
-BuildRequires: m2crypto
BuildRequires: check
BuildRequires: libsss_idmap-devel
BuildRequires: libsss_nss_idmap-devel = 1.12.2
@@ -219,7 +218,6 @@ Integrated DNS server is BIND 9. OpenDNSSEC provides key management.
Summary: Virtual package to install packages required for Active Directory trusts
Group: System Environment/Base
Requires: %{name}-server = %version-%release
-Requires: m2crypto
Requires: samba-python
Requires: samba = %{samba_version}
Requires: samba-winbind
diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py
index 4de5afb540e880e8948749c2cfa9a019eb807c47..578b3ee209ee988bca4d75bd5b898f339625236c 100644
--- a/ipaserver/dcerpc.py
+++ b/ipaserver/dcerpc.py
@@ -42,7 +42,8 @@ from samba.ndr import ndr_pack, ndr_print
from samba import net
import samba
import random
-from M2Crypto import RC4
+from cryptography.hazmat.primitives.ciphers import Cipher, algorithms
+from cryptography.hazmat.backends import default_backend
try:
from ldap.controls import RequestControl as LDAPControl #pylint: disable=F0401
except ImportError:
@@ -120,6 +121,14 @@ def assess_dcerpc_exception(num=None,message=None):
message %(message)s (both may be None)''') % dict(num=num, message=message)
return errors.RemoteRetrieveError(reason=reason)
+
+def arcfour_encrypt(key, data):
+algorithm = algorithms.ARC4(key)
+cipher = Cipher(algorithm, mode=None, backend=default_backend())
+encryptor = cipher.encryptor()
+return encryptor.update(data)
+
+
class ExtendedDNControl(LDAPControl):
# This class attempts to implement LDAP control that would work
# with both python-ldap 2.4.x and 2.3.x, thus there is mix of properties
@@ -910,10 +919,6 @@ class TrustDomainInstance(object):
self.info['is_pdc'] = (result.role == lsa.LSA_ROLE_PRIMARY)
def generate_auth(self, trustdom_secret):
-def arcfour_encrypt(key, data):
-c = RC4.RC4(key)
-return c.update(data)
-
password_blob = string_to_array(trustdom_secret.encode('utf-16-le'))
clear_value = drsblobs.AuthInfoClear()
--
2.4.3
signature.asc
Description: OpenPGP digital signature
--
Manage your subscription
[Freeipa-devel] [PATCH 0014] [py3] Replace M2Crypto RC4 with python-cryptography ARC4
This patch removes the dependency on M2Crypto in favor for cryptography.
Cryptography is more strict about the key size and doesn't support
non-standard key sizes:
from M2Crypto import RC4
from ipaserver.dcerpc import arcfour_encrypt
RC4.RC4(b'key').update(b'data')
'o\r@\x8c'
arcfour_encrypt(b'key', b'data')
Traceback (most recent call last):
...
ValueError: Invalid key size (24) for RC4.
Standard key sizes 40, 56, 64, 80, 128, 192 and 256 are supported:
arcfour_encrypt(b'key12', b'data')
'\xcd\xf80d'
RC4.RC4(b'key12').update(b'data')
'\xcd\xf80d'
http://cryptography.readthedocs.org/en/latest/hazmat/primitives/symmetric-encryption/#cryptography.hazmat.primitives.ciphers.algorithms.ARC4
https://fedorahosted.org/freeipa/ticket/5148
From da4aa9baa932e335ad0bd0f3cfe2551667c7ca76 Mon Sep 17 00:00:00 2001
From: Christian Heimes chei...@redhat.com
Date: Tue, 21 Jul 2015 15:18:40 +0200
Subject: [PATCH] [py3] Replace M2Crypto RC4 with python-cryptography ARC4
This patch removes the dependency on M2Crypto in favor for cryptography.
Cryptography is more strict about the key size and doesn't support
non-standard key sizes:
from M2Crypto import RC4
from ipaserver.dcerpc import arcfour_encrypt
RC4.RC4(b'key').update(b'data')
'o\r@\x8c'
arcfour_encrypt(b'key', b'data')
Traceback (most recent call last):
...
ValueError: Invalid key size (24) for RC4.
Standard key sizes 40, 56, 64, 80, 128, 192 and 256 are supported:
arcfour_encrypt(b'key12', b'data')
'\xcd\xf80d'
RC4.RC4(b'key12').update(b'data')
'\xcd\xf80d'
http://cryptography.readthedocs.org/en/latest/hazmat/primitives/symmetric-encryption/#cryptography.hazmat.primitives.ciphers.algorithms.ARC4
https://fedorahosted.org/freeipa/ticket/5148
---
freeipa.spec.in | 1 +
ipaserver/dcerpc.py | 15 ++-
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/freeipa.spec.in b/freeipa.spec.in
index fef20e1f7e6fde9b90851a2686e515a6a779f954..afae22430515a9f15eced9e16e0a6e192400e6e2 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -150,6 +150,7 @@ Requires(preun): python systemd-units
Requires(postun): python systemd-units
Requires: python-dns = 1.11.1
Requires: python-kdcproxy = 0.3
+Requires: python-cryptography
Requires: zip
Requires: policycoreutils = 2.1.12-5
Requires: tar
diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py
index 4de5afb540e880e8948749c2cfa9a019eb807c47..578b3ee209ee988bca4d75bd5b898f339625236c 100644
--- a/ipaserver/dcerpc.py
+++ b/ipaserver/dcerpc.py
@@ -42,7 +42,8 @@ from samba.ndr import ndr_pack, ndr_print
from samba import net
import samba
import random
-from M2Crypto import RC4
+from cryptography.hazmat.primitives.ciphers import Cipher, algorithms
+from cryptography.hazmat.backends import default_backend
try:
from ldap.controls import RequestControl as LDAPControl #pylint: disable=F0401
except ImportError:
@@ -120,6 +121,14 @@ def assess_dcerpc_exception(num=None,message=None):
message %(message)s (both may be None)''') % dict(num=num, message=message)
return errors.RemoteRetrieveError(reason=reason)
+
+def arcfour_encrypt(key, data):
+algorithm = algorithms.ARC4(key)
+cipher = Cipher(algorithm, mode=None, backend=default_backend())
+encryptor = cipher.encryptor()
+return encryptor.update(data)
+
+
class ExtendedDNControl(LDAPControl):
# This class attempts to implement LDAP control that would work
# with both python-ldap 2.4.x and 2.3.x, thus there is mix of properties
@@ -910,10 +919,6 @@ class TrustDomainInstance(object):
self.info['is_pdc'] = (result.role == lsa.LSA_ROLE_PRIMARY)
def generate_auth(self, trustdom_secret):
-def arcfour_encrypt(key, data):
-c = RC4.RC4(key)
-return c.update(data)
-
password_blob = string_to_array(trustdom_secret.encode('utf-16-le'))
clear_value = drsblobs.AuthInfoClear()
--
2.4.3
signature.asc
Description: OpenPGP digital signature
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCH 016] Require Dogtag PKI = 10.2.6
Dogtag 10.2.6 comes with two fixes for cloning from 9.x to 10.x
instances:
https://fedorahosted.org/pki/ticket/1495
https://fedorahosted.org/pki/ticket/1488
https://fedorahosted.org/freeipa/ticket/5140
https://fedorahosted.org/freeipa/ticket/5129
From a8e806816b207f242e2fc7b3fe02a961ade68d84 Mon Sep 17 00:00:00 2001
From: Christian Heimes chei...@redhat.com
Date: Thu, 23 Jul 2015 12:20:49 +0200
Subject: [PATCH] Require Dogtag PKI = 10.2.6
Dogtag 10.2.6 comes with two fixes for cloning from 9.x to 10.x
instances:
https://fedorahosted.org/pki/ticket/1495
https://fedorahosted.org/pki/ticket/1488
https://fedorahosted.org/freeipa/ticket/5140
https://fedorahosted.org/freeipa/ticket/5129
---
freeipa.spec.in | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/freeipa.spec.in b/freeipa.spec.in
index 928425fdc65a092f67a28d97101c32b7392bf1c8..f365d105211a9f8db772c14ef5a56cdbf11d031f 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -99,7 +99,7 @@ BuildRequires: python-backports-ssl_match_hostname
BuildRequires: softhsm-devel = 2.0.0rc1-1
BuildRequires: openssl-devel
BuildRequires: p11-kit-devel
-BuildRequires: pki-base = 10.2.5
+BuildRequires: pki-base = 10.2.6
BuildRequires: python-pytest-multihost = 0.5
BuildRequires: python-pytest-sourceorder
BuildRequires: python-kdcproxy = 0.3
@@ -144,8 +144,8 @@ Requires(post): systemd-units
Requires: selinux-policy = %{selinux_policy_version}
Requires(post): selinux-policy-base
Requires: slapi-nis = 0.54.2-1
-Requires: pki-ca = 10.2.5
-Requires: pki-kra = 10.2.5
+Requires: pki-ca = 10.2.6
+Requires: pki-kra = 10.2.6
Requires(preun): python systemd-units
Requires(postun): python systemd-units
Requires: python-dns = 1.11.1
--
2.4.3
signature.asc
Description: OpenPGP digital signature
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0085] Limit request sizes to /KdcProxy
On 2015-07-22 20:23, Nathaniel McCallum wrote: Related: CVE-2015-5159 https://bugzilla.redhat.com/show_bug.cgi?id=1245200 The patch prevents a flood attack but I consider more a workaround than a solution. I'll update kdcproxy tomorrow. Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0085] Limit request sizes to /KdcProxy
On 2015-07-22 20:38, Nathaniel McCallum wrote: On Wed, 2015-07-22 at 20:34 +0200, Christian Heimes wrote: On 2015-07-22 20:23, Nathaniel McCallum wrote: Related: CVE-2015-5159 https://bugzilla.redhat.com/show_bug.cgi?id=1245200 The patch prevents a flood attack but I consider more a workaround than a solution. I'll update kdcproxy tomorrow. The problem is that while we can provide a sane default, special applications might require different sizes (either smaller or larger). I think this fix is acceptable since it keeps the solution entirely within the configuration domain. The python-kdcproxy package may be used by other parties with different web servers. I also like to see a countermeasure in kdcproxy. Other installations should not fall victim to the same issue. How about we set the default maximum size to a rather large value (like 5 or 10 MB) and make it configurable in kdcproxy.conf? 5 MB is very, very large for a Kerberos request but still prevents DoS and OOM killer Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
