00:15:57 so the keylogger virus on efi partition backdoors your FDE 00:16:44 or worse ACPI table virus..like lenovo did m-i-t-m foo. 00:18:35 https://en.wikipedia.org/wiki/Superfish 00:19:09 https://www.networkworld.com/article/3091122/lenovo-thinkpwn-uefi-exploit-also-a 00:19:10 ffects-products-from-other-vendors.html 00:19:27 grr... 00:19:38 https://www.networkworld.com/article/3091122/lenovo-thinkpwn-uefi-exploit-also-affects-products-from-other-vendors.htm 00:20:57 https://www.networkworld.com/article/3091122/lenovo-thinkpwn-uefi-exploit-also-affects-products-from-other-vendors.html 00:21:02 correction 00:21:08 3rd time is the charm 00:24:05 award,ami,phoenix.insyde can't even trust the bios vendors.. 00:27:23 independent BIOS vendors (IBVs) who lenovo blamed it on..supply chain attack. 00:42:54 https://mfsbsd.vx.sk/ boot iso readonly, into ram/in-memory os. the local hd,ssd, or das,nas,san is nothing but data. how i would use freebsd. 00:45:02 i would bake in x11/bhyve into the iso. 00:47:29 cosmic rays and virus cant change .iso image..i know i can trust that. 00:48:09 how can i trust disk based os, that could have bit-flips on ls,grep,awk..you run tripwire/aide each time on os? 00:51:50 static-os image.iso, stable i know if shit starts crashing, its not software must be hardware. another bonus 00:53:01 patch Tuesday is stupid in production 01:03:41 https://en.wikipedia.org/wiki/SmartOS went that route 01:04:27 i been doing it since like 2007 or so with linux/vmware-vmx unionfs/aufs/overlayfs and squashfs before squashfs was in linux kernel. 01:07:12 https://en.wikipedia.org/wiki/SquashFS 3x compression 01:08:05 size / 3 = good guess..from what i see. 01:09:02 In 2009 Squashfs was merged into Linux mainline as part of Linux 2.6.29. 01:09:10 yeah no more tainted kernels 01:10:35 mfsbsd and Squashfs would rock. 01:14:17 https://imgur.com/PN1wOYI 2024 597MB.iso vs https://imgur.com/9H8EV5S 2021 350MB.iso 01:15:10 kernel,userland,X11/vmware-vmx. enough to run all other os's. 01:19:31 done beating this dead-horse. 01:21:46 https://imgur.com/02D6W7G stable 100days 01:22:02 thats low value craptop from hp..like $500 bucks 01:22:31 100 day uptime on craptop.. 01:22:44 no ECC ram 03:16:58 Who is rennj talking to? 03:18:19 thumbs: you obviously 03:18:26 I was just lurking 03:19:08 SponiX: No, he's not talking to me. 03:33:05 Bo Burnham - Welcome To The Internet 03:34:50 thumbs are you the same thumbs from..... maybe #php or #mysql or i forget where 03:48:41 cause /whois nick fail! 03:48:47 learn irc perhaps 03:49:03 you could tell the channels nick logged into 03:49:58 how about the time /ctcp nick time 03:50:11 how about the time /ctcp GoSox time 03:50:50 GoSox: Maybe. 03:54:31 Frank Gingras 04:04:57 thumbs thaewrapt that_lurker thekingo- thisbe Thorne thorre whats that about 04:05:41 Bo Burnham - Welcome To The Internet 04:07:39 hey frank, you want to argue with me? 04:11:37 Can you just stop flooding this channel with nonsense? 04:12:22 cause zfs,gbde,geli,secure boot is nonsense? 04:13:14 When you're talking to yourself for hours, yes, it is. 04:14:03 says you? 04:14:14 the arbitrator 04:17:59 i think https://en.wikipedia.org/wiki/SmartOS was on to something. but hey figure it out. 04:18:07 oxide computer 04:18:58 https://mfsbsd.vx.sk/ 04:19:12 it's all just spam? 06:46:48 rennj: SmartOS is still around: https://www.tritondatacenter.com/smartos 07:59:57 <_al1r4d> o_o i dont think rennj flooding. he is talking about nice topic, i guess.. without him, i dont know anything 08:08:59 Hmhm. I did "reboot" in my local console, and now the server is not rebooted but powered off 08:09:37 This is not the wanted behaviour. Anything I can do to change this? 08:27:26 Hrm, even a ctrl-alt-del in the console makes FreeBSD power off instead of rebooting 09:23:57 https://blog.qualys.com/vulnerabilities-threat-research/2024/07/01/regresshion-remote-unauthenticated-code-execution-vulnerability-in-openssh-server 09:40:12 freebsd-update fetch && freebsd-update install all your systems asap 09:40:53 https://www.freebsd.org/security/advisories/FreeBSD-SA-24:04.openssh.asc 09:41:56 If sshd(8) cannot be updated, this signal handler race condition can be 09:41:57 mitigated by setting LoginGraceTime to 0 in /etc/ssh/sshd_config and 09:41:57 restarting sshd(8). This makes sshd(8) vulnerable to a denial of service 09:41:57 (the exhaustion of all MaxStartups connections), but makes it safe from the 09:41:57 remote code execution presented in this advisory 09:45:29 <_al1r4d> okay thank you 10:29:00 please don't paste into the channel 10:31:54 13.3-RELEASE-p4 is fixed isn't it? 10:34:51 souji: yes. `echo | nc localhost 22 | grep 20240701` 10:36:07 ridcully: Ok, thank you! 10:58:10 time for pkgbase to catch up ;) 11:42:33 <|cos|> Successful exploitation of the sshd RCE should be made harder by ASLR, but Linux' implementation appears to only be as random as a toin-coss, according to qualys. Would FreeBSD:s ASLR provide a larger distribution of possible memory addresses? 11:50:53 <_al1r4d> I'm on root 11:50:56 <_al1r4d> sysctl: kern.securelevel=-1: Operation not permitted 11:51:00 <_al1r4d> How to fix 11:51:11 <_al1r4d> I dont want to "-1", but " 0" 11:56:02 _al1r4d: securelevel can't be downgraded when running the OS, only at boot 11:56:18 debdrup: sorry but it seemed crucial to provide that extra info 11:56:30 should have removed the nextlines 11:57:19 <|cos|> vortexx: for a rce in such a central component, i'd say you did the right call posting quickly 11:57:27 vortexx: that's what the SA is for 11:57:41 |cos|: it's not up for debate. 11:58:36 |cos|: the "toin-coss" is on 32-bit aslr 12:00:08 <|cos|> leah2: ...which is the only architecture the exploit is known to actually work on. beating the odds on 2^19 (linux amd64) requires "a few" more attempts, i guess. 12:00:29 or a better approach ;) 12:01:16 i wonder if the lock in syslog() forfeits these attacks into deadlocks however... 12:08:26 <|cos|> maybe this is drifting off-topic, but i'm bit confused about syslog() vs. syslog_r(). the problem is that the former is not reentrant when called from a signal handler, right? 12:09:16 syslog_r is an openbsd thing 12:09:21 <|cos|> i remember comparing them in the past, and getting confused since linux syslog() says it's thread safe. guess i never even got around to consider calling it from a signal. 12:09:23 but yes, that is the problem 12:09:33 * |cos| is quite sure AIX has it too 12:09:53 glibc syslog is not thread safe, as the exploit shows 12:10:48 <|cos|> the manpage on claims "Thread safe" "MT-Safe" 12:11:34 yes, but not AS-Safe 12:12:18 (it's thread safe, but that doesn't matter here) 12:44:36 nice job by the security team in responding to the regreSSHion bug so quickly! 12:59:29 +1 13:07:43 Hi. How do I use the new cloud-init support in 14.1? When I set an SSH key for a new instance in OpenStack, nothing seems to happen in FreeBSD. 13:15:10 ...and the logs from the first boot say: "/etc/rc: ERROR: Impossible to find a cloud init provider" 13:19:53 tunedal: you need this image https://download.freebsd.org/releases/CI-IMAGES/14.1-RELEASE/amd64/Latest/ 13:20:06 it should work out of the box 13:22:06 at least it worked with sysutils/vm-bhyve 13:24:02 Hmm, I think I used the BASIC-CLOUDINIT image, not the BASIC-CI one. Shouldn't that work? 13:29:37 tunedal: you are right, I probably misled you 13:29:51 it should have worked 13:30:03 I mean, it works in the sense that it boots, but it's not getting configuration from OpenStack to set up the SSH keys. The error message seems to be /etc/rc.d/nuageinit looking for a disk with configuration – but shouldn't OpenStack provide that somehow? 13:30:51 is this true? https://wiki.freebsd.org/PkgBase#Status I don't see any updates for today yet, and it's 13:30 UTC 14:41:01 good morning from California party people. I see the buzz is already going about today's news x_x 14:46:16 it should show you a diff 14:58:39 rtyler in terms of ssh? 14:58:51 aye 14:59:56 yeah recompiling - looks rushed, the commit message should have been p2 - https://cgit.freebsd.org/src/commit/?h=releng/14.1&id=1eba659e2f689d4014136048a8e470e852bdc69b 15:29:11 Probably better to inform the commiter via email. 16:48:29 folks, any idea what is the impact of the new opensshd remote code execution to freebsd? It looks openbsd is not impacted, but no idea with freebsd 16:49:22 lets not have any misinformation 16:49:27 here is the official security advisory 16:49:29 https://www.freebsd.org/security/advisories/FreeBSD-SA-24:04.openssh.asc 16:50:43 thanks, that is what I was looking for 16:50:45 if you like to use a newsreader, here is the feed: 16:50:47 https://www.freebsd.org/security/feed.xml 16:51:40 There is interesting discussion of the issue here: https://news.ycombinator.com/item?id=40843778 16:52:02 thx 16:53:38 that is interesting discussion, thanks! 18:33:59 agreed, that was helpful 18:46:13 I'd like to create an user just to pull backups from a server, since that user wouldn't have any login privileges where would be the bsd way to store its keys? /var/ids/user ? 18:50:54 you can make that user's home directory whatever* you want 18:51:38 * rtyler giggles at * 18:52:32 but /var/ids doesn't make quite as much sense as /home/user 18:52:36 if you're following hier 18:53:05 Just don't put them in /tmp 18:53:14 vkarlsen: that's what the * was for 18:54:18 :) 18:56:23 rtprio so nologin but /home/user, ok. 18:58:00 that's what i would do 19:05:51 s2r: you can't use the user that pushes the backups to the backup server? 19:35:29 rtprio I would rather do a pull from the server. 20:01:42 s2r, I wonder what is happening when one "pulls backups from the server"? I either have the server pull a backup from a client. Or... I have the client push a backup to the server. 20:02:19 In order to restore a backup almost certainly it needs to be the root user to restore owner:group:mode of files. 20:02:47 In order to push backups almost certainly it would need to be local root and remote storage might be unpriviledged blob storage. 20:04:17 In order to pull a backup onto a server the server would almost certainly need root access to the client in order to perform the backup pull. And then locally they would already be root but perhaps might be a non-privileged user locally storing backup blobs. 20:06:40 syncoid privileges for non-root user, fwiw: https://github.com/jimsalterjrs/sanoid/wiki/Syncoid#running-without-root 20:07:10 i do pulls, whether scp or sanoid/zfs 20:10:47 As I read that root has bestowed specific feature permissions send,hold,mount,snapshot,destroy for datasets to the non-root user elevating that user to an equiv-for-dataset-access for backup for that user. It's a reduced privilege set. 20:11:02 But it does include destroy in the set. So not completely without teeth to bite with. 20:12:49 And there is still the need for ssh access (I presume ssh is being used for access) and therefore the user credentials for ssh authorization still need to be managed. Which is at the point of the question from s2r asking "I'd like to create an user just to pull backups from a server, since that user wouldn't have any login privileges where would be the bsd way to store its keys?" 20:14:36 If I ignore my question clarifying "pull backups" then the keys would normally go in $HOME/.ssh/authorized_keys normally. However the sshd_config may be modified to have the authorized_keys file located elsewhere. Anywhere else. And as far as I know there is no BSD standard other location for it. It would be a local decision to locate it where it is thought best to locate it. 20:35:08 I've added a HDD to my server, and running "zpool attach zhdd raidz2-0 /dev/da0" but I get "cannot attach /dev/da0 to raidz2-0: can only attach to mirrors and top-level disks". What am I missing? 20:35:25 FreeBSD 14.1-RELEASE with updated ZFS on pools 20:35:59 The zhdd pool consists of disks da1 through da6 atm 20:37:06 not being able to add disks to a raidz, its there in the message 20:37:25 Yes, I know. But that should be able to do now 20:40:53 What? It's possible to expand raidz2 VDEVs now? 20:41:02 https://freebsdfoundation.org/blog/raid-z-expansion-feature-for-zfs/ 20:42:04 Are you sure that is available in 14.1R? 20:42:35 I thought it was added with 14.0, but tbh I can't find it now of course 20:44:00 I see some preparation for it in https://cgit.freebsd.org/src/commit/?id=78c9d8f1ce65 but not that it is all there yet. 20:45:24 Well clearly I don't know anything so... Good luck! It's a feature we would all love to have available! 20:45:56 yup. My pool is getting to close to full. want to add another 12TB disk to it 20:46:50 The steady state of disks is full. 20:47:56 ? 21:02:26 spare disk space is like socks. Always close to none left 21:22:15 s2r, rwp, what I do is i have a $script_user and an $scp_user. the script_user has rights to run backup scripts to prepare the things to be transferred. then the scp_user has the right to scp from a specific location. and each of their authorized_keys files specifies various restrictions, such as a specific command (script) for the script_user to run, and scp_user has no-pty