How to update or should we update Kerberos

[Sean Bruno]

https://github.com/heimdal/heimdal/releases

Since we haven't updated Kerberos for 6 years, I'm curious why we even
have it floating around in base.

I'm ignorant as to what we need it for.

sean

[Benjamin Kaduk]

On Mon, May 28, 2018 at 12:49:41PM -0600, Sean Bruno wrote:
> https://github.com/heimdal/heimdal/releases
>
> Since we haven't updated Kerberos for 6 years, I'm curious why we even

cy has some WIP in projects/krb5, which at least initially was to
switch to MIT krb5 in base (but now may be more ambitious and leave
both Heimdal and MIT options).

> have it floating around in base.
>
> I'm ignorant as to what we need it for.

It's a great way to simplify the bootstrap process when setting up
new machines (in an existing realm environment), in particular, it
is used in the FreeBSD cluster. Prior to pkgng's introduction of
signed packages, it was the only way for me to securely integrate a
new install that did not involve hand-transcribing key material or
putting it on removable media. I think the signed-packages
situation helps somewhat, but there are definitely still cases where
it's useful to have.

On the other hand, it's also sometimes frustrating when it's
6-year-old code and I also want to be in an MIT krb5 environment.
But I hope that cy will continue with the project branch and we'll
get an update "soon".

-Ben

[Cy Schubert]

In message <***@kduck.kaduk.org>, Benjamin Kaduk
writes:
>
> --jI8keyz6grp/JLjh
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Mon, May 28, 2018 at 12:49:41PM -0600, Sean Bruno wrote:
> > https://github.com/heimdal/heimdal/releases
> >=20
> > Since we haven't updated Kerberos for 6 years, I'm curious why we even
>
> cy has some WIP in projects/krb5, which at least initially was to
> switch to MIT krb5 in base (but now may be more ambitious and leave
> both Heimdal and MIT options).

Yes. The first phase, to make kerberos in base private, has been
committed to my project branch. It broke over 800 ports. I'm working on
cobbling a ports patch.

A private kerberos in base cleans up a lot of nasty issues in ports.

The next bit is messy. Originally my plan was to replace Heimdal with
MIT however one of our cluster admins objected. Though both Heimdal and
MIT use the same protocol, the kadmin protocol is incompatible. This is
a bit of a POLA violation.

IMO FreeBSD should ship with Kerberos client commands and private
libraries and allow the user to select one of the ports for their KDC.
A packaged base would make this a little more politically feasible.

With this in mind, the only viable option that would be acceptable to
everyone is a knob to allow building of one or another in base. In
other words Heimdal in base should probably also be updated.

>
> > have it floating around in base.
> >=20
> > I'm ignorant as to what we need it for.
>
> It's a great way to simplify the bootstrap process when setting up
> new machines (in an existing realm environment), in particular, it
> is used in the FreeBSD cluster. Prior to pkgng's introduction of
> signed packages, it was the only way for me to securely integrate a
> new install that did not involve hand-transcribing key material or
> putting it on removable media. I think the signed-packages
> situation helps somewhat, but there are definitely still cases where
> it's useful to have.

When I was at $JOB-1, our script created a keytab and pushed keys
through an ssh session from each admin's Linux, FreeBSD, or Solaris
desktop.

IMO, in today's environment, I'd be inclined to create a site-wide
meta-port with all required FreeBSD ports for the site as prereqs and a
port that configured kerberos. I know one person who does this using
site-wide Linux RPMs at a Linux shop. When the site-wide config changes
he updates his meta-ports and does yum update. This might be something
we might want to document in a howto doc for pkgng.

>
> On the other hand, it's also sometimes frustrating when it's
> 6-year-old code and I also want to be in an MIT krb5 environment.
> But I hope that cy will continue with the project branch and we'll
> get an update "soon".

I'm working through all 800 broken ports.


--
Cheers,
Cy Schubert <***@cschubert.com>
FreeBSD UNIX: <***@FreeBSD.org> Web: http://www.FreeBSD.org

The need of the many outweighs the greed of the few.

[Sean Bruno]

On 05/28/18 20:34, Cy Schubert wrote:
>>> I'm ignorant as to what we need it for.
>> It's a great way to simplify the bootstrap process when setting up
>> new machines (in an existing realm environment), in particular, it
>> is used in the FreeBSD cluster. Prior to pkgng's introduction of
>> signed packages, it was the only way for me to securely integrate a
>> new install that did not involve hand-transcribing key material or
>> putting it on removable media. I think the signed-packages
>> situation helps somewhat, but there are definitely still cases where
>> it's useful to have.
> When I was at $JOB-1, our script created a keytab and pushed keys
> through an ssh session from each admin's Linux, FreeBSD, or Solaris
> desktop.


Heh, yeah, I asked this question *wrong*. I know how we use it in the
cluster. :-)

I mean to ask, "why aren't we using ports for kerberos?" What purpose
does it serve in the base system?

sean

[Rick Macklem]

Sean Bruno wrote:
[stuff snipped]
>Heh, yeah, I asked this question *wrong*. I know how we use it in the
>cluster. :-)
>
>I mean to ask, "why aren't we using ports for kerberos?" What purpose
>does it serve in the base system?
Although I have no idea how many use it, both the NFS client and server can do
Kerberized mounts. I haven't tried, but it probably needs some bits to build it
and if you move it to ports, there would be duplicates (and the opportunity to
have one change without the other introducing a hard to find bug).

Also, I'd argue that security technology like this is pretty "core".

I am mainly referring to the libraries and client side stuff and not the KDC.

rick

[Cy Schubert]

In message <***@YTOPR0101MB0953.CAN
PRD01.P
ROD.OUTLOOK.COM>, Rick Macklem writes:
> Sean Bruno wrote:
> [stuff snipped]
> >Heh, yeah, I asked this question *wrong*. I know how we use it in the
> >cluster. :-)
> >
> >I mean to ask, "why aren't we using ports for kerberos?" What purpose
> >does it serve in the base system?
> Although I have no idea how many use it, both the NFS client and server can d
> o
> Kerberized mounts. I haven't tried, but it probably needs some bits to build
> it
> and if you move it to ports, there would be duplicates (and the opportunity t
> o
> have one change without the other introducing a hard to find bug).
>
> Also, I'd argue that security technology like this is pretty "core".
>
> I am mainly referring to the libraries and client side stuff and not the KDC.

IMO the base should only contain the libraries and client side.


--
Cheers,
Cy Schubert <***@cschubert.com>
FreeBSD UNIX: <***@FreeBSD.org> Web: http://www.FreeBSD.org

The need of the many outweighs the greed of the few.

[Benjamin Kaduk]

On Tue, May 29, 2018 at 06:04:23AM -0700, Cy Schubert wrote:
> In message <***@YTOPR0101MB0953.CAN
> PRD01.P
> ROD.OUTLOOK.COM>, Rick Macklem writes:
> > Sean Bruno wrote:
> > [stuff snipped]
> > >Heh, yeah, I asked this question *wrong*. I know how we use it in the
> > >cluster. :-)
> > >
> > >I mean to ask, "why aren't we using ports for kerberos?" What purpose
> > >does it serve in the base system?
> > Although I have no idea how many use it, both the NFS client and server can d
> > o
> > Kerberized mounts. I haven't tried, but it probably needs some bits to build
> > it
> > and if you move it to ports, there would be duplicates (and the opportunity t
> > o
> > have one change without the other introducing a hard to find bug).
> >
> > Also, I'd argue that security technology like this is pretty "core".
> >
> > I am mainly referring to the libraries and client side stuff and not the KDC.
>
> IMO the base should only contain the libraries and client side.

I'm inclined to agree -- running a KDC with the implementation in
the base system doesn't seem like a great plan to me.

To expand the NFS use case a bit more, NFS uses the GSS-API to
secure RPCs (only when security features are enabled, of course).
The GSS-API normally operates only with message tokens that are
opaque to the application layer, but for efficiency/speed we want to
do the bulk data processing in the kernel. The traditional way to
do this is to have an implementation-specific extension to the
GSS-API that exposes a "lucid" (i.e., not opaque) structure with
information about a security context and its key material, and shove
that stuff into the kernel to use for per-message processing. Since
this non-standard structure is implementation-specific, it's
generally expected that the kernel code is kept in sync with the
userspace code that does the actual security context
negotiation/handshake and the key export. This basically requires
having it in the base system, AFAICT.

-Ben

[Cy Schubert]

In message <***@YTOPR0101MB1820.CAN
PRD01.P
ROD.OUTLOOK.COM>, Rick Macklem writes:
> Warner Losh wrote:
> >Well, we're at 1 maybe 2 now. Only 3 more to go for a reprieve. :) You're
> >running FreeBSD-current on that i386 laptop, right?
> >
> >Warner
> >
> >On Wed, Oct 3, 2018 at 6:01 PM Cy Schubert <***@cschubert.com>
> >wrote:
> >
> >> I have a laptop (used for i386 testing) with that NIC. The plan is to move
> >> rl(4) to ports until I no longer need to test i386 on real hardware.
> >>
> >> Will this help?
> My main development machine has a bfe in it, so I will definitely be
> keeping a driver for it going. I don't care if it goes away from head/current
> .
> (I can leave the driver somewhere for anyone else that wants it, although
> I'm not a ports guy, so someone else would have to put it in ports.)
> The other box I run FreeBSD on is an fxp, so I'll be doing the same for it, i
> f/when it gets deleted. I find these machines work fine, but I don't do ZFS.
> [stuff snipped]

Ahh, the old laptop used for i386 testing has had ZFS on it since I got
it. Initially with only 768 MB RAM. It was the the one talked about in
the ZFS tuning wiki. It's got more RAM now, still with ZFS and no
special ZFS tuning except to reduce bshift to 13 and reduce the vdev
cache to 5 MB.

It'll probably become a hand-me-down for the grandkids when I teach
them programming. Junior committers, hopefully. I'm sure they'll want
something newer shortly later.


--
Cheers,
Cy Schubert <***@cschubert.com>
FreeBSD UNIX: <***@FreeBSD.org> Web: http://www.FreeBSD.org

The need of the many outweighs the greed of the few.