[Freeipa-devel] [PATCH] 0524 Add managed read permission to config

2014-04-14 Thread Petr Viktorin 

Read access is given to all authenticated users.

--
Petr³
From 2b41456b18e4ac49b07c4cbd65add0c16c8f25c4 Mon Sep 17 00:00:00 2001
From: Petr Viktorin 
Date: Wed, 26 Mar 2014 14:56:30 +0100
Subject: [PATCH] Add managed read permission to config

Part of the work for: https://fedorahosted.org/freeipa/ticket/3566
---
 ipalib/plugins/config.py | 21 +
 1 file changed, 21 insertions(+)

diff --git a/ipalib/plugins/config.py b/ipalib/plugins/config.py
index 05369be4e93052f18c6cefa03621d651f470749b..e116e82398e5b5b0e3b25789819b6be1e695bfa7 100644
--- a/ipalib/plugins/config.py
+++ b/ipalib/plugins/config.py
@@ -94,6 +94,27 @@ class config(LDAPObject):
 'ipaselinuxusermapdefault', 'ipaconfigstring', 'ipakrbauthzdata',
 'ipauserauthtype'
 ]
+container_dn = DN(('cn', 'ipaconfig'), ('cn', 'etc'))
+permission_filter_objectclasses = ['ipaguiconfig']
+managed_permissions = {
+'System: Read Global Configuration': {
+'replaces_global_anonymous_aci': True,
+'ipapermbindruletype': 'all',
+'ipapermright': {'read', 'search', 'compare'},
+'ipapermdefaultattr': {
+'ipacertificatesubjectbase', 'ipaconfigstring',
+'ipadefaultemaildomain', 'ipadefaultloginshell',
+'ipadefaultprimarygroup', 'ipagroupobjectclasses',
+'ipagroupsearchfields', 'ipahomesrootdir',
+'ipakrbauthzdata', 'ipamaxusernamelength',
+'ipamigrationenabled', 'ipapwdexpadvnotify',
+'ipaselinuxusermapdefault', 'ipaselinuxusermaporder',
+'ipasearchrecordslimit', 'ipasearchtimelimit',
+'ipauserauthtype', 'ipauserobjectclasses',
+'ipausersearchfields', 'ipacustomfields',
+},
+},
+}
 
 label = _('Configuration')
 label_singular = _('Configuration')
-- 
1.9.0

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

[Freeipa-devel] [PATCH] 0523 Fix expected output in permission tests

2014-04-14 Thread Petr Viktorin 
It turns out the test failure caused by the realmdomains ACI was not a 
single occurrence. Another one was caused by Read Group Password Policy.


--
Petr³
From 4eb4c1fe3a0fe22dd15b1f9c7ed10aa3d8098cb4 Mon Sep 17 00:00:00 2001
From: Petr Viktorin 
Date: Mon, 14 Apr 2014 20:51:29 +0200
Subject: [PATCH] Fix expected output in permission tests

There is now a second permission affecting krbMinPwdLife.
Add it to expected output.

---
 ipatests/test_xmlrpc/test_old_permission_plugin.py | 9 +++--
 ipatests/test_xmlrpc/test_permission_plugin.py | 9 +++--
 2 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/ipatests/test_xmlrpc/test_old_permission_plugin.py b/ipatests/test_xmlrpc/test_old_permission_plugin.py
index 56dd4435c2996114100334873d72f99201ec841a..c9f7e885778240320497c5ce8146f2d17c7ce4c5 100644
--- a/ipatests/test_xmlrpc/test_old_permission_plugin.py
+++ b/ipatests/test_xmlrpc/test_old_permission_plugin.py
@@ -461,15 +461,20 @@ class test_old_permission(Declarative):
 command=('permission_find', [], {'pkey_only': True,
  'attrs': [u'krbminpwdlife']}),
 expected=dict(
-count=1,
+count=2,
 truncated=False,
-summary=u'1 permission matched',
+summary=u'2 permissions matched',
 result=[
 {
 'dn': DN(('cn','Modify Group Password Policy'),
  api.env.container_permission, api.env.basedn),
 'cn': [u'Modify Group Password Policy'],
 },
+{
+'dn': DN(('cn', 'System: Read Group Password Policy'),
+ api.env.container_permission, api.env.basedn),
+'cn': [u'System: Read Group Password Policy'],
+},
 ],
 ),
 ),
diff --git a/ipatests/test_xmlrpc/test_permission_plugin.py b/ipatests/test_xmlrpc/test_permission_plugin.py
index 105f713f5e953821685baa9caba279e7e3940944..d593dd98670334d2ef696f4b632d00943c9862d6 100644
--- a/ipatests/test_xmlrpc/test_permission_plugin.py
+++ b/ipatests/test_xmlrpc/test_permission_plugin.py
@@ -752,15 +752,20 @@ class test_permission(Declarative):
 command=('permission_find', [], {'pkey_only': True,
  'attrs': [u'krbminpwdlife']}),
 expected=dict(
-count=1,
+count=2,
 truncated=False,
-summary=u'1 permission matched',
+summary=u'2 permissions matched',
 result=[
 {
 'dn': DN(('cn','Modify Group Password Policy'),
  api.env.container_permission, api.env.basedn),
 'cn': [u'Modify Group Password Policy'],
 },
+{
+'dn': DN(('cn', 'System: Read Group Password Policy'),
+ api.env.container_permission, api.env.basedn),
+'cn': [u'System: Read Group Password Policy'],
+},
 ],
 ),
 ),
-- 
1.9.0

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCHES] 0521-0522 - Add managed read permissions to krbtpolicy & Allow anonymous read access to Kerberos realm container name

2014-04-14 Thread Simo Sorce 
On Mon, 2014-04-14 at 18:54 +0200, Petr Viktorin wrote:
> Hello,
> 
> The first patch adds default read permissions to krbtpolicy. Since the 
> plugin manages entries in two trees, there are two permissions. Since 
> two permissions are needed to cover krbtpolicy, it can't be used as a 
> permission's --type.
> The permissions are added to a new privilege, 'Kerberos Ticket Policy 
> Readers'.
> 
> The second patch adds an ACI for reading the Kerberos realm name. Since 
> client enrollment won't work without this, I don't see a reason for 
> having it managed by a permission.
> 

LGTM

Simo.

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

[Freeipa-devel] [PATCHES] 0521-0522 - Add managed read permissions to krbtpolicy & Allow anonymous read access to Kerberos realm container name

2014-04-14 Thread Petr Viktorin 

Hello,

The first patch adds default read permissions to krbtpolicy. Since the 
plugin manages entries in two trees, there are two permissions. Since 
two permissions are needed to cover krbtpolicy, it can't be used as a 
permission's --type.
The permissions are added to a new privilege, 'Kerberos Ticket Policy 
Readers'.


The second patch adds an ACI for reading the Kerberos realm name. Since 
client enrollment won't work without this, I don't see a reason for 
having it managed by a permission.


--
Petr³
From 3b14c13b5584b525fd07f0eb0ddb9923361d290e Mon Sep 17 00:00:00 2001
From: Petr Viktorin 
Date: Wed, 26 Mar 2014 17:11:23 +0100
Subject: [PATCH] Add managed read permissions to krbtpolicy

Unlike other objects, the ticket policy is stored in different
subtrees: global policy in cn=kerberos and per-user policy in
cn=users,cn=accounts.
Add two permissions, one for each location.

Part of the work for: https://fedorahosted.org/freeipa/ticket/3566
---
 install/updates/40-delegation.update |  7 +++
 ipalib/plugins/krbtpolicy.py | 38 +++-
 2 files changed, 44 insertions(+), 1 deletion(-)

diff --git a/install/updates/40-delegation.update b/install/updates/40-delegation.update
index 27e605789ba152ac61796217ca12a603958931c1..17be6915e82c4893a66dbc8625e2e9ab36af1aa0 100644
--- a/install/updates/40-delegation.update
+++ b/install/updates/40-delegation.update
@@ -408,3 +408,10 @@ dn: cn=Password Policy Readers,cn=privileges,cn=pbac,$SUFFIX
 default:objectClass: top
 default:cn: Password Policy Readers
 default:description: Read password policies
+
+dn: cn=Kerberos Ticket Policy Readers,cn=privileges,cn=pbac,$SUFFIX
+default:objectClass: nestedgroup
+default:objectClass: groupofnames
+default:objectClass: top
+default:cn: Kerberos Ticket Policy Readers
+default:description: Read global and per-user Kerberos ticket policy
diff --git a/ipalib/plugins/krbtpolicy.py b/ipalib/plugins/krbtpolicy.py
index a05583dfb4d3067a1a7f1e097859eac26c3be2ae..4ae676dc5b7ece54c57c9d99afea92ca397b36be 100644
--- a/ipalib/plugins/krbtpolicy.py
+++ b/ipalib/plugins/krbtpolicy.py
@@ -75,8 +75,44 @@ class krbtpolicy(LDAPObject):
 object_name = _('kerberos ticket policy settings')
 default_attributes = ['krbmaxticketlife', 'krbmaxrenewableage']
 limit_object_classes = ['krbticketpolicyaux']
+# permission_filter_objectclasses is deliberately missing,
+# so it is not possible to create a permission of `--type krbtpolicy`.
+# This is because we need two permissions to cover both global and per-user
+# policies.
+managed_permissions = {
+'System: Read Default Kerberos Ticket Policy': {
+'non_object': True,
+'replaces_global_anonymous_aci': True,
+'ipapermtargetfilter': ['(objectclass=krbticketpolicyaux)'],
+'ipapermlocation': DN(container_dn, api.env.basedn),
+'ipapermbindruletype': 'permission',
+'ipapermright': {'read', 'search', 'compare'},
+'ipapermdefaultattr': {
+'krbdefaultencsalttypes', 'krbmaxrenewableage',
+'krbmaxticketlife', 'krbsupportedencsalttypes',
+'objectclass',
+},
+'default_privileges': {
+'Kerberos Ticket Policy Readers',
+},
+},
+'System: Read User Kerberos Ticket Policy': {
+'non_object': True,
+'replaces_global_anonymous_aci': True,
+'ipapermlocation': DN(api.env.container_user, api.env.basedn),
+'ipapermtargetfilter': ['(objectclass=krbticketpolicyaux)'],
+'ipapermbindruletype': 'permission',
+'ipapermright': {'read', 'search', 'compare'},
+'ipapermdefaultattr': {
+'krbmaxrenewableage', 'krbmaxticketlife',
+},
+'default_privileges': {
+'Kerberos Ticket Policy Readers',
+},
+},
+}
 
-label=_('Kerberos Ticket Policy')
+label = _('Kerberos Ticket Policy')
 label_singular = _('Kerberos Ticket Policy')
 
 takes_params = (
-- 
1.9.0

From 032c670a403953d3ef033f58c60299845e9ebe0b Mon Sep 17 00:00:00 2001
From: Petr Viktorin 
Date: Wed, 26 Mar 2014 17:11:23 +0100
Subject: [PATCH] Allow anonymous read access to Kerberos realm container name

Part of the work for: https://fedorahosted.org/freeipa/ticket/3566
---
 install/updates/20-aci.update | 4 
 1 file changed, 4 insertions(+)

diff --git a/install/updates/20-aci.update b/install/updates/20-aci.update
index e9e1fe9db4d9c594ae0485c6f7cec8a668a8ff92..94707660decb8dce83916a74b550b28fe4da7e35 100644
--- a/install/updates/20-aci.update
+++ b/install/updates/20-aci.update
@@ -24,3 +24,7 @@ dn: $SUFFIX
 # Read access to containers
 dn: $SUFFIX
 add:aci:'(targetfilter="(objectclass=nsContainer)")(target!="ldap:///cn=etc,$SUFFIX";)(targetattr="objectclass || cn")(version 3.0; acl "Anonymous read access to containers"; allow

Re: [Freeipa-devel] New ACIs for cn=etc

2014-04-14 Thread Simo Sorce 
On Mon, 2014-04-14 at 12:55 +0200, Martin Kosek wrote:
> When heading for a lunch today, I had a discussion with Petr3 about ACIs for
> cn=etc,SUFFIX. On our initial meeting back at DevConf.cz time, we said we will
> simply allow all attributes in cn=etc for authenticated users and will just
> exclude the blacklisted attributes (for context, see ticket #3566).
> 
> I personally think it is not the best thing to do as it will just move the
> problem we had with all-allowing ACI one level down from SUFFIX to cn=etc. It
> would be better to add normal ACIs for cn=etc as well.
> 
> I searched for nsContainer's in cn=etc and IMO the situation is not so bad, it
> seems straightforward what ACIs would be needed:
> 
> ==
> dn: cn=etc,SUFFIX
> - ADD aci allowing reading nsContainer for anonymous, EXCEPT:
>   - cn=virtual operations,cn=etc,SUFFIX
>   - cn=masters,cn=ipa,cn=etc,SUFFIX
>   - cn=Managed Entries,cn=etc,SUFFIX
> 
> dn: cn=sysaccounts,cn=etc,SUFFIX
> - ADD aci allowing reading all attributes but password attributes (people may
> add unstructured accounts following different objectclasses)
> 
> dn: cn=ipa,cn=etc,SUFFIX
> - no ACI needed
> 
> dn: cn=masters,cn=ipa,cn=etc,SUFFIX
> - ADD aci allowing reading hosts (to have it separate from global cn=etc one 
> so
> that we can once assign it only to ipamasters hostgroup for example)
> 
> dn: cn=replicas,cn=ipa,cn=etc,SUFFIX
> - ADD aci allowing reading replicas for authenticated users (masters)
> 
> dn: cn=dna,cn=ipa,cn=etc,SUFFIX
> - ADD aci allowing reading dnaSharedConfig objects for authenticated
> 
> dn: cn=posix-ids,cn=dna,cn=ipa,cn=etc,SUFFIX
> - no ACI needed
> 
> dn: cn=ca_renewal,cn=ipa,cn=etc,SUFFIX
> - ADD aci allowing reading for authenticated users (hosts' certmonger)
> 
> dn: cn=s4u2proxy,cn=etc,SUFFIX
> - no ACI needed at this point, KDC access it with DM privileges AFAIK
> 
> dn: cn=ipaConfig,cn=etc,SUFFIX
> - ADD aci allowing reading ipaConfigObject attributes for authenticated users.
> We already plan aci allowing writing them
> 
> dn: cn=ranges,cn=etc,SUFFIX
> - ADD aci allowing reading ipaIDrange for authenticated users
> 
> dn: cn=virtual operations,cn=etc,SUFFIX
> - ADD aci allowing reading/updating virtual operations, assign to RBAC 
> privileges
> 
> dn: cn=retrieve certificate,cn=virtual operations,cn=etc,SUFFIX
> dn: cn=request certificate,cn=virtual operations,cn=etc,SUFFIX
> dn: cn=request certificate different host,cn=virtual operations,SUFFIX
> dn: cn=certificate status,cn=virtual operations,cn=etc,SUFFIX
> dn: cn=revoke certificate,cn=virtual operations,cn=etc,SUFFIX
> dn: cn=certificate remove hold,cn=virtual operations,cn=etc,SUFFIX
> - no ACI needed
> 
> dn: cn=Managed Entries,cn=etc,SUFFIX
> - no ACI needed, not managed by IPA users
> 
> dn: cn=automember,cn=etc,SUFFIX
> - ADD standard automembers ACIs (read, write, delete, ...)
> 
> dn: cn=CAcert,cn=ipa,cn=etc,SUFFIX
> - ADD aci allowing reading cACertificate for anonymous
> 
> dn: cn=anonymous-limits,cn=etc,SUFFIX
> - no ACI needed, not managed by IPA users
> 
> dn: cn=replication,cn=etc,SUFFIX
> - ADD aci allowing reading for authenticated users (used in 
> ipa-replica-install)
> 
> dn: cn=Realm Domains,cn=ipa,cn=etc,SUFFIX
> - no ACI needed, we already added read aci
> 
> dn: cn=ad,cn=etc,SUFFIX
> - ADD aci allowing reading ipaNTDomainAttrs for authenticated users (trust
> settings)
> 
> ==
> 
> That should be pretty much all. I know that devil hides in details, but I did
> not see any blocker to skip the chance to add proper ACIs also for cn=etc as
> well and thus remove the all allowing ACI at all (I am afraid that we would be
> stuck with cn=etc all-allowing ACI for years otherwise).
> 
> Comments welcome.

Agree with the general plan, let's start with this and add permissions
as needed.

Simo.



___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 0506 Default read ACIs for hosts

2014-04-14 Thread Simo Sorce 
On Mon, 2014-04-14 at 10:54 +0200, Martin Kosek wrote:
> On 04/11/2014 02:53 PM, Petr Viktorin wrote:
> > On 04/11/2014 02:36 PM, Simo Sorce wrote:
> >> On Fri, 2014-04-11 at 09:48 +0200, Martin Kosek wrote:
> >>> On 04/10/2014 05:29 PM, Petr Viktorin wrote:
>  On 04/10/2014 03:04 PM, Martin Kosek wrote:
> > On 04/10/2014 02:52 PM, Simo Sorce wrote:
> >> On Thu, 2014-04-10 at 13:56 +0200, Petr Viktorin wrote:
> >>> On 04/09/2014 12:25 PM, Martin Kosek wrote:
>  On 04/03/2014 12:09 PM, Petr Viktorin wrote:
> > Hello,
> > This adds read permissions to read hosts.
> >
> > Read access is given to all authenticated users.
> > For reading host membership info, there is a separate permission 
> > that
> > also
> > defaults to all authenticated users.
> >
> > The userPassword attribute is not included for obvious reasons.
> 
>  1) We decided to show hosts only to authenticated users by default. I
>  am just
>  thinking - should some portion of hosts be readable just like groups 
>  and
>  users
>  are? For example at least the host core defined by nsHost objectlass?
> 
>  objectClasses: ( nsHost-oid NAME 'nsHost' DESC 'Netscape defined
>  objectclass'
>  SUP top STRUCTURAL MUST cn MAY ( serverHostName $ description $ 
>  l $
>  nsHostLoc
>  ation $ nsHardwarePlatform $ nsOsVersion ) X-ORIGIN 'Netscape' )
> 
>  Are application supposed to be able to anonymously read that 
>  information?
> >>>
> >>> I'm not sure. Simo?
> >>
> >> Good question, probably not by default, we offer DNS and do not
> >> recommend people to rely on exposed host maps.
> >
> > Question is if should have a separate permission like "System: Read 
> > Host Core
> > Attributes", "System: Read Host", "System: Read Host Membership" or we 
> > are
> > fine
> > with just "System: Read Host", "System: Read Host Membership".
> >
> > If we do not expect people and programs to often read the list of host 
> > or the
> > basic host information anonymously, I would stick with the latter.
> 
>  Let's do that then. It's easy enough to add a custom permission.
> 
>  2) Do we want to count enrolledBy and managedBy attribute to 
>  "System: Read
>  Host
>  Membership" permission or should it be included in the "Read Hosts"
>  permission?
> 
>  If we want to stick with previous behavior, we would want to have 
>  only
>  "memberOf" listed as this is how our original member handling ACI 
>  looks
>  like:
> 
>  install/share/default-aci.ldif:aci: (targetattr = "memberOf ||
>  memberHost ||
>  memberUser")(version 3.0; acl "No anonymous access to member 
>  information";
>  deny
>  (read,search,compare) userdn != "ldap:///all";;
> >>>
> >>> What was the reasoning behind enrolledBy and managedBy? I got it from
> >>> the notes from devconf; I don't think there was much discussion.
> >>
> >> I have no recollection :(
> >
> > There was no discussion about these particular attributes. I added then 
> > to
> > Membership permission because they were DN-ish, but when I think more
> > about it,
> > it does not seem as a membership in the sense of the ACI above. I would
> > personally only keep member/memberOf in the Membership attributes.
> 
>  Moved to Read Host.
> 
>  3) I could not functionally test if e.g. clients and replicas still
>  enroll as
>  we do not have an ACI for krbtpolicy/krbRealmContainer yet and
>  ipa-client-install searches for it.
> 
>  Speaking of which, we will need to have an ACI for reading a portion 
>  of
>  krbRealmContainer anonymously to enable IPA client autodiscovery
>  (cn+objectclass should be sufficient).
> >>
> >> Sad we ended up depending on this, I would have preferred to not depend
> >> on keeping this around if we ever want to change something.
> >
> > Yeah... But we should be OK with exposing just the CN which is not 
> > really a
> > secret as we know what is the realm name...
> >
> > Martin
> >
> >>>
> >>> The basis looks good now. However, when I was checking host's objectclass 
> >>> and
> >>> attributes we allow, I saw many attributes not listed in our DevConf 
> >>> meeting
> >>> minutes, but which are now missing in the entry when I read it as 
> >>> authenticated
> >>> used.
> >>
> >> As an admin, or as a regular user ?
> >>
> >>> krbPrincipalAux attributes like krbCanonicalName, krbExtraData,
> >>> krbLastAdminUnlock, krbLastFailedAuth...
> >>> We may want to list them all, except the ones we

[Freeipa-devel] [PATCH] 0520 Add managed read permission to service

2014-04-14 Thread Petr Viktorin 

Read access is given to all authenticated users.

Exposed attributes are:
[top]
  objectClass
[ipaObject]
  ipaUniqueID
[ipaService]
  managedBy
  memberOf
  ipaKrbAuthzData  (a.k.a. pac_type)
[pkiUser]
  userCertificate
[krbPrincipalAux]
  krbPrincipalName
  krbCanonicalName
  krbPrincipalAliases
  krbPrincipalExpiration
  krbPasswordExpiration
  krbLastPwdChange
[krbTicketPolicyAux] - none
[ipaKrbPrincipal]
  krbPrincipalName
  ipaKrbPrincipalAlias
[krbPrincipal]
  krbPrincipalName
  krbObjectReferences


Kerberos-related attributes were discussed for hosts here: 
http://www.redhat.com/archives/freeipa-devel/2014-April/msg00242.html


--
Petr³
From 1eadd2dbafd757abe6e2ac93316754f337da7ba6 Mon Sep 17 00:00:00 2001
From: Petr Viktorin 
Date: Wed, 26 Mar 2014 17:11:23 +0100
Subject: [PATCH] Add managed read permission to service

Part of the work for: https://fedorahosted.org/freeipa/ticket/3566
---
 ipalib/plugins/service.py | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/ipalib/plugins/service.py b/ipalib/plugins/service.py
index 25f02cd129e58190131b46e1523ce6db39457776..1568bb2fd11daadaf63af7bde1b020f2f0529e07 100644
--- a/ipalib/plugins/service.py
+++ b/ipalib/plugins/service.py
@@ -312,6 +312,21 @@ class service(LDAPObject):
 'managedby': ('Managed by', 'man_by_', 'not_man_by_'),
 }
 password_attributes = [('krbprincipalkey', 'has_keytab')]
+managed_permissions = {
+'System: Read Services': {
+'replaces_global_anonymous_aci': True,
+'ipapermbindruletype': 'all',
+'ipapermright': {'read', 'search', 'compare'},
+'ipapermdefaultattr': {
+'objectclass',
+'ipauniqueid', 'managedby', 'memberof', 'usercertificate',
+'krbprincipalname', 'krbcanonicalname', 'krbprincipalaliases',
+'krbprincipalexpiration', 'krbpasswordexpiration',
+'krblastpwdchange', 'ipakrbauthzdata', 'ipakrbprincipalalias',
+'krbobjectreferences',
+},
+},
+}
 
 label = _('Services')
 label_singular = _('Service')
-- 
1.9.0

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

[Freeipa-devel] New ACIs for cn=etc

2014-04-14 Thread Martin Kosek 
When heading for a lunch today, I had a discussion with Petr3 about ACIs for
cn=etc,SUFFIX. On our initial meeting back at DevConf.cz time, we said we will
simply allow all attributes in cn=etc for authenticated users and will just
exclude the blacklisted attributes (for context, see ticket #3566).

I personally think it is not the best thing to do as it will just move the
problem we had with all-allowing ACI one level down from SUFFIX to cn=etc. It
would be better to add normal ACIs for cn=etc as well.

I searched for nsContainer's in cn=etc and IMO the situation is not so bad, it
seems straightforward what ACIs would be needed:

==
dn: cn=etc,SUFFIX
- ADD aci allowing reading nsContainer for anonymous, EXCEPT:
  - cn=virtual operations,cn=etc,SUFFIX
  - cn=masters,cn=ipa,cn=etc,SUFFIX
  - cn=Managed Entries,cn=etc,SUFFIX

dn: cn=sysaccounts,cn=etc,SUFFIX
- ADD aci allowing reading all attributes but password attributes (people may
add unstructured accounts following different objectclasses)

dn: cn=ipa,cn=etc,SUFFIX
- no ACI needed

dn: cn=masters,cn=ipa,cn=etc,SUFFIX
- ADD aci allowing reading hosts (to have it separate from global cn=etc one so
that we can once assign it only to ipamasters hostgroup for example)

dn: cn=replicas,cn=ipa,cn=etc,SUFFIX
- ADD aci allowing reading replicas for authenticated users (masters)

dn: cn=dna,cn=ipa,cn=etc,SUFFIX
- ADD aci allowing reading dnaSharedConfig objects for authenticated

dn: cn=posix-ids,cn=dna,cn=ipa,cn=etc,SUFFIX
- no ACI needed

dn: cn=ca_renewal,cn=ipa,cn=etc,SUFFIX
- ADD aci allowing reading for authenticated users (hosts' certmonger)

dn: cn=s4u2proxy,cn=etc,SUFFIX
- no ACI needed at this point, KDC access it with DM privileges AFAIK

dn: cn=ipaConfig,cn=etc,SUFFIX
- ADD aci allowing reading ipaConfigObject attributes for authenticated users.
We already plan aci allowing writing them

dn: cn=ranges,cn=etc,SUFFIX
- ADD aci allowing reading ipaIDrange for authenticated users

dn: cn=virtual operations,cn=etc,SUFFIX
- ADD aci allowing reading/updating virtual operations, assign to RBAC 
privileges

dn: cn=retrieve certificate,cn=virtual operations,cn=etc,SUFFIX
dn: cn=request certificate,cn=virtual operations,cn=etc,SUFFIX
dn: cn=request certificate different host,cn=virtual operations,SUFFIX
dn: cn=certificate status,cn=virtual operations,cn=etc,SUFFIX
dn: cn=revoke certificate,cn=virtual operations,cn=etc,SUFFIX
dn: cn=certificate remove hold,cn=virtual operations,cn=etc,SUFFIX
- no ACI needed

dn: cn=Managed Entries,cn=etc,SUFFIX
- no ACI needed, not managed by IPA users

dn: cn=automember,cn=etc,SUFFIX
- ADD standard automembers ACIs (read, write, delete, ...)

dn: cn=CAcert,cn=ipa,cn=etc,SUFFIX
- ADD aci allowing reading cACertificate for anonymous

dn: cn=anonymous-limits,cn=etc,SUFFIX
- no ACI needed, not managed by IPA users

dn: cn=replication,cn=etc,SUFFIX
- ADD aci allowing reading for authenticated users (used in ipa-replica-install)

dn: cn=Realm Domains,cn=ipa,cn=etc,SUFFIX
- no ACI needed, we already added read aci

dn: cn=ad,cn=etc,SUFFIX
- ADD aci allowing reading ipaNTDomainAttrs for authenticated users (trust
settings)

==

That should be pretty much all. I know that devil hides in details, but I did
not see any blocker to skip the chance to add proper ACIs also for cn=etc as
well and thus remove the all allowing ACI at all (I am afraid that we would be
stuck with cn=etc all-allowing ACI for years otherwise).

Comments welcome.

-- 
Martin Kosek 
Supervisor, Software Engineering - Identity Management Team
Red Hat Inc.

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 0519 Add managed read permissions to pwpolicy and cosentry

2014-04-14 Thread Petr Viktorin 

On 04/14/2014 12:03 PM, Martin Kosek wrote:

On 04/11/2014 02:39 PM, Simo Sorce wrote:

On Fri, 2014-04-11 at 14:26 +0200, Petr Viktorin wrote:

Read access is given as a new privilege, 'Password Policy Readers', and
also to the existing privilege 'Password Policy Administrator'.



LGTM
Simo.



I tested and it works fine. I hit a crash when manipulating pwpolicy:
https://fedorahosted.org/freeipa/ticket/4309

However, it is not related to this patch and is present in current master tree.
I.e. not a blocker for this patch.

ACK from me too.

Martin



Thanks, pushed to master: f10ec17c03dfe6bdf46903e89f68fa588664fdc0

--
Petr³

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 0519 Add managed read permissions to pwpolicy and cosentry

2014-04-14 Thread Martin Kosek 
On 04/11/2014 02:39 PM, Simo Sorce wrote:
> On Fri, 2014-04-11 at 14:26 +0200, Petr Viktorin wrote:
>> Read access is given as a new privilege, 'Password Policy Readers', and 
>> also to the existing privilege 'Password Policy Administrator'.
>>
> 
> LGTM
> Simo.
> 

I tested and it works fine. I hit a crash when manipulating pwpolicy:
https://fedorahosted.org/freeipa/ticket/4309

However, it is not related to this patch and is present in current master tree.
I.e. not a blocker for this patch.

ACK from me too.

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 0506 Default read ACIs for hosts

2014-04-14 Thread Petr Viktorin 

On 04/14/2014 10:54 AM, Martin Kosek wrote:

On 04/11/2014 02:53 PM, Petr Viktorin wrote:

On 04/11/2014 02:36 PM, Simo Sorce wrote:

On Fri, 2014-04-11 at 09:48 +0200, Martin Kosek wrote:

On 04/10/2014 05:29 PM, Petr Viktorin wrote:

On 04/10/2014 03:04 PM, Martin Kosek wrote:

On 04/10/2014 02:52 PM, Simo Sorce wrote:

On Thu, 2014-04-10 at 13:56 +0200, Petr Viktorin wrote:

On 04/09/2014 12:25 PM, Martin Kosek wrote:

On 04/03/2014 12:09 PM, Petr Viktorin wrote:

Hello,
This adds read permissions to read hosts.

Read access is given to all authenticated users.
For reading host membership info, there is a separate permission that
also
defaults to all authenticated users.

The userPassword attribute is not included for obvious reasons.


1) We decided to show hosts only to authenticated users by default. I
am just
thinking - should some portion of hosts be readable just like groups and
users
are? For example at least the host core defined by nsHost objectlass?

objectClasses: ( nsHost-oid NAME 'nsHost' DESC 'Netscape defined
objectclass'
 SUP top STRUCTURAL MUST cn MAY ( serverHostName $ description $ l $
nsHostLoc
 ation $ nsHardwarePlatform $ nsOsVersion ) X-ORIGIN 'Netscape' )

Are application supposed to be able to anonymously read that information?


I'm not sure. Simo?


Good question, probably not by default, we offer DNS and do not
recommend people to rely on exposed host maps.


Question is if should have a separate permission like "System: Read Host Core
Attributes", "System: Read Host", "System: Read Host Membership" or we are
fine
with just "System: Read Host", "System: Read Host Membership".

If we do not expect people and programs to often read the list of host or the
basic host information anonymously, I would stick with the latter.


Let's do that then. It's easy enough to add a custom permission.


2) Do we want to count enrolledBy and managedBy attribute to "System: Read
Host
Membership" permission or should it be included in the "Read Hosts"
permission?

If we want to stick with previous behavior, we would want to have only
"memberOf" listed as this is how our original member handling ACI looks
like:

install/share/default-aci.ldif:aci: (targetattr = "memberOf ||
memberHost ||
memberUser")(version 3.0; acl "No anonymous access to member information";
deny
(read,search,compare) userdn != "ldap:///all";;


What was the reasoning behind enrolledBy and managedBy? I got it from
the notes from devconf; I don't think there was much discussion.


I have no recollection :(


There was no discussion about these particular attributes. I added then to
Membership permission because they were DN-ish, but when I think more
about it,
it does not seem as a membership in the sense of the ACI above. I would
personally only keep member/memberOf in the Membership attributes.


Moved to Read Host.


3) I could not functionally test if e.g. clients and replicas still
enroll as
we do not have an ACI for krbtpolicy/krbRealmContainer yet and
ipa-client-install searches for it.

Speaking of which, we will need to have an ACI for reading a portion of
krbRealmContainer anonymously to enable IPA client autodiscovery
(cn+objectclass should be sufficient).


Sad we ended up depending on this, I would have preferred to not depend
on keeping this around if we ever want to change something.


Yeah... But we should be OK with exposing just the CN which is not really a
secret as we know what is the realm name...

Martin



The basis looks good now. However, when I was checking host's objectclass and
attributes we allow, I saw many attributes not listed in our DevConf meeting
minutes, but which are now missing in the entry when I read it as authenticated
used.


As an admin, or as a regular user ?


krbPrincipalAux attributes like krbCanonicalName, krbExtraData,
krbLastAdminUnlock, krbLastFailedAuth...
We may want to list them all, except the ones we chose to now show, like
krbPrincipalKey :) I would welcome Simo's recommendation in this place.


I do not think we necessarily need to expose most of them to regular
users (which include keytab bearing services) by default.


krbTicketPolicyAux attributes like krbMaxRenewableAge

Objectclasses for reference:

objectClasses: ( 2.16.840.1.113719.1.301.6.8.1 NAME 'krbPrincipalAux' AUXILIAR
   Y MAY ( krbPrincipalName $ krbCanonicalName $ krbUPEnabled $ krbPrincipalKey
   $ krbTicketPolicyReference $ krbPrincipalExpiration $ krbPasswordExpiration $
krbPwdPolicyReference $ krbPrincipalType $ krbPwdHistory $ krbLastPwdChange
   $ krbPrincipalAliases $ krbLastSuccessfulAuth $ krbLastFailedAuth $ krbLoginF
   ailedCount $ krbExtraData $ krbLastAdminUnlock ) )


Of these we may want to show krbPrincipalName, krbCanonicalName,
krbPrincipalAliases by default.


Added.


I am uncertain about krbPrincipalExpiration, krbPasswordExpiration,
krbLastPwdChange, but they may be needed for clients like SSSD to do
proper checking and for power users to figure out themselves when they

Re: [Freeipa-devel] [PATCH] 0506 Default read ACIs for hosts

2014-04-14 Thread Martin Kosek 
On 04/11/2014 02:53 PM, Petr Viktorin wrote:
> On 04/11/2014 02:36 PM, Simo Sorce wrote:
>> On Fri, 2014-04-11 at 09:48 +0200, Martin Kosek wrote:
>>> On 04/10/2014 05:29 PM, Petr Viktorin wrote:
 On 04/10/2014 03:04 PM, Martin Kosek wrote:
> On 04/10/2014 02:52 PM, Simo Sorce wrote:
>> On Thu, 2014-04-10 at 13:56 +0200, Petr Viktorin wrote:
>>> On 04/09/2014 12:25 PM, Martin Kosek wrote:
 On 04/03/2014 12:09 PM, Petr Viktorin wrote:
> Hello,
> This adds read permissions to read hosts.
>
> Read access is given to all authenticated users.
> For reading host membership info, there is a separate permission that
> also
> defaults to all authenticated users.
>
> The userPassword attribute is not included for obvious reasons.

 1) We decided to show hosts only to authenticated users by default. I
 am just
 thinking - should some portion of hosts be readable just like groups 
 and
 users
 are? For example at least the host core defined by nsHost objectlass?

 objectClasses: ( nsHost-oid NAME 'nsHost' DESC 'Netscape defined
 objectclass'
 SUP top STRUCTURAL MUST cn MAY ( serverHostName $ description $ l $
 nsHostLoc
 ation $ nsHardwarePlatform $ nsOsVersion ) X-ORIGIN 'Netscape' )

 Are application supposed to be able to anonymously read that 
 information?
>>>
>>> I'm not sure. Simo?
>>
>> Good question, probably not by default, we offer DNS and do not
>> recommend people to rely on exposed host maps.
>
> Question is if should have a separate permission like "System: Read Host 
> Core
> Attributes", "System: Read Host", "System: Read Host Membership" or we are
> fine
> with just "System: Read Host", "System: Read Host Membership".
>
> If we do not expect people and programs to often read the list of host or 
> the
> basic host information anonymously, I would stick with the latter.

 Let's do that then. It's easy enough to add a custom permission.

 2) Do we want to count enrolledBy and managedBy attribute to "System: 
 Read
 Host
 Membership" permission or should it be included in the "Read Hosts"
 permission?

 If we want to stick with previous behavior, we would want to have only
 "memberOf" listed as this is how our original member handling ACI looks
 like:

 install/share/default-aci.ldif:aci: (targetattr = "memberOf ||
 memberHost ||
 memberUser")(version 3.0; acl "No anonymous access to member 
 information";
 deny
 (read,search,compare) userdn != "ldap:///all";;
>>>
>>> What was the reasoning behind enrolledBy and managedBy? I got it from
>>> the notes from devconf; I don't think there was much discussion.
>>
>> I have no recollection :(
>
> There was no discussion about these particular attributes. I added then to
> Membership permission because they were DN-ish, but when I think more
> about it,
> it does not seem as a membership in the sense of the ACI above. I would
> personally only keep member/memberOf in the Membership attributes.

 Moved to Read Host.

 3) I could not functionally test if e.g. clients and replicas still
 enroll as
 we do not have an ACI for krbtpolicy/krbRealmContainer yet and
 ipa-client-install searches for it.

 Speaking of which, we will need to have an ACI for reading a portion of
 krbRealmContainer anonymously to enable IPA client autodiscovery
 (cn+objectclass should be sufficient).
>>
>> Sad we ended up depending on this, I would have preferred to not depend
>> on keeping this around if we ever want to change something.
>
> Yeah... But we should be OK with exposing just the CN which is not really 
> a
> secret as we know what is the realm name...
>
> Martin
>
>>>
>>> The basis looks good now. However, when I was checking host's objectclass 
>>> and
>>> attributes we allow, I saw many attributes not listed in our DevConf meeting
>>> minutes, but which are now missing in the entry when I read it as 
>>> authenticated
>>> used.
>>
>> As an admin, or as a regular user ?
>>
>>> krbPrincipalAux attributes like krbCanonicalName, krbExtraData,
>>> krbLastAdminUnlock, krbLastFailedAuth...
>>> We may want to list them all, except the ones we chose to now show, like
>>> krbPrincipalKey :) I would welcome Simo's recommendation in this place.
>>
>> I do not think we necessarily need to expose most of them to regular
>> users (which include keytab bearing services) by default.
>>
>>> krbTicketPolicyAux attributes like krbMaxRenewableAge
>>>
>>> Objectclasses for reference:
>>>
>>> objectClasses: ( 2.16.840

Re: [Freeipa-devel] incorrect permission when creating home directory automatically

2014-04-14 Thread Jakub Hrozek 
On Sun, Apr 13, 2014 at 01:23:11PM +0430, farzad niazmand wrote:
> Hi
> I enabled --enablemkhomedir option when configured Clients to automatically
> create home directories as user logs in.
> The problem I have is whenever a users logs in for the first time and a
> home directory creates for it, the permission of that home directory is 755
> but I want the permission to be 700.
> How can i fix this?

Set the permissions of your choice in
/etc/oddjobd.conf.d/oddjobd-mkhomedir.conf

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel