Re: [Freeipa-devel] Don't work with Pagure right now

[Standa Laznicka]

On 05/12/2017 08:36 AM, Standa Laznicka wrote:

Hello,

This morning I found out that "https://pagure.io/freeipa/; resolves to 
a different project, originally https://pagure.io/freeIPA/. I pointed 
the problem to the developer of the system, we'll see what he can do 
about it, but for now, we're missing about 200 issues.


Please, don't open any new issues, as that's just pointless and would 
only cause us problems as these would need to be merged back to our 
project (should it be recoverable, which I hope it should).


Luckily enough, `git clone https://g...@pagure.io/freeipa.git` seemed 
to have resolved to the correct repo so our git repos should hopefully 
not be affected.


Sorry for inconvenience,
Standa


Hopefully everything is back on track now.

--
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] Don't work with Pagure right now

[Standa Laznicka]

Hello,

This morning I found out that "https://pagure.io/freeipa/; resolves to a 
different project, originally https://pagure.io/freeIPA/. I pointed the 
problem to the developer of the system, we'll see what he can do about 
it, but for now, we're missing about 200 issues.


Please, don't open any new issues, as that's just pointless and would 
only cause us problems as these would need to be merged back to our 
project (should it be recoverable, which I hope it should).


Luckily enough, `git clone https://g...@pagure.io/freeipa.git` seemed to 
have resolved to the correct repo so our git repos should hopefully not 
be affected.


Sorry for inconvenience,
Standa

--
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] "blocker" tag for pull request

[Standa Laznicka]

On 04/28/2017 02:41 PM, Martin Bašti wrote:




On 28.04.2017 14:17, Tomas Krizek wrote:

On 04/28/2017 10:15 AM, Petr Vobornik wrote:

Hi all,

I created "blocker" tag for FreeIPA Git Hub PRs.

It is should be used to mark PRs which solves test blocker or other
functional blockers - e.g. blocks creation of demo. I.e. should be
used rather rarely.

I don't like the tag name, but I couldn't find better.

I think we could use the name "high-priority". It could have other uses
besides marking a blocker, e.g. requesting prompt execution of tests in
PR CI.

Sounds good or maybe "prioritized", IMHO "blocker" word is overused.


Note: blocker priority in pagure doesn't imply blocker tag in PR. But
testblocker tag in pagure does. Actually I'm thinking about changing
Pagure priority names to: "highest, high, medium, low, patchwelcome"


+1, but I'd prefer "critical" instead of "highest"




+1 for critical

pyldap uses "help wanted" instead "patchwelcome", it sounds better to 
me. I'd use it as separate tag instead of priority. Even high 
prioritized issues can be made by contributors in early phase of 
development if they are easy enough.


Martin^2
--
Martin Bašti
Software Engineer
Red Hat Czech



+1 for critical;

+1 for "help wanted", reasons:

- "patchwelcome" sounds strange, and strange is an understatement here 
(also, are you afraid of 2 word tags?)


- "help wanted" is much more humble, "patches welcome" is a common cry 
when you just don't care enough to fix it yourself, and I don't believe 
that's the message we want to be sending outside


-- 
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] Pagure issue template

[Standa Laznicka]

On 04/21/2017 08:12 AM, Abhijeet Kasurde wrote:

+1

On 20/04/17 9:36 PM, Petr Vobornik wrote:

Hi all,

I'd like to improve quality of bug reports and RFEs.

A possibility I see is to create and issue template [1].

Sounds like a good idea! Please see my comments.


What do you think of the following template? Should we use it?


### Request for enhancement
As  , I want  so that .

This sounds very labored. How about using:
"I am a  and I want ..."


### Bug
 What doesn't work (what was the goal)
"What's not working" proposes the situation will change and 
sounds better IMO



 Steps to Reproduce

 Actual results

 Expected results

 Version/Release/Distribution
   $ rpm -q freeipa-server ipa-server 389-ds-base pki-ca krb5-server

 Additional info:





1.  Can we add pre-defined set of components in title ? for example,

[CERT] some_cert_related bug description
[installer] some installer related bug description
This is what Pagure has tags for. But you're right we might be missing 
some, although "CERT" is probably not a good example, installer is. On 
the other hand, "userstory" is a tag I will myself never use on purpose.


2. Also, Having a bot in place which will enforce or atleast suggest 
reporter to modify bug report.



[1] https://docs.pagure.org/pagure/usage/ticket_templates.html



My hope is that the issue template should do itself.

For the record, I love the way Atom guides you through their issue 
creation: https://github.com/atom/atom/issues/new.


--
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] [DRAFT] Release notes FreeIPA 4.5.0

[Standa Laznicka]

On 03/14/2017 08:42 PM, Rob Crittenden wrote:

Standa Laznicka wrote:

On 03/14/2017 04:21 PM, Rob Crittenden wrote:

Standa Laznicka wrote:

On 03/14/2017 03:14 PM, Martin Basti wrote:

On 14.03.2017 14:56, Luc de Louw wrote:

My 3 cents...

"Please note that FIPS 140-2 support may not work on some platforms"

-> Does is work in Fedora? Should be worth mention it so people are
more encouraged to test it in Fedora before its getting to RHEL 7.4

Thanks,

Luc

We cannot guarantee that FIPS mode will work with fedora, any package
update may break it.

Fedora itself is not capable of running in FIPS mode so there's no point
adding it there.

I can't believe this is correct. Did you try it and it failed? Did you
file bugs?

Yes, yes and no. Please see the header at this page:
https://fedoraproject.org/wiki/FedoraCryptoConsolidation

Um, ok? What do shared certs and centralized crypto policies have to do
with FIPS not working in Fedora?
It was the only document I found really mentioning FIPS by the time. 
There are no instructions how to set Fedora to FIPS mode so we used the 
RHEL guidelines and the boot failed but the instructions do not 
necessarily have to work for Fedora.

We tried to set up Fedora for FIPS in RHEV but the machine would not
even start.

Fedora 25 works for me in libvirt.

crypto.fips_enabled is 1.

It is enforcing it too, md5sum fails because FIPS is enabled.

So if it isn't working for you then bugs are required.

rob


The dracut-fips and dracut-fips-aesni packages are both available.
I will check dracut-fips on my earliest convenience, I did not notice it 
when we started working on FIPS for FreeIPA, thanks.


# cat /etc/redhat-release
Fedora release 25 (Twenty Five)
# sysctl crypto.fips_enabled
crypto.fips_enabled = 0

So the basic stuff is there and the kernel knows what FIPS is.

Any NSS-based application can enable FIPS-mode independently of the
kernel via modutil or application-specific settings (e.g. NSSFIPS in
mod_nss).

rob




--
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] [DRAFT] Release notes FreeIPA 4.5.0

[Standa Laznicka]

On 03/14/2017 04:21 PM, Rob Crittenden wrote:

Standa Laznicka wrote:

On 03/14/2017 03:14 PM, Martin Basti wrote:

On 14.03.2017 14:56, Luc de Louw wrote:

My 3 cents...

"Please note that FIPS 140-2 support may not work on some platforms"

-> Does is work in Fedora? Should be worth mention it so people are
more encouraged to test it in Fedora before its getting to RHEL 7.4

Thanks,

Luc

We cannot guarantee that FIPS mode will work with fedora, any package
update may break it.

Fedora itself is not capable of running in FIPS mode so there's no point
adding it there.

I can't believe this is correct. Did you try it and it failed? Did you
file bugs?

Yes, yes and no. Please see the header at this page:
https://fedoraproject.org/wiki/FedoraCryptoConsolidation

We tried to set up Fedora for FIPS in RHEV but the machine would not 
even start.


The dracut-fips and dracut-fips-aesni packages are both available.

# cat /etc/redhat-release
Fedora release 25 (Twenty Five)
# sysctl crypto.fips_enabled
crypto.fips_enabled = 0

So the basic stuff is there and the kernel knows what FIPS is.

Any NSS-based application can enable FIPS-mode independently of the
kernel via modutil or application-specific settings (e.g. NSSFIPS in
mod_nss).

rob



--
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] [DRAFT] Release notes FreeIPA 4.5.0

[Standa Laznicka]

On 03/14/2017 03:14 PM, Martin Basti wrote:

On 14.03.2017 14:56, Luc de Louw wrote:

My 3 cents...

"Please note that FIPS 140-2 support may not work on some platforms"

-> Does is work in Fedora? Should be worth mention it so people are
more encouraged to test it in Fedora before its getting to RHEL 7.4

Thanks,

Luc

We cannot guarantee that FIPS mode will work with fedora, any package
update may break it.
Fedora itself is not capable of running in FIPS mode so there's no point 
adding it there.



On 03/14/2017 02:50 PM, Jakub Hrozek wrote:

On Tue, Mar 14, 2017 at 01:51:19PM +0100, Martin Basti wrote:

Hello,

DRAFT for FreeIPA 4.5.0 release notes is ready
http://www.freeipa.org/page/Releases/4.5.0

Please update/let me know what is missing, what is extra.

Please update this paragraph:

AD User Short Names

Support for AD users short names has been added. Short
names can be enabled from CLI by setting ipa config-mod
--domain-resolution-order="domain.test:ad.domain1.test:ad.domain2.test"
or from WebUI under Configuration tab. No manual configuration on SSSD
side is required.


With a note that this feature is not supported by SSSD yet and the work
is tracked with https://pagure.io/SSSD/sssd/issue/3210



--
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] gssproxy-0.6.2-2 broken

[Standa Laznicka]

Hello,

Current gssproxy in Fedora 25 "updates" repository (gssproxy-0.6.2-2) is 
broken. For a freshly-installed IPA server, the infamous error


"ipa: ERROR: Major (851968): Unspecified GSS failure.  Minor code may 
provide more information, Minor (2598845123): No credentials cache 
found" will appear. 100% reproducible.


Please use the gssproxy-0.6.2-1 from @freeipa/freeipa-master repository 
instead. Note that downgrade + gssproxy service restart works.


Cheers,
Standa

--
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: upgrading from priv-separation to git-master

[Standa Laznicka]

On 03/01/2017 12:01 PM, Standa Laznicka wrote:

Hello,

Please note that https://github.com/freeipa/freeipa/pull/367 was 
pushed today. What this means for you is that your IPA installations 
won't work if you had privilege separation patches applied and try to 
upgrade your instances to current master.


This is because privilege separation moved the Dogtag agent 
certificate but we had to move it as well keeping in mind that users 
will be upgrading from pre-priv-sep installation to this one.


Sorry for the inconvenience,
Standa


Note I also updated the http://www.freeipa.org/page/Testing guide.

--
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] Certmonger uses different "Subject" representation based on storage

[Standa Laznicka]

Hello,

Please note that when you make a request for a certificate to 
certmonger, it uses different representation of the "Subject" that you 
provide to it, based on the storage you aim for (LDAP representation 
when storing to NSS DB, X509 representation when storing to a file).


This issue was worked around in 
https://github.com/freeipa/freeipa/commit/595f9b64e31dc9e4f035119e834db7e6cb152dce 
for FreeIPA and a ticket was created in Pagure: 
https://pagure.io/certmonger/issue/62 (you can read more thorough 
description there).


Happy coding,
Standa
-- 
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] FreeIPA: upgrading from priv-separation to git-master

[Standa Laznicka]

Hello,

Please note that https://github.com/freeipa/freeipa/pull/367 was pushed 
today. What this means for you is that your IPA installations won't work 
if you had privilege separation patches applied and try to upgrade your 
instances to current master.


This is because privilege separation moved the Dogtag agent certificate 
but we had to move it as well keeping in mind that users will be 
upgrading from pre-priv-sep installation to this one.


Sorry for the inconvenience,
Standa

--
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] MD5 certificate fingerprints removal

[Standa Laznicka]

On 02/24/2017 08:29 AM, Jan Cholasta wrote:

On 23.2.2017 19:06, Martin Basti wrote:



On 23.02.2017 15:09, Tomas Krizek wrote:

On 02/22/2017 01:44 PM, Fraser Tweedale wrote:

On Wed, Feb 22, 2017 at 01:41:22PM +0100, Tomas Krizek wrote:

On 02/22/2017 12:28 AM, Fraser Tweedale wrote:

On Tue, Feb 21, 2017 at 05:23:07PM +0100, Standa Laznicka wrote:

On 02/21/2017 04:24 PM, Tomas Krizek wrote:

On 02/21/2017 03:23 PM, Rob Crittenden wrote:

Standa Laznicka wrote:

Hello,

Since we're trying to make FreeIPA work in FIPS we got to the 
point
where we need to do something with MD5 fingerprints in the 
cert plugin.
Eventually we came to a realization that it'd be best to get 
rid of them
as a whole. These are counted by the framework and are not 
stored
anywhere. Note that alongside with these fingerprints SHA1 
fingerprints

are also counted and those are there to stay.

The question for this ML is, then - is it OK to remove these 
or would
you rather have them replaced with SHA-256 alongside the 
SHA-1? MD5 is a

grandpa and I think it should go.
I based the values displayed on what certutil displayed at the 
time (7

years ago). I don't know that anyone uses these fingerprints. The
OpenSSL equivalent doesn't include them by default.

You may be able to deprecate fingerprints altogether.

rob
I think it's useful to display the certificate's fingerprint. 
I'm in

favor of removing md5 and adding sha256 instead.

Rob, thank you for sharing the information of where the cert 
fingerprints
are originated! `certutil` shipped with nss-3.27.0-1.3 currently 
displays
SHA-256 and SHA1 fingerprints for certificates so I propose 
going that way

too.


IMO we should remove MD5 and SHA-1, and add SHA-256. But we should
also make no API stability guarantee w.r.t. the fingerprint
attributes, i.e. to allow us to move to newer digests in future (and
remove broken/no-longer-secure ones).  We should advise that if a
customer has a hard requirement on a particular digest that they
should compute it themselves from the certificate.

Cheers,
Fraser

What is the motivation to remove SHA-1? Are there any attacks besides
theoretical ones on SHA-1?

Do other libraries already deprecate SHA-1?


Come to think of it, I was thinking about SHA-1 signatures (which
are completely forbidden in the public PKI nowadays).  But for
fingerprints it is not so bad (for now).

Thanks,
Fraser

Actually, there's been a practical SHA1 attack just published [1].
Computational complexity was
9,223,372,036,854,775,808 SHA1 computations, which takes about 110 
years

on a single GPU.

Therefore, I'm in favor to deprecate SHA1 as well and provide only 
SHA256.


[1] - https://shattered.io/





I think we should wait with removal SHA1, don't remove it prematurely.
As MD5 is deprecated for very long time, SHA1 is not and we are not
using it for any cryptographic operation nor certificates. It is just
informational fingerprint.


+1

+1, I don't favour the 
http://new2.fjcdn.com/gifs/Everybody_d72014_61779.gif approach.


--
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] MD5 certificate fingerprints removal

[Standa Laznicka]

On 02/22/2017 12:28 AM, Fraser Tweedale wrote:

On Tue, Feb 21, 2017 at 05:23:07PM +0100, Standa Laznicka wrote:

On 02/21/2017 04:24 PM, Tomas Krizek wrote:

On 02/21/2017 03:23 PM, Rob Crittenden wrote:

Standa Laznicka wrote:

Hello,

Since we're trying to make FreeIPA work in FIPS we got to the point
where we need to do something with MD5 fingerprints in the cert plugin.
Eventually we came to a realization that it'd be best to get rid of them
as a whole. These are counted by the framework and are not stored
anywhere. Note that alongside with these fingerprints SHA1 fingerprints
are also counted and those are there to stay.

The question for this ML is, then - is it OK to remove these or would
you rather have them replaced with SHA-256 alongside the SHA-1? MD5 is a
grandpa and I think it should go.

I based the values displayed on what certutil displayed at the time (7
years ago). I don't know that anyone uses these fingerprints. The
OpenSSL equivalent doesn't include them by default.

You may be able to deprecate fingerprints altogether.

rob

I think it's useful to display the certificate's fingerprint. I'm in
favor of removing md5 and adding sha256 instead.


Rob, thank you for sharing the information of where the cert fingerprints
are originated! `certutil` shipped with nss-3.27.0-1.3 currently displays
SHA-256 and SHA1 fingerprints for certificates so I propose going that way
too.


IMO we should remove MD5 and SHA-1, and add SHA-256.  But we should
also make no API stability guarantee w.r.t. the fingerprint
attributes, i.e. to allow us to move to newer digests in future (and
remove broken/no-longer-secure ones).  We should advise that if a
customer has a hard requirement on a particular digest that they
should compute it themselves from the certificate.

Cheers,
Fraser


That's something I would like but am not sure whether we can just go 
ahead and do. I, personally, wouldn't mind it.


--
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] MD5 certificate fingerprints removal

[Standa Laznicka]

On 02/21/2017 04:24 PM, Tomas Krizek wrote:

On 02/21/2017 03:23 PM, Rob Crittenden wrote:

Standa Laznicka wrote:

Hello,

Since we're trying to make FreeIPA work in FIPS we got to the point
where we need to do something with MD5 fingerprints in the cert plugin.
Eventually we came to a realization that it'd be best to get rid of them
as a whole. These are counted by the framework and are not stored
anywhere. Note that alongside with these fingerprints SHA1 fingerprints
are also counted and those are there to stay.

The question for this ML is, then - is it OK to remove these or would
you rather have them replaced with SHA-256 alongside the SHA-1? MD5 is a
grandpa and I think it should go.

I based the values displayed on what certutil displayed at the time (7
years ago). I don't know that anyone uses these fingerprints. The
OpenSSL equivalent doesn't include them by default.

You may be able to deprecate fingerprints altogether.

rob

I think it's useful to display the certificate's fingerprint. I'm in
favor of removing md5 and adding sha256 instead.

Rob, thank you for sharing the information of where the cert 
fingerprints are originated! `certutil` shipped with nss-3.27.0-1.3 
currently displays SHA-256 and SHA1 fingerprints for certificates so I 
propose going that way too.


--
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] MD5 certificate fingerprints removal

[Standa Laznicka]

Hello,

Since we're trying to make FreeIPA work in FIPS we got to the point 
where we need to do something with MD5 fingerprints in the cert plugin. 
Eventually we came to a realization that it'd be best to get rid of them 
as a whole. These are counted by the framework and are not stored 
anywhere. Note that alongside with these fingerprints SHA1 fingerprints 
are also counted and those are there to stay.


The question for this ML is, then - is it OK to remove these or would 
you rather have them replaced with SHA-256 alongside the SHA-1? MD5 is a 
grandpa and I think it should go.


Standa

--
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] Password generation in FreeIPA Python modules

[Standa Laznicka]

Hello,

Please don't use any ad-hoc cruft when generating passwords throughout 
IPA if not really really necessary. We have a nice refreshed password 
generator `ipapython.ipautil.ipa_generate_password()` default config of 
which does the work for you. It also by default generates passwords 
compatible with NSS requirements for FIPS (see 
https://dxr.mozilla.org/nss/source/nss/lib/softoken/fipstokn.c#97 for 
details).


Thanks!
Standa

--
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] Changed SSH public key fingerprint to SHA256

[Standa Laznicka]

Hello list,

In PR https://github.com/freeipa/freeipa/pull/385 we changed the hashing 
algorithm for SSH public key fingerprints which are printed for 
hosts/users in their respective show commands. These fingerprints are 
not stored anywhere and are calculated during runtime on demand.


We did the mentioned change to move from MD5 use of which breaks IPA in 
FIPS. Also, SHA256 (along with MD5) fingerprints are now printed by 
default in Fedora 25 when trying to connect to a new host via ssh.


If you think this could break some use-case, please, share your concern.

Have a nice day,
Standa

--
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

[Standa Laznicka]

On 12/19/2016 03:07 PM, John Dennis wrote:

On 12/19/2016 03:12 AM, Standa Laznicka wrote:

On 12/16/2016 03:23 PM, Rob Crittenden wrote:

Standa Laznicka wrote:

Hello,

I started a design page for FreeIPA on FIPS-enabled systems:
https://www.freeipa.org/page/V4/FreeIPA-on-FIPS

Me and Tomáš are still investigating what of all things will need to
change in order to have FreeIPA on FIPS-enabled RHEL. So far I managed
to install and run patched FreeIPA server and client and connect them
together.

There are some issues with NSS when trying to create an HTTPS request
(apparently, NSS requires an NSS database password to set up an SSL
connection). I am actually thinking of removing NSSConnection from the
client altogether.

Can you expand on this a bit? NSS should only need a pin when it needs
access to a private key. What connection(s) are you talking about, and
what would you replace NSSConnection with?

rob


Hello Rob,

Thank you for this excellent question, in order to cut the email short I
seem to have omitted quite a few information.

One of the very first problems I had with FreeIPA with FIPS was that NSS
was always asking for password/pin. I was discussing this with the NSS
guys on their IRC chat last week and it turns out that NSS tries to
create a private key every time you want to use it as a backend for an
SSL connection on FIPS. I still don't think this is quite right so I may
open a bugzilla for that.


I don't understand, I thought the case you were having problems with 
was the FreeIPA client, not the server. I assume when you use the term 
"backend" you mean server, and yes when NSS is in server mode it will 
access to keys. So isn't the problem NSS is not being initialized 
correctly so that it recognizes it is in client mode and not server mode?


What I meant was "a client backend for an SSL connection" - we're using 
NSS implementation of SSL (via python-nss) for HTTPS connections from 
client to server during which we're getting a CA cert from an NSS 
database but this eventually leads to a password prompt.


Anyway, the guys suggested me that we could try to create the database
with an empty password and everything will work. I don't quite like
that, too, but it's at least something if you don't want the `ipa`
command to always bug you for password you have no way knowing if you're
just a regular user.

What I think would be a better way to go is to use
httplib.HTTPSConnection. We have the needed certificates in
/etc/ipa/ca.crt anyway so why not use them instead. We had a discussion
with Honza this morning and it seems that with this approach we may get
rid of the NSSConnection class altogether (although I still need to
check a few spots) and start the process of moving away from NSS which
was discussed some year ago in an internal mailing list (for some 
reason).


Will be happy to hear thoughts on this,
Standa


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.


I'm sorry I generalized too much, the original topic was moving away 
from python-nss (of which I am even more sorry as you're the author).


--
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

[Standa Laznicka]

On 12/16/2016 03:23 PM, Rob Crittenden wrote:

Standa Laznicka wrote:

Hello,

I started a design page for FreeIPA on FIPS-enabled systems:
https://www.freeipa.org/page/V4/FreeIPA-on-FIPS

Me and Tomáš are still investigating what of all things will need to
change in order to have FreeIPA on FIPS-enabled RHEL. So far I managed
to install and run patched FreeIPA server and client and connect them
together.

There are some issues with NSS when trying to create an HTTPS request
(apparently, NSS requires an NSS database password to set up an SSL
connection). I am actually thinking of removing NSSConnection from the
client altogether.

Can you expand on this a bit? NSS should only need a pin when it needs
access to a private key. What connection(s) are you talking about, and
what would you replace NSSConnection with?

rob


Hello Rob,

Thank you for this excellent question, in order to cut the email short I 
seem to have omitted quite a few information.


One of the very first problems I had with FreeIPA with FIPS was that NSS 
was always asking for password/pin. I was discussing this with the NSS 
guys on their IRC chat last week and it turns out that NSS tries to 
create a private key every time you want to use it as a backend for an 
SSL connection on FIPS. I still don't think this is quite right so I may 
open a bugzilla for that.


Anyway, the guys suggested me that we could try to create the database 
with an empty password and everything will work. I don't quite like 
that, too, but it's at least something if you don't want the `ipa` 
command to always bug you for password you have no way knowing if you're 
just a regular user.


What I think would be a better way to go is to use 
httplib.HTTPSConnection. We have the needed certificates in 
/etc/ipa/ca.crt anyway so why not use them instead. We had a discussion 
with Honza this morning and it seems that with this approach we may get 
rid of the NSSConnection class altogether (although I still need to 
check a few spots) and start the process of moving away from NSS which 
was discussed some year ago in an internal mailing list (for some reason).


Will be happy to hear thoughts on this,
Standa

--
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] FreeIPA on FIPS + NSS question

[Standa Laznicka]

Hello,

I started a design page for FreeIPA on FIPS-enabled systems: 
https://www.freeipa.org/page/V4/FreeIPA-on-FIPS


Me and Tomáš are still investigating what of all things will need to 
change in order to have FreeIPA on FIPS-enabled RHEL. So far I managed 
to install and run patched FreeIPA server and client and connect them 
together.


There are some issues with NSS when trying to create an HTTPS request 
(apparently, NSS requires an NSS database password to set up an SSL 
connection). I am actually thinking of removing NSSConnection from the 
client altogether.


Best regards,
Standa

P.S: we've got some Ansible scripts that help us setup FIPS in our 
testing environment and build FreeIPA on RHEL 7.3 in our internal IdM 
gitlab (sorry, communities, we'll release them to the public later, they 
might currently make your eyes bleed as we're not so good w/ Ansible yet).


--
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] Travis CI unexpected PEP8 errors

[Standa Laznicka]

On 12/14/2016 02:53 AM, Ben Lipton wrote:

Hi all,

I'm pretty sure this is unrelated to the CI issues discussed in other 
threads recently, but they reminded me that I've been having this odd 
issue.


https://travis-ci.org/freeipa/freeipa/jobs/183756995 is the most 
recent run on my pull request, 
https://github.com/freeipa/freeipa/pull/10. For a while now, every 
time the CI runs on my PR, it fails due to several PEP8 errors that 
are not detected when I run `git diff master -U0 | pep8 --diff` on my 
local copy. In fact, the errors are all in files not touched by my PR, 
which doesn't make much sense to me based on the behavior of `git diff`.


I noticed that the top of the travis build says:

 - Commit 1f50550
 - #10: Client-side CSR autogeneration
 - Branch master

I'm not sure what the "commit" link actually means, but that commit 
seems to have nothing to do with my PR nor the current master. Could 
Travis be diffing against the wrong code? Or if not, do you have any 
idea what might be causing these failures?


Thanks,
Ben


Hi Ben,

I was going through the Travis CI log of and noticed what might have 
caused the issue:


$ cd freeipa/freeipa
$ git fetch origin +refs/pull/109/merge:

It seems that for your pull request #10 (and for some reason for your 
pull request only), Travis fetched a different (old) pull request which 
it then tried to merge with current master, hence the errors. I don't 
think it was testing your code at all.


I do not have an explanation for this other than it might be a Travis 
bug, CCing Martin for a better answer.


Standa
-- 
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-users] ipalib authentication

[Standa Laznicka]

On 11/24/2016 04:27 PM, Adam Bishop wrote:

I'm writing a bit of code using ipalib directly, I'm a little stuck on 
authentication though.

It works fine if grab a Kerberos ticket with kinit then run the code 
interactively, but I'd like to run this as a daemon which makes maintaining a 
ticket tricky.

What other options are there for authenticating to the API, avoiding calling 
external tools like curl or kinit?

Regards,

Adam Bishop

   gpg: E75B 1F92 6407 DFDF 9F1C  BF10 C993 2504 6609 D460

jisc.ac.uk

Jisc is a registered charity (number 1149740) and a company limited by 
guarantee which is registered in England under Company No. 5747339, VAT No. GB 
197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, 
BS2 0JA. T 0203 697 5800.

Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited 
by guarantee which is registered in England under company number 2881024, VAT 
number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, 
Bristol BS2 0JA. T 0203 697 5800.



Hello Adam,

Nice to see someone interested in FreeIPA development. For questions 
about developing FreeIPA, feel free to contact other developers at 
freeipa-devel@redhat.com (in CC). You can also create a pull request on 
GitHub (https://github.com/freeipa/freeipa) if you'd like to share your 
code with the community.


As for your question, would it be feasible to use keytabs? Sure, you 
still have to perform kinit but there's no user action required (except 
for maintaining the keytab, of course).


Standa

--
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 0058] Make get_entries not ignore its size_limit argument

[Standa Laznicka]

On 10/10/2016 07:53 AM, Jan Cholasta wrote:

On 7.10.2016 12:23, Standa Laznicka wrote:

On 10/07/2016 08:31 AM, Jan Cholasta wrote:

On 17.8.2016 13:47, Stanislav Laznicka wrote:

On 08/11/2016 02:59 PM, Stanislav Laznicka wrote:

On 08/11/2016 07:49 AM, Jan Cholasta wrote:

On 2.8.2016 13:47, Stanislav Laznicka wrote:

On 07/19/2016 09:20 AM, Jan Cholasta wrote:

Hi,

On 14.7.2016 14:36, Stanislav Laznicka wrote:

Hello,

This patch fixes https://fedorahosted.org/freeipa/ticket/5640.

With not so much experience with the framework, it raises 
question

in my
head whether ipaldap.get_entries is used properly throughout the
system
- does it always assume that it gets ALL the requested entries or
just a
few of those as configured by the 'ipaSearchRecordsLimit'
attribute of
ipaConfig.etc which it actually gets?


That depends. If you call get_entries() on the ldap2 plugin
(which is
usually the case in the framework), then ipaSearchRecordsLimit is
used. If you call it on some arbitrary LDAPClient instance, the
hardcoded default (= unlimited) is used.



One spot that I know the get_entries method was definitely not 
used

properly before this patch is in the
baseldap.LDAPObject.get_memberindirect() method:

 692 result = self.backend.get_entries(
 693 self.api.env.basedn,
 694 filter=filter,
 695 attrs_list=['member'],
 696 size_limit=-1, # paged search will get
everything
anyway
 697 paged_search=True)

which to me seems kind of important if the environment size_limit
is not
set properly :) The patch does not fix the non-propagation of the
paged_search, though.


Why do you think size_limit is not used properly here?
AFAIU it is desired that the search is unlimited. However, due 
to the

fact that neither size_limit nor paged_search are passed from
ldap2.get_entries() to ldap2.find_entries() (methods inherited from
LDAPClient), only the number of records specified by
ipaSearchRecordsLimit is returned. That could eventually cause
problems
should ipaSearchRecordsLimit be set to a low value as in the 
ticket.


I see. This is *not* intentional, the **kwargs of get_entries()
should be passed to find_entries(). This definitely needs to be 
fixed.




Anyway, this ticket is not really easily fixable without more
profound
changes. Often, multiple LDAP searches are done during command
execution. What do you do with the size limit then? Do you pass 
the
same size limit to all the searches? Do you subtract the result 
size
from the size limit after each search? Do you do something else 
with

it? ... The answer is that it depends on the purpose of each
individual LDAP search (like in get_memberindirect() above, we
have to
do unlimited search, otherwise the resulting entry would be
incomplete), and fixing this accross the whole framework is a
non-trivial task.


I do realize that the proposed fix for the permission plugin is not
perfect, it would probably be better to subtract the number of
currently
loaded records from the sizelimit, although in the end the 
number of

returned values will not be higher than the given size_limit.
However,
it seems reasonable that if get_entries is passed a size limit, it
should apply it over current ipaSearchRecordsLimit rather than
ignoring
it. Then, any use of get_entries could be fixed accordingly if
someone
sees fit.



Right. Anyway, this is a different issue than above, so please put
this into a separate commit.


Please see the attached patches, then.

Self-NACK, with Honza's help I found there was a mistake in the 
code. I
also found an off-by-one bug which I hope I could stick to the 
other two

patches (attaching only the modified and new patches).


Works for me, but this bit in patch 0064 looks suspicious to me:

+if max_entries > 0 and len(entries) ==
max_entries:

Shouldn't it rather be:

+if max_entries > 0 and len(entries) >=
max_entries:

?


The length of entries list should not exceed max_entries if size_limit
is properly implemented. Therefore the list you get from execute()
should not have more then max_entries entries. You shouldn't also be
able to append a legacy entry to entries list if this check is the first
thing you do.


That's a lot of shoulds :-) I would expect at least an assert 
statement to make sure everything is right.




That being said, >= could be used but then some popping of entries from
entries list would be necessary. But it's perhaps safer to do, although
if there's a bug, it won't be that obvious :)


OK, nevermind then, just add the assert please, to make bugs *very* 
obvious.



An assert seems like a very good idea, attached is an asserting patch.

From 8af317a2fb8d3d3976c69620baf70171653cb925 Mon Sep 17 00:00:00 2001
From: Stanislav Laznicka <slazn...@redhat.com>
Date: Wed, 17 Aug 2016 13:35:04 +0200
Subject: [PATCH] permission-find: fix a sizelimit off-by-one bug

permissi

Re: [Freeipa-devel] [PATCH 0058] Make get_entries not ignore its size_limit argument

[Standa Laznicka]

On 10/07/2016 08:31 AM, Jan Cholasta wrote:

On 17.8.2016 13:47, Stanislav Laznicka wrote:

On 08/11/2016 02:59 PM, Stanislav Laznicka wrote:

On 08/11/2016 07:49 AM, Jan Cholasta wrote:

On 2.8.2016 13:47, Stanislav Laznicka wrote:

On 07/19/2016 09:20 AM, Jan Cholasta wrote:

Hi,

On 14.7.2016 14:36, Stanislav Laznicka wrote:

Hello,

This patch fixes https://fedorahosted.org/freeipa/ticket/5640.

With not so much experience with the framework, it raises question
in my
head whether ipaldap.get_entries is used properly throughout the
system
- does it always assume that it gets ALL the requested entries or
just a
few of those as configured by the 'ipaSearchRecordsLimit'
attribute of
ipaConfig.etc which it actually gets?


That depends. If you call get_entries() on the ldap2 plugin 
(which is

usually the case in the framework), then ipaSearchRecordsLimit is
used. If you call it on some arbitrary LDAPClient instance, the
hardcoded default (= unlimited) is used.



One spot that I know the get_entries method was definitely not used
properly before this patch is in the
baseldap.LDAPObject.get_memberindirect() method:

 692 result = self.backend.get_entries(
 693 self.api.env.basedn,
 694 filter=filter,
 695 attrs_list=['member'],
 696 size_limit=-1, # paged search will get
everything
anyway
 697 paged_search=True)

which to me seems kind of important if the environment size_limit
is not
set properly :) The patch does not fix the non-propagation of the
paged_search, though.


Why do you think size_limit is not used properly here?

AFAIU it is desired that the search is unlimited. However, due to the
fact that neither size_limit nor paged_search are passed from
ldap2.get_entries() to ldap2.find_entries() (methods inherited from
LDAPClient), only the number of records specified by
ipaSearchRecordsLimit is returned. That could eventually cause 
problems

should ipaSearchRecordsLimit be set to a low value as in the ticket.


I see. This is *not* intentional, the **kwargs of get_entries()
should be passed to find_entries(). This definitely needs to be fixed.



Anyway, this ticket is not really easily fixable without more 
profound

changes. Often, multiple LDAP searches are done during command
execution. What do you do with the size limit then? Do you pass the
same size limit to all the searches? Do you subtract the result size
from the size limit after each search? Do you do something else with
it? ... The answer is that it depends on the purpose of each
individual LDAP search (like in get_memberindirect() above, we 
have to

do unlimited search, otherwise the resulting entry would be
incomplete), and fixing this accross the whole framework is a
non-trivial task.


I do realize that the proposed fix for the permission plugin is not
perfect, it would probably be better to subtract the number of
currently
loaded records from the sizelimit, although in the end the number of
returned values will not be higher than the given size_limit. 
However,

it seems reasonable that if get_entries is passed a size limit, it
should apply it over current ipaSearchRecordsLimit rather than 
ignoring
it. Then, any use of get_entries could be fixed accordingly if 
someone

sees fit.



Right. Anyway, this is a different issue than above, so please put
this into a separate commit.


Please see the attached patches, then.


Self-NACK, with Honza's help I found there was a mistake in the code. I
also found an off-by-one bug which I hope I could stick to the other two
patches (attaching only the modified and new patches).


Works for me, but this bit in patch 0064 looks suspicious to me:

+if max_entries > 0 and len(entries) == 
max_entries:


Shouldn't it rather be:

+if max_entries > 0 and len(entries) >= 
max_entries:


?

The length of entries list should not exceed max_entries if size_limit 
is properly implemented. Therefore the list you get from execute() 
should not have more then max_entries entries. You shouldn't also be 
able to append a legacy entry to entries list if this check is the first 
thing you do.


That being said, >= could be used but then some popping of entries from 
entries list would be necessary. But it's perhaps safer to do, although 
if there's a bug, it won't be that obvious :)


--
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] pylint: remove unused variables

[Standa Laznicka]

On 09/23/2016 02:11 PM, Martin Basti wrote:



On 23.09.2016 14:12, Jan Cholasta wrote:

On 23.9.2016 13:23, Standa Laznicka wrote:

On 09/23/2016 07:28 AM, Jan Cholasta wrote:

On 22.9.2016 16:39, Martin Basti wrote:

Hello all,

In 4.5, I would like to remove all unused variables from code and 
enable

pylint check. Due to big amount of unused variables in the code this
will be longterm effort.

Why this?:

* better code readability

* removing dead code

* unused variable may uncover potential bug


It is clear what to do with unused assignments, but I need an 
agreement

what to do with unpacking or iteration with unused variables


For example:

for name, surname, gender in (('Martin', 'Basti', 'M'), ):

name, surname, gender = user['mbasti']

Where 'surname' is unused


Pylint will detect surname as unused variable and we have to agree 
on a

way how to tell pylint that this variable is unused on purpose:


1)

(

   name,

   surname,  # pylint: disable=unused-variable

   gender

) = user['mbasti']


I dont like this approach


+1




2)

Use defined keyword: 'dummy' is default in pylint, we can set our 
own,

like ignored, unused

name, dummy, gender = user['mbasti']


-1, not visible enough.




3)

use a prefix for unused variables: '_' or 'ignore_'

name, _surname, gender = user['mbasti']


This. We have already been using it in new code for quite some time,
and it's common in other Python projects too. Don't reinvent the 
wheel.





4)

we can combine all :)


For me the best is to have prefix '_' and 'dummy' keyword


Use '_dummy', it's both :-)


+1. I would rather use _meh as it's easier to type but perhaps not that
self-explanatory and not established at all, so _dummy is just fine :)


What I'm actually suggesting is that any local variable with "_" 
prefix should be considered unused, so _meh would be fine as well.




+1 regexp '_.+' works for me


Wonderful, I'm all in.

--
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] pylint: remove unused variables

[Standa Laznicka]

On 09/23/2016 07:28 AM, Jan Cholasta wrote:

On 22.9.2016 16:39, Martin Basti wrote:

Hello all,

In 4.5, I would like to remove all unused variables from code and enable
pylint check. Due to big amount of unused variables in the code this
will be longterm effort.

Why this?:

* better code readability

* removing dead code

* unused variable may uncover potential bug


It is clear what to do with unused assignments, but I need an agreement
what to do with unpacking or iteration with unused variables


For example:

for name, surname, gender in (('Martin', 'Basti', 'M'), ):

name, surname, gender = user['mbasti']

Where 'surname' is unused


Pylint will detect surname as unused variable and we have to agree on a
way how to tell pylint that this variable is unused on purpose:


1)

(

   name,

   surname,  # pylint: disable=unused-variable

   gender

) = user['mbasti']


I dont like this approach


+1




2)

Use defined keyword: 'dummy' is default in pylint, we can set our own,
like ignored, unused

name, dummy, gender = user['mbasti']


-1, not visible enough.




3)

use a prefix for unused variables: '_' or 'ignore_'

name, _surname, gender = user['mbasti']


This. We have already been using it in new code for quite some time, 
and it's common in other Python projects too. Don't reinvent the wheel.





4)

we can combine all :)


For me the best is to have prefix '_' and 'dummy' keyword


Use '_dummy', it's both :-)

+1. I would rather use _meh as it's easier to type but perhaps not that 
self-explanatory and not established at all, so _dummy is just fine :)



As first step I'll enable pylint check and disable it locally per module
where unused variables are, to avoid new regressions. Then I will fix it
module by module.


I'm open to suggestions

Martin^2






--
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 0060] Add --force-join option to ipa-replica-install

[Standa Laznicka]

On 09/23/2016 08:50 AM, Jan Cholasta wrote:

On 25.8.2016 15:31, Martin Basti wrote:



On 10.08.2016 07:53, Stanislav Laznicka wrote:

On 08/10/2016 07:31 AM, Jan Cholasta wrote:

On 9.8.2016 18:52, Petr Vobornik wrote:

On 08/09/2016 04:18 PM, Martin Basti wrote:



On 09.08.2016 16:07, Stanislav Laznicka wrote:

https://fedorahosted.org/freeipa/ticket/6183




Didn't we agreed that --force-join should be always used (without
extra
replica-install option)


+1


Did we?

IMO the default behavior should be the same as in domain level 0 when
trying to install replica on an already enrolled host.

That was my impression as well.


OK then, I don't like to add mostly useless option, but client install
is broken by design so whatever.


Bump, what is the status of this?

FTR this is what happens on domain level 0 if the host is already 
enrolled:


# ipa-replica-install replica-info-test.example.com.gpg
WARNING: conflicting time synchronization service 'chronyd' will
be disabled in favor of ntpd

Directory Manager (existing master) password:

The host test.example.com already exists on the master server.
You should remove it before proceeding:
% ipa host-del test.example.com
ipa.ipapython.install.cli.install_tool(Replica): ERRORThe 
ipa-replica-install command failed. See 
/var/log/ipareplica-install.log for more information




There's been no status change.

I think the problem here is more about client-install advertising the 
--force-join option which does not exist for ipa-replica-install. I do 
not think we can detect that exactly this error occurred during 
client-install being run from replica-install (can we?) but we can add 
this option and pass it to client-install if required.


--
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][UPDATE] Time-Based HBAC Policies

[Standa Laznicka]

On 09/09/2016 02:58 PM, Simo Sorce wrote:

On Fri, 2016-09-09 at 13:14 +0200, Standa Laznicka wrote:

On 09/03/2016 06:25 PM, Jan Pazdziora wrote:

On Thu, Sep 01, 2016 at 11:18:45AM -0400, Simo Sorce wrote:

The thing is we (and admins) will be stuck with old client s for a loong
time, so we need to make it clear to them what works for what. We need
to allow admins to create rules that work for both new and old client
w/o interfering with each other.
In your scheme there must be a way to create a set of rule such that old
clients can login at any time while newer clients use time rules.
that was easy to accomplish by adding an auxiliary class and simply
defining a new type.
Old clients would see old stuff only, new clients would add time rules
if present.
If we have 2 completely different objects because the admin has to
create both, then old clients still care only for the old rule, new
clients instead have an interesting challenge, what rule do they apply ?

You use host groups to serve the old rule to old clients and time-based
rule to new clients. Each client will apply the rule they see.

If you happen to serve the old rule to the new client, access will
be allowed no matter what the other, time-based rule says.

You do not use magic to interpret one rule differently, one way on
one version of client and other way on different client version.


How do you make sure a new client will enforce time restriction when it
looks up the old rule as well ?

You make sure the new client does not see the old rule.


Of course admins can always create very barrow host groups and apply
rules only to them, but this is burdensome if you have a *lot* of
clients and some other people are tasked to slowly upgrade them. It is
possible though, so having 2 separate objects that new clients know
about is potentially ok. I would prefer a scheme where they could be
combined though for maximum flexibility with as little as possible
ambiguity.

I agree that managing separate host group membership might be
and extra work. But it seems to be the only way to remove the ambiguity.


I also believe there's no way avoiding that (if we want to be somehow
backward compatible).

I would just love us to come to a consensus as I am growing weary of
this discussion and am willing to go with just anything as long as it's
somehow OK with most people. Could we therefore decide to go with
something, please?

As long as the tooling does not try to replace object classes I am ok
with the solution most people agree on.

Simo.


So, basically, we are back at accessRuleType usage, which I guess is 
kind of ok? We may either use its multi-valueness (is that a word?) or 
be setting it as flags (e.g. "tu" or "ut" for URI with time rules etc.).


In the multi-valued case, when someone adds "allow" amongst the values, 
it will screw HBAC evaluation up (=> deny even if it's among allow rules 
for the given host) but I guess that's something we could live with.


In the flag-case, the filters for obtaining the rules from IPA may seem 
rather ridiculous (substring match) and may be a very bad decision for 
future development. Also, anyone is able to add "allow" as another value 
but that would just be their fault.


In both cases, "allow" as an only value may be the default which states 
the rule may be evaluated even on older clients and SSSD just has to 
guess what the rule is capable of (which is OK with time rules as if 
there's none it means "always allow" should previous evaluation allow as 
well).


Please note that I rather included the rather "naive" flag 
implementation just to make sure to cover everything. We could just as 
well of course add something like "capabilities" attribute to 
ipaHBACRule object as another solution but that's starting to be an 
overkill IMO.


Standa

--
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][UPDATE] Time-Based HBAC Policies

[Standa Laznicka]

On 09/03/2016 06:25 PM, Jan Pazdziora wrote:

On Thu, Sep 01, 2016 at 11:18:45AM -0400, Simo Sorce wrote:

The thing is we (and admins) will be stuck with old client s for a loong
time, so we need to make it clear to them what works for what. We need
to allow admins to create rules that work for both new and old client
w/o interfering with each other.
In your scheme there must be a way to create a set of rule such that old
clients can login at any time while newer clients use time rules.
that was easy to accomplish by adding an auxiliary class and simply
defining a new type.
Old clients would see old stuff only, new clients would add time rules
if present.
If we have 2 completely different objects because the admin has to
create both, then old clients still care only for the old rule, new
clients instead have an interesting challenge, what rule do they apply ?

You use host groups to serve the old rule to old clients and time-based
rule to new clients. Each client will apply the rule they see.

If you happen to serve the old rule to the new client, access will
be allowed no matter what the other, time-based rule says.

You do not use magic to interpret one rule differently, one way on
one version of client and other way on different client version.


How do you make sure a new client will enforce time restriction when it
looks up the old rule as well ?

You make sure the new client does not see the old rule.


Of course admins can always create very barrow host groups and apply
rules only to them, but this is burdensome if you have a *lot* of
clients and some other people are tasked to slowly upgrade them. It is
possible though, so having 2 separate objects that new clients know
about is potentially ok. I would prefer a scheme where they could be
combined though for maximum flexibility with as little as possible
ambiguity.

I agree that managing separate host group membership might be
and extra work. But it seems to be the only way to remove the ambiguity.

I also believe there's no way avoiding that (if we want to be somehow 
backward compatible).


I would just love us to come to a consensus as I am growing weary of 
this discussion and am willing to go with just anything as long as it's 
somehow OK with most people. Could we therefore decide to go with 
something, please?


--
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][UPDATE] Time-Based HBAC Policies

[Standa Laznicka]

On 09/01/2016 05:18 PM, Simo Sorce wrote:

On Thu, 2016-09-01 at 16:35 +0200, Standa Laznicka wrote:

On 09/01/2016 03:06 PM, Simo Sorce wrote:

On Thu, 2016-09-01 at 14:09 +0200, Standa Laznicka wrote:

The class ipaHBACRuleV2 is dynamically switched to from ipaHBACRule
upon
addition of a time rule to a certain HBAC rule.

Honestly I am against this.

If you really want the two objects to be incompatible then you tell the
admin he can't add time rules to old objects.
The new object type should clearly identified as a new rule type and the
admin will have to create a new rule of the correct type and
remove/disable or retain the old rule as he prefers.

I do not think we should ever try to switch objectclasses dynamically.

Simo.


A child's question: why not?

Also, should it come to life like you propose, what would you expect the
user interface to be like?

LDAPv3 does not allow changing structural classes, 389ds allows it but
it is a non-standard feature.
I do not want to create issues to people that create solutions that do
things like synchronizing our LDAP tree to another LDAP server, for
caching, proxying or anything else.
It is one thing to allow to do something illegal in the LDAP protocol,
it is *entirely* different to rely on an illegal feature in day to day
operations.

Furthermore when you change a rule this way old clients will suddenly
see a rule disappear as it will not match their queries anymore. If you
silently do this change in the framework an admin may not realize this
is the case and break access to his legacy clients. If the admin has to
delete and recreate a rule instead it will be much clear to the admin
that this is the case.

So the above is for why I am pretty against switching objectclass.
Please do not do that, it is a NACK from me.
Thank you for the explanation, I was actually really curious about this 
as I still don't have that much experience and I just don't get some 
implications.

But below find additional things I have been thinking:

The thing is we (and admins) will be stuck with old client s for a loong
time, so we need to make it clear to them what works for what. We need
to allow admins to create rules that work for both new and old client
w/o interfering with each other.
In your scheme there must be a way to create a set of rule such that old
clients can login at any time while newer clients use time rules.
that was easy to accomplish by adding an auxiliary class and simply
defining a new type.
Old clients would see old stuff only, new clients would add time rules
if present.
If we have 2 completely different objects because the admin has to
create both, then old clients still care only for the old rule, new
clients instead have an interesting challenge, what rule do they apply ?

How do you make sure a new client will enforce time restriction when it
looks up the old rule as well ?
After all the old rule grants access at "all times".

Of course admins can always create very barrow host groups and apply
rules only to them, but this is burdensome if you have a *lot* of
clients and some other people are tasked to slowly upgrade them. It is
possible though, so having 2 separate objects that new clients know
about is potentially ok. I would prefer a scheme where they could be
combined though for maximum flexibility with as little as possible
ambiguity.
If an admin wants the capabilities of time rules then they should just 
upgrade the clients. If that is a problem, it's their choice. They can 
either create a special host group for those clients that just won't 
upgrade or just revoke access to them if it's a problem of a stubborn 
user who does not want their system upgraded.


Having a single object would also be wrong - there's no way telling the 
older clients to ignore the objects you want them to ignore if you want 
them not to ignore some.


But all and all thank you for the explanation with the example, it made 
some of your previous points more clear.


--
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][UPDATE] Time-Based HBAC Policies

[Standa Laznicka]

On 09/01/2016 03:06 PM, Simo Sorce wrote:

On Thu, 2016-09-01 at 14:09 +0200, Standa Laznicka wrote:

The class ipaHBACRuleV2 is dynamically switched to from ipaHBACRule
upon
addition of a time rule to a certain HBAC rule.

Honestly I am against this.

If you really want the two objects to be incompatible then you tell the
admin he can't add time rules to old objects.
The new object type should clearly identified as a new rule type and the
admin will have to create a new rule of the correct type and
remove/disable or retain the old rule as he prefers.

I do not think we should ever try to switch objectclasses dynamically.

Simo.


A child's question: why not?

Also, should it come to life like you propose, what would you expect the 
user interface to be like?


--
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][UPDATE] Time-Based HBAC Policies

[Standa Laznicka]

On 09/01/2016 02:14 PM, Petr Spacek wrote:

On 1.9.2016 14:09, Standa Laznicka wrote:

On 09/01/2016 01:26 PM, Standa Laznicka wrote:

On 08/31/2016 12:57 PM, Petr Spacek wrote:

On 31.8.2016 12:42, Standa Laznicka wrote:

On 08/30/2016 03:34 PM, Simo Sorce wrote:

On Tue, 2016-08-30 at 08:47 +0200, Standa Laznicka wrote:

On 08/26/2016 05:37 PM, Simo Sorce wrote:

On Fri, 2016-08-26 at 11:26 -0400, Simo Sorce wrote:

On Fri, 2016-08-26 at 18:09 +0300, Alexander Bokovoy wrote:

On Fri, 26 Aug 2016, Simo Sorce wrote:

On Fri, 2016-08-26 at 12:39 +0200, Martin Basti wrote:

I miss "why" part of "To be able to handle backward compatibility

with

ease, a new object called ipaHBACRulev2 is introduced. " in the

design

page. If the reason is the above - old client's should ignore time

rules

then it has to be mentioned there. Otherwise I don't see a reason to
introduce a new object type instead of extending the current.

How do you want to enforce HBAC rule that have set time from 10 to 14
everyday? With the same objectclass old clients will allow this HBAC
for
all day. Isn't this CVE?

This is a discussion worth having.

In general it is a CVE only if an authorization mechanism fails to work
as advertised.

If you make it clear that old clients *DO NOT* respect time rules then
there is no CVE material, it is working as "described".

The admins already have a way to not set those rules for older clients
by simply grouping newer clients in a different host group and applying
time rules only there.

So the question really is: should we allow admins to apply an HBAC Rule
potentially to older clients that do not understand it and will
therefore allow access at any time of the day, or should we prevent
it ?

This is a hard question to answer and can go both ways.

A time rule may be something that admins want to enforce at all cost or
deny access. In this case a client that fails to handle it would be a
problem.

But it may be something that is just used for defense in depth and
not a
strictly hard requirement. In this case allowing older clients would
make it an easy transition as you just set up the rule and the client
will start enforcing the time when it is upgraded but work otherwise
with the same rules.

I am a bit conflicted on trying to decide what scenario we should
target, but the second one appeals to me because host groups do already
give admins a good way to apply rules to a specific set of hosts and
exclude old clients w/o us making it a hard rule.
OTOH if an admin does not understand this difference, they may be
surprised to find out there are clients that do not honor it.

Perhaps we could find a way to set a flag on the rule such that when
set
(and only when set) older clients get excluded by way of changing the
objectlass or something else to similar effect.

Open to discussion.

At this point using new object class becomes an attractive approach. We
don't have means to exclude HBAC rules other than applying them
per-host/hostgroup. We also have no deny rules.

I have another idea: what about enforcing time rules always to apply
per-host or per-hostgroup by default? Add --force option to override the
behavior but default to not allow --hostcat=all. This would raise
awareness and make sure admins are actually applying these rules with
intention.

This sounds like a good idea, but it is not a silver bullet I am afraid.

Simo.

I was thinking that for future proofing we could add a version field,
then reasoned more and realized that changing the object class is
basically the same thing.

There is only one big problem, ipaHBACRule is a STRUCTURAL objectclass.
(I know 389ds allows us to do an LDAPv3 illegal operation and change it,
but I do not like to depend on that behavoir).

Now looking into this I had an idea to solve the problem of legacy
clients without having to swap classes.
We can redefine the accessRuleType attribute to be a "capability" type.

Ie rules that have a timeAccess component will be of type
"allow_with_time" instead of just "allow".
Old clients are supposed to search with accessRuleType=allow (and I can
see that SSSD does that), so an older client will fail to get those
rules as they won't match.

New clients instead can recognize both types.

Also if we need a future extension we will simpy add a new access rule
type and we can have the same effect.
The nice thing is that accessRyleType is defined as multivalue (no
SINGLE in schema) so we may actually create compatible rules if we want
to.
Ie we could set both "allow" and "allow_with_time" on an object for
cases where the admin wants to enforce the time part only o newer client
but otherwise apply the rule to any client.

This should give us the best of all options at once.

Thoughts ?

Simo.


Sorry to join the discussion so late, I was away yesterday.

I have to say I too like this idea much better than fiddling with the
objectClasses. Also,

Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies

[Standa Laznicka]

On 09/01/2016 01:26 PM, Standa Laznicka wrote:

On 08/31/2016 12:57 PM, Petr Spacek wrote:

On 31.8.2016 12:42, Standa Laznicka wrote:

On 08/30/2016 03:34 PM, Simo Sorce wrote:

On Tue, 2016-08-30 at 08:47 +0200, Standa Laznicka wrote:

On 08/26/2016 05:37 PM, Simo Sorce wrote:

On Fri, 2016-08-26 at 11:26 -0400, Simo Sorce wrote:

On Fri, 2016-08-26 at 18:09 +0300, Alexander Bokovoy wrote:

On Fri, 26 Aug 2016, Simo Sorce wrote:

On Fri, 2016-08-26 at 12:39 +0200, Martin Basti wrote:
I miss "why" part of "To be able to handle backward 
compatibility

with

ease, a new object called ipaHBACRulev2 is introduced. " in the

design
page. If the reason is the above - old client's should 
ignore time

rules
then it has to be mentioned there. Otherwise I don't see a 
reason to

introduce a new object type instead of extending the current.
How do you want to enforce HBAC rule that have set time from 
10 to 14
everyday? With the same objectclass old clients will allow 
this HBAC

for
all day. Isn't this CVE?

This is a discussion worth having.

In general it is a CVE only if an authorization mechanism 
fails to work

as advertised.

If you make it clear that old clients *DO NOT* respect time 
rules then

there is no CVE material, it is working as "described".

The admins already have a way to not set those rules for older 
clients
by simply grouping newer clients in a different host group and 
applying

time rules only there.

So the question really is: should we allow admins to apply an 
HBAC Rule

potentially to older clients that do not understand it and will
therefore allow access at any time of the day, or should we 
prevent it ?


This is a hard question to answer and can go both ways.

A time rule may be something that admins want to enforce at 
all cost or
deny access. In this case a client that fails to handle it 
would be a

problem.

But it may be something that is just used for defense in depth 
and not a
strictly hard requirement. In this case allowing older clients 
would
make it an easy transition as you just set up the rule and the 
client
will start enforcing the time when it is upgraded but work 
otherwise

with the same rules.

I am a bit conflicted on trying to decide what scenario we should
target, but the second one appeals to me because host groups 
do already
give admins a good way to apply rules to a specific set of 
hosts and

exclude old clients w/o us making it a hard rule.
OTOH if an admin does not understand this difference, they may be
surprised to find out there are clients that do not honor it.

Perhaps we could find a way to set a flag on the rule such 
that when set
(and only when set) older clients get excluded by way of 
changing the

objectlass or something else to similar effect.

Open to discussion.
At this point using new object class becomes an attractive 
approach. We

don't have means to exclude HBAC rules other than applying them
per-host/hostgroup. We also have no deny rules.

I have another idea: what about enforcing time rules always to 
apply
per-host or per-hostgroup by default? Add --force option to 
override the

behavior but default to not allow --hostcat=all. This would raise
awareness and make sure admins are actually applying these 
rules with

intention.
This sounds like a good idea, but it is not a silver bullet I am 
afraid.


Simo.
I was thinking that for future proofing we could add a version 
field,

then reasoned more and realized that changing the object class is
basically the same thing.

There is only one big problem, ipaHBACRule is a STRUCTURAL 
objectclass.
(I know 389ds allows us to do an LDAPv3 illegal operation and 
change it,

but I do not like to depend on that behavoir).

Now looking into this I had an idea to solve the problem of legacy
clients without having to swap classes.
We can redefine the accessRuleType attribute to be a "capability" 
type.


Ie rules that have a timeAccess component will be of type
"allow_with_time" instead of just "allow".
Old clients are supposed to search with accessRuleType=allow (and 
I can

see that SSSD does that), so an older client will fail to get those
rules as they won't match.

New clients instead can recognize both types.

Also if we need a future extension we will simpy add a new access 
rule

type and we can have the same effect.
The nice thing is that accessRyleType is defined as multivalue (no
SINGLE in schema) so we may actually create compatible rules if 
we want

to.
Ie we could set both "allow" and "allow_with_time" on an object for
cases where the admin wants to enforce the time part only o newer 
client

but otherwise apply the rule to any client.

This should give us the best of all options at once.

Thoughts ?

Simo.


Sorry to join the discussion so late, I was away yesterday.

I have to say I too like this idea much better than fiddling with the
objectClasses. Also, I believe that accessRuleType was origina

Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies

[Standa Laznicka]

On 08/31/2016 12:57 PM, Petr Spacek wrote:

On 31.8.2016 12:42, Standa Laznicka wrote:

On 08/30/2016 03:34 PM, Simo Sorce wrote:

On Tue, 2016-08-30 at 08:47 +0200, Standa Laznicka wrote:

On 08/26/2016 05:37 PM, Simo Sorce wrote:

On Fri, 2016-08-26 at 11:26 -0400, Simo Sorce wrote:

On Fri, 2016-08-26 at 18:09 +0300, Alexander Bokovoy wrote:

On Fri, 26 Aug 2016, Simo Sorce wrote:

On Fri, 2016-08-26 at 12:39 +0200, Martin Basti wrote:

I miss "why" part of "To be able to handle backward compatibility

with

ease, a new object called ipaHBACRulev2 is introduced. " in the

design

page. If the reason is the above - old client's should ignore time

rules

then it has to be mentioned there. Otherwise I don't see a reason to
introduce a new object type instead of extending the current.

How do you want to enforce HBAC rule that have set time from 10 to 14
everyday? With the same objectclass old clients will allow this HBAC
for
all day. Isn't this CVE?

This is a discussion worth having.

In general it is a CVE only if an authorization mechanism fails to work
as advertised.

If you make it clear that old clients *DO NOT* respect time rules then
there is no CVE material, it is working as "described".

The admins already have a way to not set those rules for older clients
by simply grouping newer clients in a different host group and applying
time rules only there.

So the question really is: should we allow admins to apply an HBAC Rule
potentially to older clients that do not understand it and will
therefore allow access at any time of the day, or should we prevent it ?

This is a hard question to answer and can go both ways.

A time rule may be something that admins want to enforce at all cost or
deny access. In this case a client that fails to handle it would be a
problem.

But it may be something that is just used for defense in depth and not a
strictly hard requirement. In this case allowing older clients would
make it an easy transition as you just set up the rule and the client
will start enforcing the time when it is upgraded but work otherwise
with the same rules.

I am a bit conflicted on trying to decide what scenario we should
target, but the second one appeals to me because host groups do already
give admins a good way to apply rules to a specific set of hosts and
exclude old clients w/o us making it a hard rule.
OTOH if an admin does not understand this difference, they may be
surprised to find out there are clients that do not honor it.

Perhaps we could find a way to set a flag on the rule such that when set
(and only when set) older clients get excluded by way of changing the
objectlass or something else to similar effect.

Open to discussion.

At this point using new object class becomes an attractive approach. We
don't have means to exclude HBAC rules other than applying them
per-host/hostgroup. We also have no deny rules.

I have another idea: what about enforcing time rules always to apply
per-host or per-hostgroup by default? Add --force option to override the
behavior but default to not allow --hostcat=all. This would raise
awareness and make sure admins are actually applying these rules with
intention.

This sounds like a good idea, but it is not a silver bullet I am afraid.

Simo.

I was thinking that for future proofing we could add a version field,
then reasoned more and realized that changing the object class is
basically the same thing.

There is only one big problem, ipaHBACRule is a STRUCTURAL objectclass.
(I know 389ds allows us to do an LDAPv3 illegal operation and change it,
but I do not like to depend on that behavoir).

Now looking into this I had an idea to solve the problem of legacy
clients without having to swap classes.
We can redefine the accessRuleType attribute to be a "capability" type.

Ie rules that have a timeAccess component will be of type
"allow_with_time" instead of just "allow".
Old clients are supposed to search with accessRuleType=allow (and I can
see that SSSD does that), so an older client will fail to get those
rules as they won't match.

New clients instead can recognize both types.

Also if we need a future extension we will simpy add a new access rule
type and we can have the same effect.
The nice thing is that accessRyleType is defined as multivalue (no
SINGLE in schema) so we may actually create compatible rules if we want
to.
Ie we could set both "allow" and "allow_with_time" on an object for
cases where the admin wants to enforce the time part only o newer client
but otherwise apply the rule to any client.

This should give us the best of all options at once.

Thoughts ?

Simo.


Sorry to join the discussion so late, I was away yesterday.

I have to say I too like this idea much better than fiddling with the
objectClasses. Also, I believe that accessRuleType was originally
actually used to distinguish newer version of HBAC rules from the older
so we may just do th

Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies

[Standa Laznicka]

On 08/30/2016 03:34 PM, Simo Sorce wrote:

On Tue, 2016-08-30 at 08:47 +0200, Standa Laznicka wrote:

On 08/26/2016 05:37 PM, Simo Sorce wrote:

On Fri, 2016-08-26 at 11:26 -0400, Simo Sorce wrote:

On Fri, 2016-08-26 at 18:09 +0300, Alexander Bokovoy wrote:

On Fri, 26 Aug 2016, Simo Sorce wrote:

On Fri, 2016-08-26 at 12:39 +0200, Martin Basti wrote:

I miss "why" part of "To be able to handle backward compatibility

with

ease, a new object called ipaHBACRulev2 is introduced. " in the

design

page. If the reason is the above - old client's should ignore time

rules

then it has to be mentioned there. Otherwise I don't see a reason to
introduce a new object type instead of extending the current.

How do you want to enforce HBAC rule that have set time from 10 to 14
everyday? With the same objectclass old clients will allow this HBAC
for
all day. Isn't this CVE?

This is a discussion worth having.

In general it is a CVE only if an authorization mechanism fails to work
as advertised.

If you make it clear that old clients *DO NOT* respect time rules then
there is no CVE material, it is working as "described".

The admins already have a way to not set those rules for older clients
by simply grouping newer clients in a different host group and applying
time rules only there.

So the question really is: should we allow admins to apply an HBAC Rule
potentially to older clients that do not understand it and will
therefore allow access at any time of the day, or should we prevent it ?

This is a hard question to answer and can go both ways.

A time rule may be something that admins want to enforce at all cost or
deny access. In this case a client that fails to handle it would be a
problem.

But it may be something that is just used for defense in depth and not a
strictly hard requirement. In this case allowing older clients would
make it an easy transition as you just set up the rule and the client
will start enforcing the time when it is upgraded but work otherwise
with the same rules.

I am a bit conflicted on trying to decide what scenario we should
target, but the second one appeals to me because host groups do already
give admins a good way to apply rules to a specific set of hosts and
exclude old clients w/o us making it a hard rule.
OTOH if an admin does not understand this difference, they may be
surprised to find out there are clients that do not honor it.

Perhaps we could find a way to set a flag on the rule such that when set
(and only when set) older clients get excluded by way of changing the
objectlass or something else to similar effect.

Open to discussion.

At this point using new object class becomes an attractive approach. We
don't have means to exclude HBAC rules other than applying them
per-host/hostgroup. We also have no deny rules.

I have another idea: what about enforcing time rules always to apply
per-host or per-hostgroup by default? Add --force option to override the
behavior but default to not allow --hostcat=all. This would raise
awareness and make sure admins are actually applying these rules with
intention.

This sounds like a good idea, but it is not a silver bullet I am afraid.

Simo.

I was thinking that for future proofing we could add a version field,
then reasoned more and realized that changing the object class is
basically the same thing.

There is only one big problem, ipaHBACRule is a STRUCTURAL objectclass.
(I know 389ds allows us to do an LDAPv3 illegal operation and change it,
but I do not like to depend on that behavoir).

Now looking into this I had an idea to solve the problem of legacy
clients without having to swap classes.
We can redefine the accessRuleType attribute to be a "capability" type.

Ie rules that have a timeAccess component will be of type
"allow_with_time" instead of just "allow".
Old clients are supposed to search with accessRuleType=allow (and I can
see that SSSD does that), so an older client will fail to get those
rules as they won't match.

New clients instead can recognize both types.

Also if we need a future extension we will simpy add a new access rule
type and we can have the same effect.
The nice thing is that accessRyleType is defined as multivalue (no
SINGLE in schema) so we may actually create compatible rules if we want
to.
Ie we could set both "allow" and "allow_with_time" on an object for
cases where the admin wants to enforce the time part only o newer client
but otherwise apply the rule to any client.

This should give us the best of all options at once.

Thoughts ?

Simo.


Sorry to join the discussion so late, I was away yesterday.

I have to say I too like this idea much better than fiddling with the
objectClasses. Also, I believe that accessRuleType was originally
actually used to distinguish newer version of HBAC rules from the older
so we may just do this again and profit from its original purpose. To
top it off, this change should be reall

Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies

[Standa Laznicka]

On 08/30/2016 09:34 AM, Standa Laznicka wrote:

On 08/30/2016 09:23 AM, Alexander Bokovoy wrote:

On Tue, 30 Aug 2016, Jan Cholasta wrote:

On 30.8.2016 08:47, Standa Laznicka wrote:

On 08/26/2016 05:37 PM, Simo Sorce wrote:

On Fri, 2016-08-26 at 11:26 -0400, Simo Sorce wrote:

On Fri, 2016-08-26 at 18:09 +0300, Alexander Bokovoy wrote:

On Fri, 26 Aug 2016, Simo Sorce wrote:

On Fri, 2016-08-26 at 12:39 +0200, Martin Basti wrote:
I miss "why" part of "To be able to handle backward 
compatibility

with

ease, a new object called ipaHBACRulev2 is introduced. " in the

design
page. If the reason is the above - old client's should ignore 
time

rules
then it has to be mentioned there. Otherwise I don't see a 
reason to

introduce a new object type instead of extending the current.
How do you want to enforce HBAC rule that have set time from 
10 to 14
everyday? With the same objectclass old clients will allow 
this HBAC

for
all day. Isn't this CVE?

This is a discussion worth having.

In general it is a CVE only if an authorization mechanism fails to
work
as advertised.

If you make it clear that old clients *DO NOT* respect time 
rules then

there is no CVE material, it is working as "described".

The admins already have a way to not set those rules for older 
clients

by simply grouping newer clients in a different host group and
applying
time rules only there.

So the question really is: should we allow admins to apply an HBAC
Rule
potentially to older clients that do not understand it and will
therefore allow access at any time of the day, or should we 
prevent

it ?

This is a hard question to answer and can go both ways.

A time rule may be something that admins want to enforce at all
cost or
deny access. In this case a client that fails to handle it 
would be a

problem.

But it may be something that is just used for defense in depth and
not a
strictly hard requirement. In this case allowing older clients 
would
make it an easy transition as you just set up the rule and the 
client
will start enforcing the time when it is upgraded but work 
otherwise

with the same rules.

I am a bit conflicted on trying to decide what scenario we should
target, but the second one appeals to me because host groups do
already
give admins a good way to apply rules to a specific set of 
hosts and

exclude old clients w/o us making it a hard rule.
OTOH if an admin does not understand this difference, they may be
surprised to find out there are clients that do not honor it.

Perhaps we could find a way to set a flag on the rule such that
when set
(and only when set) older clients get excluded by way of 
changing the

objectlass or something else to similar effect.

Open to discussion.
At this point using new object class becomes an attractive 
approach. We

don't have means to exclude HBAC rules other than applying them
per-host/hostgroup. We also have no deny rules.

I have another idea: what about enforcing time rules always to 
apply
per-host or per-hostgroup by default? Add --force option to 
override

the
behavior but default to not allow --hostcat=all. This would raise
awareness and make sure admins are actually applying these rules 
with

intention.
This sounds like a good idea, but it is not a silver bullet I am 
afraid.


Simo.

I was thinking that for future proofing we could add a version field,
then reasoned more and realized that changing the object class is
basically the same thing.

There is only one big problem, ipaHBACRule is a STRUCTURAL 
objectclass.
(I know 389ds allows us to do an LDAPv3 illegal operation and 
change it,

but I do not like to depend on that behavoir).

Now looking into this I had an idea to solve the problem of legacy
clients without having to swap classes.
We can redefine the accessRuleType attribute to be a "capability" 
type.


Ie rules that have a timeAccess component will be of type
"allow_with_time" instead of just "allow".
Old clients are supposed to search with accessRuleType=allow (and 
I can

see that SSSD does that), so an older client will fail to get those
rules as they won't match.

New clients instead can recognize both types.

Also if we need a future extension we will simpy add a new access 
rule

type and we can have the same effect.
The nice thing is that accessRyleType is defined as multivalue (no
SINGLE in schema) so we may actually create compatible rules if we 
want

to.
Ie we could set both "allow" and "allow_with_time" on an object for
cases where the admin wants to enforce the time part only o newer 
client

but otherwise apply the rule to any client.

This should give us the best of all options at once.

Thoughts ?

Simo.


Sorry to join the discussion so late, I was away yesterday.

I have to say I too like this idea much better than fiddling with the
objectClasses.


Note that the resulting code will be exactly the same except for the 
attribute name - you won't be fiddlin

Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies

[Standa Laznicka]

On 08/30/2016 09:23 AM, Alexander Bokovoy wrote:

On Tue, 30 Aug 2016, Jan Cholasta wrote:

On 30.8.2016 08:47, Standa Laznicka wrote:

On 08/26/2016 05:37 PM, Simo Sorce wrote:

On Fri, 2016-08-26 at 11:26 -0400, Simo Sorce wrote:

On Fri, 2016-08-26 at 18:09 +0300, Alexander Bokovoy wrote:

On Fri, 26 Aug 2016, Simo Sorce wrote:

On Fri, 2016-08-26 at 12:39 +0200, Martin Basti wrote:

I miss "why" part of "To be able to handle backward compatibility

with

ease, a new object called ipaHBACRulev2 is introduced. " in the

design
page. If the reason is the above - old client's should ignore 
time

rules
then it has to be mentioned there. Otherwise I don't see a 
reason to

introduce a new object type instead of extending the current.
How do you want to enforce HBAC rule that have set time from 10 
to 14
everyday? With the same objectclass old clients will allow this 
HBAC

for
all day. Isn't this CVE?

This is a discussion worth having.

In general it is a CVE only if an authorization mechanism fails to
work
as advertised.

If you make it clear that old clients *DO NOT* respect time 
rules then

there is no CVE material, it is working as "described".

The admins already have a way to not set those rules for older 
clients

by simply grouping newer clients in a different host group and
applying
time rules only there.

So the question really is: should we allow admins to apply an HBAC
Rule
potentially to older clients that do not understand it and will
therefore allow access at any time of the day, or should we prevent
it ?

This is a hard question to answer and can go both ways.

A time rule may be something that admins want to enforce at all
cost or
deny access. In this case a client that fails to handle it would 
be a

problem.

But it may be something that is just used for defense in depth and
not a
strictly hard requirement. In this case allowing older clients 
would
make it an easy transition as you just set up the rule and the 
client
will start enforcing the time when it is upgraded but work 
otherwise

with the same rules.

I am a bit conflicted on trying to decide what scenario we should
target, but the second one appeals to me because host groups do
already
give admins a good way to apply rules to a specific set of hosts 
and

exclude old clients w/o us making it a hard rule.
OTOH if an admin does not understand this difference, they may be
surprised to find out there are clients that do not honor it.

Perhaps we could find a way to set a flag on the rule such that
when set
(and only when set) older clients get excluded by way of 
changing the

objectlass or something else to similar effect.

Open to discussion.
At this point using new object class becomes an attractive 
approach. We

don't have means to exclude HBAC rules other than applying them
per-host/hostgroup. We also have no deny rules.

I have another idea: what about enforcing time rules always to apply
per-host or per-hostgroup by default? Add --force option to override
the
behavior but default to not allow --hostcat=all. This would raise
awareness and make sure admins are actually applying these rules 
with

intention.
This sounds like a good idea, but it is not a silver bullet I am 
afraid.


Simo.

I was thinking that for future proofing we could add a version field,
then reasoned more and realized that changing the object class is
basically the same thing.

There is only one big problem, ipaHBACRule is a STRUCTURAL 
objectclass.
(I know 389ds allows us to do an LDAPv3 illegal operation and 
change it,

but I do not like to depend on that behavoir).

Now looking into this I had an idea to solve the problem of legacy
clients without having to swap classes.
We can redefine the accessRuleType attribute to be a "capability" 
type.


Ie rules that have a timeAccess component will be of type
"allow_with_time" instead of just "allow".
Old clients are supposed to search with accessRuleType=allow (and I 
can

see that SSSD does that), so an older client will fail to get those
rules as they won't match.

New clients instead can recognize both types.

Also if we need a future extension we will simpy add a new access rule
type and we can have the same effect.
The nice thing is that accessRyleType is defined as multivalue (no
SINGLE in schema) so we may actually create compatible rules if we 
want

to.
Ie we could set both "allow" and "allow_with_time" on an object for
cases where the admin wants to enforce the time part only o newer 
client

but otherwise apply the rule to any client.

This should give us the best of all options at once.

Thoughts ?

Simo.


Sorry to join the discussion so late, I was away yesterday.

I have to say I too like this idea much better than fiddling with the
objectClasses.


Note that the resulting code will be exactly the same except for the 
attribute name - you won't be fiddling with objectClass but with 
attributeRuleType.
I do r

Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies

[Standa Laznicka]

On 08/26/2016 05:37 PM, Simo Sorce wrote:

On Fri, 2016-08-26 at 11:26 -0400, Simo Sorce wrote:

On Fri, 2016-08-26 at 18:09 +0300, Alexander Bokovoy wrote:

On Fri, 26 Aug 2016, Simo Sorce wrote:

On Fri, 2016-08-26 at 12:39 +0200, Martin Basti wrote:

I miss "why" part of "To be able to handle backward compatibility

with

ease, a new object called ipaHBACRulev2 is introduced. " in the

design

page. If the reason is the above - old client's should ignore time

rules

then it has to be mentioned there. Otherwise I don't see a reason to
introduce a new object type instead of extending the current.

How do you want to enforce HBAC rule that have set time from 10 to 14
everyday? With the same objectclass old clients will allow this HBAC
for
all day. Isn't this CVE?

This is a discussion worth having.

In general it is a CVE only if an authorization mechanism fails to work
as advertised.

If you make it clear that old clients *DO NOT* respect time rules then
there is no CVE material, it is working as "described".

The admins already have a way to not set those rules for older clients
by simply grouping newer clients in a different host group and applying
time rules only there.

So the question really is: should we allow admins to apply an HBAC Rule
potentially to older clients that do not understand it and will
therefore allow access at any time of the day, or should we prevent it ?

This is a hard question to answer and can go both ways.

A time rule may be something that admins want to enforce at all cost or
deny access. In this case a client that fails to handle it would be a
problem.

But it may be something that is just used for defense in depth and not a
strictly hard requirement. In this case allowing older clients would
make it an easy transition as you just set up the rule and the client
will start enforcing the time when it is upgraded but work otherwise
with the same rules.

I am a bit conflicted on trying to decide what scenario we should
target, but the second one appeals to me because host groups do already
give admins a good way to apply rules to a specific set of hosts and
exclude old clients w/o us making it a hard rule.
OTOH if an admin does not understand this difference, they may be
surprised to find out there are clients that do not honor it.

Perhaps we could find a way to set a flag on the rule such that when set
(and only when set) older clients get excluded by way of changing the
objectlass or something else to similar effect.

Open to discussion.

At this point using new object class becomes an attractive approach. We
don't have means to exclude HBAC rules other than applying them
per-host/hostgroup. We also have no deny rules.

I have another idea: what about enforcing time rules always to apply
per-host or per-hostgroup by default? Add --force option to override the
behavior but default to not allow --hostcat=all. This would raise
awareness and make sure admins are actually applying these rules with
intention.

This sounds like a good idea, but it is not a silver bullet I am afraid.

Simo.

I was thinking that for future proofing we could add a version field,
then reasoned more and realized that changing the object class is
basically the same thing.

There is only one big problem, ipaHBACRule is a STRUCTURAL objectclass.
(I know 389ds allows us to do an LDAPv3 illegal operation and change it,
but I do not like to depend on that behavoir).

Now looking into this I had an idea to solve the problem of legacy
clients without having to swap classes.
We can redefine the accessRuleType attribute to be a "capability" type.

Ie rules that have a timeAccess component will be of type
"allow_with_time" instead of just "allow".
Old clients are supposed to search with accessRuleType=allow (and I can
see that SSSD does that), so an older client will fail to get those
rules as they won't match.

New clients instead can recognize both types.

Also if we need a future extension we will simpy add a new access rule
type and we can have the same effect.
The nice thing is that accessRyleType is defined as multivalue (no
SINGLE in schema) so we may actually create compatible rules if we want
to.
Ie we could set both "allow" and "allow_with_time" on an object for
cases where the admin wants to enforce the time part only o newer client
but otherwise apply the rule to any client.

This should give us the best of all options at once.

Thoughts ?

Simo.


Sorry to join the discussion so late, I was away yesterday.

I have to say I too like this idea much better than fiddling with the 
objectClasses. Also, I believe that accessRuleType was originally 
actually used to distinguish newer version of HBAC rules from the older 
so we may just do this again and profit from its original purpose. To 
top it off, this change should be really easy to implement to what I 
currently have on SSSD side.


I was just wondering - would you propose for every newly created rule to 
have the new accessRuleType set to 

Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies

[Standa Laznicka]

On 08/26/2016 12:27 PM, Jan Cholasta wrote:

On 26.8.2016 12:21, Martin Basti wrote:

On 26.08.2016 12:13, Jan Cholasta wrote:

On 26.8.2016 11:55, Martin Basti wrote:

On 26.08.2016 11:43, Jan Cholasta wrote:

Hi,

On 11.8.2016 12:34, Stanislav Laznicka wrote:

Hello,

I updated the design of the Time-Based HBAC Policies according to 
the

discussion we led here earlier. Please check the design page
http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The
biggest
changes are in the Implementation and Feature Management sections. I
also added a short How to Use section.


1) Please use the 'ipa' prefix for new attributes: memberTimeRule ->
ipaMemberTimeRule


2) Source hosts are deprecated and thus should be removed from
ipaHBACRuleV2.


3) Since time rules are defined by memberTimeRule, accessTime should
be removed from ipaHBACRuleV2.


ad 2) 3)

Because backward compatibility, ipaHBACRuleV2 must contain all
attributes from ipaHBACRule as MAY


Not true.



With current approach, when timerule is added to HBAC, we just change
objectclass from 'ipahbacrule' to 'ipahbacrulev2' so we keep all
attributes that was defined in older HBAC. Removing any attrs from
ipaHBACRuleV2 can cause schema violation.


Which is perfectly fine.




I'm not sure if want to handle this in code (removing deprecated
attributes from HBAC entry when timerule is added)


We don't have to do anything. If any of the deprecated attributes are
present when you change the object class (which they shouldn't
anyway), you'll get schema violation, otherwise it will work just fine.


I'm not sure if this is user friendly.


You can obviously catch the schema violation and provided a meaningful 
error instead.


I don't really have a strong opinion here. My point was to be able to 
hold all the attributes of the old type rule to be able to switch back 
without losing anything. Then the new objectClass would obviously be 
only used so that the older clients don't get the new HBAC rules that 
have the restrictions they don't understand.


On the other hand, we do not want the mess from the older rules there 
anyway if we want to use capabilities of the newer rule type so it might 
be fine. But if user wants to create a new rule from an old one they 
have to go through all the old attributes and manually remove their 
values which may be a bother for them. Also, I believe that there's code 
in SSSD that deals with some of these older attributes and this MIGHT 
cause schema violation even on SSSD side if we want to work with older 
HBAC rules in the same way as with the newer.






I realized that AccessTime is MUST for 'ipahbacrule', so when timerule
('ipahbacrulev2') is removed and somebody deleted accesstime we 
have to

add it back.


It is MAY. The only MUST attribute is accessRuleType, but that is
deprecated as well and should be removed from ipaHBACRuleV2. We only
support allow rules, so when timerule is removed, that's the value you
set accessRuleType to.


Right, sorry.
Martin^2








4) The CLI sections needs more work, especially for non-standard
commands like timerule-test.

I definitely plan to look into the *test commands a bit more, I only 
drafted it quick yesterday.


On the link below is a PROTOTYPE-patched FreeIPA that covers most
of the
CLI functionality (except for the creation of iCalendar strings from
options) for better illustration of the design.

https://github.com/stlaz/freeipa/tree/timerules_2

I will add FreeIPA people that recently had some say about this to
CC so
that we can get the discussion flowing.


Honza











--
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][UPDATE] Time-Based HBAC Policies

[Standa Laznicka]

On 08/26/2016 12:39 PM, Martin Basti wrote:



On 26.08.2016 12:37, Petr Vobornik wrote:

On 08/26/2016 12:23 PM, Martin Basti wrote:


On 26.08.2016 12:20, Alexander Bokovoy wrote:

On Fri, 26 Aug 2016, Jan Cholasta wrote:

On 26.8.2016 11:55, Martin Basti wrote:


On 26.08.2016 11:43, Jan Cholasta wrote:

Hi,

On 11.8.2016 12:34, Stanislav Laznicka wrote:

Hello,

I updated the design of the Time-Based HBAC Policies according 
to the

discussion we led here earlier. Please check the design page
http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The
biggest
changes are in the Implementation and Feature Management 
sections. I

also added a short How to Use section.
1) Please use the 'ipa' prefix for new attributes: 
memberTimeRule ->

ipaMemberTimeRule


2) Source hosts are deprecated and thus should be removed from
ipaHBACRuleV2.


3) Since time rules are defined by memberTimeRule, accessTime 
should

be removed from ipaHBACRuleV2.

ad 2) 3)

Because backward compatibility, ipaHBACRuleV2 must contain all
attributes from ipaHBACRule as MAY

Not true.

With current approach, when timerule is added to HBAC, we just 
change

objectclass from 'ipahbacrule' to 'ipahbacrulev2' so we keep all
attributes that was defined in older HBAC. Removing any attrs from
ipaHBACRuleV2 can cause schema violation.

Which is perfectly fine.



I'm not sure if want to handle this in code (removing deprecated
attributes from HBAC entry when timerule is added)

We don't have to do anything. If any of the deprecated attributes are
present when you change the object class (which they shouldn't
anyway), you'll get schema violation, otherwise it will work just 
fine.


I realized that AccessTime is MUST for 'ipahbacrule', so when 
timerule
('ipahbacrulev2') is removed and somebody deleted accesstime we 
have to

add it back.

It is MAY. The only MUST attribute is accessRuleType, but that is
deprecated as well and should be removed from ipaHBACRuleV2. We only
support allow rules, so when timerule is removed, that's the value
you set accessRuleType to.

SSSD does search for HBAC rules by '(objectclass=ipaHBACRule)' filter.
Changing to ipaHBACRuleV2 means these rules will not be found by older
SSSD versions and therefore people will experience problems with older
clients not being able to use new rules even if they would lack time
component.


Older client do not support timerules, so they should not search for
them. HBAC without timerules will be still have 'ipaHBACRule'
objectclass and will work with old clients. Only HBAC with timerules
will have assigned 'ipaHBACRuleV2'

Martin^2

I miss "why" part of "To be able to handle backward compatibility with
ease, a new object called ipaHBACRulev2 is introduced. " in the design
page. If the reason is the above - old client's should ignore time rules
then it has to be mentioned there. Otherwise I don't see a reason to
introduce a new object type instead of extending the current.



It's exactly that - I will mention it there, then.
How do you want to enforce HBAC rule that have set time from 10 to 14 
everyday? With the same objectclass old clients will allow this HBAC 
for all day. Isn't this CVE?



Word.



2. About API and CLI: wasn't there an idea to hide/not provide
--icalfile=file.ics and --time=escaped_icalstring  options in the first
implementation. So that we can limit the support scope to only a subset
of option(the  OPTS part). If arbitrary ical is allowed since the
beginning then we are asking for a lot of bugs filed.



Why hide it if there's no real problem with it? The string/content only 
has to be cut down to the restrictions of one event per VCALENDAR but I 
do not see the problem there.


--
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] [WIP][PATCH] Time-Based HBAC Policies

[Standa Laznicka]

On 05/06/2016 12:28 PM, Stanislav Laznicka wrote:

Hello,

The time rules for FreeIPA effort is now to be found on Github. I 
forked FreeIPA and SSSD repos and added the current state of work there.


https://github.com/stlaz/freeipa/tree/timerules
https://github.com/stlaz/sssd/tree/freeipa-timerules

Please note that if I'll be making changes to the code it will be done 
through rebasing so you may not necessarily be always able to easily 
pull the repository.


I also updated the design so that I may present the current state of 
the effort to SSSD developers. The SSSD code is almost finished - some 
more tests may be necessary and I still need to do python bindings.  
Also, as the pam_hbac module seems to aim for portability, I will need 
to discuss the system of getting time zone information on various 
systems but the current solution should work just fine on Red Hat-like 
and Debian-like distributions.


In the meantime, I published quite a patch for python-icalendar that 
should make it a bit stricter parser but also improve some of its 
behavior: https://github.com/collective/icalendar/pull/192.


Standa

Please note that there's no need to follow this discussion anymore, 
thanks to the team's GitHub effort all further patches and their 
discussion moved to https://github.com/freeipa/freeipa/pull/23.


--
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 0065] Fix ugly quit during external CA installation

[Standa Laznicka]

https://fedorahosted.org/freeipa/ticket/6230

From 33d25d76d71ede4b4d4ac3f57663132ac4c6decb Mon Sep 17 00:00:00 2001
From: Stanislav Laznicka 
Date: Tue, 23 Aug 2016 13:43:24 +0200
Subject: [PATCH] Make installer quit more nicely on external CA installation

cainstance.__spawn_instance() exits in rather weird manner on
successful external CA install. This masks the weird implementation
from the user. :-&

https://fedorahosted.org/freeipa/ticket/6230
---
 ipaserver/install/cainstance.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py
index 2ec02d6628ebc9e3a9bad141ec636c84eab14cef..9ae46bba41a98dd4949ff0e1187cfd5a8016adf9 100644
--- a/ipaserver/install/cainstance.py
+++ b/ipaserver/install/cainstance.py
@@ -591,7 +591,7 @@ class CAInstance(DogtagInstance):
 if self.external == 1:
 print("The next step is to get %s signed by your CA and re-run %s as:" % (self.csr_file, sys.argv[0]))
 print("%s --external-cert-file=/path/to/signed_certificate --external-cert-file=/path/to/external_ca_certificate" % sys.argv[0])
-raise ScriptError(rval=0)
+sys.exit(0)
 else:
 shutil.move(paths.CA_BACKUP_KEYS_P12,
 paths.CACERT_P12)
-- 
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

Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies

[Standa Laznicka]

On 08/19/2016 04:06 PM, Martin Basti wrote:

On 19.08.2016 12:37, Pavel Vomacka wrote:

On 08/16/2016 08:21 AM, Stanislav Laznicka wrote:

On 08/12/2016 06:48 PM, Petr Spacek wrote:

On 11.8.2016 12:34, Stanislav Laznicka wrote:

Hello,

I updated the design of the Time-Based HBAC Policies according to the
discussion we led here earlier. Please check the design page
http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The 
biggest
changes are in the Implementation and Feature Management sections. 
I also

added a short How to Use section.

Thank you for the review! I will add some comments inline.

Nice page!

On the high level it all makes sense.

ad LDAP schema
==
1) Why accessTime attribute is MAY in ipaTimeRule object class?
Does it make sense to have the object without accessTime? I do not 
think so.
My idea was that we allow users prepare a few time rule objects 
before filling them with the actual times.
Also, it could be good to add description attribute to the object 
class and

incorporate it into commands (including find).


Definitely a good idea, I will work that in.

2) Besides all this, I spent few minutes in dark history of IPA. The
accessTime attribute was introduced back in 2009 in commit
"55ba300c7cb59cf05b16cc01281f51d93eb25acf" aka "Incorporate new 
schema for IPAv2".


The commit does not contain any reasoning for the change but I can 
see that
the attribute is already used as MAY in old object classes 
ipaHBACRule and

ipaSELinuxUserMap.

Is any of these a problem?
I believe that the accessTime attribute was originally brought to 
IPA when there was an implementation of time policies for HBAC 
objects and it's been rotting there ever since those capabilities 
were removed. We may eventually use a new attribute for storage of 
the time strings as accessTime by definition is multi-valued which 
is not what's currently desired (although we may end up with it some 
day in the future). However, I don't think any other use of 
accessTime should be a problem as it's been obsoleted for a long time.

Why is it even in ipaSELinuxUserMap object class?
I'm sorry to say I have no idea. I used it for what it originally 
was - a means for storing time strings at HBAC rules.

Commit
55512dc938eb4a9a6655e473beab587e340af55c does not mention any 
reason for doing so.


I cannot see any other problem so the low-level stuff is good and 
can be

implemented.


ad User interface
=
We need to polish the user interface so it really usable.

At least the web interface should contain some shortcuts. E.g. when 
I'm adding

a new HBAC rule, the "time" section should contain also "something" to
immediately add new time rule so I do not need to go to time rules 
first and

then go back to HBAC page.
I'm definitely for creating a field where admin can choose a existing 
time rule when creating a new HBAC. But I'm not sure about 
possibility to create and define new time rule in dialog for creating 
new HBAC. I think that mixing these two things together is like a 
possibility to create a new user when you are creating a user group. 
Which is mixing two different things together. I can imagine a button 
like "Create HBAC and add a new time rule to it" which could store 
new HBAC rule and immediately take admin to the page (or dialog) 
where admin can create a new time rule with prefilled HBAC rule. But 
as you write below it would be good to discuss it with some UX designer.


I'm not UX guru, but if you add button there and show dialog window to 
create new timerule and then automatically assign it to the HBACrule 
it may work for me :)




Similarly, dialog for rule modification should allow to easily 
change all the

values, warn if time rules is shared, and also have an easy way to
'disconnect' the time rule, i.e. make a copy of it and edit only 
the new copy

(instead of the shared original).


All of these points are really good.



All these are user interface things not affecting the low-level stuff.


Maybe you should sat down with some UX designer, talk about these 
cases and

draw some hand-made pictures.

I will add Pavel V. to CC, we may want to discuss this.
I do not believe that this will require any changes in schema so 
you can

polish SSSD and framework implementation in meantime.

On the link below is a PROTOTYPE-patched FreeIPA that covers most 
of the CLI
functionality (except for the creation of iCalendar strings from 
options) for

better illustration of the design.

https://github.com/stlaz/freeipa/tree/timerules_2
Honestly I did not look at the code today :-)

Overall, I'm glad to see current proposal. After so many iteration, 
we reached

something which does not have any glaring problem :-)
It definitely felt better to be writing it with all the previous 
knowledge. Thank you! :-)




LGTM with all previous comments

Thank you for the review, my comments are inline



(Nitpick mode enabled: True)
1.
It may not be clear from design that client is