[Freeipa-devel] [PATCH 556-557] Add option to disable setkeytab extended operations

[Simo Sorce]

On Tue, 2015-12-01 at 14:42 +0100, Martin Kosek wrote:
> On 12/01/2015 02:38 PM, Simo Sorce wrote:
> > On Tue, 2015-12-01 at 10:11 +0200, Alexander Bokovoy wrote:
> >> On Mon, 30 Nov 2015, Simo Sorce wrote:
> >>> On Wed, 2015-11-25 at 09:47 -0500, Simo Sorce wrote:
> >>>> On Wed, 2015-11-25 at 09:02 -0500, Rob Crittenden wrote:
> >>>>> Jan Cholasta wrote:
> >>>>>> On 24.11.2015 22:17, Simo Sorce wrote:
> >>>>>>> On Tue, 2015-11-24 at 14:57 -0500, Simo Sorce wrote:
> >>>>>>>> On Tue, 2015-11-24 at 14:42 -0500, Simo Sorce wrote:
> >>>>>>>>> Since some time we use the getkeytab operation to fetch keytabs on
> >>>>>>>>> newer
> >>>>>>>>> clients. According to bug #232 setkeytab can be used to circumvent
> >>>>>>>>> password quality controls so it needs to be slowly retired.
> >>>>>>>>>
> >>>>>>>>> The attached patches implement #5485 in 2 parts.
> >>>>>>>>>
> >>>>>>>>> The first introduces the option DisableSetKeytab which globally
> >>>>>>>>> disables
> >>>>>>>>> the setkeytab extended operation. This is set to false by default for
> >>>>>>>>> backwards compatibility.
> >>>>>>>>>
> >>>>>>>>> The second introduces an option called DisableUserSetKeytab, which is
> >>>>>>>>> active by default in new installs (but not in upgraded ones), and only
> >>>>>>>>> disables the use of setkeytab for ipa suers, but not for
> >>>>>>>>> hosts/services.
> >>>>>>>>> This is because user's are the ones that may abuse the interface to
> >>>>>>>>> escape password policies and users also normally do not acquire
> >>>>>>>>> keytabs,
> >>>>>>>>> so it is a safe bet to disable just them by default in new installs.
> >>>>>>>>>
> >>>>>>>>> (Testing in progress)
> >>>>>>>>
> >>>>>>>> Tested and working as expected.
> >>>>>>>
> >>>>>>> I realized that adding options to ipaConfig require to add them in the
> >>>>>>> UI as well, attached patches add options in API.txt and config.py
> >>>>>>> Make now complain I should change API Major or Minor, but it is not
> >>>>>>> clear to me why given this are additional values and no real change or
> >>>>>>> new function is introduced. What's the recommendation ?
> >>>>>>
> >>>>>> When does make complain? It is supposed to complain only when API.txt
> >>>>>> does not match code.
> >>>>>>
> >>>>>> Anyway, we usually bump minor version even for backward compatible
> >>>>>> changes, see e.g. commit 9549a59.
> >>>>>>
> >>>>>
> >>>>> The point of API.txt (and the heavy client) was to save a round-trip.
> >>>>> Being able to pass in an invalid option would void that rule hence
> >>>>> having to update the API when new values are added.
> >>>>>
> >>>>> rob
> >>>>
> >>>> Ok added version change to the second patch (so we bump it only once
> >>>> given these are basically related changes.
> >>>
> >>> Bump, is this ok ?
> >> This patch is fine but please fix setkeytab use in ipa-sam before
> >> committing this patch.
> > 
> > This patch does not disable setkeytab yet, so it can go in right away
> > (it blocks other patches already). We have a bug to change ipa-sam,
> > should we mark it blocker for 4.4 ?
> 
> We also have to fix the permission to change keytab, so that it uses the new
> style (https://fedorahosted.org/freeipa/ticket/5487). I would actually make
> this ticket and the ipa-sam ticket a blocker for this patch set.
> 
> Otherwise you are actually introducing a switch that breaks FreeIPA as some of
> it's core server functions still use the old method.

The point of this patchset is to introduce the switch early so that
current server will support the off switch when newer servers down the
road are ready to flip it. The defaults are still to allow these
operations for services/hosts.

If you flip it right now you'll break stuff, including all older clients
on "Enterprise" distributions, so this switch will not be flipped soon.

Simo.

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