On 03/31/2014 12:32 PM, Martin Kosek wrote:
On 03/31/2014 10:41 AM, Ludwig Krispenz wrote:
Hi Petr,
we already discussed on IRC, but see some comments below
On 03/28/2014 04:11 PM, Petr Viktorin wrote:
Hello,
I'm trying to add ACIs to allow read access to containers, and I need some
input.
The DS's access control system is not designed to allow access to a single
entry but not its descendants. The [ACI documentation] suggests some ways to
work around it.
This doesn't work that well for read access in IPA:
$SUFFIX needs anonymous read access; ipa-client-install looks for "info=IPA
V2.0" anonymously.
cn=accounts,$SUFFIX needs read access if it or any of its children are to be
listed in a GUI
cn=users,cn=accounts,$SUFFIX needs read access if it or any users are to be
listed in a GUI
uid=*,cn=accounts,$SUFFIX might need to have anonymous reads denied
It's safe to expose IPA's default containers anonymously; all they tell the
user is that they're looking an IPA server.
The container entries themselves just have cn and an objectClass of
cnContainer, so it's impossible to construct a general targetfilter that
targets them but not any possible descendants.
I see 3 possible solutions:
1) File a DS RFE to implement [targetscope]. With that we could have ACIs
that only target a single entry, so admins could manage read access to
containers in the usual way (with permissions).
2) Add a (objectClass=nsContainer) filter. The problem here is that if this
is on cn=accounts,$S, it would also affect e.g. cn=users,cn=accounts,$S, and
other nsContainers under it. For example,
cn=$HOSTNAME,cn=masters,cn=ipa,cn=etc,$S is a nsContainer.
3) Add a special attribute to mark "public" containers, and add an ACI with a
filter on that. Something like objectClass=ipaPublicContainer would do.
there is one more option
4) add an allow aci for cn=accounts,$S and a deny aci for cn=*,cn=accounts,$S
or uid=*,cn=accounts,$S
In the past, we tried hard to avoid deny acis and I think we should keep it
this way. deny ACI is just a hard stop that cannot be overriden by any other
ACI. If possible, I would prefer to only add allow ACIs.
I agree, in my opinion the access restriction is much clearer if only
allow is used
In general I think we should implement 1), there will be other scenarios where
it could be useful. If something is needed imemdiately I would also prefer 3)
We need this feature for FreeIPA 4.0, so I am thinking waiting for 389 feature
is not an option unless it'd be done really fast.
how fast does it have to be ? If we just can use the same concept with
targetscope=[base,one,sub]
implementation should not take too much time, about a week or so, but we
need to get it accepted by
DS core.
Given Petr's findings, I am thinking that solution based on 3) seems like way
to go. We would of course only allow objectclass + cn attributes. I am not
convinced that objectclass like ipaPublicContainer is the right way to go, does
not sound to me as a standard solution and not something that people would
assume they need to do when they are adding a custom container.
When I installed a fresh FreeIPA, I did a (cn=nsContainer) search (results
attached) and there were 61 results. Do we really want to update 61 LDAP
entries and add a custom ipaPublicContainer objectclass to all? Sounds a little
bit hackish to me.
Would adding following ACIs work?
dn: SUFFIX
aci: allow anonymous read for "(objectclass=nsContainer)" for cn, objectclass;
except cn=etc,SUFFIX
how do you want to specify the "except" ?
dn: cn=etc,SUFFIX
aci: allow authenticated read for "(objectclass=nsContainer)" for cn,
objectclass
As I just checked, allowing whole cn=etc,SUFFIX for authenticated only is
something we agreed on during DevConf.
With this approach, the only question is what should we do with nsContainer
based LDAP entries that contains sensitive information. I wonder - is this a
real situation? Are there many nsContainer LDAP entries with sensitive
information? Shouldn't we have a rule instead that would recommend using custom
(not nsContainer) objectclasses to store sensitive information based on cn?
Otherwise it seems to me a an abuse of nsContainer purpose.
Martin
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
