[Freeipa-devel] [freeipa PR#10] Client-side CSR autogeneration (synchronize)

[LiptonB]

LiptonB's pull request #10: "Client-side CSR autogeneration" was synchronize

See the full pull-request at https://github.com/freeipa/freeipa/pull/10
... or pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/10/head:pr10
git checkout pr10


freeipa-pr-10.patch
Description: application/text/diff
-- 
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 PR#10] Client-side CSR autogeneration (synchronize)

[LiptonB]

LiptonB's pull request #10: "Client-side CSR autogeneration" was synchronize

See the full pull-request at https://github.com/freeipa/freeipa/pull/10
... or pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/10/head:pr10
git checkout pr10


freeipa-pr-10.patch
Description: application/text/diff
-- 
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

[Simo Sorce]

On Fri, 2016-08-26 at 11:37 -0400, Simo Sorce wrote:
> 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.

I notice that SSSD does not like it if there are multiple values on this
attribute, but we could change this easily in older clients when we
update them. worst case the rule will not apply and admins have to
create 2 rules, one with allow and one with allow_with_time.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

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

[Simo Sorce]

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.

-- 
Simo Sorce * Red Hat, Inc * New York

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

[Simo Sorce]

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.

-- 
Simo Sorce * Red Hat, Inc * New York

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

[Alexander Bokovoy]

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.

--
/ Alexander Bokovoy

--
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 PR#30] Print to debug output answer from CA (opened)

[mbasti-rh]

mbasti-rh's pull request #30: "Print to debug output answer from CA" was opened

PR body:
"""
CA request may fail due various erros, without debug output we cannot
decide what is wrong.
"""

See the full pull-request at https://github.com/freeipa/freeipa/pull/30
... or pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/30/head:pr30
git checkout pr30


freeipa-pr-30.patch
Description: application/text/diff
-- 
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 PR#29] Enable LDAPS in replica promotion (opened)

[tomaskrizek]

tomaskrizek's pull request #29: "Enable LDAPS in replica promotion" was opened

PR body:
"""
With CA-less master and CA-less replica, attempting to install CA on replica
would fail. LDAPS has to be enabled during replica promotion, because it is
required by Dogtag.

https://fedorahosted.org/freeipa/ticket/6226
"""

See the full pull-request at https://github.com/freeipa/freeipa/pull/29
... or pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/29/head:pr29
git checkout pr29


freeipa-pr-29.patch
Description: application/text/diff
-- 
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

[Simo Sorce]

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.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
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 PR#21] custodia: include known CA certs in the PKCS#12 file for Dogtag (closed)

[mbasti-rh]

jcholast's pull request #21: "custodia: include known CA certs in the PKCS#12 
file for Dogtag" was closed

See the full pull-request at https://github.com/freeipa/freeipa/pull/21
... or pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/21/head:pr21
git checkout pr21
-- 
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 PR#21] custodia: include known CA certs in the PKCS#12 file for Dogtag (comment)

[mbasti-rh]

mbasti-rh commented on a pull request

"""
Yes, I can reproduce it without this PR. ACK for this
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/21#issuecomment-242751300
-- 
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 PR#21] custodia: include known CA certs in the PKCS#12 file for Dogtag (+ack)

[mbasti-rh]

jcholast's pull request #21: "custodia: include known CA certs in the PKCS#12 
file for Dogtag" label *ack* has been added

See the full pull-request at https://github.com/freeipa/freeipa/pull/21
-- 
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

[Simo Sorce]

On Fri, 2016-08-26 at 11:55 +0200, 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
> 
> 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.

Is there a good reason to "change" the objectclass instead of just
"adding" to it ?
Are v1 and v2 "incompatible" at the object lvl ?
(Sorry I probably knew the answer last I looked at it but I somehow
forgot).

> I'm not sure if want to handle this in code (removing deprecated 
> attributes from HBAC entry when timerule is added)
> 
> I realized that AccessTime is MUST for 'ipahbacrule', so when timerule 
> ('ipahbacrulev2') is removed and somebody deleted accesstime we have to 
> add it back.

What is it set to these days ?

Simo.

> 
> 
> >
> >
> > 4) The CLI sections needs more work, especially for non-standard 
> > commands like timerule-test.
> >
> >>
> >> 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
> >
> 


-- 
Simo Sorce * Red Hat, Inc * New York

-- 
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 PR#21] custodia: include known CA certs in the PKCS#12 file for Dogtag (comment)

[pvoborni]

pvoborni commented on a pull request

"""
Promotion of replica is missing ds.enable_ssl step (or how is it called). Tomas 
is working on it in ticket  https://fedorahosted.org/freeipa/ticket/6226
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/21#issuecomment-242750401
-- 
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 PR#21] custodia: include known CA certs in the PKCS#12 file for Dogtag (comment)

[mbasti-rh]

mbasti-rh commented on a pull request

"""
I cannot connect to LDAPS even if only CA-less servers are installed
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/21#issuecomment-242746093
-- 
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 PR#28] Added a sleep interval after domainlevel raise in tests (+pushed)

[mbasti-rh]

ofayans's pull request #28: "Added a sleep interval after domainlevel raise in 
tests" label *pushed* has been added

See the full pull-request at https://github.com/freeipa/freeipa/pull/28
-- 
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 PR#28] Added a sleep interval after domainlevel raise in tests (comment)

[mbasti-rh]

mbasti-rh commented on a pull request

"""
Fixed upstream
master:
https://fedorahosted.org/freeipa/changeset/9dffe55e6582bca7b1a4b8ad3042c63c5ccde51a
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/28#issuecomment-242747200
-- 
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 PR#28] Added a sleep interval after domainlevel raise in tests (closed)

[mbasti-rh]

ofayans's pull request #28: "Added a sleep interval after domainlevel raise in 
tests" was closed

See the full pull-request at https://github.com/freeipa/freeipa/pull/28
... or pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/28/head:pr28
git checkout pr28
-- 
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 PR#28] Added a sleep interval after domainlevel raise in tests (+ack)

[mbasti-rh]

ofayans's pull request #28: "Added a sleep interval after domainlevel raise in 
tests" label *ack* has been added

See the full pull-request at https://github.com/freeipa/freeipa/pull/28
-- 
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 PR#28] Added a sleep interval after domainlevel raise in tests (comment)

[ofayans]

ofayans commented on a pull request

"""
Done.
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/28#issuecomment-242733667
-- 
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 PR#28] Added a sleep interval after domainlevel raise in tests (synchronize)

[ofayans]

ofayans's pull request #28: "Added a sleep interval after domainlevel raise in 
tests" was synchronize

See the full pull-request at https://github.com/freeipa/freeipa/pull/28
... or pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/28/head:pr28
git checkout pr28


freeipa-pr-28.patch
Description: application/text/diff
-- 
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 PR#23] Time-Based HBAC Policies (synchronize)

[stlaz]

stlaz's pull request #23: "Time-Based HBAC Policies" was synchronize

See the full pull-request at https://github.com/freeipa/freeipa/pull/23
... or pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/23/head:pr23
git checkout pr23


freeipa-pr-23.patch
Description: application/text/diff
-- 
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 PR#23] Time-Based HBAC Policies (synchronize)

[stlaz]

stlaz's pull request #23: "Time-Based HBAC Policies" was synchronize

See the full pull-request at https://github.com/freeipa/freeipa/pull/23
... or pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/23/head:pr23
git checkout pr23


freeipa-pr-23.patch
Description: application/text/diff
-- 
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 PR#28] Added a sleep interval after domainlevel raise in tests (comment)

[mbasti-rh]

mbasti-rh commented on a pull request

"""
Maybe comment next to sleep why the sleep is there, may not hurt
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/28#issuecomment-242727734
-- 
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 PR#21] custodia: include known CA certs in the PKCS#12 file for Dogtag (comment)

[mbasti-rh]

mbasti-rh commented on a pull request

"""
On replica:

```
[root@vm-058-017 ~]# ipa-ca-install
Directory Manager (existing master) password: 

Run connection check to master
Connection check OK
Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes 30 
seconds
  [1/25]: creating certificate server user
  [2/25]: creating certificate server db
  [3/25]: setting up initial replication
Starting replication, please wait until this has completed.
Update in progress, 2 seconds elapsed
Update succeeded

  [4/25]: creating installation admin user
  [5/25]: setting up certificate server
  [6/25]: stopping instance to update CS.cfg
  [7/25]: backing up CS.cfg
  [8/25]: disabling nonces
  [9/25]: set up CRL publishing
  [10/25]: enable PKIX certificate path discovery and validation
  [11/25]: set up client auth to db
  [12/25]: destroying installation admin user
  [13/25]: Ensure lightweight CAs container exists
  [14/25]: Configure lightweight CA key retrieval
  [15/25]: starting instance
ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to restart the 
Dogtag instance.See the installation log for details.
  [16/25]: importing CA chain to RA certificate database
  [error] RuntimeError: Unable to retrieve CA chain: request failed with HTTP 
status 500
```

```
2016-08-26T12:41:39Z DEBUG The CA status is: check interrupted due to error: 
Retrieving CA status failed with status 500
2016-08-26T12:41:39Z DEBUG Waiting for CA to start...
2016-08-26T12:41:40Z DEBUG request POST 
http://vm-058-017.abc.idm.lab.eng.brq.redhat.com:8080/ca/admin/ca/getStatus
2016-08-26T12:41:40Z DEBUG request body ''
2016-08-26T12:41:40Z DEBUG response status 500
2016-08-26T12:41:40Z DEBUG response headers {'content-length': '2351', 
'content-language': 'en', 'server': 'Apache-Coyote/1.1', 'connection': 'close', 
'date': 'Fri, 26 Aug 2016 12:41:40 GMT', 'content-type': 'te
xt/html;charset=utf-8'}
2016-08-26T12:41:40Z DEBUG response body 'Apache Tomcat/8.0.32 - Error reportH1 
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:
#525D76;font-size:22px;} H2 
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;}
 H3 
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;
} BODY 
{font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B 
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P 
{font-family:Tahoma,Arial,sans-serif;background:wh
ite;color:black;font-size:12px;}A {color : black;}A.name {color : black;}.line 
{height: 1px; background-color: #525D76; border: none;} 
HTTP Status 500 - Subsystem unavailabletype Exception reportmessage 
Subsystem unavailabledescription The server encountered 
an internal error that prevented it from fulfilling this requ
est.exceptionjavax.ws.rs.ServiceUnavailableException:
 Subsystem 
unavailable\n\tcom.netscape.cms.tomcat.ProxyRealm.findSecurityConstraints(ProxyRealm.java:138)\n\torg.apache.catalina.au
thenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:496)\n\torg.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)\n\torg.apache.catalina.valves.AbstractAccessLogValve.invoke(Abstra
ctAccessLogValve.java:616)\n\torg.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:522)\n\torg.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1095)\n\torg.apa
che.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:672)\n\torg.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1500)\n\torg.apache.tomcat.util.net.NioEn
dpoint$SocketProcessor.run(NioEndpoint.java:1456)\n\tjava.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)\n\tjava.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:
617)\n\torg.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)\n\tjava.lang.Thread.run(Thread.java:745)\nnote
 The full stack trace of the root cause is available in
 the Apache Tomcat/8.0.32 logs.Apache 
Tomcat/8.0.32'
2016-08-26T12:41:40Z DEBUG The CA status is: check interrupted due to error: 
Retrieving CA status failed with status 500
2016-08-26T12:41:40Z DEBUG Waiting for CA to start...
2016-08-26T12:41:41Z DEBUG Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", 
line 194, in start_instance
self.start('pki-tomcat')
  File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 
345, in start
self.service.start(instance_name, capture_output=capture_output, wait=wait)
  File "/usr/lib/python2.7/site-packages/ipaplatform/redhat/services.py", line 
218, in start
self.wait_until_running()
  File "/usr/lib/python2.7/site-packages/ipaplatform/redhat/services.py", line 
212, in wait_until_running
raise RuntimeError('CA did not start in %ss' % timeout)
RuntimeError: CA did not start in 300.0s
```

Debug 

[Freeipa-devel] [freeipa PR#28] Added a sleep interval after domainlevel raise in tests (opened)

[ofayans]

ofayans's pull request #28: "Added a sleep interval after domainlevel raise in 
tests" was opened

PR body:
"""
Due to race conditions the test sometimes catches 2 one-way segments instead of
one bidirectional. We need to give the master time to merge the one-way
segments before we test the output.

https://fedorahosted.org/freeipa/ticket/6265
"""

See the full pull-request at https://github.com/freeipa/freeipa/pull/28
... or pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/28/head:pr28
git checkout pr28


freeipa-pr-28.patch
Description: application/text/diff
-- 
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: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

[Freeipa-devel] [freeipa PR#27] Tests: Fix integration sudo tests setup and checks (edited)

[mirielka]

mirielka's pull request #27: "Tests: Fix integration sudo tests setup and 
checks" was edited

See the full pull-request at https://github.com/freeipa/freeipa/pull/27
... or pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/27/head:pr27
git checkout pr27
-- 
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 PR#27] Tests: Fix integration sudo tests setup and checks (opened)

[mirielka]

mirielka's pull request #27: "Tests: Fix integration sudo tests setup and 
checks" was opened

PR body:
"""
Adding 'defaults' sudorule to prevent requesting further user authentication.
Adding checks that if a user should be rejected access, a proper error message
is displayed.

https://fedorahosted.org/freeipa/ticket/6262
"""

See the full pull-request at https://github.com/freeipa/freeipa/pull/27
... or pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/27/head:pr27
git checkout pr27


freeipa-pr-27.patch
Description: application/text/diff
-- 
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 PR#26] Don't ignore --ignore-last-of-role for last CA (opened)

[stlaz]

stlaz's pull request #26: "Don't ignore --ignore-last-of-role for last CA" was 
opened

PR body:
"""
Use a handler created for the purpose of deciding whether
to raise exception or not.

https://fedorahosted.org/freeipa/ticket/6259
"""

See the full pull-request at https://github.com/freeipa/freeipa/pull/26
... or pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/26/head:pr26
git checkout pr26


freeipa-pr-26.patch
Description: application/text/diff
-- 
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

[Petr Vobornik]

On 08/26/2016 12:47 PM, Standa Laznicka wrote:
> 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.

Thanks

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

OK then.
-- 
Petr Vobornik

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

[Petr Vobornik]

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

My point is that the design is missing the explanation.

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


-- 
Petr Vobornik

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

[Martin Basti]

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.


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?





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.



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

[Petr Vobornik]

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.


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.

-- 
Petr Vobornik

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

[Martin Basti]

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

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

[Jan Cholasta]

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



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











--
Jan Cholasta

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

[Martin Basti]

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.





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.



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

[Alexander Bokovoy]

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.

--
/ Alexander Bokovoy

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

[Jan Cholasta]

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.









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



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






--
Jan Cholasta

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

[Martin Basti]

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


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.



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


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







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




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

[Freeipa-devel] [freeipa PR#25] Added install check before executing ipa-* command (opened)

[Akasurde]

Akasurde's pull request #25: "Added install check before executing ipa-* 
command" was opened

PR body:
"""
Fixes: https://fedorahosted.org/freeipa/ticket/6261

Signed-off-by: Abhijeet Kasurde 
"""

See the full pull-request at https://github.com/freeipa/freeipa/pull/25
... or pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/25/head:pr25
git checkout pr25


freeipa-pr-25.patch
Description: application/text/diff
-- 
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

[Jan Cholasta]

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.



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




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

--
Jan Cholasta

--
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 PR#20] cert: include CA name in cert command output (synchronize)

[jcholast]

jcholast's pull request #20: "cert: include CA name in cert command output" was 
synchronize

See the full pull-request at https://github.com/freeipa/freeipa/pull/20
... or pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/20/head:pr20
git checkout pr20


freeipa-pr-20.patch
Description: application/text/diff
-- 
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 PR#20] cert: include CA name in cert command output (synchronize)

[jcholast]

jcholast's pull request #20: "cert: include CA name in cert command output" was 
synchronize

See the full pull-request at https://github.com/freeipa/freeipa/pull/20
... or pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/20/head:pr20
git checkout pr20


freeipa-pr-20.patch
Description: application/text/diff
-- 
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] 0095 cert-request: allow directoryName in SAN extension

[Jan Cholasta]

Hi,

On 22.7.2016 07:18, Fraser Tweedale wrote:

While I was poking around SAN-processing code, I decided to
implement a small enhancement: allowing the subject principal's DN
to appear in SAN.

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

Patch depends on my other patches 0090, 0092, 0093, 0094.


I don't think this is how DN SANs are supposed to be handled. For 
example, see this bit about DN name constraints in RFC 5280 section 
4.2.1.10:


   Restrictions of the form directoryName MUST be applied to the subject
   field in the certificate (when the certificate includes a non-empty
   subject field) and to any names of type directoryName in the
   subjectAltName extension.

It would appear to me that DN SANs only provide additional values to the 
subject name of the certificate and thus should be treated the same way 
as the subject name.


We don't impose any restrictions on subject names with regard to DN of 
the subject LDAP entry, so I think we should not do it for DN SANs as 
well. Or, alternatively, we should do it for both.


Honza

--
Jan Cholasta

--
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] 0097 Add options to write lightweight CA cert or chain to file

[Jan Cholasta]

On 19.8.2016 13:11, Fraser Tweedale wrote:

Bump for review.

On Wed, Aug 17, 2016 at 12:09:39AM +1000, Fraser Tweedale wrote:

On Tue, Aug 16, 2016 at 08:10:08AM +0200, Jan Cholasta wrote:

On 16.8.2016 07:24, Fraser Tweedale wrote:

On Mon, Aug 15, 2016 at 08:19:33AM +0200, Jan Cholasta wrote:

On 9.8.2016 16:47, Fraser Tweedale wrote:

On Mon, Aug 08, 2016 at 10:49:27AM +0200, Jan Cholasta wrote:

On 8.8.2016 09:06, Fraser Tweedale wrote:

On Mon, Aug 08, 2016 at 08:54:05AM +0200, Jan Cholasta wrote:

Hi,

On 8.8.2016 06:34, Fraser Tweedale wrote:

Please review the attached patch with adds --certificate-out and
--certificate-chain-out options to `ca-show' command.

Note that --certificate-chain-out currently writes a bogus file due
to a bug in Dogtag that will be fixed in this week's build.

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


1) The client-side *-out options should be defined on the client side, not
on the server side.


Will option defined on client side be propagated to, and observable
in the ipaserver plugin?  The ipaserver plugin needs to observe that
*-out has been requested and executes additional command(s) on that
basis.


Is there a reason not to *always* return the certs?


We hit Dogtag to retrieve them.


I don't think that's an issue in a -show command.


cert_show is invoked by other commands (cert_find*, cert_show,
cert_request, cert_status, ca_del) but these all hit Dogtag anyway
so I suppose that's fine.  I'll return the cert *and* the chain in
separate attributes, unconditionally.







2) I don't think there should be additional information included in summary
(and it definitely should not be multi-line). I would rather inform the user
via an error message when unable to write the files.


I was just following the pattern of other commands that write certs,
profile config, etc.  Apart from consistency with other commands I
agree that there is no need to have it.  So I will remove it.


If you think there is an actual value in informing the user about
successfully writing the files, please use ipalib.messages for the job.


3) IMO a better format for the certificate chain than PKCS#7 would be
concatenated PEM, as that's the most commonly used format in IPA (in
installers, there are no cert chains in API commands ATM).


Sure, but the main use case isn't IPA.  Other apps require PKCS #7
or concatenated PEMs, but sometimes they must be concatenated
forward, and othertimes backwards.  There is no one size fits all.


True, which is exactly why I think we should at least be self-consistent and
use concatenated PEM (and multi-value DER over the wire).


Dogtag returns a PKCS7 (either DER or PEM, according to HTTP Accept
header).

If we want list-of-PEMs between server and client we have to convert
on the server.  Do we have a good way of doing this without exec'ing
`openssl pkcs7' on the server?  Is it acceptable to exec 'openssl'
to do the conversion on the server?  python-nss does not have PKCS7
functions and I am not keen on adding a pyasn1 PKCS7 parser just for
the sake of pushing bits as list-of-PEMs.


I'm afraid we can't avoid conversion to/from PKCS#7 one way or the other.
For example, if we added a call to retrieve external CA chain using certs
from cn=certificates,cn=ipa,cn=etc, we would have to convert the result to
PKCS#7 if it was our cert chain format of choice.

What we can avoid though is executing "openssl pkcs7" to do the conversion -
we can use an approach similar to our DNSSEC code and use python-cffi to
call libcrypto's PKCS#7 conversion routines instead.


I had a look at the OpenSSL API for parsing PKCS #7; now I prefer to
exec `openssl' to do the job :)

I will transmit DER-encoded PKCS #7 object on the wire; we cannot
used multi-valued DER attribute because order is important.   Client
will convert to PEMs.


Well, my point was not to send PKCS#7 over the wire, so that clients
(including 3rd party clients) do not have to convert from PKCS#7 themselves.

In fact we can use multi-valued DER - whatever you send over the wire from
the server will be received in the exact same order by the client. Even if
it wasn't, you can easily restore the order by matching issuer and subject
names of the certificates.



Should have new patch on list this afternoon.

Thanks,
Fraser



FWIW, man pages and code suggest that PKCS #7 is accepted in
installer, etc.


True, but that's a relatively new feature (since 4.1) and the installer
internally executes "openssl pkcs7" to convert PKCS #7 to list of certs :-)




We can add an option to control the format later, but for now,
Dogtag returns a PKCS #7 (PEM or DER) so let's go with that.  Worst
case is an admin has to invoke `openssl pkcs7' and concat the certs
themselves.


AFAIK none of NSS, OpenSSL or p11-kit can use PKCS#7 cert chains directly,
so I'm afraid the worst case would happen virtually always.


If you're OK with invoking OpenSSL on the client to convert PKCS #7
to list-of-PEMs (similar to what is done in

Re: [Freeipa-devel] [PATCH] 0090, 0092..0094 cert-show: show subject alternative names

[Jan Cholasta]

On 23.8.2016 11:46, Fraser Tweedale wrote:

Thanks for review; rebased and updated patch attached.  Only 0090
has substantive changes.

Cheers,
Fraser

On Mon, Aug 22, 2016 at 09:22:08AM +0200, Jan Cholasta wrote:

On 19.8.2016 13:11, Fraser Tweedale wrote:

Bump for review.

On Mon, Aug 15, 2016 at 05:15:16PM +1000, Fraser Tweedale wrote:

Thanks for reviews.  Rebased and updated patches attached (and one
new patch).  No substantive changes to 92..94.  Patch order is:

92-2, 93-2, 94-2, 98, 90-3

Other comments inline.

Thanks,
Fraser

On Fri, Aug 12, 2016 at 11:33:28AM +0200, Jan Cholasta wrote:

Patch 0092: ACK

Patch 0093: ACK

Patch 0094: ACK


Please fix this PEP8 issue before pushing:

./ipaserver/plugins/cert.py:597:17: W503 line break before binary operator


Patch 0098: ACK



Patch 0090:

1) Generic otherNames (san_other) do not work correctly. The OID is not
included in the value and names with complex type other than
KerberosPrincipal are not parsed correctly. The value should include the OID
and DER blob of the name.


Updated to use "OID:b64(DER)" as the attribute value.


OK.




2) With --all, san_other should be included in the result for all
otherNames, even the known ones, to provide (limited) forward compatibility.


Done; when --all given, known otherName kinds are included in
'san_other' attribute in addition to their own attribute.


OK.




3) Do we have to support *all* the name types? I mean we could, for the sake
of completeness, but it might be easier to just keep the few ones we
actually care about (email, DNS name, principal name, UPN and directory name
in your patch 0095).


Yeah, why not support them all?  See also Petr's comments in other
branch of thread.


Works for me, but see Lukáš's reply, I think he has a point. Maybe we can
make a compromise and show only supported name types by default and
everything with --all?


Now only showing DNSName, RFC822Name, DirectoryName, UPN and
KRBPrincipalName unless --all is given.




4)

+obj.setdefault(attr_name, []).append(unicode(name))

The value should not (always) be unicode, but of the type declared by the
param (unicode or ipapython.kerberos.Principal or
ipapython.dnsutil.DNSName).


I now pass the value to the constructor of whatever type the
parameter uses:

attr_value = self.params[attr_name].type(name_formatted)
obj.setdefault(attr_name, []).append(attr_value)


OK.


5) san_directoryname should be a DNParam rather than Str.


Fixed, thanks.



6) Could we use "Subject " instead of "Subject Alternative Name
()" for labels? Or something else which is shorter and has the
name type more "visible" than the current form.


No worries.



7) The patch needs a rebase.


Thanks, ACK, but I have a couple additional nitpicks:

8) I think we should move the san_* param definitions right after 
subject param definition, so that they are visually close in CLI output.



9) san_directoryname should be added to default_attrs in patch 95, not here.

I took the liberty of fixing these myself.

Pushed to master: 48aaf2bbf5df6dcedaa466753c8fafb478cb31b2

Honza

--
Jan Cholasta

--
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 PR#24] [master, ipa-4-3] Raise error when running ipa-adtrust-install with empty netbios--name (opened)

[mirielka]

mirielka's pull request #24: "[master, ipa-4-3] Raise error when running 
ipa-adtrust-install with empty netbios--name" was opened

PR body:
"""
When running ipa-adtrust-install, a netbios-name option must be specified.
Currently if an invalid netbios name in form of empty string is specified, the
installation proceeds, but changes the invalid value to a netbios name
determined from domain name without any notification.

Fixing this so that any attempt to supply empty string as netbios name fails
with error in case of unattended installation, or to request input of valid
netbios name from command line during normal installation.

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

**Note - newly intended behavirour of ipa-adtrust-install:**
- unattended installation with --netbios-name="" fails
- unattended installation without --netbios-name specification proceeds and 
uses default value derived from domain name
- normal installation in both cases requests inserting of valid netbios name
"""

See the full pull-request at https://github.com/freeipa/freeipa/pull/24
... or pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/24/head:pr24
git checkout pr24


freeipa-pr-24.patch
Description: application/text/diff
-- 
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 PR#24] [master, ipa-4-3] Raise error when running ipa-adtrust-install with empty netbios--name (edited)

[mirielka]

mirielka's pull request #24: "[master, ipa-4-3] Raise error when running 
ipa-adtrust-install with empty netbios--name" was edited

See the full pull-request at https://github.com/freeipa/freeipa/pull/24
... or pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/24/head:pr24
git checkout pr24
-- 
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