4 ms·

>First, LibreSSL should raise an error if it can't get a good source of entropy. Comments for getentropy_linux.c explain this http://www.openbsd.org/cgi-bin/cv

>First, LibreSSL should raise an error if it can't get a good source of entropy. Comments for getentropy_linux.c explain this http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libcrypto/crypto/getentropy_linux.c?rev=1.2;content-type=text%2Fplain http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libcrypto/cryp... We have very few options: - Even syslog_r is unsafe to call at this low level, so there is no way to alert the user or program. - Cannot call abort() because some systems have unsafe corefiles.

agwa 12y ago
The comments don't justify why going to the sketchy entropy is better than SIGKILLing the process, except with: > This code path exists to bring light to the issue that Linux does not provide a failsafe API for entropy collection. Trying to make a point about Linux doesn't seem like a very good reason to me.
- dobbsbob 12y ago
  The sketchy entropy is only an example, and is a work in progress. Comments read "XXX Should be replaced with a proper entropy measure." and is only called if entropy collection via /dev/urandom and sysctl have failed. If the sysctl method is depreciated it does raise(SIGKILL). They also rearranged getentroy_linux.c so that the main function with the important comments is at the top in hopes whoever is porting reads it. If you were porting this to a GNU/Linux distro, you can read their list of options and raise (SIGKILL) resulting in silent termination if that's what your platform decided to do if both entropy methods fail, or test for it earlier and fail. Since they are BSD developers they leave it up to whoever is porting to decide.
- vidarh 12y ago
  It seems to be working, given the number of articles I've seen about this issue so far.
quotemstr 12y ago
> cannot call abort() because some systems have unsafe corefiles. This logic seems specious. It's not the job of a library to solve that problem. If a system has crash dump collection configured insecurely, the problem is going to extend well past the SSL library. > * This can fail if the process is inside a chroot or if file * descriptors are exhausted. The right solution is to pre-open the file descriptor. SSL_library_init can fail. Do it there.
- dobbsbob 12y ago
  NSS does something similar since NSS will not be able to access /dev/urandom via file system after the sandbox activates the chroot so they reserve it first and fails with a log warning if no descriptors are available.
  - quotemstr 12y ago
    Warn? Hell, I'd hard-fail. Libraries need resources to do their jobs. The key is to acquire resources in places that can fail and use them in places that can't. I'm amazed and disappointed that the LibreSSL people aren't following this basic principle.
    - agwa 12y ago
      > The key is to acquire resources in places that can fail and use them in places that can't. I'm amazed and disappointed that the LibreSSL people aren't following this basic principle. To be fair to the LIbreSSL devs, the Linux-specific /dev/urandom code is currently encapsulated rather nicely behind an interface that's compatible with the OpenBSD getentropy() syscall. Following your suggestion would create a layer violation and move LibreSSL closer toward the (much maligned) OpenSSL approach to cross platform compatibility. I don't think this is a great excuse for the current design, but it's an explanation.
      - quotemstr 12y ago
        > Following your suggestion would create a layer violation and move LibreSSL closer toward the (much maligned) OpenSSL approach to cross platform compatibility. The OpenSSL approach to portability is doomed: it can only deal with cosmetic differences between platforms. I appreciate the principle of using compatibility functions instead of #ifdef, but at some point, you need to incorporate the panoply of architectures into your design. It galls me to see the OpenBSD people claim that Linux is broken merely because it is different. That's incredibly arrogance.
lcampbell 12y ago
> Cannot call abort() because some systems have unsafe corefiles. Huh, FreeBSD has MAP_NOCORE which allows the program to map pages that will explicitly not be included in the core file. I never realized that this was FreeBSD-specific extension (added in 2007?). I'm really surprised other platforms haven't adopted it, though I surmise there's a good technical reason or two. (EDIT: or maybe there's similar functionality via another API? I haven't been able to turn up anything).
- tcoppi 12y ago
  Linux since 3.4 has MADV_DONTDUMP [1], and there also appears to be a /proc filter file you can use to exclude general segments of memory from being dumped [2]. 1. http://man7.org/linux/man-pages/man2/madvise.2.html http://man7.org/linux/man-pages/man2/madvise.2.html 2. http://man7.org/linux/man-pages/man5/core.5.html http://man7.org/linux/man-pages/man5/core.5.html
  - quotemstr 12y ago
    It's hard to blacklist every piece of memory that might be sensitive. It's a much better idea, IMHO, to just put corefiles in a location accessible only to root. That's how Windows, OS X, Ubuntu, Android, and lots of other commercial systems work.
    - xorcist 12y ago
      .. which you need to do anyway. The SSL library, and the program linked against it, can fail in a thousand more ways that generate them.
- floatboth 12y ago
  Well, there is a way to disable core dumps entirely: setrlimit RLIMIT_CORE to 0

agwa 12y ago

The comments don't justify why going to the sketchy entropy is better than SIGKILLing the process, except with: > This code path exists to bring light to the issue that Linux does not provide a failsafe API for entropy collection. Trying to make a point about Linux doesn't seem like a very good reason to me.

dobbsbob 12y ago
The sketchy entropy is only an example, and is a work in progress. Comments read "XXX Should be replaced with a proper entropy measure." and is only called if entropy collection via /dev/urandom and sysctl have failed. If the sysctl method is depreciated it does raise(SIGKILL). They also rearranged getentroy_linux.c so that the main function with the important comments is at the top in hopes whoever is porting reads it. If you were porting this to a GNU/Linux distro, you can read their list of options and raise (SIGKILL) resulting in silent termination if that's what your platform decided to do if both entropy methods fail, or test for it earlier and fail. Since they are BSD developers they leave it up to whoever is porting to decide.
vidarh 12y ago
It seems to be working, given the number of articles I've seen about this issue so far.

quotemstr 12y ago

> cannot call abort() because some systems have unsafe corefiles. This logic seems specious. It's not the job of a library to solve that problem. If a system has crash dump collection configured insecurely, the problem is going to extend well past the SSL library. > * This can fail if the process is inside a chroot or if file * descriptors are exhausted. The right solution is to pre-open the file descriptor. SSL_library_init can fail. Do it there.

dobbsbob 12y ago
NSS does something similar since NSS will not be able to access /dev/urandom via file system after the sandbox activates the chroot so they reserve it first and fails with a log warning if no descriptors are available.
- quotemstr 12y ago
  Warn? Hell, I'd hard-fail. Libraries need resources to do their jobs. The key is to acquire resources in places that can fail and use them in places that can't. I'm amazed and disappointed that the LibreSSL people aren't following this basic principle.
  - agwa 12y ago
    > The key is to acquire resources in places that can fail and use them in places that can't. I'm amazed and disappointed that the LibreSSL people aren't following this basic principle. To be fair to the LIbreSSL devs, the Linux-specific /dev/urandom code is currently encapsulated rather nicely behind an interface that's compatible with the OpenBSD getentropy() syscall. Following your suggestion would create a layer violation and move LibreSSL closer toward the (much maligned) OpenSSL approach to cross platform compatibility. I don't think this is a great excuse for the current design, but it's an explanation.
    - quotemstr 12y ago
      > Following your suggestion would create a layer violation and move LibreSSL closer toward the (much maligned) OpenSSL approach to cross platform compatibility. The OpenSSL approach to portability is doomed: it can only deal with cosmetic differences between platforms. I appreciate the principle of using compatibility functions instead of #ifdef, but at some point, you need to incorporate the panoply of architectures into your design. It galls me to see the OpenBSD people claim that Linux is broken merely because it is different. That's incredibly arrogance.

lcampbell 12y ago

> Cannot call abort() because some systems have unsafe corefiles. Huh, FreeBSD has MAP_NOCORE which allows the program to map pages that will explicitly not be included in the core file. I never realized that this was FreeBSD-specific extension (added in 2007?). I'm really surprised other platforms haven't adopted it, though I surmise there's a good technical reason or two. (EDIT: or maybe there's similar functionality via another API? I haven't been able to turn up anything).

tcoppi 12y ago
Linux since 3.4 has MADV_DONTDUMP [1], and there also appears to be a /proc filter file you can use to exclude general segments of memory from being dumped [2]. 1. http://man7.org/linux/man-pages/man2/madvise.2.html http://man7.org/linux/man-pages/man2/madvise.2.html 2. http://man7.org/linux/man-pages/man5/core.5.html http://man7.org/linux/man-pages/man5/core.5.html
- quotemstr 12y ago
  It's hard to blacklist every piece of memory that might be sensitive. It's a much better idea, IMHO, to just put corefiles in a location accessible only to root. That's how Windows, OS X, Ubuntu, Android, and lots of other commercial systems work.
  - xorcist 12y ago
    .. which you need to do anyway. The SSL library, and the program linked against it, can fail in a thousand more ways that generate them.
floatboth 12y ago
Well, there is a way to disable core dumps entirely: setrlimit RLIMIT_CORE to 0