Re: iprop: Problem forcing complete database sync

[Jeffrey Hutzelman]

On October 6, 2017 5:56:22 AM EDT, Harald Barth  wrote:
>
>Removing that without putting something else in place (and I would say
>not only s->version == 0 but even current_version == 0 should trigger
>a send_complete) was probably a bad idea.

It shouldn't be needed. First, a full dump is automatically triggered if the 
master doesn't have enough log entries to bring the slave from its current 
version to the master version. so if a slave us at version 0, you either get a 
complete log replay out a full dump, either of which is sufficient. In 
practice, it should always be a full dump, because the log should never contain 
an entry for version 1.

It's also not necessary and in fact potentially harmful to check the master's 
version for 0.  A real database can never be at version 0, so if you see that, 
something is wrong, and copying that database wholesale to another server is 
probably a bad idea.

Remember that truncation does not zero the version. It throws away the existing 
log entries and writes a new log containing a single transaction with a newer 
version than the existing log. This forces a full update for any slave that was 
not already up to date.

>I think the log can be at version 0 (which means "invalid, please
>recover") but the database should not be able to be at version 0.

only an empty, never-initialized log can be at version 0.

databases don't have versions; they're entirely an artifact of the log

>> Unless I am missing something this would mean that if something like
>the code
>> above was added back, truncating the log to version 0 would make all
>slaves
>> fetch the complete database over and over again until a modification
>bumps the
>> version at the master.
>
>That would be unfortunate ;-)

it would, but truncating the log doesn't set the version to 0.

>Harald.

Re: kinit error message (Heimdal 7.4.0)

[Jeffrey Hutzelman]

On October 5, 2017 12:06:51 PM EDT, Greg Hudson  wrote:
>On 10/05/2017 07:52 AM, Harald Barth wrote:
>> And because the return code ret is the same as the error_code in the
>> context, krb5_get_error_message() just copies the string from the
>> context. However, if krb5_get_error_message() does its own lookup of
>> -1765328383 it gets "Client's entry in database has expired" which is
>> more like it. But where does "No ENC-TS found" come from and why is
>it
>> "better" than the own lookup?
>
>I didn't find anything like "No ENC-TS found" in the Heimdal source
>code, so my best guess is that this is coming from
>rd_error.c:krb5_error_from_rd_error() which does:
>
>ret = error->error_code;
>if (error->e_text != NULL) {
>krb5_set_error_message(context, ret, "%s", *error->e_text);
>} ...
>
>If my theory is correct, the KDC is sending unhelpful e_text and/or
>Heimdal is too trusting in using the e_text in preference to the string
>corresponding to the error code.

Both, I think. kinit (and other clients) ought to report something like 
"error_message (e_text)", unless the e_text is empty or the same as the message 
for the error code. of course, more complex variations are possible, what with 
both locally- and KDC-generated error codes and additional messages. but just 
blindly using the e_text and nothing else is clearly wrong.

That said, the KDC should not be sending this particular e_text in this 
situation. I'll bet there's a loop that looks for suitable PA data, and that 
message gets produced if it finishes without finding any, even though the 
problem is something else entirely.

-- Jeff




  In this case, concatenating the error
>code string with the e_text would produce a better result but not an
>ideal one, as "No ENC-TS found" shouldn't appear in the error message
>at
>all.

Re: Heimdal 7.3: ext_keytab fails with "Operation requires `get-keys' privilege"

[Jeffrey Hutzelman]

On Tue, 2017-06-27 at 16:42 -0700, Henry B (Hank) Hotz, CISSP wrote:
> > 
> > On Jun 27, 2017, at 4:23 PM, Nico Williams 
> > wrote:
> > 
> > We decided that it was never a good idea for "all" to have meant
> > "extract keys", because in general that's not desirable.
> How is extracting keys different from extracting a keytab (with the
> keys inside it)?


ext_keytab is poorly-named. In MIT Kerberos, it doesn't actually
extract anything; it generates a new key with a new kvno and stores it
in both the keytab and the kdb. MIT kadmind, going back as far as krb4,
didn't even have an operation to fetch existing keys from the database;
that was considered an exceptionally dangerous ability and not really
necessary.

Heimdal initially took a different approach, which is still what
ext_keytab does by default, for backward compatibility and to avoid
unpleasantly-surprising results. With -r, it randomizes the key
instead, which is safer. Note that ext_keytab without -r will not work
if you don't have the get-keys privilege.

I have patches going back as far as Heimdal 0.6 which make get-keys a
separate privilege not included in 'all'. I didn't write the change
that eventually made it into Heimdal, but I certainly agree with it.


-- Jeff

Re: Can ipropd-master service not do reverse DNS lookups?

[Jeffrey Hutzelman]

On Fri, 2017-04-07 at 13:41 -0700, Adam Lewenberg wrote:

> It would be nice if I could start ipropd-slave with an option to set
> the iprop principal to something other than `hostname`.

I agree, that would seem to be a useful feature. As would the ability
to set the ipropd-master service principal name, for similar reasons.

-- Jeff

Re: Re-encrypt on change of master key

[Jeffrey Hutzelman]

On March 14, 2017 6:32:13 PM EDT, Nico Williams  wrote:
>On Tue, Mar 14, 2017 at 03:26:57PM -0700, Henry B (Hank) Hotz, CISSP
>wrote:
>> Probably, but encrypting the key material separately doesn’t seem
>like a bad thing.
>
>It's a waste of CPU cycles.  It adds no real protection _by itself_
>unless you're keying in the master key on daemon startup.

it provides some additional protection against disclosure of the keys while in 
transit (i.e. during propagation). it doesn't protect against copy/paste 
attacks or do much of anything for a database at rest

Re: Heimdal 7.1 and the sqlite backend

[Jeffrey Hutzelman]

On December 22, 2016 8:25:08 AM EST, Harald Barth  wrote:
>
>I have "limited" (read "so far no") success in running heimdal with
>the sqlite db backend.
>
>I'm trying to get the sqlite backend to work lik this in
>/etc/krb5.conf and /var/heimdal/kdc.conf:
>
>[kadmin]
> database = {
>dbname = sqlite:/var/heimdal/heimdal.sqlite
>realm = TEST
> }
> require_preauth = true
>[kdc]
> database = {
>dbname = sqlite:/var/heimdal/heimdal.sqlite
>realm = TEST
> }
> require_preauth = true
>
>Which resulted in a file named /var/heimdal/heimdal.sqlite that looks
>like an sqlite database and an error when doing the init with kadmin
>-l:
>
># kadmin -l
>kadmin> init TEST
>kadmin: hdb_open: dbopen (/var/heimdal/heimdal): Inappropriate file
>type or format
>kadmin> 
>
>So somethiung I'm missing here, help or pointers to documentation how
>to set this up appreciated.
>
>Or what alternate backend do think is solid and stable and why? ;-)
>I am not planning to use ldap =;-)
>
>Harald.

kadmin -l is not a kdc and probably does not read kdc.conf.  I've not looked at 
the current code to see how much of this was resolved, but we used to have to 
patch a bunch of places to get kadmin -l and a bunch of the servers to read 
kdc.conf.

-- Jeff

Re: Heimdal 7 Release candidate 1 (7.0.1) available

[Jeffrey Hutzelman]

On Wed, 2016-11-30 at 11:38 -0800, Henry B (Hank) Hotz, CISSP wrote:
> Yay!
> 
> Did I miss a 7.0 release? Also why does 7.0.1rcX automatically become
> 7.1?

No.  Apparently the next real release will be 7.1, and they're spelling
"7.1 release candidate 1" as "7.0.1".  I'm not sure what the thinking
is behind this odd numbering scheme.  It would be a whole lot easier to
understand if the first RC were 7.0rc1 and the first real release were
7.0.


> While I’m asking, why are we renaming 1.7 as 7.x?

Good question.  I look forward to hearing the answer.

-- Jeff

Re: Preparing for the Heimdal 7 Release

[Jeffrey Hutzelman]

On Wed, 2016-10-19 at 13:02 -0700, Russ Allbery wrote:
> January 5th is the soft freeze, beyond which new packages cannot be
> introduced into Debian stretch.  This is probably the last possible date
> for Heimdal 7 making it into the next Debian stable release.  If there is
> no stable release of Heimdal (with security support) by this point, and
> more realistically several weeks prior to this for people to package it
> (assuming the Heimdal packaging team in Debian is still willing to package
> Heimdal), Debian stable will ship without Heimdal.

I'd really like to avoid that happening.  Last I checked, Heimdal was
being maintained in Debian by Brian May.  If he's no longer interested
in doing so, and assuming we can get a stable release in a timely
fashion, I can probably scare up some cycles to get the packaging in
shape.  Someone else will have to do the uploads, though...

-- Jeff