My first troublesome hallucination with a #LLM in a while: #Claude3#Opus (200k context) insisting that I can configure my existing #Yubikey#GPG keys to work with PKINIT with #Kerberos and helping me for a couple of hours to try to do so — before realising that GPG keys aren't supported for this use case. Whoops.
No real bother other than some wasted time, but a bit painful and disappointing.
Sigh. So copying and pasting commands from the internet doesn't solve my problem. This means I'm going to have to actually try and /understand/ what's wrong. I didn't sign up for this.
@hl@xdydx#FreeBSD has only support for SMBv1, which you should absolutely avoid for security reasons, although you can probably configure #samba to still allow it ... but ... don't. Nowadays I'd prefer to say FreeBSD does not support mounting SMB shares.
There are some ports available implementing "modern" SMB (v2/v3) on top of #fuse, which might be an option, but in my experience, they're not perfectly reliable and performance isn't the greatest either.
If ever possible, work on the server side and see whether you can share via #NFS instead. Either #NFSv3 (which is only "secure" as long as your network is perfectly secure and you control all participating machines, but at least it doesn't pretend to do anything else), or #NFSv4 with #kerberos security.
If the local machine is missing a keytab file, though, isn’t that local #Kerberos for PAM implementation already fundamentally broken? Without a keytab entry, you could /never/ be sure the TGT was legit.
Are keytab files optional when configuring krb5 on FreeBSD? How about other OSes? IOW, does this CVE describe a fundamental, common implementation issue with OTHER pam-krb5 installs?
I haven’t looked at the patch yet (on a phone, not entirely sure I want to get out of bed yet on a Sunday). But the more documentation I read on fixing common pam-krb5 problems, the more suspicious I become that nobody does keytab checking correctly (except, now, #FreeBSD).
That's fun. Reminds me of netcat's GAPING_SECURITY_HOLE
Skimming #RedHat Linux docs, it looks like pam_krb5 is deprecated anyway in favor of pam_sssd, and pam_sssd automatically creates a keytab file upon joining the domain -- looks non-optional.
Over in #Ubuntu land, it looks like keytab is similarly required, but you can turn it off manually (according to the man page).
So with those two examples, my bet is that most #Linux domain members are okay by default. Broken #Kerberos is still broken, but you have to go out of your way to break it (and if you have that breaking power, you can do easier things anyway like just straight up suing as someone else).
The above is based purely on documentation, no testing.
>The Government of Nova Scotia, which uses MOVEit to share files across departments, also confirmed it was affected, and said in a statement that some citizens’ personal information may have been compromised. However, in a message on its leak site, Clop said, “if you are a government, city or police service… we erased all your data.”
@lewdthewides Yeah... with #sftp servers supporting #LDAP + #Kerberos and #Wormhole existing, I just can't find myself being particularly sympathetic to them.
There was absolutely no reason to use some #proprietary service for it.