Re: TLS certificates for NFS-over-TLS floating client
Alexander Leidinger wrote: John-Mark Gurney wrote: >>Rick Macklem wrote: >>> to be the best solution. The server can verify that the certificate >>> was issued by >>> the local CA. Unfortunately, if the client is compromised and the >>> certificate is copied >>> to another client, that client would gain access. >> >> This is why CRLs/OSCP is necessary, but there isn't anything you can do >> to prevent that. This is both a better situation than what we have >> today (no auth/confidentiality), and if you tie the cert to an IP, it's >> of limited use, and better than today... > >There are multiple ways to handle that: > - First of all, you can just validate based upon "cert is signed by >trusted CA". > - Then you can require that the CN matches the hostname and the >reverse lookup matches. > - Or (similar to browsers today) you can ignore the CN and require >that the hostnames of the client matches one of the subject >alternative name (SAN) entries (requires reverse DNS lookup to work >and match). At this point, I have three variants in the code (strictest to less strict): 1 - A "-h" command line option on the server handshake daemon (called rpctlssd). This requires that all clients have certificates that validate and have the FQDN acquired via reverse DNS of the IP address of the client for the TCP connection (getnameinfo(NI_NAMEREQD)) in either the subjectAltName or CommonName. (I call X509_check_host() and this is what I understand it checks.) --> This case implies that the NFS server admin. does not "trust" the client's IP address enough to apply exports(5) line(s)to it to decide to allow the client to do an NFS mount. (An NFS server *might* be willing to allow client(s) to mount via any IP address for the #2 case below and not use this option.) 2 - Without "-h" the rpctlssd daemon passes flags into the kernel to indicate if the client provided a certificate and whether or not it verified. Then the "-tlscert" option on the appropriate exports(5) line(s) indicates that the client must have provided a certificate that verified. --> For this case (and #3), the server admin. is willing to "trust" the client's IP address enough to apply exports(5) rules to it. --> This is the case where a floating (no fixed IP) laptop could have a certificate signed by a site local CA. 3 - Similar to #2, but uses the "-tls" option on the exports(5) line(s). In this case, the client must use TLS so that data is encrypted on the wire, but does not need to have a certificate. --> The NFS server admin. "trusts" the client IP address enough that they are willing to allow the client to mount based on that IP, but wants the data to be encrypted on the wire. - Avoids the bother of generating certificates for the client(s). A part of this (as discussed in the IETF draft) is to make this easy enough to use that it does get used. (sec=krb5p achieves both user authentication and data encryption on the wire, but does not get widely used, due to the need to run a KDC, etc). Comments on the above options is welcome, since this does need to be reviewed by users. rick At this point you prevent simple cert theft as additionally you require that someone also has to be able to modify the DNS (or NFS server hosts file, but then he probably can already add an additional cert to the truststore of nfsd). Additional protection is possible by also adding the IP to the SAN. I haven't put an effort into evaluating if either IP or DNS is enough from a security point of view, or if it makes a difference if the "IP in SAN" case has an additional benefit in terms of security if it is in addition to the reverse DNS requirement. Yes this makes it more inconvenient to change the IP of a host, but if all the policy possibilities are up to the admin to configure (e.g. "cert is signed by trusted CA" as a default, and all the other possibilities as an option for nfsd), it is up to the admin and the security requirement. In general, all the possibilities are can either be distinct, or accumulative. There is also the possibility that you do not go with any CA but configure X self-signed certs for X clients as being trusted and the cert of the client needs to be an exact match with one of the X self-signed certs in the truststore. Whatever the policy(/ies) is/are in nfsd, I suggest to make it explicit in the docs what is required and what is checked for each policy. And even if it may be obvious for you Rick, please also print out why a client was rejected. Unfortunately I've seen a lot of cases where the error is a simple/frustrating "certificate rejected", but no info which part of the certificate check failed. Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org
Re: make fetchindex in /usr/ports failing with Authentication error
Nevermind. I found an email that I had received last month that explained that I had to make install ca_root_nss. Did that and all is well with make fetchindex now. Bob On Mon, Mar 23, 2020 at 03:57:30PM -0500, Bob Willcox wrote: > I just updated my /usr/ports on my 13.0-current system and after that > completed I tried to > run 'make fetchindex' and got a continuous stream of these errors written to > the display: > > fetch: https://www.FreeBSD.org/ports/INDEX-13.bz2: Authentication error > Certificate verification failed for /C=US/O=Let's Encrypt/CN=Let's Encrypt > Authority X3 > 34370576384:error:1416F086:SSL > routines:tls_process_server_certificate:certificate verify > failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915: > > Anyone have any idea what I have wrong or am missing? This was previously > working on this > system (and make fetchindex works on my 12.1 systems ok). > > Thanks, > Bob > > -- > Bob Willcox| It's possible that the whole purpose of your life is to > b...@immure.com | serve as a warning to others. > Austin, TX | > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" -- Bob Willcox| It's possible that the whole purpose of your life is to b...@immure.com | serve as a warning to others. Austin, TX | ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: users of xorg, in particular on FreeBSD 11.3
On 2020-03-23 22:00, Niclas Zeising wrote: In ports r528813 I switched FreeBSD 11 (including FreeBSD 11.3 and the This should be r529003, sorry about that. upcoming 11.4) back to use the legacy rule set. This means that once you have installed libxkbcommon 0.10.0_2 on FreeBSD 11, things should work as normal, and the environment variable XKB_DEFAULT_RULES does not need to be changed. If you are on FreeBSD 12 or later, and are using xf96-input-keyboard, you might still need to set this env variable. Please see the instructions below. Regards On 2020-03-21 00:41, Niclas Zeising wrote: [ This is cross-posted across several mailing lists for maximum visibility. Please respect reply-to and keep replies to x...@freebsd.org . Thank you! ] In order to improve support when using evdev to manage input devices, in particular keyboards, we have switched the default in x11/libxkbcommon to the evdev instead of the legacy ruleset. This was done in ports r528813 . On FreeBSD 11.3, the default configuration still requires the legacy ruleset. If you are using FreeBSD 11.3, or if you are using xf86-input-keyboard on FreeBSD 12 or later, you need to change the ruleset used by x11/libxkbcommon. If you have issues with your keyboard, most notably arrow keys, and if /var/log/Xorg.*.log shows that the "kbd" or "keyboard" driver is being used, you need to switch to legacy rules by setting the environment variable XKB_DEFAULT_RULES to xorg. The easiest way to accomplish this is by adding it to your shell startup file. As an example, for users of [t]csh, put setenv XKB_DEFAULT_RULES xorg in ~/.login For users of bourne type shells (sh, bash, ksh, zsh, ...) instead put export XKB_DEFAULT_RULES=xorg in ~/.profile Regards Regards -- Niclas Zeising ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: users of xorg, in particular on FreeBSD 11.3
In ports r528813 I switched FreeBSD 11 (including FreeBSD 11.3 and the upcoming 11.4) back to use the legacy rule set. This means that once you have installed libxkbcommon 0.10.0_2 on FreeBSD 11, things should work as normal, and the environment variable XKB_DEFAULT_RULES does not need to be changed. If you are on FreeBSD 12 or later, and are using xf96-input-keyboard, you might still need to set this env variable. Please see the instructions below. Regards On 2020-03-21 00:41, Niclas Zeising wrote: [ This is cross-posted across several mailing lists for maximum visibility. Please respect reply-to and keep replies to x...@freebsd.org . Thank you! ] In order to improve support when using evdev to manage input devices, in particular keyboards, we have switched the default in x11/libxkbcommon to the evdev instead of the legacy ruleset. This was done in ports r528813 . On FreeBSD 11.3, the default configuration still requires the legacy ruleset. If you are using FreeBSD 11.3, or if you are using xf86-input-keyboard on FreeBSD 12 or later, you need to change the ruleset used by x11/libxkbcommon. If you have issues with your keyboard, most notably arrow keys, and if /var/log/Xorg.*.log shows that the "kbd" or "keyboard" driver is being used, you need to switch to legacy rules by setting the environment variable XKB_DEFAULT_RULES to xorg. The easiest way to accomplish this is by adding it to your shell startup file. As an example, for users of [t]csh, put setenv XKB_DEFAULT_RULES xorg in ~/.login For users of bourne type shells (sh, bash, ksh, zsh, ...) instead put export XKB_DEFAULT_RULES=xorg in ~/.profile Regards -- Niclas Zeising FreeBSD Graphics Team ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
make fetchindex in /usr/ports failing with Authentication error
I just updated my /usr/ports on my 13.0-current system and after that completed I tried to run 'make fetchindex' and got a continuous stream of these errors written to the display: fetch: https://www.FreeBSD.org/ports/INDEX-13.bz2: Authentication error Certificate verification failed for /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 34370576384:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915: Anyone have any idea what I have wrong or am missing? This was previously working on this system (and make fetchindex works on my 12.1 systems ok). Thanks, Bob -- Bob Willcox| It's possible that the whole purpose of your life is to b...@immure.com | serve as a warning to others. Austin, TX | ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD-head-powerpc-build - Build #15561 (r359260) - Failure
I'm looking into this build error. I believe it's caused by under-specified LIBADD entries (and the corresponding __DP entries) and differing bfd vs lld behavior. Once I've got a failing powerpc build (in progress) I should be able to fix this pretty quickly. -- Brooks On Mon, Mar 23, 2020 at 07:57:50PM +, jenkins-ad...@freebsd.org wrote: > FreeBSD-head-powerpc-build - Build #15561 (r359260) - Failure > > Build information: > https://ci.freebsd.org/job/FreeBSD-head-powerpc-build/15561/ > Full change log: > https://ci.freebsd.org/job/FreeBSD-head-powerpc-build/15561/changes > Full build log: > https://ci.freebsd.org/job/FreeBSD-head-powerpc-build/15561/console > > Status explanation: > "Failure" - the build is suspected being broken by the following changes > "Still Failing" - the build has not been fixed by the following changes and > this is a notification to note that these changes have > not been fully tested by the CI system > > Change summaries: > (Those commits are likely but not certainly responsible) > > 359260 by brooks: > Import the kyua test framework. > > Having kyua in the base system will simplify automated testing in CI and > eliminates bootstrapping issues on new platforms. > > The build of kyua is controlled by WITH(OUT)_TESTS_SUPPORT. > > Reviewed by: emaste > Obtained from:CheriBSD > Sponsored by: DARPA > Differential Revision:https://reviews.freebsd.org/D24103 > > 359255 by brooks: > Add liblutok a lightweight C++ API for lua. > > It is added an INTERNALLIB and not installed. It will be used by kyua. > > This is a preparatory commit for D24103. > > Reviewed by: emaste > Obtained from:CheriBSD > Sponsored by: DARPA > > 359254 by emaste: > arch.7: remove Default Tool Chain footnote about xtoolchain > > MIPS was the last arch to use external toolchain by default but uses > in-tree Clang and lld as of r359233, and now no table entries reference > the footnote. > > 359253 by emaste: > arch.7: update Default Tool Chain intro text > > All FreeBSD archs now use an in-tree toolchain - Clang and ELF Tool > Chain everywhere, and lld everywhere but 32-bit PowerPC (which still > uses ld.bfd). No archs use external toolchain by default. > > Sponsored by: The FreeBSD Foundation > > 359252 by arichardson: > Fix newvers.sh on macOS 10.15 > > It appears that the macOS /bin/sh echo now defaults to -e and therefore the > `#define VERSTR` included newline characters instead of \n. This caused > compiler > errors due to unterminated strings. Fix by using printf instead of echo. > A less fragile solution might be to bootstrap the in-tree /bin/sh but that > requires more changes. > > Reviewed By: brooks > Differential Revision: https://reviews.freebsd.org/D24136 > > 359251 by arichardson: > Update arch.7 .Dd for r359233 > > Suggested by: lwhsu > > 359248 by trasz: > Add STANDARDS and HISTORY to getcontext(3), makecontext(3), and ucontext(3). > > Obtained from:NetBSD > MFC after:2 weeks > Sponsored by: DARPA > > > > The end of the build log: > > [...truncated 28.68 MB...] > /usr/obj/usr/src/powerpc.powerpc/lib/kyua/engine/libkyua_engine.a(requirements.o): > In function `(anonymous > namespace)::check_required_user(std::__1::basic_string std::__1::char_traits, std::__1::allocator > const&, > utils::config::tree const&)': > requirements.cpp:(.text+0xcf0): undefined reference to > `utils::passwd::current_user()' > requirements.cpp:(.text+0xd14): undefined reference to > `utils::passwd::user::is_root() const' > requirements.cpp:(.text+0xd84): undefined reference to > `utils::passwd::user::is_root() const' > /usr/obj/usr/src/powerpc.powerpc/lib/kyua/engine/libkyua_engine.a(requirements.o): > In function `(anonymous > namespace)::check_required_memory(utils::units::bytes const&)': > requirements.cpp:(.text+0x146c): undefined reference to > `utils::physical_memory()' > /usr/obj/usr/src/powerpc.powerpc/tmp/usr/bin/ld: Dwarf Error: found dwarf > version '4', this reader only handles version 2 information. > /usr/obj/usr/src/powerpc.powerpc/lib/kyua/engine/libkyua_engine.a(config.o): > In function `engine::user_node::push_lua(lutok::state&) const': > config.cpp:(.text+0x150): undefined reference to > `lutok::state::push_string(std::__1::basic_string std::__1::char_traits, std::__1::allocator > const&)' > /usr/obj/usr/src/powerpc.powerpc/lib/kyua/engine/libkyua_engine.a(config.o): > In function `engine::user_node::set_lua(lutok::state&, int)': > config.cpp:(.text+0x1ac): undefined reference to > `lutok::state::is_number(int)' > config.cpp:(.text+0x1c4): undefined reference to > `lutok::state::to_integer(int)' > config.cpp:(.text+0x1e0): undefined reference to > `utils::passwd::find_user_by_uid(unsigned int)' > config.cpp:(.text+0x21c): undefined reference to > `lutok::state::is_string(int)' > config.cpp:(.text+0x24c): undefined reference to > `lutok::state::to_string(int)' >
Re: HOWTO donate CPU to the fight against the Corona-virus
Quoting Alex S (from Sun, 22 Mar 2020 17:53:47 +0300): Alexander Leidinger wrote: First step would be to get CUDA support in FreeBSD. Ahem, I have a little patch, consisting of several functions copy-pasted from the Linux driver, which is supposed to enable core CUDA functionality: https://github.com/shkhln/nvshim/issues/1#issuecomment-600358438. This won't work for applications depending on unified memory support, but otherwise should be good enough. Could you plesae describe a little bit more detailed what your shim does? I have the impression it maps some linux glibc symbols which are used in a NVidia library for CUDA which only exists as a linux lib to FreeBSD symbols and when some FreeBSD binary then tries to load the NVidia CUDA lib it is then using the FreeBSD libc/m/pthread. If this is correct, what would be in your opinion the correct way to get official CUDA support? Something like the following or is more needed? - implement nvida-uvm - implement os_lock_user_pages - submit the above to NVidia and ask for the CUDA lob to be compiled for FreeBSD Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF pgpiPy9_HIm84.pgp Description: Digitale PGP-Signatur
Re: HOWTO donate CPU to the fight against the Corona-virus
Quoting Alexander Leidinger via freebsd-stable (from Mon, 23 Mar 2020 08:05:24 +0100): Quoting tech-lists (from Mon, 23 Mar 2020 01:35:52 +): Is it possible to use this with a cuda-compatible nvidia card and if so how would one go about it? First step would be to convince NVidia to provide a driver package for FreeBSD with CUDA support. Hmmm... seems we could help NVidia... https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224358 - see specially comment #6 + #7 + #13 - implement nvidia-uvm Anyone? Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF pgpKgpRsNkX7k.pgp Description: Digitale PGP-Signatur
