[PATCH] Update to the Samba crypto requirements document

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

[PATCH] Update to the Samba crypto requirements document

Samba - samba-technical mailing list
Hi,

I've had a call with Nikos (GnuTLS maintainer) and we updated the REQUIREMENTS
document.

We've opened bugs to support missing crypto algorithms we require in GnuTLS
and nettle. The plan is to move to GnuTLS one day to get out of the crypto
business and have more hardware accelerated crypto in Samba.

We could also use gnutls_rnd() in generate_random_buffer() which would be much
faster than opening /dev/urandom.

Please check and push.


Thanks,


        Andreas

--
Andreas Schneider                   GPG-ID: CC014E3D
Samba Team                             [hidden email]
www.samba.org

crypto-Update-the-REQUIREMENTS.patch1.txt (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Update to the Samba crypto requirements document

Samba - samba-technical mailing list
On Wednesday, 3 January 2018 11:36:20 CET Andreas Schneider via samba-
technical wrote:

> Hi,
>
> I've had a call with Nikos (GnuTLS maintainer) and we updated the
> REQUIREMENTS document.
>
> We've opened bugs to support missing crypto algorithms we require in GnuTLS
> and nettle. The plan is to move to GnuTLS one day to get out of the crypto
> business and have more hardware accelerated crypto in Samba.
>
> We could also use gnutls_rnd() in generate_random_buffer() which would be
> much faster than opening /dev/urandom.
>
> Please check and push.
Update to add GnuTLS Milestone URL:

  https://gitlab.com/gnutls/gnutls/milestones/14



--
Andreas Schneider                   GPG-ID: CC014E3D
Samba Team                             [hidden email]
www.samba.org

crypto-Update-the-REQUIREMENTS.patch2.txt (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Update to the Samba crypto requirements document

Samba - samba-technical mailing list
In reply to this post by Samba - samba-technical mailing list
On Wed, Jan 03, 2018 at 11:36:20AM +0100, Andreas Schneider via samba-technical wrote:

> Hi,
>
> I've had a call with Nikos (GnuTLS maintainer) and we updated the REQUIREMENTS
> document.
>
> We've opened bugs to support missing crypto algorithms we require in GnuTLS
> and nettle. The plan is to move to GnuTLS one day to get out of the crypto
> business and have more hardware accelerated crypto in Samba.
>
> We could also use gnutls_rnd() in generate_random_buffer() which would be much
> faster than opening /dev/urandom.

Do we depend on gnutls even for the plain simple file server?

Volker

--
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Update to the Samba crypto requirements document

Samba - samba-technical mailing list
On Wednesday, 3 January 2018 12:41:04 CET Volker Lendecke wrote:
> On Wed, Jan 03, 2018 at 11:36:20AM +0100, Andreas Schneider via samba-
technical wrote:

> > Hi,
> >
> > I've had a call with Nikos (GnuTLS maintainer) and we updated the
> > REQUIREMENTS document.
> >
> > We've opened bugs to support missing crypto algorithms we require in
> > GnuTLS
> > and nettle. The plan is to move to GnuTLS one day to get out of the crypto
> > business and have more hardware accelerated crypto in Samba.
> >
> > We could also use gnutls_rnd() in generate_random_buffer() which would be
> > much faster than opening /dev/urandom.
>
> Do we depend on gnutls even for the plain simple file server?

We don't depend on gnutls for Samba FS (yet).

--
Andreas Schneider                   GPG-ID: CC014E3D
Samba Team                             [hidden email]
www.samba.org



Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Update to the Samba crypto requirements document

Samba - samba-technical mailing list
On Wed, Jan 03, 2018 at 12:53:18PM +0100, Andreas Schneider via samba-technical wrote:
> > > We could also use gnutls_rnd() in generate_random_buffer() which would be
> > > much faster than opening /dev/urandom.
> >
> > Do we depend on gnutls even for the plain simple file server?
>
> We don't depend on gnutls for Samba FS (yet).

So gnutls_rnd() would have to be #ifdef'ed.

If you look at commit e73ccc06, when I changed to always use
/dev/urandom, I did measure the speed, and it was not bad. How much
better is gnutls_rnd(), and does it handle fork() well? We should not
run into the situation where two smbds have the same random source in
user space.

Volker

--
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Update to the Samba crypto requirements document

Samba - samba-technical mailing list
On Wednesday, 3 January 2018 12:58:50 CET Volker Lendecke wrote:
> On Wed, Jan 03, 2018 at 12:53:18PM +0100, Andreas Schneider via samba-
technical wrote:

> > > > We could also use gnutls_rnd() in generate_random_buffer() which would
> > > > be
> > > > much faster than opening /dev/urandom.
> > >
> > > Do we depend on gnutls even for the plain simple file server?
> >
> > We don't depend on gnutls for Samba FS (yet).
>
> So gnutls_rnd() would have to be #ifdef'ed.
>
> If you look at commit e73ccc06, when I changed to always use
> /dev/urandom, I did measure the speed, and it was not bad. How much
> better is gnutls_rnd(), and does it handle fork() well? We should not
> run into the situation where two smbds have the same random source in
> user space.
I think it is faster because on it calls getentropy(), if it is available. But
we could do that too. See attached patch.


Cheers,


        Andreas


--
Andreas Schneider                   GPG-ID: CC014E3D
Samba Team                             [hidden email]
www.samba.org

lib-util-use-getentropy.patch1.txt (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Update to the Samba crypto requirements document

Samba - samba-technical mailing list
On Wed, Jan 03, 2018 at 03:23:09PM +0100, Andreas Schneider wrote:

> On Wednesday, 3 January 2018 12:58:50 CET Volker Lendecke wrote:
> > On Wed, Jan 03, 2018 at 12:53:18PM +0100, Andreas Schneider via samba-
> technical wrote:
> > > > > We could also use gnutls_rnd() in generate_random_buffer() which would
> > > > > be
> > > > > much faster than opening /dev/urandom.
> > > >
> > > > Do we depend on gnutls even for the plain simple file server?
> > >
> > > We don't depend on gnutls for Samba FS (yet).
> >
> > So gnutls_rnd() would have to be #ifdef'ed.
> >
> > If you look at commit e73ccc06, when I changed to always use
> > /dev/urandom, I did measure the speed, and it was not bad. How much
> > better is gnutls_rnd(), and does it handle fork() well? We should not
> > run into the situation where two smbds have the same random source in
> > user space.
>
> I think it is faster because on it calls getentropy(), if it is available. But
> we could do that too. See attached patch.

Do you have numbers how much faster getentropy is? One main argument
for getentropy was that you don't need a file descriptor. If you read
urandom when you need this, and open returns ENFILE, you're in
trouble. But we open urandom pretty early. Sure, we waste a file
descriptor, but a speed argument would be just as compelling :-)

Thanks,

Volker

--
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Update to the Samba crypto requirements document

Samba - samba-technical mailing list

our latest keynote speaker wrote about getentropy earlier this year:
https://blog.fefe.de/?ts=a6673828

Björn

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Update to the Samba crypto requirements document

Samba - samba-technical mailing list
On Wed, Jan 03, 2018 at 03:49:10PM +0100, Björn JACKE via samba-technical wrote:
> our latest keynote speaker wrote about getentropy earlier this year:
> https://blog.fefe.de/?ts=a6673828

This says that glibc does not have a fallback to /dev/urandom if the
syscall is not around. That means we have to implement the fallback
ourselves in case we run with modern libc on an old kernel? Or shall
we just abort then?

Volker

--
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Update to the Samba crypto requirements document

Samba - samba-technical mailing list
On 2018-01-03 at 15:54 +0100 Volker Lendecke via samba-technical sent off:
> This says that glibc does not have a fallback to /dev/urandom if the
> syscall is not around. That means we have to implement the fallback
> ourselves in case we run with modern libc on an old kernel? Or shall
> we just abort then?

I think we should do the fallback in that case. It's not too unlikely that
people use the latest patch level of a random distro but have to stick to a
patch level 0 kernel because the latest kernel is not working. And we have to
have the fallback code anyway...

Björn
--
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Update to the Samba crypto requirements document

Samba - samba-technical mailing list
On Wed, Jan 03, 2018 at 05:26:58PM +0100, Björn JACKE wrote:

> On 2018-01-03 at 15:54 +0100 Volker Lendecke via samba-technical sent off:
> > This says that glibc does not have a fallback to /dev/urandom if the
> > syscall is not around. That means we have to implement the fallback
> > ourselves in case we run with modern libc on an old kernel? Or shall
> > we just abort then?
>
> I think we should do the fallback in that case. It's not too unlikely that
> people use the latest patch level of a random distro but have to stick to a
> patch level 0 kernel because the latest kernel is not working. And we have to
> have the fallback code anyway...

If we need the fallback code anyway, and the getentropy call does not
prove a significant speed advantage, we should stick with the pretty
portable read of /dev/urandom.

Once every kernel that we have to run on has the syscall, we can
reconsider.

Just my 2ct.

Volker

>
> Björn
> --
> SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
> phone: +49-551-370000-0, fax: +49-551-370000-9
> AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
> http://www.sernet.de, mailto:[hidden email]

--
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Update to the Samba crypto requirements document

Samba - samba-technical mailing list
On 2018-01-03 at 19:32 +0100 Volker Lendecke via samba-technical sent off:
> If we need the fallback code anyway, and the getentropy call does not
> prove a significant speed advantage, we should stick with the pretty
> portable read of /dev/urandom.

I don't see speed as the main advantage. The point that /dev/urandom isn't
required is a pro point, people who use chroot or selinux or apparmor or
simply jailbash might notice quite late that /dev/urandom access is needed at
some point. And a urandom device node can also only be created by root while an
unprivileged user can't.

Björn
--
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Update to the Samba crypto requirements document

Samba - samba-technical mailing list
On Thu, Jan 04, 2018 at 10:14:01AM +0100, Björn JACKE wrote:

> On 2018-01-03 at 19:32 +0100 Volker Lendecke via samba-technical sent off:
> > If we need the fallback code anyway, and the getentropy call does not
> > prove a significant speed advantage, we should stick with the pretty
> > portable read of /dev/urandom.
>
> I don't see speed as the main advantage. The point that /dev/urandom isn't
> required is a pro point, people who use chroot or selinux or apparmor or
> simply jailbash might notice quite late that /dev/urandom access is needed at
> some point. And a urandom device node can also only be created by root while an
> unprivileged user can't.

Isn't a good random source a pretty universal requirement for many
services? If every program that wants to live in a sandbox has to
implement not only one but two mechanisms for getting randomness for
the different situations (old kernel and faulty selinux settings),
from my point of view this is just asking for trouble. This is
security relevant, and if there is one enemy of security, it is
complexity.

We can do either. /dev/urandom *or* getentropy syscall, determined at
compile time. No runtime fallback.

If modern glibc screws us on old kernels, we just can't use
getentropy.

Volker

--
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:[hidden email]