Why is /usr/share/pam-configs/krb5 specifying minimum_uid= ?

Hi Daniel,

> Why is /usr/share/pam-configs/krb5 specifying minimum_uid= ?

Because this is the correct default minimum_uid value to use on Ubuntu systems, where 1000 marks the boundary between system and user accounts, and this default has not been otherwise specified.

> The problem is that some installations may have the convention of a higher minimum UID for Kerberos
> users, and their options are limited to either modifying the number in the profile file (a no-no given that
> the file lives in /usr and not /etc), or bypassing the krb5 profile altogether (either with a custom profile,
> or direct edits to /etc/pam.d/*).

Well, no, you have two other options:

- edit /etc/pam.d/common-* directly to remove / modify the minimum_uid option according to your sites needs (these are config files, and pam-auth-update is meant to honor any changes you make to the module options - if it fails to do so, that's a bug), or
- provide your own 'krb5-mysite' profile in /usr/share/pam-configs/ and use that in place of the default one.

But it would also be reasonable to set this default via appdefaults in /etc/krb5.conf, which I didn't know was possible - if that were done in the default krb5.conf, then we could drop the module option from /usr/share/pam/configs/krb5. So I'll mark this bug as invalid for pam-krb5, and open a task on kerberos-configs.

Steve Langasek <email address hidden> writes:

> But it would also be reasonable to set this default via appdefaults in
> /etc/krb5.conf, which I didn't know was possible - if that were done
> in the default krb5.conf, then we could drop the module option from
> /usr/share/pam/configs/krb5. So I'll mark this bug as invalid for
> pam-krb5, and open a task on kerberos-configs.

In practice, krb5.conf files usually aren't a useful place to set
distribution options. A lot of sites that use Kerberos (such as
Stanford) distribute a global krb5.conf file for the whole site and
encourage all users to just install it. One has to assume that in most
cases krb5.conf is going to get overridden by the user. (This is one of
the reasons why it's not a conffile in kerberos-configs and instead is
only created once and then very selectively modified, so note that no
changes will be picked up by existing systems, only by new
installations.)

I'm not sure there's any reason *not* to set the option in krb5.conf,
other than maybe a minor slippery slope argument that setting
application options in the distribution default krb5.conf isn't going to
scale well since we don't have an include mechanism for fragments. But
it may or may not really fix the problem of preventing Kerberos getting
in the way of local logins as thoroughly as using a PAM option.

The reason why that option is recommended is because if there's
something wrong with the network that causes pam-krb5 to hang for long
periods, login can time out and leave you in a situation where you can't
log in as root. Maybe it would make sense to leave minimum_uid for
/etc/krb5.conf but set ignore_root in the profile to eliminate the worst
of the problem of not having minimum_uid set.

--
Russ Allbery (<email address hidden>) <http://www.eyrie.org/~eagle/>

minimum_uid in krb5.conf, and ignore_root in .../pam-configs/krb5 sounds like a good way to go. For sites that distribute a global krb5.conf, they can always add the minimum_uid option if they like---if it's not already there, the distribution is likely passing that in as a PAM module option anyway (whether via pam-auth-update or otherwise).

For now, I guess I'll have to go with the custom krb5-mysite profile option. (Editing /etc/pam.d/common-* is possible, and indeed honored by pam-auth-update, but then you lose the whole benefit of being able to generate the config with a checklist. From an administrative standpoint, that's a *major* price to pay.)

Can we get minimum_uid out of pam-configs/krb5 for Lucid?

"Daniel Richard G." <email address hidden> writes:

> Can we get minimum_uid out of pam-configs/krb5 for Lucid?

I haven't had a chance to discuss the idea with the other kerberos-configs
maintainer, and at the moment this is a low priority for me since I think
the current behavior is correct.

At the moment, therefore, I think it's unlikely there will be any changes
for lucid if they're waiting on me to initiate the work.

--
Russ Allbery (<email address hidden>) <http://www.eyrie.org/~eagle/>

I know this isn't a big deal in the larger scheme of things, but it's the difference between being able to use the stock krb5 profile, and having to maintain a custom one. (And remember, the current behavior involves headaches if you have any non-root local users.)

Please bring this up with Sam when you get an opportunity....

"Daniel Richard G." <email address hidden> writes:

> I know this isn't a big deal in the larger scheme of things, but it's
> the difference between being able to use the stock krb5 profile, and
> having to maintain a custom one. (And remember, the current behavior
> involves headaches if you have any non-root local users.)

The current behavior does the correct thing if the UID allocation strategy
follows Debian policy, including for local users. That's what I mean by
not being convinced that the current behavior is wrong.

I realize there are sites that have UID allocation strategies that don't
follow the Debian guarantees about UID ranges and therefore need to use
lower UIDs due to historic allocations, although I'm surprised that those
sites would also be interested in using a stock PAM configuration (or, for
that matter, a stock krb5.conf).

You really don't want pam-krb5 to be willing to authenticate system users
just because you have a principal in your local realm named "daemon", and
krb5-config never touches an existing krb5.conf file when upgraded, which
makes me nervous about removing this setting from the default PAM
configuration. This is particularly true in Debian where those accounts
have valid shells by default.

--
Russ Allbery (<email address hidden>) <http://www.eyrie.org/~eagle/>

No no, the goal is not to have Kerberos users with uid < 1000. It's to push minimum_uid higher, so that you can have normal 1000-something-uid local users authenticate without any Kerberos interaction. Same argument as for the root user and ignore_root.

As for doing the upgrade, isn't pam-configs/krb5 a conffile? The user would see what's going on.

"Daniel Richard G." <email address hidden> writes:

> No no, the goal is not to have Kerberos users with uid < 1000. It's to
> push minimum_uid higher, so that you can have normal 1000-something-uid
> local users authenticate without any Kerberos interaction. Same argument
> as for the root user and ignore_root.

Oh, sorry. I forgot the context. I even re-read the bug and missed
that. Apologies.

> As for doing the upgrade, isn't pam-configs/krb5 a conffile? The user
> would see what's going on.

No, it's not a conffile. The generated /etc/pam.d files are configuration
files, but if the user is using the defaults, I believe changes to the
defaults are just automatically applied (although Steve would know better
than I). And krb5.conf normally isn't updated once written and I don't
think it could be updated with this particular type of change.

--
Russ Allbery (<email address hidden>) <http://www.eyrie.org/~eagle/>

What about just punting on upgrades altogether, and putting in the rearranged config only on a new install? Could that be done with appropriate postinst magic?

Alternately, you could pop up a big scary debconf warning... there's ample precedent for that.

"Daniel Richard G." <email address hidden> writes:

> What about just punting on upgrades altogether, and putting in the
> rearranged config only on a new install? Could that be done with
> appropriate postinst magic?

The tricky part is coordination. At what point can libpam-krb5 drop the
minimum_uid setting and assume that it's in krb5.conf?

> Alternately, you could pop up a big scary debconf warning... there's
> ample precedent for that.

My concern with this is that I think this only affects a small set of
users of the packages, so I'm reluctant to bother the other ones. One has
to both have a mix of Kerberos-authenticated and non-Kerberos users,
distinguish by UID, and mind the silent Kerberos authentication failure
when handling the UNIX login.

--
Russ Allbery (<email address hidden>) <http://www.eyrie.org/~eagle/>

You can see why I'm pushing on this. It's pay now, or pay later... no real gain in waiting :-]

Ah, yes, users who've been dist-upgrading their Ubuntu installs since Warty... I guess there's no such thing as "temporary" postinst logic, if those need to be handled.

A warning wouldn't be so bad. The users who would see it are those who are (1) dist-upgrading a distribution that (2) uses Kerberos authentication. Which often occurs in (3) an institutional setting with dedicated admins who can hand-hold/auto-script the change as needed. I don't think so many would be affected, and of those who are, a large part should be spoken for by their mother hens.

How did PAM-related packages manage changes to /etc/pam.d/* before pam-auth-update came along? Yeah, automated editing is gauche, but it's not like you just can't do *anything* in that sort of scenario...

Thought about the upgrade process a bit. How about this:

1. kerberos-configs starts generating new krb5.conf files with minimum_uid=1000. Then a little later...

2. libpam-krb5 has minimum_uid removed from pam-configs/krb5. On upgrade, it checks to see if this is in krb5.conf. If yes, great. If no, then copy pam-configs/krb5 to e.g. krb5_old, have pam-auth-update use that instead of the new krb5 profile, and show a warning to the user. The user can dismiss the warning, and nothing changes for him/her. krb5_old sticks around as a conffile (removed if package is purged, but otherwise remains untouched by future upgrades), and the regular krb5 profile doesn't have to be hobbled by backward-compatibility measures.

"Daniel Richard G." <email address hidden> writes:

> Thought about the upgrade process a bit. How about this:

> 1. kerberos-configs starts generating new krb5.conf files with
> minimum_uid=1000. Then a little later...

> 2. libpam-krb5 has minimum_uid removed from pam-configs/krb5. On
> upgrade, it checks to see if this is in krb5.conf. If yes, great. If no,
> then copy pam-configs/krb5 to e.g. krb5_old, have pam-auth-update use
> that instead of the new krb5 profile, and show a warning to the user.
> The user can dismiss the warning, and nothing changes for him/her.
> krb5_old sticks around as a conffile (removed if package is purged, but
> otherwise remains untouched by future upgrades), and the regular krb5
> profile doesn't have to be hobbled by backward-compatibility measures.

The input files to pam-auth-update aren't configuration files, so this
would need to change somewhat, but I think I can see how to do something
like this. Basically, libpam-krb5 would ship two different krb5 PAM
profiles and select between them based on whether or not krb5.conf had a
minimum_uid setting.

However, so far as I can tell, there's no way to do this right now in the
existing pam-auth-update system. The package doesn't tell pam-auth-update
which profile to add. It just configures all of them. So the user would
keep having to select between krb5 and krb5-old (or whatever) without
knowing which one too chose, and they'd conflict with each other which
would make everything more complicated.

Steve, if you're still following this bug report, do you have any feelings
about how we should handle this? My primary concern is ending up with
only ignore_root and not minimum_uid and hence opening a possible security
vulnerability wherein one could authenticate as a Kerberos principal named
daemon, etc., and log on to a system account.

Fixing Debian Bug#330882 (and in general not creating real shells for
system users) would remove a lot of my concern.

--
Russ Allbery (<email address hidden>) <http://www.eyrie.org/~eagle/>

"Daniel Richard G." <email address hidden> writes:

> How did PAM-related packages manage changes to /etc/pam.d/* before pam-
> auth-update came along? Yeah, automated editing is gauche, but it's not
> like you just can't do *anything* in that sort of scenario...

Doing nothing is exactly what they did, so far as I know. The base PAM
packages shipped the default files, and if the local sysadmin added any
additional modules, those files became modified conffiles and weren't
further changed by package installations.

--
Russ Allbery (<email address hidden>) <http://www.eyrie.org/~eagle/>

On Wed, Mar 31, 2010 at 05:06:48AM -0000, Russ Allbery wrote:

> No, it's not a conffile. The generated /etc/pam.d files are configuration
> files, but if the user is using the defaults, I believe changes to the
> defaults are just automatically applied (although Steve would know better
> than I).

Yes, pam-auth-update does word-wise parsing of the options for each module
in the stack, and does an automatic three-way merge of these options on
upgrade.

On Fri, Apr 02, 2010 at 12:31:50AM -0000, Russ Allbery wrote:
> The input files to pam-auth-update aren't configuration files, so this
> would need to change somewhat, but I think I can see how to do something
> like this. Basically, libpam-krb5 would ship two different krb5 PAM
> profiles and select between them based on whether or not krb5.conf had a
> minimum_uid setting.

> However, so far as I can tell, there's no way to do this right now in the
> existing pam-auth-update system. The package doesn't tell pam-auth-update
> which profile to add. It just configures all of them. So the user would
> keep having to select between krb5 and krb5-old (or whatever) without
> knowing which one too chose, and they'd conflict with each other which
> would make everything more complicated.

> Steve, if you're still following this bug report, do you have any feelings
> about how we should handle this? My primary concern is ending up with
> only ignore_root and not minimum_uid and hence opening a possible security
> vulnerability wherein one could authenticate as a Kerberos principal named
> daemon, etc., and log on to a system account.

You can set up two pam module configs that conflict with one another, but
there's no way for the package to automatically select between them (a
limitation of the use of debconf, really).

You can use maintainer script logic to post-process /etc/pam.d/common-* and
tune the options for pam_krb5 based on the contents of /etc/krb5.conf, but
this isn't persistent if the user at any point disables and re-enables the
krb5 pam profile.

Honestly, I don't see any good choices at the packaging level for permuting
the pam_krb5 options used.

Why wouldn't it work to have krb5-config do a one-time adjustment of
/etc/krb5.conf on upgrade (w/ version guard), and give libpam-krb5 a
versioned dependency on the version of krb5-config that implements this?

As for your original problem, Daniel, - you already have to set the
non-default minimum_uid in krb5.conf; why couldn't you automatically apply
the same setting to /etc/pam.d/common-* by the same mechanism? There may be
room for improvement in the package defaults, but ISTM that this shouldn't
stand in the way of you solving your immediate problem - especially given
that you're decidedly not using the package defaults anyway.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Isn't it possible to use debconf to change around the enabled profiles, via the libpam-runtime/profiles selection?

Steve: I'm not sure I understand what you mean by "automatically apply ... by the same mechanism." I can set minimum_uid in krb5.conf, but I also have to toss the minimum_uid= options in /etc/pam.d/common-*, because PAM module options take precedence over what's in krb5.conf.

That's why I'm using a custom Kerberos profile. It's basically identical to the stock "krb5" profile, just without the minimum_uid= bit. I *want* to use the package defaults---the only reason I can't is because minimum_uid is hardcoded in there, not in a conffile, and not under /etc.

Steve Langasek <email address hidden> writes:

> Honestly, I don't see any good choices at the packaging level for
> permuting the pam_krb5 options used.

Yeah, that's what it was looking like to me as well.

> Why wouldn't it work to have krb5-config do a one-time adjustment of
> /etc/krb5.conf on upgrade (w/ version guard), and give libpam-krb5 a
> versioned dependency on the version of krb5-config that implements this?

Hm, yes, I suppose I could try that. I don't see an obvious problem with
it, at least. I'll run that past Sam and see what he thinks about it.

I'm a little concerned by the implications for sites that maintain a
site-wide krb5.conf file that they distribute to all of their systems and
don't have this setting in it because it doesn't apply uniformly to all of
their systems. In that situation, they really need to use PAM
configuration instead, and this transition could easily leave them without
a minimum_uid setting. But I suppose that's what NEWS.Debian is for.

> As for your original problem, Daniel, - you already have to set the
> non-default minimum_uid in krb5.conf; why couldn't you automatically
> apply the same setting to /etc/pam.d/common-* by the same mechanism?
> There may be room for improvement in the package defaults, but ISTM that
> this shouldn't stand in the way of you solving your immediate problem -
> especially given that you're decidedly not using the package defaults
> anyway.

Right -- if you're already distributing a krb5.conf with this setting,
surely the same mechanism could be used to override the PAM configuration
as well.

--
Russ Allbery (<email address hidden>) <http://www.eyrie.org/~eagle/>

> But I suppose that's what NEWS.Debian is for.

You could also stick in a debconf notice, like what x11-common had for a while ("Major possible upgrade issues").

> Right -- if you're already distributing a krb5.conf with this setting, surely the same mechanism could be used to override the PAM configuration as well.

At the moment, my PAM-profile override *is* put into place by the same script that adds the minimum_uid bit to krb5.conf. But that's just a workaround. I don't need a workaround; I need a fix for this, so that I can toss the workaround :-)

(Incidentally, Russ, Steve... what would you think of asking minimum_uid as a debconf question, when initially creating krb5.conf? Other sites may want to frob this setting as well.)

"Daniel Richard G." <email address hidden> writes:

> At the moment, my PAM-profile override *is* put into place by the same
> script that adds the minimum_uid bit to krb5.conf. But that's just a
> workaround. I don't need a workaround; I need a fix for this, so that I
> can toss the workaround :-)

I guess I'm a bit baffled by why fixing your PAM configuration is a
workaround but installing a custom krb5.conf is a desired configuration
step. That just isn't how I think about the files. But that's okay, I
don't have to understand. :)

> (Incidentally, Russ, Steve... what would you think of asking minimum_uid
> as a debconf question, when initially creating krb5.conf? Other sites
> may want to frob this setting as well.)

It's a weird situation, since krb5-config doesn't know whether you're ever
going to care about the Kerberos PAM module. You may be installing a
krb5.conf for some other reason entirely.

A strong argument could be made that the whole [appdefaults] thing in
krb5.conf is a basically bad idea (particularly since krb5.conf doesn't
support file includes) and should not be used to distribute PAM
configuration, or any other app-specific configuration. That's part of
the reason why it was initially done through the PAM configuration
directly, since after all it is configuration for the PAM module, not for
the general Kerberos installation on the system. But despite feeling that
at times, I do use [appdefaults] for a bunch of my stuff because it's
convenient to have a nice configuration syntax and configuration reading
functions built-in, and because a lot of people like to distribute
Kerberos settings site-wide through krb5.conf and there are some PAM
settings that are really site-wide. (I don't think of minimum_uid as one,
but things like renewable lifetime or forwardable tickets are more.)

--
Russ Allbery (<email address hidden>) <http://www.eyrie.org/~eagle/>

On Tue, Apr 13, 2010 at 04:42:37AM -0000, Daniel Richard G. wrote:
> > But I suppose that's what NEWS.Debian is for.

> You could also stick in a debconf notice, like what x11-common had for a
> while ("Major possible upgrade issues").

This is not considered good practice, and I don't think it's warranted in
this case. I agree that this is what NEWS.Debian is for.

> (Incidentally, Russ, Steve... what would you think of asking minimum_uid
> as a debconf question, when initially creating krb5.conf? Other sites
> may want to frob this setting as well.)

They may want to, but I don't think the added complexity of debconf solely
for what I believe is a rarely-used option makes sense. Given that a
site-implementation of this requires nothing more than a simple sed
one-liner (
sed -i -e'/pam_krb5/ { s/minimum_uid=[0-9]*/minimum_uid=9999/ }' /etc/pam.d/common-*
), I don't think debconf offers much benefit here.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

> I guess I'm a bit baffled by why fixing your PAM configuration is a workaround but installing a custom krb5.conf is a desired configuration step.

krb5.conf is a config file under /etc. That's the ideal place to make configuration changes. As it is, right now, adding the minimum_uid bit involves just appending a few lines to the file---it doesn't get much simpler than that.

> It's a weird situation, since krb5-config doesn't know whether you're ever going to care about the Kerberos PAM module. You may be installing a krb5.conf for some other reason entirely.

Yeah, that's true. It's like with LDAP; my site uses LDAP for "ls -l", ~user lookups et al., but not for authentication. Still, having it in debconf may be convenient enough for sites that use pam_krb5, to be worth the "this setting only has an effect if ..." qualifier for sites that don't.

Though I haven't made much use of [appdefaults] myself (just for the PAM module), I've never seen a philosophical problem with it, since all the settings there would relate to Kerberos anyway---it just comes down to making the admin's job easier. Splitting them out elsewhere might be more pedantically correct, but...

For that matter, has there been any talk on a better way doing krb5.conf, like doing a /etc/krb5.conf.d/ or a krb5-auth-update(8) or the like? With all that's been said here about the limitations of the file and how it's structured/managed, it seems like this is a problem that's crying out for a solution.

> They may want to, but I don't think the added complexity of debconf solely for what I believe is a rarely-used option makes sense. [...] I don't think debconf offers much benefit here.

Fair enough, though I hope you're not suggesting direct modification of the /etc/pam.d/common-* files as a practical way of doing site customization. (That'll work fine until the next time someone wants to run pam-auth-update...)

On Tue, Apr 13, 2010 at 06:48:21AM -0000, Daniel Richard G. wrote:
> krb5.conf is a config file under /etc.

/etc/pam.d/common-* are also config files under /etc.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

On Tue, Apr 13, 2010 at 06:58:02AM -0000, Daniel Richard G. wrote:

> Fair enough, though I hope you're not suggesting direct modification of
> the /etc/pam.d/common-* files as a practical way of doing site
> customization. (That'll work fine until the next time someone wants to
> run pam-auth-update...)

No, it's persistent unless you disable pam_krb5 entirely. Have you tried
it?

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

> No, it's persistent unless you disable pam_krb5 entirely. Have you tried it?

Yeah, where pam-auth-update asks you "Override local changes to /etc/pam.d/common-*?" I see the man page says something about preserving module options, but if I add an option to (say) common-auth, and re-run p-a-u, the option is silently blown away. (This is on my Karmic work system; has this changed since? I don't see anything in the changelog.)

"Daniel Richard G." <email address hidden> writes:

> Yeah, where pam-auth-update asks you "Override local changes to
> /etc/pam.d/common-*?" I see the man page says something about preserving
> module options, but if I add an option to (say) common-auth, and re-run
> p-a-u, the option is silently blown away.

Er, how is it silent when pam-auth-update asks you a question?

I hesitate to tell you how to do system administration for your site, but
at Stanford we just figure out what common-* PAM configuration files we
want for all of our systems and then install them everywhere using the
same configuration management system we use for krb5.conf. That seems to
me like the best way to do things at scale. The target audience of the
automated configuration is, in my view, more the individual user
installing Debian or Ubuntu on a single system, or the system
administrator who wants to use the automated configuration tool to create
something to start from and then customize for the site.

We can certainly try to make it work more smoothly for you, but it does
feel like you're creating extra work for yourself in a few places.

--
Russ Allbery (<email address hidden>) <http://www.eyrie.org/~eagle/>

"Daniel Richard G." <email address hidden> writes:

> For that matter, has there been any talk on a better way doing
> krb5.conf, like doing a /etc/krb5.conf.d/ or a krb5-auth-update(8) or
> the like?

Debian Bug#429692. There's no progress on it so far as I know. I should
look at adding something like that to Heimdal, since it would be rather
convenient at times.

--
Russ Allbery (<email address hidden>) <http://www.eyrie.org/~eagle/>

> Er, how is it silent when pam-auth-update asks you a question?

Silent, in the sense that when you run p-a-u, it doesn't indicate that the common-* files have been modified in any way; it just presents you with the same checkbox-list of profiles. You leave everything as-is, hit OK, look at the file, and the option you had just added is gone.

(Not that I'm keen on the ability for p-a-u to preserve module options---that means I have to guess what the tool does if the options change in a profile, and it has to "merge" that change with hand-modified options in common-*. Even worse if it asks the user what to do; how do you even word that question without confusing most people?)

> That seems to me like the best way to do things at scale.

I don't want to forgo p-a-u. It's beneficial for single users and admins, yes, but it's a boon to large sites as well, because it reduces your entire PAM configuration from four arbitrary freeform "script" files (in which any mistakes can have major consequences) to a short vector of enabled/disabled PAM profiles. If a user wants to install something that hooks into the PAM stack that isn't already in the image (let's say, ConsoleKit), they don't have to hand-edit/merge anything, or come running for support when they inevitably break PAM and lock themselves out; they just check a new box. This is why I never considered hand-tuning common-*, and instead went with a custom profile. It's far better to wedge a new piece into p-a-u, than to toss p-a-u altogether and hand-maintain everything the old-fashioned way. (I can hardly even stand working with Debian Lenny anymore because it doesn't have this. That's how big an improvement it's been for me.)

> We can certainly try to make it work more smoothly for you, but it does feel like you're creating extra work for yourself in a few places.

As I see it, custom profiles and hand-editing auto-generated files are "extra work," and I'm trying to laze my way away from that! :-)

> Debian Bug#429692. There's no progress on it so far as I know.

Just #include functionality? That seems overly modest (packages would still have to modify an existing file, they can't just drop a file into a directory), but still an improvement over what we have now. *push* *goad* *cajole*

On Tue, Apr 13, 2010 at 07:41:04AM -0000, Daniel Richard G. wrote:
> > No, it's persistent unless you disable pam_krb5 entirely. Have you
> tried it?

> Yeah, where pam-auth-update asks you "Override local changes to
> /etc/pam.d/common-*?" I see the man page says something about preserving
> module options, but if I add an option to (say) common-auth, and re-run
> p-a-u, the option is silently blown away. (This is on my Karmic work
> system; has this changed since? I don't see anything in the changelog.)

Er, well, shoot - it turns out there's a bug in pam-auth-update's handling
of module options, that *only* affects modules with numbers in their names
(like pam_krb5) :/ I knew I wasn't imagining that I had tested this code, I
just didn't test it with this module...

I've committed the one-liner fix for this to the Debian package, and will
work on getting this into an SRU for lucid.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Daniel,

I've opened a separate bug, bug #579826, to track the problem with pam-auth-update not saving changes to the pam_krb5 module options. Would you mind testing the libpam-runtime 1.1.1-2ubuntu3 package in lucid-proposed and reporting on that bug whether it solves the problem for you (specifically, the problem of config changes being lost - I realize you may not consider it a complete solution for your use case)?

Happy to give it a try, Steve. I just commented in that bug report.

This is a potential solution, but putting aside the tricky case of "what happens if the common-* files have customized options, and then the PAM profile changes?", another problem with this approach is the fragility of the customization. If you deselect the module, update, then reselect it, and update... the customized module options are gone without a trace. There's no way to get them back, other than making the same edit to the common-* files again. The only real way to safeguard such customizations is to revert the files to manually-edited mode.

I'm not terribly comfortable with the way the "statefulness" works with this approach, either. The PAM configuration is not just a vector of bits indicating enabled/disabled profiles, but also whatever customizations have been made in the common-* files. If I'm not aware of what these customizations are, then I have no good way of knowing if my PAM config is just that vector, or if there's something more to it. There's no mechanism to tell me "here are all the module options that are different from what's in the profiles."

On Sat, May 15, 2010 at 12:31:18AM -0000, Daniel Richard G. wrote:

> This is a potential solution, but putting aside the tricky case of "what
> happens if the common-* files have customized options, and then the PAM
> profile changes?", another problem with this approach is the fragility
> of the customization. If you deselect the module, update, then reselect
> it, and update... the customized module options are gone without a
> trace. There's no way to get them back, other than making the same edit
> to the common-* files again. The only real way to safeguard such
> customizations is to revert the files to manually-edited mode.

The only way to preserve such options would be to store the authoritative
configuration somewhere other than in the configuration file. (Right now,
we only record what the last-seen set of module defaults are; the
configuration itself is only ever stored in /etc/.) I don't think moving
parts of the user configuration out of the config files is acceptable, and
if you disable and then re-enable a module, I don't see any reason that the
config options *should* be sticky.

> I'm not terribly comfortable with the way the "statefulness" works with
> this approach, either. The PAM configuration is not just a vector of
> bits indicating enabled/disabled profiles, but also whatever
> customizations have been made in the common-* files. If I'm not aware of
> what these customizations are, then I have no good way of knowing if my
> PAM config is just that vector, or if there's something more to it.
> There's no mechanism to tell me "here are all the module options that
> are different from what's in the profiles."

True. We could add an option for this, but as things stand today,
pam-auth-update already implements the usual guarantee required by
Debian/Ubuntu policy - that local configuration changes are respected.
Helping the user understand which bits of the configuration *are* local
changes is gravy.

Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

> I don't think moving parts of the user configuration out of the config files is acceptable, and if you disable and then re-enable a module, I don't see any reason that the config options *should* be sticky.

I wasn't so much proposing an alternative, just going over the shortcomings I see of this approach. (Sticky options would present another quandary---what if they're wrong, and you're not sure how? What easy way do you have to revert to a "pristine" config, if disabling/re-enabling a module doesn't do it?)

> pam-auth-update already implements the usual guarantee required by Debian/Ubuntu policy - that local configuration changes are respected. Helping the user understand which bits of the configuration *are* local changes is gravy.

What's implemented now is serviceable, to be sure, but I think the PAM config warrants a higher level of transparency than (say) inetd.conf. Maybe it can be machine-generated comments in the common-* files that indicate which options are customized; maybe some external file (/etc/pam.overrides? pam.custom?) that stores these options, allowing easy review and editing. I don't know what the solution would be---only that I'm vaguely uncomfortable with something as critical as the PAM config having this not-easily-inspected space in which changes can be made. There's definitely room for improvement here.

I've been working on a Kerberos system config lately, and have once more run into the title question.

It's been six years. Debian bugs #330882 (no real shells for system users) and #429692 (support include directives in krb5.conf) are done and laid to rest.

Can we move minimum_uid= out from the "krb5" PAM config and in to krb5.conf? (Perhaps adding "ignore_root" to the former at the same time)

In order to take the path of moving this setting to a krb5.conf snippet that's included by the default krb5.conf, at the very least it needs to work with both Heimdal and MIT. I don't think Heimdal supports including krb5.conf snippets, which means we can't use the include functionality in kerberos-configs.

The upgrade path for this is going to be awful no matter what. :(

I don't think it's acceptable from a security standpoint for minimum_uid to be turned off by an upgrade without an affirmative response from the user (not any sort of default), and we can't use any sort of krb5-config dependency to ensure that a Kerberos configuration fragment is available (even if Heimdal supports it) because krb5-config intentionally doesn't mess with a user-supplied krb5.conf file. So we'd have to do something really fancy here that preserves the minimum_uid setting for all old installations unless the admin intentionally removes it, and I'm not entirely sure how to do that. All the approaches I can think of have obvious ways in which the setting is lost.

Some sort of user override on the default pam-auth-update configuration would be ideal, but I can understand that not being a priority.

I would love to find a way to fix this, but we really *cannot* have an upgrade turn off minimum_uid without user intervention. I think a package that would do that would deserve a CVE due to the security vulnerabilities that can introduce, since the local admin may be relying on that setting for local security.

> I don't think Heimdal supports including krb5.conf snippets, which means we can't use the include functionality in kerberos-configs.

And even if it did, it would still be awkward (you have to add the #include at any rate). It needs to be a standard expectation these days that configs in /etc support a foobaz.d directory convention, so all you have to do is drop in a file.

> I don't think it's acceptable from a security standpoint for minimum_uid to be turned off by an upgrade without an affirmative response from the user (not any sort of default), and we can't use any sort of krb5-config dependency to ensure that a Kerberos configuration fragment is available (even if Heimdal supports it) because krb5-config intentionally doesn't mess with a user-supplied krb5.conf file.

Would it work to convert the PAM profile into a config file, and treat an existing file with minimum_uid=1000 as user-modified?

I'd argue that this file should be marked as config on its own merits. One other thing I want to do, in fact, is bump down the Priority: so that Kerberos auth is checked after Unix auth. I'd sure want to see the config merge question come up if an update messes with that.

ignore_root won't work.

The first user—the local admin—is UID 1000. If you ever try to passwd that user, it asks for the user's Kerberos password. If you try to `passwd -r files`, it ... asks for the user's Kerberos password, because the -r option doesn't work.

The root user generally is locked without a password.

Honestly the right option is probably to patch pam_krb5 to allow overriding in krb5.conf (possibly by an option, possibly by default).

John Moser <email address hidden> writes:

> Honestly the right option is probably to patch pam_krb5 to allow
> overriding in krb5.conf (possibly by an option, possibly by default).

PAM options intentionally override krb5.conf settings because you need to
be able to override some options for specific programs. Reversing that
will break way, way more than this.

krb5.conf snippets, and then moving this setting into a snippet on new
installations, is the right long-term solution to this problem, I think.
Heimdal now supports including a directory of conf files. The remaining
work is in krb5-config, and I think there's some discussion in the Debian
bug.

Separately, I do think that the pam-update-config configuration files
really should be conffiles in their own right. I'm not sure why they were
made system files installed in /usr/share originally. They seem very
config-y to me, and that would be another relatively clean solution.

--
Russ Allbery (<email address hidden>) <http://www.eyrie.org/~eagle/>