How to update or should we update Kerberos

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

How to update or should we update Kerberos

Sean Bruno-7
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


signature.asc (631 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: How to update or should we update Kerberos

Benjamin Kaduk-2
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

signature.asc (681 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: How to update or should we update Kerberos

Cy Schubert-4
In reply to this post by Sean Bruno-7
In message <[hidden email]>, 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 <[hidden email]>
FreeBSD UNIX:  <[hidden email]>   Web:  http://www.FreeBSD.org

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


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: How to update or should we update Kerberos

Sean Bruno-7


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


signature.asc (631 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: How to update or should we update Kerberos

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

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: How to update or should we update Kerberos

Cy Schubert-4
In reply to this post by Sean Bruno-7
In message <[hidden email]
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 <[hidden email]>
FreeBSD UNIX:  <[hidden email]>   Web:  http://www.FreeBSD.org

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


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: How to update or should we update Kerberos

Benjamin Kaduk-2
On Tue, May 29, 2018 at 06:04:23AM -0700, Cy Schubert wrote:

> In message <[hidden email]
> 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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"