ACI to allow group to access one attribute

[Angel Bosch]

hi,

I need one specific attribute to be hidden for anyone but one group.

I've tested this one:

(targetattr = "myCustomAttr") (version 3.0; acl "deny all but admins"; deny (all) groupdn != "ldap:///cn=admins,ou=Groups,dc=company,dc=global";)

and seems to work.

Is this the right way to do it?
Can I face any side effects?

regards,

abosch

--

[William Brown]

On Thu, 2018-02-22 at 12:17 +0100, Angel Bosch wrote:
> hi,
>
> I need one specific attribute to be hidden for anyone but one group.
>
> I've tested this one:
>  (targetattr = "myCustomAttr") (version 3.0; acl "deny all but
>
> admins"; deny (all) groupdn !=
> "ldap:///cn=admins,ou=Groups,dc=company,dc=global";)
>
> and seems to work.
>
> Is this the right way to do it?

A better way to write this is:

(targetattr = "mycustomattr")(version 3.0; acl "allow admins
mycustomattr"; allow (all) groupdn =
"ldap:///cn=admins,ou=Groups,dc=company,dc=global";)

That's a better rule.
> Can I face any side effects?

So if you apply the "allow" rather than the deny rule here, and a "non-
admin" user can read mycustomattr, that indicates a bug in your acl's.

I have some posts about this which might help:

https://fy.blackhats.net.au/blog/html/2015/07/04/Unit_testing_LDAP_acis
_for_fun_and_profit.html?highlight=aci

This is a very common "anti-pattern" I see, and it creates huge
security issues. If you find with the "allow" version that this is
happening, check your other rules!

Hope that helps,
> regards,
>
> abosch
>
> -- 
> _______________________________________________
> 389-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail].o
> rg

[Angel Bosch]

> A better way to write this is:
>
> (targetattr = "mycustomattr")(version 3.0; acl "allow admins
> mycustomattr"; allow (all) groupdn =
> "ldap:///cn=admins,ou=Groups,dc=company,dc=global";)
>
> That's a better rule.

I've tried this and I still can see the attribute without binding (anonymous search).

here you can see the custom attr imasLocalAdminPass

dn: uid=provamaquina01,ou=users,dc=example.net,dc=petratest,dc=proves,dc=global
imasLocalAdminPass: 12345678test
objectClass: account
objectClass: top
objectClass: posixAccount
objectClass: imasMaquines
uidNumber: 999999
homeDirectory: /dev/null
gidNumber: 999999
cn: provamaquina01
uid: provamaquina01
entryLevelRights: vn
attributeLevelRights: userPassword:wo, imasLocalAdminPass:rscwo, objectClass:r
 scwo, uidNumber:rscwo, homeDirectory:rscwo, gidNumber:rscwo, cn:rscwo, uid:r
 scwo

thanks for your time, william.

[Ludwig Krispenz]

On 02/27/2018 01:44 PM, Angel Bosch wrote:
> > A better way to write this is:
> >
> > (targetattr = "mycustomattr")(version 3.0; acl "allow admins
> > mycustomattr"; allow (all) groupdn =
> > "ldap:///cn=admins,ou=Groups,dc=company,dc=global";)
> >
> > That's a better rule.
>
> I've tried this and I still can see the attribute without binding (anonymous search).

this means you have another aci which allows access for anonymous. The 
"deny" method works as the evaluation of the deny acis has precedence 
over the allow acis.
But I think what Williams point is, you are fixing specific access and 
thene will do it again ... and again. The preferable way is to design 
acis based on who should be allowed to do what and anly have explicite 
allow rules, and no broad allows which need to get holes punched into by 
denys
> here you can see the custom attr imasLocalAdminPass
>
> dn: uid=provamaquina01,ou=users,dc=example.net,dc=petratest,dc=proves,dc=global
> imasLocalAdminPass: 12345678test
> objectClass: account
> objectClass: top
> objectClass: posixAccount
> objectClass: imasMaquines
> uidNumber: 999999
> homeDirectory: /dev/null
> gidNumber: 999999
> cn: provamaquina01
> uid: provamaquina01
> entryLevelRights: vn
> attributeLevelRights: userPassword:wo, imasLocalAdminPass:rscwo, objectClass:r
>   scwo, uidNumber:rscwo, homeDirectory:rscwo, gidNumber:rscwo, cn:rscwo, uid:r
>   scwo
>
> thanks for your time, william.
> _______________________________________________
> 389-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[William Brown]

On Tue, 2018-02-27 at 13:44 +0100, Angel Bosch wrote:
> > A better way to write this is:
> >
> > (targetattr = "mycustomattr")(version 3.0; acl "allow admins
> > mycustomattr"; allow (all) groupdn =
> > "ldap:///cn=admins,ou=Groups,dc=company,dc=global";)
> >
> > That's a better rule.
>
> I've tried this and I still can see the attribute without binding
> (anonymous search).
>
> here you can see the custom attr imasLocalAdminPass
>
> dn:
> uid=provamaquina01,ou=users,dc=example.net,dc=petratest,dc=proves,dc=
> global
> imasLocalAdminPass: 12345678test
> objectClass: account
> objectClass: top
> objectClass: posixAccount
> objectClass: imasMaquines
> uidNumber: 999999
> homeDirectory: /dev/null
> gidNumber: 999999
> cn: provamaquina01
> uid: provamaquina01
> entryLevelRights: vn
> attributeLevelRights: userPassword:wo, imasLocalAdminPass:rscwo,
> objectClass:r
>  scwo, uidNumber:rscwo, homeDirectory:rscwo, gidNumber:rscwo,
> cn:rscwo, uid:r
>  scwo

I need to see the aci's on your server to help more. Can you please
send me (either to the list, or directly to my email) the output of:

ldapsearch -x -b "your basedn" -D 'cn=Directory Manager' -w -H
ldaps://<your server> '(aci=*)' aci

That well help me answer the question as to what is causing this
attribute to be readable,

Thanks!
> thanks for your time, william.

[Angel Bosch]

> I need to see the aci's on your server to help more. Can you please
> send me (either to the list, or directly to my email) the output of:
>
> ldapsearch -x -b "your basedn" -D 'cn=Directory Manager' -w -H
> ldaps://<your server> '(aci=*)' aci
>
> That well help me answer the question as to what is causing this
> attribute to be readable,

William was kind enough to answer me directly.

> # /usr/lib/mozldap/ldapsearch -D 'cn=Directory Manager' -j
    > /etc/.ldap.secret -b 'dc=global' '(aci=*)' aci
    > version: 1
    > dn: dc=global
    > aci: (targetattr != "userPassword") (version 3.0; acl "Anonymous
    > access"; allo
    >  w (read, search, compare)userdn = "ldap:///anyone"

See this '!=' in targetattr? This doesn't mean "exclude userPassword
    from searches" it means "take the set of every attribute that exists in
    the server, and allow search on ALL of them EXCEPT userPassword.". This
    aci is a huge security risk because you are disclosing ALL attribute
    states.

It's better to have a super long list of attributes here that you trust
    to be read. In the next version of Directory Server we fix these
    default attributes to have sane content.

> aci: (targetattr != "nsroledn||aci")(version 3.0; acl "Allow self
    > entry modifi
    >  cation except for nsroledn and aci attributes"; allow (write)userdn
    > ="ldap:/
    >  //self"

Again, the same effect here: But this time this allows a user to "self
    write any attribute that exists EXCEPT these two". Which again has huge
    security risks, because now they can self edit objectClass, add a
    container type, child entries .... They can edit the nsadminlimits, or
    more. So again, this needs to be a "targetattr = ...." list of what you
    WANT to allow self write to.

> aci: (targetattr = "*")(version 3.0; acl "Configuration
    > Adminstrator"; allow (
    >  all) userdn =
    > "ldap:///uid=admin,ou=Administrators,ou=TopologyManagement,o=N
    >  etscapeRoot"
    > aci: (targetattr ="*")(version 3.0;acl "Configuration Administrators
    > Group";al
    >  low (all) (groupdn = "ldap:///cn=Configuration Administrators,
    > ou=Groups, ou
    >  =TopologyManagement, o=NetscapeRoot")
    > aci: (targetattr = "*")(version 3.0; acl "SIE Group"; allow
    > (all)groupdn = "ld
    >  ap:///dc=global"

These three are probably okay, because you expect these members to be
    able to change everything arbitrarily.

I would like to note that all those acis where defined by default during installation and initial configuration of 389, I didn't added anything manually.
I understand now that is lot better to have an explicit list of allowed attributes than negative blacklist.
If I get it correctly this is a huge security problem and I've seen lot of ldap servers configured this way.

thanks again for your time, william.

abosch

[William Brown]

<snip>
> I would like to note that all those acis where defined by default
> during installation and initial configuration of 389, I didn't added
> anything manually.
> I understand now that is lot better to have an explicit list of
> allowed attributes than negative blacklist.
> If I get it correctly this is a huge security problem and I've seen
> lot of ldap servers configured this way.

Yes - you will notice that the 1.4.x servers completely change the
default ACI's to no longer have this vulnerability :)

I rewrote our 1.4.x ACI's to be a guide on secure ACI practices, that
also have useful features like delegation of permissions and more.

In general I am personally very excited for 1.4.x because it comes with
many changes that will improve the administrator experience and safety
by default,

Thanks!
> thanks again for your time, william.
>
> abosch