CheriBSD
Any thoughts on the security and performance of CHERI. The claim is making existing C codebases memory safe with insignificant modifications to the code being required. https://www.cheribsd.org/
Re: xenodm freezes on current
19 Aug 2024 02:29:39 Henry Ford : > Have you enabled the intel driver in xorg.conf? > I had this same issue, and switching back to the default modesetting > driver fixed it for me. I have the same issue on the latest snapshot kernel #266 on a thinkpad t410 with no xorg.conf used. regards, kc
Appimage
I'm not sure if this is a pipe dream but atleast I imagine the filesystem API and /proc avoidance is likely possible. "https://github.com/AppImage/AppImageKit/issues/98";
Re: Mouse touchpad no longer working
Ignore this. Sorry for the junk thread. Apparently there is a touchpad disable button that I hit whilst trying to work out why the OpenBSD compatible wireless cards Windows driver isn't working with Windows.
Mouse touchpad no longer working
Unfortunately due to covid the following machine hasn't been updated a great deal. The touchpad works in Windows and used to work in OpenBSD but now no movement or button presses have any affect. > OpenBSD 7.0-current (GENERIC.MP) #133: Tue Nov 30 00:53:23 MST 2021 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 3129393152 (2984MB) > avail mem = 3018649600 (2878MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe7d50 (39 entries) > bios0: vendor Acer version "V1.14" date 07/26/2011 > bios0: Acer TravelMate 5735 > acpi0 at bios0: ACPI 4.0 > acpi0: sleep states S3 S4 S5 > acpi0: tables DSDT FACP HPET APIC MCFG ASF! SLIC BOOT SSDT > acpi0: wakeup devices UHC0(S3) EHC1(S3) UHC3(S3) EHC2(S3) EXP3(S4) AZAL(S3) > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpihpet0 at acpi0: 14318179 Hz > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Core(TM)2 Duo CPU T6670 @ 2.20GHz, 2194.80 MHz, 06-17-0a > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN > cpu0: 2MB 64b/line 8-way L2 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > cpu0: apic clock running at 199MHz > cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2.1.3, IBE > cpu1 at mainbus0: apid 1 (application processor) > cpu1: Intel(R) Core(TM)2 Duo CPU T6670 @ 2.20GHz, 2194.50 MHz, 06-17-0a > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN > cpu1: 2MB 64b/line 8-way L2 cache > cpu1: smt 0, core 1, package 0 > ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins, remapped > acpimcfg0 at acpi0 > acpimcfg0: addr 0xf800, bus 0-63 > acpiprt0 at acpi0: bus 0 (PCI0) > acpiprt1 at acpi0: bus -1 (PEGP) > acpiprt2 at acpi0: bus 2 (EXP1) > acpiprt3 at acpi0: bus 4 (EXP2) > acpiprt4 at acpi0: bus 5 (EXP3) > acpiprt5 at acpi0: bus -1 (EXP4) > acpiprt6 at acpi0: bus -1 (EXP5) > acpiprt7 at acpi0: bus -1 (EXP6) > acpiec0 at acpi0 > acpipci0 at acpi0 PCI0 > "pnp0c14" at acpi0 not configured > acpibat0 at acpi0: BAT0 model "13848641818153793" serial 63 type Lion oem > "SANYO " > acpiac0 at acpi0: AC unit online > acpibtn0 at acpi0: PWRB > acpibtn1 at acpi0: LID0 > acpibtn2 at acpi0: SLPB > acpicmos0 at acpi0 > "PNP0C14" at acpi0 not configured > "PNP0C14" at acpi0 not configured > acpicpu0 at acpi0: !C3(100@162 mwait.3@0x50), !C2(500@1 mwait.1@0x10), > C1(1000@1 mwait.1), PSS > acpicpu1 at acpi0: !C3(100@162 mwait.3@0x50), !C2(500@1 mwait.1@0x10), > C1(1000@1 mwait.1), PSS > acpitz0 at acpi0: critical temperature is 110 degC > acpivideo0 at acpi0: VGA_ > acpivideo1 at acpi0: OVGA > acpivout0 at acpivideo1: DD02 > cpu0: Enhanced SpeedStep 2194 MHz: speeds: 2201, 2200, 1600, 1200 MHz > pci0 at mainbus0 bus 0 > pchb0 at pci0 dev 0 function 0 "Intel GM45 Host" rev 0x07 > inteldrm0 at pci0 dev 2 function 0 "Intel GM45 Video" rev 0x07 > drm0 at inteldrm0 > intagp0 at inteldrm0 > agp0 at intagp0: aperture at 0xc000, size 0x1000 > inteldrm0: apic 4 int 16, GM45, gen 4 > "Intel GM45 Video" rev 0x07 at pci0 dev 2 function 1 not configured > uhci0 at pci0 dev 26 function 0 "Intel 82801I USB" rev 0x03: apic 4 int 20 > uhci1 at pci0 dev 26 function 1 "Intel 82801I USB" rev 0x03: apic 4 int 21 > ehci0 at pci0 dev 26 function 7 "Intel 82801I USB" rev 0x03: apic 4 int 21 > usb0 at ehci0: USB revision 2.0 > uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 > addr 1 > azalia0 at pci0 dev 27 function 0 "Intel 82801I HD Audio" rev 0x03: msi > azalia0: codecs: Realtek ALC272, Intel/0x2802, using Realtek ALC272 > audio0 at azalia0 > ppb0 at pci0 dev 28 function 0 "Intel 82801I PCIE" rev 0x03: msi > pci1 at ppb0 bus 2 > ppb1 at pci0 dev 28 function 1 "Intel 82801I PCIE" rev 0x03: msi > pci2 at ppb1 bus 4 > iwn0 at pci2 dev 0 function 0 "Intel Centrino Advanced-N 6200" rev 0x35: msi, > MIMO 2T2R, MoW, address 58:94:6b:6f:f8:b4 > ppb2 at pci0 dev 28 function 2 "Intel 82801I PCIE" rev 0x03: msi > pci3 at ppb2 bus 5 > bge0 at pci3 dev 0 function 0 "Broadcom BCM57780" rev 0x01, BCM57780 A1 > (0x57780001): msi, address 1c:75:08:f5:34:9b > brgphy0 at bge0 phy 1: BCM57780 10/100/1000baseT PHY, rev. 1 > uhci2 at pci0 dev 29 function 0 "Intel 82801I USB" rev 0x03: apic 4 int 23 > uhci3 at pci0 dev 29 function 1 "Intel 82801I USB" rev 0x03: apic 4 int 19 > uhci4 at pci0 dev 29 function 2 "Intel 82801I USB" rev 0x03: apic 4 int 20 > uhci5 at pci0 dev 29 function 3 "Intel 82801I USB" rev 0x03: apic 4 int 18 > ehci1 at pci0 dev 29 function 7 "Int
Re: How to check that HT is working and used?
In case you missed Stuarts email that also mentioned that you were booting the uni processor kernel. Then I will re-mention that HT, if still re-enabled by you, was disabled by default for security reasons (hunch) on OpenBSD. Linux came to realise issues later, but decided to stick with insecure by default on a lot of hw!
Re: DHCP non-issues
On July 20, 2021 10:35:55 AM UTC, Kevin Chadwick wrote: >On Mon, 19 Jul 2021, 12:47 Christian Weisgerber, >wrote: > >> Look guys, it's simple. >> >> If you want IPv6 (SLAAC) autoconfiguration, you set "inet6 autoconf" >> for that interface. slaacd(8) will then automatically handle things. >> >> If you want IPv4 (DHCP) autoconfiguration, you set "inet autoconf" >> for that interface. dhcpleased(8) will then automatically handle >> things. If you require special DHCP options that dhcpleased(8) >> doesn't include, then you don't enable autoconfigurarion and run >> dhclient(8) instead, which can be extensively configured. >> > Is it possible to try inet autoconf and then also inet6 autoconf opportunistically maybe even with inet preferred, for deployment in foreign networks?
Re: Adding Password Protection to Single User Mode
On 7/6/21 12:27 PM, Valdrin MUJA wrote: > Hi Folks, > > I want to add a small password protection mechanism to > "boot -s" (single-user mode). > > Therefore, I'm working on /sys/stand/boot/boot.c, I've written > some code in boot.c, and run "make", "make obj", "make install" > in /sys/. However, I couldn't enable my update "boot" binary on startup. > On startup, the default boot program is working. > > How can I replace my updated boot program with the default one? > > P.S.: I've tried compile and install kernel and the result didn't change. If you remove secure from console in /etc/ttys then a standard install will require a password. Of course if they can boot a custom kernel or bsd.rd then any password can always be bypassed.
Re: pf firewall packet size
> > > There is just small ACK packets left. I wonder what is solution for > small packets in OpenBSD Checkout set prio in pf.conf...TCP ACKs with no data payload
Re: sysupgrade failure logs
On 2/15/21 2:14 PM, Ed Ahlsen-Girard wrote: > I am confident that I can speak for for ... a non-zero number of > people who use sysupgrade the way it says to on the box and would miss > it if it went away. +1 Even though it is a little surprising that some people don't realise how easy it is to upgrade OpenBSD manually. I guess that surprise will just happen a little later on.
Dropping privileges and execve CAVEAT
If rather than setuid, a root process calls setgroups(1000) setresgid(1000, 1000, 1000) setresuid(1000, 1000, 1000) Is there anything to worry about in regard to the caveat in execve(2)? "If a program is setuid to a non-superuser, but is executed when the real uid is "root", then the process has some of the powers of a superuser as well." Thanks, Kc
Re: Go language and pledge exec promises
On 1/21/21 3:06 PM, Theo de Raadt wrote: >> This is just testing with the most permissable settings. > That statement is wrong. The most permissable setting is to not use > pledge, and use full POSIX. > True, perhaps that explains it. I should have done more testing and not assumed it might be an upstream issue so readily, and could be fixed like syscall 74. > pledge use should be based upon informed decisions after study of > everything a program needs to do, rather than slapping it in and then in > an uneducated fashion complaining about the result not meeting > expectations. > > People using pledge in high-level language programs are making > uninformed decisions, since the high-level language environments perform > many complicated operations. > I will give this some consideration, especially wrt upstream changes that will not see pledge calls. Perhaps I should limit pledge use to Go code that does not use any libraries or drop it all together. Unveil is still useful. > Your problem report is useless. You don't supply source, you don't show > what is going on, yet you want hand-holding. You don't trace what the > program or the heavy-environment is doing. I could decouple the source from my libraries and provide the source and the full trace. Do you want it? I don't need execpromises anyway so I'd be doing it mainly for Go users. The program simply modifies /dev/speaker permissions, drops privs to an unpriviledged user, unveils and then executes. "/bin/sh -c echo A > /dev/speaker"
Re: Go language and pledge exec promises
On 1/21/21 2:58 PM, Kevin Chadwick wrote: >>>840 beep CALL pledge(0xcf4000,0xcae384) >>>840 beep STRU promise="stdio rpath wpath cpath dpath tmppath inet >>> mcast fattr chown flock unix d\ >>> ns getpw sendfd recvfd tape tty proc exec prot_exec settime ps vminfo >>> id pf route wroute audio v\ >>> ideo bpf unveil error" >>>840 beep STRU execpromise="" >>>840 beep RET pledge 0 >>> >> Whatever you are trying to do is ridiculous. > Absolutely. In fact the program itself is pointless to pledge, playing a beep > to > the speaker. However, I had pledge disabled in my binaries due to the syscall > 74 > Go bug that was fixed. This is just testing with the most permissable > settings. > Perhaps that in itself could cause an issue. Is execpromise="" equivalent to passing null in c as a nil string in Go is initialised to "" (function sig = string) Perhaps I should ktrace the whacky full promise passsed as execpromise too?
Re: Go language and pledge exec promises
On 1/21/21 2:54 PM, Theo de Raadt wrote: >>> Run your code under ktrace and see what is actually passed to pledge(), >>> that might give some clues. >>> >>> >>840 beep CALL pledge(0xcf4000,0xcae384) >>840 beep STRU promise="stdio rpath wpath cpath dpath tmppath inet >> mcast fattr chown flock unix d\ >> ns getpw sendfd recvfd tape tty proc exec prot_exec settime ps vminfo >> id pf route wroute audio v\ >> ideo bpf unveil error" >>840 beep STRU execpromise="" >>840 beep RET pledge 0 >> > Whatever you are trying to do is ridiculous. Absolutely. In fact the program itself is pointless to pledge, playing a beep to the speaker. However, I had pledge disabled in my binaries due to the syscall 74 Go bug that was fixed. This is just testing with the most permissable settings. Perhaps that in itself could cause an issue.
Re: Go language and pledge exec promises
On 1/21/21 2:18 PM, Stuart Henderson wrote: > Run your code under ktrace and see what is actually passed to pledge(), > that might give some clues. > > 840 beep CALL pledge(0xcf4000,0xcae384) 840 beep STRU promise="stdio rpath wpath cpath dpath tmppath inet mcast fattr chown flock unix d\ ns getpw sendfd recvfd tape tty proc exec prot_exec settime ps vminfo id pf route wroute audio v\ ideo bpf unveil error" 840 beep STRU execpromise="" 840 beep RET pledge 0
Go language and pledge exec promises
I can live without exec promises. However I believe I have stumbled across an
issue on 6.8 and current.
When I try to exec /bin/sh where promises is a string of all possible promises
from the man page and the second parameter is exec promises.
unix.Pledge(promises, "")
I get
sh[97964]: pledge "stdio", syscall 253
unix.Pledge(promises, promises)
results in no execution and no error
If I use unix.PledgePromises that omits the exec promises instead of unix.Pledge
then it works just fine?
https://github.com/golang/sys/blob/master/unix/pledge_openbsd.go
syscalls.master:
253 STD NOLOCK { int sys_issetugid(void); }
Re: Usermod -G failure without error
On 1/19/21 10:59 AM, Kevin Chadwick wrote: > Sorry, I think that I must have ran groupadd first which brought users and > groups IDs, out of sync. Ok, after failing to reproduce it this morning; With admin safely jumping to 1020, I worked it out. groupadd elansys useradd admin userdel admin groupdel elansys useradd admin groupadd elansys /etc/passwd admin:*:1018:1018::/home/admin:/bin/ksh /etc/group admin:*:1019: elansyssftp:*:1018: Shoudl userdel remove the group too?
Re: Usermod -G failure without error
> For example, does 'admin' exist in /etc/passwd? What does "grep elansyssftp > /etc/group" return? I had played a little. So it shows /bin/ksh and test user etc. /etc/passwd admin:*:1018:1018::/home/admin:/bin/ksh /etc/group admin:*:1019: elansyssftp:*:1018:test Sorry, I think that I must have ran groupadd first which brought users and groups IDs, out of sync. I am guessing, the elansyssftp group seems to have gotten the same ID as admin user, so there is no point adding it and so returns without error? The admin group is then marooned, I guess, so I broke the user namespace system. I see that system groups without users have dedicated IDs, so my bad. Is there anything to improve upon? An informational message be printed in the case of the permission already being facilitated? Obviously the return code 0 is correct. Alternatively, maybe when you add a group without an ID, a warning? Or perhaps a groupadd man page CAVEAT? Or I could just pay ultimate attention to the numbers, in the future?
Usermod -G failure without error
When I run the following commands, the elansyssftp group isn't populated. Yet using a differently named group seems to work. I seem to have been able to do so, on two different systems. useradd -m -s /sbin/nologin -p `cat /etc/ssh/ssh_host_ed25519_key.pub | /usr/bin/encrypt -b a` admin groupadd elansyssftp usermod -G elansyssftp admin Is this a bug, can anyone reproduce it or clear up my confusion? Thanks, Kc
Re: wg(4) listen on a specific interface / address
On 10/29/20 5:20 PM, Kevin Chadwick wrote: > I believe it actually operates at layer 2/3 below IP and uses the default gw > IP > to decide where to operate for a peer to peer link. I'm not actually sure how that makes any sense as it uses UDP which is layer 4. But this says layer 3 "https://www.wireguard.com/papers/wireguard.pdf";
Re: wg(4) listen on a specific interface / address
On 10/29/20 4:00 PM, Pierre Emeriaud wrote: >>> Is there a reason why wg needs such a large bind? >> I don't know why wg does that, because I haven't looked at the code. >> Your configuration is definately pushing the limits. > Allright many thanks Theo. Maybe Jason can chime in on this topic. I believe it actually operates at layer 2/3 below IP and uses the default gw IP to decide where to operate for a peer to peer link. I could be totally wrong and I just hit some Windows bugs but I had issues getting the Windows clients to work for more than a few seconds on a LAN around 6 months ago and that was my conclusion (designed for easy internet use). I just used OpenSSH tunnels instead?
Re: Firefox Security 2020
On 2020-08-17 06:06, Stuart Henderson wrote: >> With the recent news. I decided to take a look again at Firefox and after a >> days >> use on multiple systems, it even seems to be faster than Chrome. >> >> I notice significant work on pledge support. Does anyone know if it's >> comparable >> to Chrome on that front now or still held back by not being designed with >> isolation in mind? > Run "ps -O pledge" with both running and see what you think. (Shorter > pledge list = more restricted). > > I see, nice, pledge is ace, Thank You Darn it. I'm sure I saw an article saying Firefox isolation is comparable to Chrome on Windows now. I guess they simply meant it uses similar tech at a high level, on Windows. Also not clear if rlbox has gone further than testing a widely unused libGraphite on Linux yet. Perhaps rlbox has complexity issues. "https://arxiv.org/pdf/2003.00572.pdf"; Back to Chrome for me then.
Firefox Security 2020
With the recent news. I decided to take a look again at Firefox and after a days use on multiple systems, it even seems to be faster than Chrome. I notice significant work on pledge support. Does anyone know if it's comparable to Chrome on that front now or still held back by not being designed with isolation in mind? What do people think about rlbox? https://hacks.mozilla.org/2020/02/securing-firefox-with-webassembly/ Is Rust delivering security benefits for firefox?
TLS stall ftp or pkg_add
Has anyone else noticed stalls when using a https link in /etc/installurl. I found that downloading the following file works fine in Chrome but stalls at 128K every time via ftp before completing a significant time later. https://ftp.heanet.ie/pub/OpenBSD/snapshots/packages/amd64/bzip2-1.0.8.tgz It also downloads without stalling via ftp as an http link.
Re: An Athn ar9280 client seems to require cold boots of late?
With this patch I have been able to bring the device down and back up with a subsequently successful dhclient and http download. Annoying how quirky and poorly documented, chips often are! Thank You
Re: An Athn ar9280 client seems to require cold boots of late?
On 2020-06-29 08:35, Kevin Chadwick wrote: > After leaving this up all weekend, the issue seems to have occurred without an > ifconfig down command too. Though the down triggers it immediately. Perhaps it's a hw issue. I have tried updating the coreboot firmware to see if it helps as well as toggling the few bios options but the issue still occurs. I shall try older firmware if newer snapshots or coreboot releases don't solve it. Rebooting it isn't a huge issue for now and I can't really afford any more time. Does anyone have any tips on the best pcengines apu4 bios settings for OpenBSD? I notice some extent acpipci, Perhaps of interest to someone. OpenBSD 6.7-current (GENERIC.MP) #313: Sun Jun 28 22:05:28 MDT 2020 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 1996484608 (1903MB) avail mem = 1921003520 (1832MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x7ee9e020 (13 entries) bios0: vendor coreboot version "v4.12.0.1" date 05/29/2020 bios0: PC Engines apu4 acpi0 at bios0: ACPI 6.0 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP SSDT MCFG APIC HEST SSDT SSDT HPET acpi0: wakeup devices PWRB(S4) PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) PBR8(S4) UOH1(S3) UOH2(S3) UOH3(S3) UOH4(S3) UOH5(S3) UOH6(S3) XHC0(S4) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-64 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD GX-412TC SOC, 998.40 MHz, 16-30-01 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu0: TSC skew=0 observed drift=0 cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD GX-412TC SOC, 998.19 MHz, 16-30-01 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu1: TSC skew=32 observed drift=0 cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: AMD GX-412TC SOC, 998.13 MHz, 16-30-01 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT cpu2: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu2: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu2: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu2: TSC skew=31 observed drift=0 cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: AMD GX-412TC SOC, 998.14 MHz, 16-30-01 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT cpu3: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu3: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu3: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu3: TSC skew=28 observed drift=0 cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 4 pa 0xfec0, version 21, 24 pins ioapic1 at mainbus0: apid 5 pa 0xfec2, version 21, 32 pins acpihpet0 at acpi0: 14318180 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (PBR4) acpiprt2 at acpi0: bus 2 (PBR5) acpiprt3 at acpi0: bus 3 (PBR6) acpiprt4 at acpi0: bus 4 (PBR7) acpiprt5 at acpi0: bus 5 (PBR8) acpicpu0 at ac
Re: An Athn ar9280 client seems to require cold boots of late?
On 2020-06-29 07:36, Stefan Sperling wrote: > There is one interop problem in 6.7 which has been fixed in -current > by reverting a change which was committted between 6.6 and 6.7: > https://marc.info/?l=openbsd-cvs&m=159100149411516&w=2 > Perhaps that applies to your situation? Could you check if a -current > bsd.rd kernel is able to connect to this problematic AP? After leaving this up all weekend, the issue seems to have occurred without an ifconfig down command too. Though the down triggers it immediately.
An Athn ar9280 client seems to require cold boots of late?
After upgrading via sysupgrade for a few releases, I have had to cold boot to get dhclient athn0 working on an ar9280 in client mode. Since my latest upgrade to a snapshot of Jun 17 kernel #275 with the previous kernel being from Jun 2nd #237. I seem to have to cold boot after running ifconfig athn0 down and then back up, where I'm *fairly* sure that I didn't need to before that Jun 17th upgrade. ifconfig debug mode shows the wireless handshake completing 4/4. Yet dhclient can't establish a link until cold booted. A warm reboot does not resolve the problem. Has anyone else seen this or can reproduce it? I'll try a sysupgrade in the meantime but I'm not sure there has been any code changes in areas that could resolve it.
Re: Thoughts or links on optimally secure defaults for pf.conf and fstab, whilst aiming to minimise support issues.
On 2020-06-14 13:58, Kevin Chadwick wrote: > set reassemble yes no-df > match scrub (random-id max-mss 1389) > > Should I drop the no-df from set reassemble? Any other recommendations > welcome? To be clear. Previously, with scrub (no-df... the set reassemble line was missing/default.
Thoughts or links on optimally secure defaults for pf.conf and fstab, whilst aiming to minimise support issues.
We are basing the server part of our products on OpenBSD. We care more about reducing support issues than say performance. We will have batteries but I hope to deploy some kind of root partition redundancy, for upgrades. However, Is sync or softdep a better default for the best chance of avoiding manual fsck/support issues? Turns out the issue that I had on pkg_add/ftp, that seemed to be eliminated by switching to 3g was somehow, a short lived reprieve and was more to do with re-assembly settings that had worked for me flawlessly, for years on a landline. I believe scrub had no-df before and I am now using without issue, so far. set reassemble yes no-df match scrub (random-id max-mss 1389) Should I drop the no-df from set reassemble? Any other recommendations welcome? Any thoughts or links on the most secure pf.conf that remains being compatible with any network? Thank You
Re: OpenBSD Readonly File System
On 2020-06-11 23:47, Dirk Coetzee wrote: > I always thought that 'sync' mount option is enough to avoid corruption of the FS. > Am I just "fooling" myself ? > I guess it boils down to a matter of preference and business requirements. > > "slow writes" vs "no writes". It's a good point, perhaps? Comments anyone? I think many went the RO route to avoid fsck and add an extra layer of security. Now that there is KARL and ffs2 means fsck is faster. The argument for RO being more of a problem than anything else, has gotten stronger, whilst ironically there seems to be more frequent reports of people using RO. Batteries/UPS are certainly still, the best answer. Database corruption for example. I also wonder how sync might affect disk churn during KARL. I'm not sure I care at all, about a one-off at boot though. Is there any mileage for root to be mounted sync in any case with so few writes, but maybe a problem for bsd.rd and live upgrades may want to re-mount? Though perhaps safety is more important, in any case?
Re: Mounting encrypted drive on boot
On 2020-06-02 23:27, Chris Narkiewicz wrote: > Somebody on StackOverflow advised on modifying /etc/rc > and run bioctl before disks are mounted, but I'm not sure > if this is a right approach, especially that attaching > more disks might change the /dev/sd* numberign. That would cause yourself maintenance pain/broken systems. A less broken solution, would be more targeted. I have retrofitted encryption before, to allow manual post boot activation of encryption via ssh, when abroad, without leaving a fob. Mounting a mail drive and also encrypted /var/spool and a backup drive from /etc/rc.securelevel. When it asks for a password on boot, rc.securelvel runs fsck -p ... && /sbin/mount ... (... = duid etc) It also reads the passwords for the extra volumes with bioctl -p, for convenience of only entering one password. Obviously the passwords are readable only by root and stored on the first encrypted drive.
Re: Could somebody please put unveil() in ftp(1)?
On 2020-06-01 13:30, Theo de Raadt wrote: >> I wonder, if 99% of users just use /etc/ssl/cert.pem? whether a flag that >> breaks/enables other use cases (removes capath support at runtime), might >> work? > I guess you don't understand unveil. You didn't understand what Stuart > just said *at all*. > I do understand unveil, well enough to apply it but I guess not to ftp. I guess capath isn't preventing tightening the veil then, unless -S is used or I am even further out of touch with the conversation. > Sounds completely unrelated. > Let's cut this short -- if you don't know what you are talking about > just don't comment, ok? Unrelated to improving ftp, considering OpenBSD wouldn't switch to single user designs, sure. I shall try to make sure I understand the details and only comment, when I can contribute.
Re: Could somebody please put unveil() in ftp(1)?
On 2020-06-01 11:20, Stuart Henderson wrote: > We went through this earlier when unveil was added to nc. The way capath > directories are often populated in the real world is not compatible with > unveil, you would need to resolve all files in capath, recursively resolve > symlinks, and add the chain of symlinks to the list of files to unveil. > Or remove capath support, or don't bother with unveil. > I wonder, if 99% of users just use /etc/ssl/cert.pem? whether a flag that breaks/enables other use cases (removes capath support at runtime), might work? >> I’d love to make it as safe to run as root as it is running it as an >> unprivileged chrooted user! And I love C! > It *cannot* be as safe to run as root as it is running it as an unprivileged > chrooted user. ftp -o /bin/sh http://dodgy.server/trojanned-sh > > This "safe to run as root" sounds a lot like the talk around a subtler issue that I used to see often on the hardened-gentoo list. In that they would say root doesn't exist with RBAC (meaning not necessary). Whilst the more complex and so potentially buggy RBAC systems should IMO be added layers. You shouldn't disable/ignore the simpler, tried and tested DAC systems, because of something new and shiny.
Re: Article OpenBSD: Not Free Not Fuctional and Definetly Not Secure and BSD, the truth blog
On 2020-05-28 18:38, Amarendra Godbole wrote: > It indeed is written by someone lacking knowledge about everything. It > is funny, and gave me a good laugh - the comments are even funnier! Be aware that the author deletes your comments and replaces them with his own, under your name, whilst hiding behind wordpress.com!
Re: Intel wireless issue after upgrading to 6.7
On 2020-05-28 14:40, Michael Steeves wrote: > but I'm wondering if there's some other way to get any more detail out of the > laptop about what's going on? ifconfig has a debug flag. A packet capture from another device with monitor mode, may be a helpful option too. e.g. iwm or athn http://openbsd-archive.7691.n7.nabble.com/monitor-mode-for-iwm-4-td343773.html
Re: Dovecot and multi-factor auth support
>> Is there any sort of supported way of wiring up login_duo with >> OpenSMTPD and Dovecot, or using bsdauth in some way to enforce a >> second auth factor? > >bsdauth isn't really setup for multi factor, the only way I've seen >this >done is splitting the password field into a fixed-length OTP and a >password. I use a ssh tunnel for access to dovecot, with the same username via bsdauth. Not exactly two factor at the account level but even more secure IMO and ssh has two factor ability now too. I tried but abandoned switching to client tls certs as keeping tunnels or vpns open isn't so great on mobile for notifications and ensuring clients trust one CA, especially on mobiles is impossible? Nowadays, without writing your own client (all use android trust store?!) Note: bsdauth may be being removed by dovecot, annoyingly. http://openbsd-archive.7691.n7.nabble.com/bsdauth-being-removed-from-Dovecot-td387268.html
Re: Why does OpenBSD still include Perl in its base installation?
On 2020-05-21 09:55, Anders Andersson wrote: >> I am a huge fan of minimal and custom installations >> as I mostly use OpenBSD to host simple HTTP servers. > ... >> I would like to get your opinion on that. > From what I've seen, those goals are not compatible with OpenBSD, as > in: You're just making it harder for you and anyone trying to help > debugging something if you change the default installation. I've seen > some wishes about even getting rid of the whole "sets" thing and just > install everything. I agree and disagree. I agree with the unsupported compatible side, with a big question of why do you want to? I like having a well considered useful base, rather than a million linux kernel/package options. I disagree with OpenBSD being incompatible. Take bsd.rd or single user and a binary and it could be a very small executer atleast. Anyone that has hosed the root fs and and had to fix the shared cache with ldconfig, probably realises that. No idea, why you would want to go that small and not use something like app engine and go though. I guess you could use pledge/unveil if you have all the networking side sorted. I can't see involatile storage as an issue there or anywhere OpenBSD runs though and it's focus on security means updates are fairly infrequent?? p.s. Even app engine uses a fairly big and useful install, before the deploy stage.
Re: Howto change login mechanism on OpenBSD
On May 20, 2020 9:31:19 PM UTC, Edgar Pettijohn wrote:
>On Wed, May 20, 2020 at 08:48:20PM +0200, Valdrin MUJA wrote:
>> Hi Misc,
>>
>> I have an interactive shell program which has an authentication
>section and I want to login via my program. How can I do that?
>>
>> Actually I want to run this program instead of /bin/ksh. I changed
>the root's shell with "chsh -s /bin/{my_program} root" command.
>However, when the system boots, firstly OpenBSD Login is coming and
>after that my program is running.
>>
>> In short, I want to run an external program on startup without
>OpenBSD Login.
>
>I believe login(1) is executed by getty(8) which is started by init(8).
>So you would likely have to make changes to one or more of them. But I
>could be wrong.
>
>Edgar
I believe /etc/ttys controls getty, which may or not help. Getty is respawned
too.
https://man.openbsd.org/man5/ttys.5
unveil documentation
The unveil man page is perfectly correct and it is not hard to test it's behaviour. I just wonder if it may aid unveil adoption in languages other than C, if it explicitly mentioned that exec is not required on a dir to allow reading the files within, e.g. if the dev is more used to filesystem permissions than OS functions? Perhaps a FAQ on unveil is intended instead, time permitting? Perhaps a link to the following paper or whichever best demonstrates usage, could be added to the faq for now? https://lteo.net/assets/pdf/lteo-openbsd-carolinacon15-20190427.pdf Trying to help provide differing perspectives and not just create work for people. Feel free to ignore me, obviously.
Re: Mandate control in OpenBSD like SELinux or AppArmor
On May 11, 2020 7:27:49 PM UTC, i...@aulix.com wrote: >Please let me know, what are analogues of SELinux and AppArmor in OBSD > http://www.openbsd.org/mail.html You are supposed to "do your homework" and try googling and searching the mailing list archive before asking questions. Clearly you have not, please do!
Re: OpenBSD insecurity rumors from isopenbsdsecu.re
Here's a game. Name as many operating systems as you can that encrypt the page file or swap space by default?
Re: 'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
On 2020-05-09 16:25, i...@aulix.com wrote: > Note: Since these MS / U.S. government keys are deeply sticking in Intel XEON > processor hardware, it doesn’t play a role, what other OS you install or boot > afterwards: Debian/UBUNTU Linux, OpenBSD, … If your software uses Intel > AES-NI hardware encryption, all encrypted packets ingoing, outgoing - then > automatically contain that U.S. government backdoor! Careful of what sources you trust! If a processor was storing the keys used, non volatile then people would have found out. Software encryption wouldn't save you either. If there is a back door it won't have anything to do with AES-NI that can be analysed so easily. I'm conscious of being far from OpenBSD relevance, so excluding myself from this thread now.
Re: 'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
On 2020-05-09 14:34, i...@aulix.com wrote: > D-waves has too uncoupled qubits if I understand it correctly, it is nothing > to do about qubits quantity as we used to think about it. Like a "cluster" of > completely isolated hosts (which is already not a cluster or course). I don't care for the details. D-waves tech has no hope of breaking any crypto in use today is what I have heard from reputable sources. Googles needs to go from 53 to an estimated more than 3000 for nistp-521 with each one being exponentially harder to manage. RSA 8192/4096 are the next best options but RSA takes exponentially longer to generate larger keys. Don't worry. The work is to be ready in case someone with enough funds makes a breakthrough. There is almost zero chance for many many years. You can always mix in a static symmetric key, if really needed or encrypt the data first with a static key? Wireguard offers mixing in a static key as an optional extra config option but wireguard has chosen not to support AES, so will be a lot slower on many modern processors and microchips that have AES hw support. The wireguard author seems to think the opposite about micro support, but he is wrong.
Re: 'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
On 2020-05-09 14:31, i...@aulix.com wrote: > guessed by quantum provided session symmetric cipher is strong enough? Quantum does not break any in use today and AES-256 symmetric is expected to be quantum resistant in any case. I personally prefer AES-256 ctr over the more complex GCM. I am not a developer btw.
Re: 'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
On 2020-05-09 07:41, Martin wrote: > This one > https://www.tomshardware.com/news/d-wave-5000-qubit-first-sale,40470.html > is the most powerful 5000qbits quantum computer sells nowadays. D-waves definition of qubit is different and their machines will never be capable of breaking public key cryptography using Shor's algorithm. I assume they want free publicity that you are giving them.
Re: 'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
On 2020-05-09 07:41, Martin wrote: > This one > https://www.tomshardware.com/news/d-wave-5000-qubit-first-sale,40470.html > is the most powerful 5000qbits quantum computer sells nowadays. > > Moreother, D-Wave opened online service to access 5000qbit remotely for > solving 'special' tasks which can be accelerated using quantum architecture. > > In 2016 Google tested some encryption sub-layer in Chrome browser to test > quantum resistant encryption algo. > > According to current online data collecting practices, after six years most > of 'old' algorithms will possible to decrypt directly from storage by > 'modern' quantum computers. That last sentence doesn't even make sense but is completely wrong. Decrypt according to? No Googles computer was an impressive jump to 53 qubits but every qubit is exponentially harder to keep stable. The pqcrypto project estimated far longer before an algorithm is broken by a computer and even then I believe they are talking about weaker keys. Not in our lifetime is often mentioned. It is quite possible and in my opinion probable that a nistp-521 key will never be broken by a quantum computer. I assume this is coming from the recent release of code by the PQCrypto project for OpenSSL. The PQCrypto project hasn't concluded yet. You should not use it yet especially without existing crypto too. There are some conservative algorithms that may not win the competition that are arguably useable under certain conditions but that is aside from the point. The one OpenSSH has developed is one of those.
Re: OpenBSD insecurity rumors from isopenbsdsecu.re
On 2020-05-07 14:48, Aisha Tammy wrote: >> I wouldn't want to read an OS written in Rust and I would love to see secure >> developments in C even if it hampers potential performance. Things like Go >> are >> not suitable for an OS with many small programs. >> > Curious about why... though admittedly I have never written or read rust in > great detail. > Genuinely curious why, I thought it was supposed to be pretty nice with > thread safety and > all that jazz. > It was more the privilege separation part that I found made the comment show a lack of understanding. Privsep really has more to do with design than a language. Aside from the Go/Linux Kernel seteuid bug. https://github.com/golang/go/issues/1435 There have been many proposals for many years to reduce the care needed to write good C and performance or feature support like breaking some pointer use cases, always seems to win the argument upstream. A paper/plugin/extension is written and rarely makes the mainstream compilers, even as a flag. Admittedly, I don't have much Rust experience, either. Ada seems more applicable to avoiding dynamic memory on micro processors and I don't have the time to sacrifice, even on ADA with GCC support or on maintaining tooling and porting code bases. To me, Rust reads like C++ on steroids and I never liked C++ and so I lost all interest very quickly. I just have too many questions when reading it. I rarely like abstraction. Ada looks nicer to read to me but perhaps it wouldn't have that thread safety that you mention or the momentum Rust seems to have gained? Didn't Linus push back against C++ too? I guess I like Go and Ada because they are more similar to C and fairly simple in their core. I think Reyk tweeted about not liking Rust or it being a real pain and now seems to have tweeted about quite liking it. I am not closed minded but more skeptical of ever taking to it.
Re: List a package's dependencies
On 2020-04-21 17:54, Kevin Chadwick wrote: >> Nope, it's definitely the wrong place to fix things. >> >> You should fix your pipes (change the timeouts or whatever). >> >> If worse comes to worst, pkg_add could *possibly* retry running ftp(1), >> but that makes little sense. > I agree ftp/tcp should be re-trying anyway. However I believe a re-run of ftp > might work around it. It hangs for a long time and ctrl->C followed by pkg_add > -u seems to work second time around (faster than waiting for the timeout). > > It only happens on one or two pkgs occasionally. I believe it has happened via > wired(landline) and wireless(4G) internet access but can't be 100% sure. I > shall > keep an eye on it and see if it has any patterns like CDN or particular > networks. I may have found the broken pipe. It happened again and switching my phone to 3G, rather than 4G seemed to fix the issue completely. Sometimes 4G degrades badly enough for a few hours here to stop Netflix working, but rarely. I am still left wondering if package installation, should/could be slightly more robust to broken networks though, considering a browser may fail to upgrade and may not always get noticed that quickly?
Re: OpenBSD insecurity rumors from isopenbsdsecu.re
On 2020-05-07 14:10, Consus wrote: > On Thu, May 07, 2020 at 04:00:15PM +0200, i...@aulix.com wrote: >> Dear OpenBSD fans, >> >> Can you please comment negative appraisal from the following website: >> >> https://isopenbsdsecu.re/quotes/ >> >> I did not want to hurt anyone, just looking for a secure OS and >> OpenBSD looked very nice to me before I have found this website. > Perhaps you could cite which part as the parts I read should seem without merit to anybody? > The fun thing to do: offer $50k rewards for code execution > vulnerabilities and wait for results. > "Apple has lately been slapping proprietary mitigations around like there’s no tomorrow. But thing is, mitigations are often delicate creatures, with rather fragile assumptions. Having too many of them in one place can easily make them break one another, as happened here with execute-only memory vs PAN." I am sure that examples of mitigations leveraging and protecting each other, or an exploit failing because of multiple mitigations is far more common than them hurting each other. "I put a lot more faith in privilege separation and reduction than in all the mitigations. I’d be really impressed by a move to a safe language… most everyone is late to that party, so it’s a chance for someone to pull ahead if they wanted bragging rights" I wouldn't want to read an OS written in Rust and I would love to see secure developments in C even if it hampers potential performance. Things like Go are not suitable for an OS with many small programs. Also, OpenBSD is one of the pioneers of privilege separation and most Go programs are not privilege separated at all. I quickly lost interest, sorry. IMO, the main thing that causes exploitations is carelessness. OpenBSD cares and is careful!
Re: How to enable TLS 1.3?
On 2020-04-30 13:55, Chad Hoolie wrote: > Any idea about relayd though? I don't see any mentioning of 1.3 in man > relayd.conf: I'm not a dev but tls1.3 dropped RSA and I think requires ecdsa key support that relayd currently lacks. Although httpd was originally based on relayd. I assume the code is different here because of relayds more complex tls interception and acceleration abilities. Pound and nginx may be alternatives, but they likely won't protect the key so well, if an exploit is found.
Cross platform apps.
Go/Golang can cross compile non graphical programs for many systems including OpenBSD from Windows etc. This means that web apps can be almost as cross platform. Of course the browser isn't so easily built/bundled cross platform with many app creation technologies supporting OSX, Windows, Linux and occasionally Android like ionic but not BSD. fyne may work but not sure I want many OS installations for building apps and again fyne-cross, leaves BSD... in the cold. Electron doesn't support mobile, but mobile apps have webview/go support. Electron produces huge apps though. Currently I am thinking like portsdancer of just opening a web browser but in app mode where possible for PCs. Not sure how slick that option, can be made but is most flexible. I guess an option is to build for some platforms and provide the source for packagers. Perhaps porters would know of graphical apps that were easy to port e.g. Qt? Any other ideas, perhaps from the Lua gaming community etc.? Thank You for any help
Re: Has anyone launched Steam for Linux on openbsd?
On 2020-04-21 23:28, m...@patrickmarchand.com wrote: > Steam depot downloader utilizing the SteamKit2 library. Supports > .NET Core 2.0. Client to download apps and Workshop items from > Steam. > > Maintainer: Thomas Frohwein > > WWW: https://github.com/SteamRE/DepotDownloader > > There's also the https://www.playonbsd.com/ website that has more > information on gaming with BSD systems. > Both very cool > Kevin Chadwick wrote: >> Not sure but there wouldn't be much incentive anyway as there >> aren't many steam games that run on Linux! > There's at least one, and that's enough to legitimize wanting access > to a game you've paid for. > > Have a nice day, ID and the company providing Steam (Valve) have always been very good to Linux/OpenSource, even releasing binaries for Linux imediately and sometimes open sourcing further down the line. CounterStrike, Doom, Quake 4, Quake Arena... I have even run EAs? Medal Of honour Airborne on Linux after copying half of Windows across for wine to run it and worked around various crashes. I even solely ran steam on Linux 5 or 10 years ago for a short time. I ended up with less performance, buying games that weren't so good and wasting my time. Perhaps things have improved. Many cross platform app creation tools support Linux these days, but leave BSD in the cold. The graphics libraries often require native building, as far as I can tell. IDs just released Doom Eternal says my hardware won't run it on Windows (yet they port it to ps4, grr). (Though the last Doom did have wildly over egged min specs. I guess to avoid complaints) So, I want to use the best tool for the job. Between OpenBSD and Windows. I have everything covered and in that time Microsofts attitude towards security has improved significantly. This also applies to work. In the embedded tool world Linux is hit and miss and I am not going to play around with Wine or reboot... for some little but essential tool. Getting the IDE to work on Linux also ended up costing time, though admittedly it used to somewhat on Windows too. Atleast those issues were ones that the billion dollar companies behind the chips, would be sure to be working on. There are plenty of great older games and steam workshop on OpenBSD may well be a useful tool, in that regard. I still plan to look into the BSD gaming community, time permitting.
Re: List a package's dependencies
On 2020-04-20 22:47, Marc Espie wrote: > Nope, it's definitely the wrong place to fix things. > > You should fix your pipes (change the timeouts or whatever). > > If worse comes to worst, pkg_add could *possibly* retry running ftp(1), > but that makes little sense. I agree ftp/tcp should be re-trying anyway. However I believe a re-run of ftp might work around it. It hangs for a long time and ctrl->C followed by pkg_add -u seems to work second time around (faster than waiting for the timeout). It only happens on one or two pkgs occasionally. I believe it has happened via wired(landline) and wireless(4G) internet access but can't be 100% sure. I shall keep an eye on it and see if it has any patterns like CDN or particular networks.
Re: List a package's dependencies
> There are some unavoidable complexities to the sheer size of the tree, > and the necessities of updates not to fail... I have noticed recently that I occasionally get a gz truncated message (I think due to tcp timeout) and then the dependent package doesn't get updated. I then re-run pkg_add -u. Is the way to deal with this from a script, to; re-run pkg_add -u, if it's output is > 0 ?
Re: WLAN throughput less 10Mb/s
On 2020-04-14 09:21, Stefan Sperling wrote: > Regarding other chipsets, if you want the fastest possible AP on OpenBSD > your best option right now is to get a bwfm(4) device, which offloads almost > all of its 802.11 operation into a firmware blob running in the embedded > system on the device. Interesting. BWFM(4) CAVEATS The firmware is outdated and contains known vulnerabilities. Any more information on the seriousness of these vulnerabilities? I can probably look it up in CVS actually but figured it *may* be prudent of me to highlight that caveat on the list explicitly, in any case.
Re: Will windows 10 boot after installing openBSD?
You can also install Windows after and boot OpenBSD quite easily by following the faq. This is not easy on grub/Linux as grub is greedy. Atleast the guides that I found for grub/Linux, failed to work. I have no interest in running Linux these days though and little interest then. I had the notion that my mum might find updating easier. Now the opposite is certainly true. In fact, I had to tell a grafana user on slack about apt-get dist-upgrade recently just to install grafana. Also, when I did try a wifi experiment with fedora, it's recovery kernel managed to break *itself* (yum or rather it's new name, broke/failed to update it over time). Perhaps it had something to do with building the wifi module, but recovery kernels should not break! Well done on many counts, OpenBSD!
Re: Iridium vs Chromium
On April 12, 2020 7:07:01 PM UTC, Patrick Harper wrote: >The effort to support Chromium and Firefox (sans ESR) on OpenBSD akin >to Windows/macOS/'Linux' has not happened. On atleast current as Theo showed, Chromium is just as well if not better supported on OpenBSD than on Linux, these days. I assume you are judging by a while ago. Or perhaps you mean Chrome where pre-built binaries for Linux are released by Google? I used to install chrome on debian/ubuntu to get the extra days.
Re: Has anyone launched Steam for Linux on openbsd?
Not sure but there wouldn't be much incentive anyway as there aren't many steam games that run on Linux!
Re: secure MTA
> Now this whole debate boils down to "how much effort is someone willing to > invest > into hacking Cord's computers?", and that's something I can't answer. And how competent Cord is at defending his computer because they may not be able to if he is competent enough, which is my point; It is not just about "how much effort an attacker is willing to invest". However, at the end of the day, like it says in the faq. If black suits in helcopters come and demand your password, it almost certainly doesn't matter if your computer is secure! I was objecting to a particular comment that you still lament.
Re: secure MTA
On 2020-04-09 10:55, Rudolf Leitgeb wrote: > My point was, that security is an ongoing effort. Flaws and new > exploit venues are discovered. There will be different numbers > of flaws for different operating systems, but none remains unscathed > for years. As soon as your server does anything useful, it will > present an attack vector to the outside world, and one needs to > be aware of it. OpenBSD has remained unscathed for years with sshd listening by default, despite sshd doing some complicated things. Take ipv6 out of the picture and it's a very long time? Note that ipv6 is way more complex than it should have been like ASN.1, due to a committee. OpenBSD resisted ipv6 for a long time and I still don't use it, neither does my phone network or ISPs, on my side. I'm not sure anyone has said OpenBSD is infallible or that what OpenBSD strives to achieve isn't great. What I said was that the idea that everything is hackable is complete nonsense. I am not saying sshd is infallible but you can run all sorts behind sshd and it be a very useful server. You can take some of the security designs like priv sep of sshd and make a simpler service arguably unhackable. People have put services out there and said I will pay you to hack me and remained unhacked. Maybe the amount was too small. You could argue sshd will be broken by quantum cryptography one day. It might and it might not, the mantra "everything is hackable", is still misleading and FUD. Conversely, if everything was easily hackable then we probably wouldn't use computers, at all. "unhackable" is an unknown. It is normal to fear the unknown. It is right to hold many to a higher standard of security. Saying everything is unhackable is almost like saying what's the point in securing anything, or spend lots of money and we will worry about that for you. That is wrong.
Re: secure MTA
On 2020-04-08 18:39, Claus Assmann wrote: > - Client-side exploitation: This vulnerability is remotely exploitable > in OpenSMTPD's (and hence OpenBSD's) default configuration. Although You missed some out. I assume on purpose. Client-side exploitation: This vulnerability is remotely exploitable in OpenSMTPD's (and hence OpenBSD's) default configuration. Although OpenSMTPD listens on localhost only, by default, it does accept mail from local users and delivers it to remote servers. If such a remote server is controlled by an attacker (either because it is malicious or compromised, or because of a man-in-the-middle, DNS, or BGP attack -- SMTP is not TLS-encrypted by default), then the attacker can execute arbitrary shell commands on the vulnerable OpenSMTPD installation. So it does require internal users to make an action and a MITM or outbound connection to an attacker controlled server and not an incoming connection... Qualsys chose to call that remote, at a stretch. Either way, it does not change the point around "everything is hackable" being false. I never brought up smtpd and never said smtpd was unhackable!
Re: news from my hacked box
On 2020-04-08 18:02, Rudolf Leitgeb wrote: > A public facing server with ftp, http, smtp and sshd would have had to be > patched > in regular intervals to remain reasonably secure. False, even though you have lowered the bar from "anything/everything is hackable". httpd and libressl have done quite well despite talking over http to anyone and dealing with crappy interfaces like ASN.1 for TLS. You missed the point. If your interface requires authentication first, like ssh then that is good, it has a good record. If your interface requires auth in a simple format and is a very simple interface after that fact. Then you will find examples of devices and services that have never been hacked, even without the layers of defence of sshd, though you are free to have some of them! ergo the mantra of anything is hackable is bullshit, largely spread by pen testers and fuzzers. There isn't much to fuzz when auth of a simple key is required up front. Most hacks occur by inside users not remote and that is a whole other matter but that does not mean that anything is hackable. "everything is hackable" is FUD
Re: news from my hacked box
On 2020-04-08 12:08, Rudolf Leitgeb wrote: >> I believe that is false too. > You're kidding, yes? Did you somehow miss the opensmtp hole? > > https://poolp.org/posts/2020-01-30/opensmtpd-advisory-dissected/ OpenSMTPD does not listen to the internet, by default and even if you do set it to, it only affected certain configurations. Is it hard to write a secure mail server, sure. Look at exims bugs. If your project, like most could; has made sane design choices for simple interfaces then it certainly can be made very secure, remotely unhackable is easier than you think for a modest project. You cannot take the easy road though. How the heck sshd has such as good security record, considering all that it does, interface wise, is rather astounding. I guess a remotely critical bug may be found there one day, but it does not affect my point!
Re: news from my hacked box
On 2020-04-07 18:21, Rudolf Leitgeb wrote: > You have no chance defending your desktop against each and every attacker, no > matter > which operating system you have running. True if you consider physical attacks and for most hardware, otherwise mostly false. Anything can be hacked is also one of my biggest annoyances as a mantra from "infosec", that gets more money than it deserves in comparison to real security, like OpenBSD works on. Anyone that says anything can be hacked without qualification, loses any respect from me, atleast for that moment. Even browsers take some skill/time to hack and a modern browser is anakin to putting the Death Star exhaust port in the hangar of a Mon Calamari Cruiser. Even OpenBSD had a remote root hole just > a few weeks ago. I believe that is false too. To the OP. I apologise if you are not but to me I thought you are/were a Troll. If not then I would consider what you posted from the point of view of a Vulcan. Did you even consider pxeboot as a vector, if installing from a cafe? HW bios defaults are often atrocious, unlike OpenBSD defaults! p.s. A web browser that is rarely exploitable is perfectly possible. It would require some breaking re-design and likely removal if not severe limitations on js, for a start though. I'm guessing wasm will not go the right way to fix js. Perhaps infosec could chime in on improving was but then they would be hurting their own income streams!! Annoying!
Re: Guidance: How often to update -current?
My upgrades usually follow chromium pkg upgrades. In fact, I have a script on my phone that greps the chromium pkg version. I test on my own laptop first.
Re: Hosting a CDN question
On 2020-03-17 02:48, Aaron Mason wrote: > It's worth noting that httpd didn't go over ~30% in the test, whereas > the Go web server absolutely slammed the system. I wonder if this is linked to Go's concurrency. Personally I would look into tweaking httpd defaults and relayd as GOs net/http runs everything as one user and so I prefer to gain httpds TLS key protection with go via fcgi akin to gcp app engine. You also need to tweak timeouts etc. for Go, as it's defaults are not ready for production (easy DOS upon internet exposure) without being behind app engine/httpd etc. I would also trust httpds routing over gorilla/mux, though stdlib mux is probably closer (no regex) but *maybe* not as powerful as httpds. Of course fcgi *may* slow it down further, if HW cost is paramount.
Re: Hardening browser
On 2020-03-04 11:38, Ottavio Caruso wrote: > Probably not what you were looking for but, back in the days when I > was ultra paranoid about my web browsing, I used to use stripped down > live usb installations of Linux distros (DSL was one of them that I > remember). I ignore if OpenBSD comes with such a solution out the box, > but I'm sure it wouldn't be difficult to make your own read-only > install. Then, you could either reboot from it or run it through an > emulator. A live cd is read-only and is also something I did for a while in my teenage years. Knoppix, Insert were examples and STD was another aptly named one as it contains outdated tools that really need to be upto date, otherwise they can do more harm than good. Scarily it is still downloadable and quite a dangerous but equally interesting learning tool. Comes with mozilla firebird that starts super fast and uses twenty something meg of ram, lol. There was also a guide to build your own OpenBSD live cd with X/packages. However, considering OpenBSD replaces it's whole base every upgrade with signed binaries, then you get all of that for free. You can even double check the bios with flashrom (less so on laptops), bootloader, signing keys, packages etc., if you want to. If this effort is really worth it, then it probably makes more sense than trusting someone else to package up a usb linux distro or CD.
Re: Hardening browser
On 2020-03-04 01:06, whistlez...@riseup.net wrote: > in the following message: > https://marc.info/?l=openbsd-misc&m=158110613210895&w=2 > Theo discourages to use unveil instead of chroot. > I asked if he suggests the same for the browser but he asked that chroot > is onlye for *root*. I thought that he was quite clear in the context of a privilege separated daemon in "discouraging" carte blanche replacement of all chroot cases (chroot is simpler and has been found secure without issue when done correctly on OpenBSD for a long time and so is being conservative). He even replied to the browser question in your link! If Theo has some concerns about complexity in unveil then I am sure he would be worried sick if implementing the Linux equivalents. > Then what should I do to hardening the most exposed piece of code that > we use everyday ? > Now I'm using unveil+chrome... Javascript is probably your biggest threat and unveil will help but by "STUPID CRAZY DESIGN!" it is permitted to do a great deal more, than it should be. Nothing can protect you very well from something designed like that, except prudence! Chrome/Firefox are unveiled on OpenBSD, so isolate your browsing (umatrix for javascript or separate hardware) or only visit trusted sites if you must. Html email is "arguably" more of a risk, as the html comes to you, though javascript and even links are sometimes disabled, so perhaps it isn't. Not sure if Thunderbird has the unveil support that Firefox has recently had endowed upon it.
Re: Full disk encryption including /boot, excluding bootloader?
On 2020-02-17 15:09, Julius Zint wrote: > Some feedback from the OpenBSD community on this would also be appreciated. > Are there > enought people interessted in a Trusted Boot with OpenBSD? I'm interested
Re: strange dmesg
On 2020-02-08 16:40, Otto Moerbeek wrote: > When booting, the contents of the existing dmesg buffer are examined. > If the current contents are deemed to be a dmesg, it is not cleared. > It's possible the (random) contents of the buffer are seen as valid by > chance and are thus regarded as dmesg content. When I have seen it, it has been dmesg intermingled with other bytes. It is a little worrying to see but I assume this is by design (no crc/checksum) in case something useful is retrievable? I guess Stus reference to UEFI doesn't suggest it can expose anything sensitive?
Re: strange dmesg
On February 8, 2020 2:24:21 PM UTC, Justin Noor wrote: >I have the same output on a Protecli firewall device (it’s not in >production yet) running 6.6 stable, and have yet to figure out what it >is. I have seen similar on an intel i3 but then it has just been short term (snapshot or maybe particular/seemingly random boots). This was months and also maybe more than a year ago and haven't seen it since.
Re: chroot vs unveil
> >> I am considering replacing all chroot use with unveil in my processes even >> where >> no filesystem access is required. > > I am discouraging this. > > unveil is a complicated mechanism, and we may still discover a bug in > it. > > Almost all the chroot in the tree are to empty unwriteable directories, > in which case chroot is very secure and a very simple mechanism. > I shall do the same then, thank you for the guidance.
Re: Can't install OpenBSD 6.6 on apu4d4
On 2020-02-06 07:56, mabi wrote: > Thanks Mischa! I should have thought about that but I couldn't remember > having done this with previous APU models and OpenBSD versions. I expect you known but you can add this into /etc/boot.conf I also recently forgot or found I had to edit /etc/ttys too to get a getty login.
chroot vs unveil
I am considering replacing all chroot use with unveil in my processes even where no filesystem access is required. Is there any guidance on whether that is the best practice, where you only intend to run on OpenBSD?
Re: Process Isolation
On 2020-02-06 07:59, Charlie Burnett wrote: > I apologize if this was a question I've somehow missed the answer to! OpenBSD takes a more fine grained approach in isolating functions rather than whole programs ideally by the person best suited to do the job (the program developer). Isolating whole programs has proven not to work very well, especially on Intel ;) https://www.openbsd.org/papers/bsdcan2019-unveil/index.html
Re: FreeBSD daemon(8)-like command for OpenBSD
On 2020-01-31 12:16, KatolaZ wrote: > For instance, golang has had native support > for pledge(2) and unveil(2) for a while now. The semantics are a little different to C unveil but it certainly works and bundled by default in the golang.org/x. Not sure the documentation is great. It's a little ironic that whilst golangs smallest binary (ignoring tinygo) is > 2 megabytes preventing generic use. One of the main incentives for it's initial development was to have something somewhat like C whilst avoiding compiling unused dependencies and speedup build times. It has found a good place between C and the montrosity of java and I expect will replace java slowly but likely not C. Unless unix dies from the systemd treatment (I'm confident it won't in OpenBSD)
Re: OpenBSD's extremely poor network/disk performance?
On 2020-01-30 10:57, Handreas wrote: > "Can't say much for the performance of a suite of servers which have > all been taken down to handle the security threat du jour." > > Repeat it again? > https://www.qualys.com/2020/01/28/cve-2020-7247/lpe-rce-opensmtpd.txt?_ga=2.120267019.2069438099.1580381821-1178380388.1580381821 syspatch rcctl restart smtpd Also, I have seen ~147 megabytes per second of data read from disk and from /dev/urandom without issue at almost any time!
Re: How did it happen?
On 2020-01-29 13:07, Oriol Demaria wrote: > I understand that root might be required to open privileged ports, but then > how commands are run as root when you exploit opensmtpd vulnerability? Giles has said further information is coming but it root isn't just required for privileged ports but also other things like creating files owned by various users etc. Looks to me like some extra checks, created an issue. Should be an interesting read.
Re: FreeBSD daemon(8)-like command for OpenBSD
On 2020-01-27 19:13, Patrick Kristiansen wrote: > Is there something like the FreeBSD daemon(8) command for OpenBSD, which > can run a process in the background and restart it if it crashes? Of course init does this for getty but as others have pointed out, restarting daemons listening to the network during unexpected occurrences, like the kernel killing it during exploitation is a terrible default. I hear it in GoLang all the time and it irks me. I am against panic handling in Go generally but perhaps there will be some occasion where it may be of some use for semi-unexpected issues (perhaps hw redundancy, though generally that is better handled by having redundant complete systems). You can always use monit from pkg/ports for anything you have decided is an exception but it is good that OpenBSD makes people stop and think and maybe fix first.
Re: ownership of mailboxes with dovecot
On 2019-12-31 14:10, Kevin Chadwick wrote: > I believe the mail boxes are chrooted into too. Actually that may be incorrect with the chroot being more broad than that as they should be owned by root otherwise!
Re: ownership of mailboxes with dovecot
On 2019-12-31 13:13, Eike Lantzsch wrote: > I regret having mentioned fetchmail. > It happens as part of setting up dovecot with virtual users. Do you need virtual users. I saw all the guides recommending this and wrote scripts to manage system users instead. Every box is owned by the login user and I believe the mail boxes are chrooted into too. Also means it inherited the system bcrypt login protection and it's maintenance for years. I don't have that many users though. Noone seems to discuss what the limits would actually be?
Re: The OpenBSD talk at 36c3
On 2019-12-31 05:19, g...@isdaq.com wrote: > he completely misses the mark. > rather than think "hmm 75% of commits are only 20 chars or less which seem Having watched the video now, that particular part of the talk is poor. He doesn't seem to even know that stable exists. My original thought was that there were mal intent. I think not now, unless it has been shaped by criticism. It is a highly complex talk and I am sure there are parts where he is short on knowledge but got threw in the deep end of making a talk comprehensive and trying to look as competent as possible. He could lose a bit of arrogance and is wrong in a few places. I don't actually even agree with his security quotes entirely as with everything it depends on context like mitigations cannot be taken alone, without the context of other mitigations, older hardware etc.. Though, I don't even agree with the security triangle entirely ;-) Perhaps I missed the point but attacks not being currently used is a false metric as they could still be used, if allowed. I think he has done quite well considering and clearly made an effort surrounded by voices likely from competitive projects. He clearly has some knowledge around attack vectors. His biggest mistake is he should be asking questions considering his limited knowledge of OpenBSD and not making arrogant statements. It was an interesting talk atleast and re-evaluation is almost always useful. OTOH hand, it may stem from attempting to make the case that if Linux does priv sep/drop, unveil and pledge then Linux is good and the Linux kernel, is not an issue. If so, then that is a naive view. More likely, he is just in transition to OpenBSD :-)
Re: off-topic
On 2019-12-30 13:09, Gustavo Rios wrote: > Is qmail dead ? > Not Dead (I would hope the original unpatched verson is) https://www.fehcom.de/sqmail/sqmail.html > Does anyone here use openbsd with qmail+ldap ? > I switched to OpenSMTPD
Re: The OpenBSD talk at 36c3
> I liked the presentation. An excerpt from https://isopenbsdsecu.re/about/: >> This website was done because studying mitigations is fun, not to get >> involved in a huge flamewars or endless bike-shedding on mailing lists. It is not my place to comment, however I will say that it did not read to me as unbiased. Perhaps things like embargos were mentioned in the video. There are significant mis-understandings and perhaps mis-informations, with at times oppositional mistakes in the slides. My initial opinion is that very limited research effort happened to aid credibility, not in order to create a fair and comprehensive report. I welcome the praise on unveil and pledge though. It would be nice, if there was an OpenBSD version of GCP app engine for the less serious but easily scalable web services!
Re: shell_exec() exec() and system() not working in php 5.6 openbsd 6.4
>Agree this is likely the problem, unfortunately in PHP-land sometimes >you can't avoid it. For platforms such as Drupal (just to pick an >example I am familiar with) some of the modules will run shell commands >to do things such as send email. > >Allan The php mail() function runs /bin/sh sendmail. I used to replace /bin/sh in the chroot but I've moved to golang now :)
Sidenote: Filesystem corruption on OpenBSD routers after power outage?
> Even after many tries, I have not yet been able to corrupt the > filesystem so fsck cannot repair it without manual intervention. Another less severe corner fail case I have found is that on a couple of buggy 386 laptops (that will be replaced soon anyway) with temperamental over temp shutdowns on some bootups (and now failing host controller, I'm guessing due to age/damage). I have found LOST+FOUND can fill up the filesystem, preventing library and kernel randomisation from taking affect. I have a script to check and remove older LOST+FOUND files. It's unlikely that there would be anything important lost on these browsing machines anyway. I guess a proper solution would be thorny?
Openrsync poll Hangup
Whilst getting current packages from the leaseweb mirror. I kept getting a stall followed by poll:hangup with 6.5 openrsync -v -a --delete Eventually all the packages download as it gets further each time. I tried building the latest openrsync from the current src tree still on 6.5 but I get the same issue. If you want me to try a different mirror or anything then let me know. I can use pkgd rsync without the priv sep otherwise for now. Regards, Kc
Re: OpenBSD runs only in RAM from a USB Flash Drive
>FFS isn't a journaling filesystem so any 'wear', even on primitive >flash storage, won't be enough to worry about. I disagree, depending on a few variables. If you can't get a better device then be prepared to replace the storage or count writes and create new files, keeping the old. KARL and randomness development depends on writing and shouldn't be disabled. There is a lot of misinformation about flash out there from fairly respectable people too. Maybe because phones are also in the close our eyes and hope brigade.
Re: Debug Tool for golang
On 5/31/19 5:28 PM, Ted Unangst wrote: > Kevin Chadwick wrote: >> Does anyone debug golang on OpenBSD and can advise on llvm/gcc or provide any >> other insight? > > I just use log. > Yep, not missing a trick then and apparently the old recommendation, Thanks all. https://blog.golang.org/debugging-go-code-status-report "When it comes to debugging, nothing beats a few strategic print statements to inspect variables or a well-placed panic to obtain a stack trace. However, sometimes you’re missing either the patience or the source code, and in those cases a good debugger can be invaluable. That's why over the past few releases we have been improving the support in Go’s gc linker (6l, 8l) for GDB, the GNU debugger."
Debug Tool for golang
It seems delve which is suggested by golang.org due to optimised binary support expects a Linux /proc and Linux threads (FreeBSD delve github issue tracker). So I guess without delve then building unoptimised binaries would be required which is possibly to be expected when debugging. I'm not sure that should make delve the preferred tool, if it is platform centric! Does anyone debug golang on OpenBSD and can advise on llvm/gcc or provide any other insight? Thanks
Re: PF firewall for desktop
On 5/24/19 8:30 PM, Jean-Francois Simon wrote: > Hi, > > Out of interest, I'd like to let you know a specific use of OpenBSD with PF, > in > virtualbox, 2 virtual network card Bridged to physical NIC, and building up a > subnet with NAT and hence running Packet Filter as the machine's firewall. > > > That's the firewall I use under Win7, OpenBSD running in a VM, out of pure > interest into running BSD and let it purify the network access to > desktop (without need for additional hardware). > > > Works well, love it. I have done something similar in the past. My personal preference is hyper-v on windows 10 pro which seven can be upgraded to. I would hope hyper-V has inherited kernel sandboxing/mitigation protections and hardening from Windows kernel/azure. I assign the physical nick to the OpenBSD VM and remove all check boxes like ipv4/ipv6 support from that nick. Then I had an VNAT device for windows to talk to. Glasswire ontop gives a window into the why is it connecting there or obfuscating CDNs https certs without the other free windows firewall cruft. I assume communications to the windows box could be made from a foreign network via arp manipulation but a nice setup none the less, if you can be bothered with it.
Re: One-shot upgrade script
On 4/25/19 9:27 PM, Christian Weisgerber wrote: > ... and this has now been supplanted by /usr/sbin/sysupgrade. How difficult would it be to have a sysupgrade flag to make the upgrade newfs /usr, to save having to rm the files shown in upgrade.html. (I guess it should work for all users with sane partition setups, but is quite a dangerous/severe action?) Just wondering if it is easy or problematic to accomplish.
Re: Malloc config became global sysctl in 6.5
On 4/27/19 8:23 AM, Otto Moerbeek wrote: > Additionally, in many cases using a symlink has unclear effects, since > it is hard to determine if the first malloc call (malloc inits itself > on first use) happens before of after the chroot call. I would argue > that in many cases people were thinking they had per-chroot settings, > while actually they had not. Also, as Otto informed me on twitter, base is quite happy with the stronger settings. The code that really needs weaker settings inside the chroot, probably needs the stronger settings the most, technically (if it didn't break). I like the more convenient sysctl. Be careful though, S cost me a couple of hours last night. After much success on many systems without issue. I foolishly enabled S at the same time as PHP5 with suhosin to php7 upgrade, All the statically built pledged parts, femail, PHP output and reop, worked individually but femail would not send the mail when directly sent from PHP. I still don't understand how malloc S could cause that but turning back to the default, solved the breakage. In any case, the inherent clarity of what is happening under the hood in golang (php sh flags etc.) and the loss of php suhosin function whitelist feature (again) that has avoided so many CVEs has affirmed moving to golang. Therefore, I am not so bothered about finding why unless it helps OpenBSD somehow, which I doubt?
Re: hacked for the second time
On 4/4/19 10:57 AM, Cord wrote: > Hi, my english seems very bad because my problem is not to make secure the > ssh key. My problem is how do not be hacked. > I have talked about the ssh key stealing to show signs that my pc was been > compromised. > I can for sure make secure my ssh key but how to make secure my the pc ? > If I have a rootkit that steal the ssh key the problem is the rootkit. You > know keylogger that steal password ? or cookie stealing ? > The latest chrome (available with current) just had 30 security fixes, however pledge could possibly still protect your ssh key. More likely the html/js email is the vector. You could run email as another user, or use plain text only. OpenBSD puts the odds in your favour more than anything else, but it is not infallible. If you can't evaluate the risks yourself. I would suggest you do the work to run current and upgrade from snapshots regularly.
Re: fluctuating error on chromium
On 1/7/19 9:47 AM, Mihai Popescu wrote: > Hello, > > Each first time i start chromium after reboot, i get this error: > libGL error: failed to open drm device: No such file or directory > libGL error: failed to load driver: r600 > Your user(s) needs access to atleast /dev/drm0, if you want better graphics support. Not sure if /dev/drm > 0 are also needed? > If i close chromium and start it again many times, there is no more this > error. > Is there something I need to do to avoid this? Do I need to wait a > little bit for some startup initializations? > > Thanks. > I assume that is an artificial fix, perhaps it didn't actually close down properly.
Re: current snapshot breaks ports? (strange libc versioning)
On 11/22/18 9:24 AM, Karel Gardas wrote: > in an attempt to update today from ftp.spline.de I've been kicked out > after -current update with pkg_add -u complaining about wrong libc > versions. Packages complains like: Likely you have a snapshot or packages out of sync. The packages take a lot longer to build so wait and try again. Most of the time they work together but not always. If you are running current, the best advice I can give is to rsync a local repo of the snapshot and packages. Then you can also install packages later without library compatibility issues.
OT: Https very slow since openbsd 6.1/Cipher String
On 11/21/18 4:00 PM, Gerhard Schweiger wrote on bugs@: > Then comes in openbsd 6.1 amd64, and now the same huge speed difference > between with or without encryption as found on OpenBSD 6.4.Is there any > tweak I could test or is this just bad luck on my VPS or something else? > Speed goes down so badly you can notice it very clearly on photo gallery > but even on static html, site is kind of "slow" when using https. There were some constant time changes that had a significant impact. Not sure if the impact was reduced or not or if that is even the cause here. Lol, Google says https is faster without mentioning parameters! Akin to a lie, evil or not. If you can upgrade to hw or a processor with AES-NI (hw acceleration), I guess you will be ~10* faster than you had before 6.1 with AES and still be constant time. Incidentally, does anyone know a good ciphers string to select AES only on OpenBSD httpd? I know it may use a bit more power for phone clients, but any other downsides? All countries can use AES these days, right?
Re: With all this CPU/hardware mess, any advice on what to use for an organization?
On 11/20/18 4:43 PM, Chris Bennett wrote: > AMD? I have read about problems with non-CPU chips being compromised. > Another architecture? I have never used anything other than Intel/AMD. I can't comment on SUN etc. but AMD would be the way to go if you can. Theo has said in a recent presentation something along the lines of that AMD are far more considerate and apply the security checks first whereas Intel do so at the end!! Many modern UEFI (bios) have very limited configuration enabled, however the configs the OEM has access to enable are larger than ever. It would be better if the functionality that caused them were not there by default but you may find these chip attacks can be mitigated for your scenario, quite easily with the right Vendor/OEM board?? Incidentally the Intel usb debug access has been there for years but it was a physical motherboard access only scenario until recently. I can't help with a good vendor unfortunately. I have no fairly new, off the shelf commercial HW to inspect the BIOS of.
Re: OpenBSD with root FS mounted read only
On 11/16/18 3:43 PM, Jarkko Oranen wrote: > As far as I'm aware, they are/were originally separated largely due to > historical reasons anyway, not because it's inherently better to keep > them separate. However they came about it is inherently better. Linux often takes the easy rather than best route like / for the whole system. Suddenly a separate /usr was unsupported, this was decided. A static single user is far better than a busybox fixer. I think they have changed the stance again since then?
