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,  > >>> > >>> 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  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 _______________________________________________ Freeipa-devel mailing list Freeipafirstname.lastname@example.org https://www.redhat.com/mailman/listinfo/freeipa-devel