[Freeipa-devel] Draft: Read permissions for user

[Simo Sorce]

On Tue, 2014-04-29 at 15:10 +0200, Martin Kosek wrote:
> On 04/29/2014 02:48 PM, Simo Sorce wrote:
> > On Tue, 2014-04-29 at 14:21 +0200, Martin Kosek wrote:
> >> On 04/29/2014 01:03 PM, Petr Viktorin wrote:
> >>> On 04/24/2014 11:35 AM, Martin Kosek wrote:
> >>>> On 04/23/2014 10:53 PM, Martin Kosek wrote:
> >>>>> On 04/23/2014 08:07 PM, Simo Sorce wrote:
> >>> [...]
> >>>>>>
> >>>>>> I know, we may need to provide another permission admins can use to turn
> >>>>>> on anonymous searches for those attributes too.
> >>>>>> We may also decide that on upgrade vs new install we retain anonymous
> >>>>>> access.
> >>>>>>
> >>>>>> Simo.
> >>>
> >>> This is an interesting challenge.
> >>> We want the permission to be set to anonymous when:
> >>> 1) we're creating it, and
> >>> 2) the updater is *not* run from ipa-server-install (which would mean we're
> >>> installing a new cluster).
> >>> Full analysis below, [0]
> >>>
> >>> We discussed this on a meeting and it was mentioned that we can just start with
> >>> anonymous, and simply change to "all authenticated" at the end of
> >>> ipa-server-install. Thinking about it, I don't like that approach.
> >>> We may want an ACI audit tool [1] to list differences from defaults.
> >>> For uses like this, the metadata should list to up-to-date "best practices",
> >>> i.e. what you'd get with a fresh ipa-server-install.
> >>> So the metadata should list the bind type as all authenticated, and setting it
> >>> to anonymous should be handled as a special operation.
> >>>
> >>> This will be somewhat harder to code but I think it's worth it.
> >>
> >> I agree with Petr - managed permission definition should state our recommended
> >> and default access control that we are convinced that will fit most
> >> deployments. Restrictive or benevolent admins can always change the default
> >> with simple
> >>
> >> $ ipa permission-mod --bindtype=(all|anonymous|permission)
> >>
> >> call.
> >>
> >> Maybe the easiest way after all will be to list the changes in access control
> >> in the release note, compared to FreeIPA 3.x, e.g.
> >>
> >> 1) Host groups read access change from anonymous to authenticated by default
> >> 2) User calendar attributes read access change from anonymous to authenticated
> >> by default
> >> ...
> >>
> >> and educate users how they can change it if it does not fit their needs. IMO it
> >> may be more transparent and deterministic than to come with some hard coded
> >> changes in ipa-server-install that will create different defaults after upgrade
> >> and new installation.
> > 
> > It will break working servers pretty badly, that's a big NO on my side.
> > 
> > You do not want people to scramble understanding a new ACI system at
> > gunpoint because their production environment is broken.
> > 
> > It is a little harder for us, true, but it is worth it.
> > 
> > Simo.
> > 
> 
> User plugin is just one part of the change we do in access control. What about
> config object, hosts, host groups, ID ranges, netgroups, permissions, etc.?
> These are now accessible for authenticated users only and not for the
> anonymous. Should we then make them anonymous on upgrades as well?

I think yes probably for netgroups ?

> Then I doubt anyone would change it after upgrade to be more restricted
> default. I thought we created the new default to be the access control we
> recommend for most servers and which we expect to be present at most
> deployments. I.e. both on upgrades and new installations.

As usual this needs careful balance, the reason we use anonymous is for
allowing historically challenge systems that do not use authentication
to keep working.

For those what we care about is only anything related to the old NIS
maps, all of those need to be left accessible by anonymous if they are
in the system being upgraded.

Then we need to make a judgment call for other objects.
permissions, host groups, ID ranges and all that are arguably only
accessed by authenticated users normally, either by SSSD, which always
authenticates, or the 'ipa' command which also authenticates and goes
through the framework.

The other bits of data that may be accessed anonymously if custom
objects and addressbook data.

For custom objects there is little we can do, as we have no way to know,
and admins already know they need to be careful if they modify the tree,
so it is fine to ignore those as long as we clearly document that we are
changing the default from "anyone gets access w/o explicit ACIs" to
"nobody gets access w/o explicit ACIs".

For addressbook entries I think we really need to maintain whatever
access is already allowed in the tree being upgraded. Because in most
case mail programs are configured by users and if auth is not required
people do not go out of their way to add auth credentials. So changing
those would break users. Admins should be allowed to easily turn the
knob of course.

Any other attribute set need to be consider in a similar way: what is
the most probable use case ? The answer tells you what we should do on
upgrade.

HTH,
Simo.

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