Re: gzip compression and httpd/relayd
> Yes it's possible. Make sure to set the appriopriate HTTP headers aswell > with relayd: read "Accept-Encoding" and if it's acceptable set > "Content-Encoding". Indeed, it works. relayd.conf : match response header "Accept-Encoding" value "gzip" match response header set "Content-Encoding" value "gzip" Then : cd /var/www/htdocs/site gzip style.css && mv style.css.gz style.css Now, open URL pointing to style.css, and here you go. However, all your files must be gzipped, or the browser is unhappy. Thanks a lot.
"uhub1: device problem, disabling port 1" on Zenbook
Hi, I'm trying to install OpenBSD 6.2 on a Zenbook (UX390UA) but it is unable to find the installer USB key (after booting from it). The key is connected via the USB-A/C adapter/hub that comes with the laptop. The same hardware works fine under Linux. The initial dmesg (full output below) has: sd1 at scsibus1 targ 1 lun 0: SCSI2 0/direct removable sd1: 3728MB, 512 bytes/sector, 7634944 sectors ...but: $ ls /dev/*sd1* ls: /dev/*sd1*: No such file or directory When un- and replugging the key, the following additional lines appear: sd1 detached scsibus1 detached umass0 detached uhub1: port 1, set config 0 at addr 3 failed uhub1: device problem, disabling port 1 When un- and replugging the adapter (with the key in it), the following additional lines appear: uhub1 detached uhub2 detached uhub1 at uhub0 port 1 configuration 1 interface 0 "VIA Labs, Inc. USB2.0 Hub" rev 2.10/6.80 addr 2 uhub1: port 1, set config 0 at addr 3 failed uhub1: device problem, disabling port 1 "VIA Technologies Inc. USB 2.0 BILLBOARD" rev 2.01/3.04 addr 3 at uhub1 port 2 not configured uhub2 at uhub0 port 13 configuration 1 interface 0 "VIA Labs, Inc. USB3.0 Hub" rev 3.00/6.85 addr 4 Using another type of USB hub and an external HDD gives similar results: uhub1 at uhub0 port 1 configuration 1 interface 0 "Apple Inc. USB2.0 Hub" rev 2.10/45.28 addr 2 "Apple Inc. USB-C Digital AV Multiport Adapter" rev 2.10/2.35 addr 3 at uhub1 port 2 not configured uhub2 at uhub0 port 13 configuration 1 interface 0 "Apple Inc. USB3.0 Hub" rev 3.00/45.28 addr 4 umass0 at uhub2 port 1 configuration 1 interface 0 "Seagate Expansion" rev 3.00/0.00 addr 8 mass0: using SCSI over Bulk-Only scsibus1 at umass0: 2 targets, initiator 0 sd1 at scsibus1 targ 1 lun 0: SCSI4 0/direct fixed sd1: 3815447MB, 512 bytes/sector, 7814037167 sectors uhub1 detached uhub1 at uhub0 port 1 configuration 1 interface 0 "Apple Inc. USB2.0 Hub" rev 2.10/45.28 addr 2 "Apple Inc. USB-C Digital AV Multiport Adapter" rev 2.10/2.35 addr 3 at uhub1 port 2 not configured Any help with this would be much appreciated! Thanks Max Initial dmesg: OpenBSD 6.2 (RAMDISK_CD) #132: Tue Oct 3 21:26:51 MDT 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD real mem = 17037766656 (16248MB) avail mem = 16517648384 (15752MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xeb350 (31 entries) bios0: vendor American Megatrends Inc. version "UX390UAK.312" date 04/25/2017 bios0: ASUSTeK COMPUTER INC. UX390UAK acpi0 at bios0: rev 2 acpi0: tables DSDT FACP APIC FPDT ECDT MCFG FIDT SSDT MSDM SSDT HPET UEFI SSDT LPIT WSMT SSDT SSDT DBGP DBG2 DMAR TPM2 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz, 2904.00 MHz 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache cpu0: TSC frequency 290400 Hz cpu0: apic clock running at 23MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins acpiec0 at acpi0 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG0) acpiprt2 at acpi0: bus -1 (PEG1) acpiprt3 at acpi0: bus -1 (PEG2) acpiprt4 at acpi0: bus 3 (RP09) acpiprt5 at acpi0: bus -1 (RP10) acpiprt6 at acpi0: bus -1 (RP11) acpiprt7 at acpi0: bus -1 (RP12) acpiprt8 at acpi0: bus -1 (RP13) acpiprt9 at acpi0: bus 1 (RP01) acpiprt10 at acpi0: bus -1 (RP02) acpiprt11 at acpi0: bus -1 (RP03) acpiprt12 at acpi0: bus -1 (RP04) acpiprt13 at acpi0: bus -1 (RP05) acpiprt14 at acpi0: bus 2 (RP06) acpiprt15 at acpi0: bus -1 (RP07) acpiprt16 at acpi0: bus -1 (RP08) acpiprt17 at acpi0: bus -1 (RP17) acpiprt18 at acpi0: bus -1 (RP18) acpiprt19 at acpi0: bus -1 (RP19) acpiprt20 at acpi0: bus -1 (RP20) acpiprt21 at acpi0: bus -1 (RP14) acpiprt22 at acpi0: bus -1 (RP15) acpiprt23 at acpi0: bus -1 (RP16) acpiec at acpi0 not configured acpicpu at acpi0 not configured acpipwrres at acpi0 not configured acpipwrres at acpi0 not configured acpipwrres at acpi0 not configured acpipwrres at acpi0 not configured acpipwrres at acpi0 not configured acpipwrres at acpi0 not configured acpipwrres at acpi0 not configured acpipwrres at acpi0 not configured acpipwrres at acpi0 not configured acpipwrres at acpi0 not configured acpipwrres at acpi0 not configured acpipwrres at acpi0 not configured acpipwrres at acpi0 not configured acpipwrres at acpi0 not configured acpipwrres at acpi0 not configured acpipwrres at acpi0 not configured acpipwrres at acpi0
Re: gzip compression and httpd/relayd
On Sun, Jan 28, 2018 at 10:18:30AM +0100, Thuban wrote: > > > Yes it's possible. Make sure to set the appriopriate HTTP headers aswell > > with relayd: read "Accept-Encoding" and if it's acceptable set > > "Content-Encoding". > > Indeed, it works. > > relayd.conf : > > match response header "Accept-Encoding" value "gzip" This should be: match request header "Accept-Encoding" value "*gzip*" I think. It should only output gzip if it's an accepted encoding, else some clients break. > match response header set "Content-Encoding" value "gzip" > > Then : > > cd /var/www/htdocs/site > gzip style.css && mv style.css.gz style.css > > Now, open URL pointing to style.css, and here you go. > > However, all your files must be gzipped, or the browser is unhappy. > > Thanks a lot. > You're welcome :) -- Kind regards, Hiltjo
van Sprundel
Really, did he actually post any real vulnerabilities to OpenBSD! This article has to be govt propaganda.. https://www.csoonline.com/article/3250653/open-source-tools/is-the-bsd-os-dying-some-security-researchers-think-so.amp.html I was laughing with tears when I read this.. OpenBSD is the only OS I place any real trust in <3 Is probably the only OS they can’t hack. And SystemD makes me want to both cry and scream at the same time. A Sent from a teeny tiny keyboard, so please excuse typos
IKEv2 - Tunnel all internet traffic from gateway
Hi misc, I've been beating my head against the wall on and off for the last few weeks - it's past time to ask for help. I'm trying to tunnel all internet traffic from my internal network (192.168.2.0/24) through another internet-facing machine (10.1.1.0/24) using IKEv2. After trying what seems to be every possibility of pf.conf and iked.conf combinations, I just can't seem to get it right. My closest attempt is to NAT all traffic from 192.168.2.0/24 to appear as virtual IP 10.1.1.2 on the other side, which is then NAT'd out to the internet as usual. The problem with this config is that ALL traffic, including local traffic to 192.168.2.0/24, is tunneled. This is not desired because I can no longer access my local gateway (192.168.2.1), or any locally hosted services. What I think I need is to be able to specify something like "from 10.1.1.2 (192.168.2.0/24) to !192.168.2.0/24" instead of "...to 0.0.0.0/0" in my iked.conf, but this doesn't seem to be valid syntax. Nor does limiting the tunnel to certain protos/ports, e.g. ... proto { tcp udp } ... port { 53 80 443 }. It seems only one proto and port combination is accepted by iked. I tried adding additional flows manually - i.e. specifying only proto tcp ... port 80 in iked.conf and feeding a file of additional flows via ipsecctl -F, but I receive errors about bad syntax - even though I copied the lines from ipsecctl -sa. It looks like only IKEv1 syntax is accepted there? I appreciate any thoughts and assistance. Regards, Daniel OpenBSD 6.2 (GENERIC.MP) #2: Sun Dec 10 21:14:42 CET 2017 r...@syspatch-62-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 17033199616 (16244MB) avail mem = 16509960192 (15745MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xecff0 (90 entries) bios0: vendor American Megatrends Inc. version "2901" date 10/25/2015 bios0: ASUS All Series acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT SSDT SSDT SSDT MCFG HPET SSDT SSDT BGRT UEFI acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) UAR1(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP05(S4) PXSX(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E3-1265L v3 @ 2.50GHz, 2498.89 MHz 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache cpu0: TSC frequency 2498887240 Hz cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU E3-1265L v3 @ 2.50GHz, 2498.56 MHz 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,SENSOR,ARAT cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Xeon(R) CPU E3-1265L v3 @ 2.50GHz, 2498.56 MHz cpu2: 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,SENSOR,ARAT cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Xeon(R) CPU E3-1265L v3 @ 2.50GHz, 2498.56 MHz cpu3: 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,SENSOR,ARAT cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 cpu4 at mainbus0: apid 1 (application processor) cpu4: Intel(R) Xeon(R) CPU E3-1265L v3 @ 2.50GHz, 2498.56 MHz cpu4: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE
Re: van Sprundel
On Sun, Jan 28, 2018 at 12:56:26PM +, Andy Lemin wrote: > Really, did he actually post any real vulnerabilities to OpenBSD! > > This article has to be govt propaganda.. > > https://www.csoonline.com/article/3250653/open-source-tools/is-the-bsd-os-dying-some-security-researchers-think-so.amp.html > > I was laughing with tears when I read this.. > > OpenBSD is the only OS I place any real trust in <3 > > Is probably the only OS they can’t hack. > > And SystemD makes me want to both cry and scream at the same time. > > A > > > Sent from a teeny tiny keyboard, so please excuse typos Hey, Maybe I shouldn't reply, but I feel this is insulting to the amazing work of Van Sprundel. I've also seen better nuanced articles about the same presentation talk. Sources: - https://www.openbsd.org/errata60.html (the batch of patches on August 3 2017). - http://undeadly.org/cgi?action=article&sid=20170804053102 - Slides: https://media.defcon.org/DEF%20CON%2025/DEF%20CON%2025%20presentations/DEFCON-25-Ilja-van-Sprundel-BSD-Kern-Vulns.pdf - https://www.openbsd.org/errata56.html (earlier work). Please do more research before you post. -- Kind regards, Hiltjo
Re: van Sprundel
Hi. That’s ok. This list is a place for open and honest conversation :) My reaction was towards the article trying to say that BSD’s are dying, rather than against Van Sprundle or his research. I’ve read through his slides before and I skim through the erratas each upgrade, but this article tries to bloat the truth in my eyes. So I’m asking the question as to where the reality lies as it stands today? Linux is such a moving target with so much unnecessary complexity with SystemD, that in the bigger picture we can place far more more trust in the BSD’s. It’s also a pretty serious allegation to cite so many vulnerabilities as still being unfixed today? Is this true? Thanks for your reply :) A Sent from a teeny tiny keyboard, so please excuse typos > On 28 Jan 2018, at 14:11, Hiltjo Posthuma wrote: > >> On Sun, Jan 28, 2018 at 12:56:26PM +, Andy Lemin wrote: >> Really, did he actually post any real vulnerabilities to OpenBSD! >> >> This article has to be govt propaganda.. >> >> https://www.csoonline.com/article/3250653/open-source-tools/is-the-bsd-os-dying-some-security-researchers-think-so.amp.html >> >> I was laughing with tears when I read this.. >> >> OpenBSD is the only OS I place any real trust in <3 >> >> Is probably the only OS they can’t hack. >> >> And SystemD makes me want to both cry and scream at the same time. >> >> A >> >> >> Sent from a teeny tiny keyboard, so please excuse typos > > Hey, > > Maybe I shouldn't reply, but I feel this is insulting to the amazing work of > Van Sprundel. I've also seen better nuanced articles about the same > presentation talk. > > Sources: > - https://www.openbsd.org/errata60.html (the batch of patches on August 3 > 2017). > - http://undeadly.org/cgi?action=article&sid=20170804053102 > - Slides: > https://media.defcon.org/DEF%20CON%2025/DEF%20CON%2025%20presentations/DEFCON-25-Ilja-van-Sprundel-BSD-Kern-Vulns.pdf > - https://www.openbsd.org/errata56.html (earlier work). > > Please do more research before you post. > > -- > Kind regards, > Hiltjo
Re: van Sprundel
On 01/28/18 08:29, Andy Lemin wrote: Hi. That’s ok. This list is a place for open and honest conversation :) My reaction was towards the article trying to say that BSD’s are dying, rather than against Van Sprundle or his research. I’ve read through his slides before and I skim through the erratas each upgrade, but this article tries to bloat the truth in my eyes. So I’m asking the question as to where the reality lies as it stands today? Linux is such a moving target with so much unnecessary complexity with SystemD, that in the bigger picture we can place far more more trust in the BSD’s. It’s also a pretty serious allegation to cite so many vulnerabilities as still being unfixed today? Is this true? Thanks for your reply :) A Sent from a teeny tiny keyboard, so please excuse typos On 28 Jan 2018, at 14:11, Hiltjo Posthuma wrote: On Sun, Jan 28, 2018 at 12:56:26PM +, Andy Lemin wrote: Really, did he actually post any real vulnerabilities to OpenBSD! This article has to be govt propaganda.. https://www.csoonline.com/article/3250653/open-source-tools/is-the-bsd-os-dying-some-security-researchers-think-so.amp.html I was laughing with tears when I read this.. OpenBSD is the only OS I place any real trust in <3 Is probably the only OS they can’t hack. And SystemD makes me want to both cry and scream at the same time. A Sent from a teeny tiny keyboard, so please excuse typos Hey, Maybe I shouldn't reply, but I feel this is insulting to the amazing work of Van Sprundel. I've also seen better nuanced articles about the same presentation talk. Sources: - https://www.openbsd.org/errata60.html (the batch of patches on August 3 2017). - http://undeadly.org/cgi?action=article&sid=20170804053102 - Slides: https://media.defcon.org/DEF%20CON%2025/DEF%20CON%2025%20presentations/DEFCON-25-Ilja-van-Sprundel-BSD-Kern-Vulns.pdf - https://www.openbsd.org/errata56.html (earlier work). Please do more research before you post. -- Kind regards, Hiltjo Interesting read. Thanks for sharing.
Re: Segmentation fault / firefox (core dumped)
La 27.01.2018 14:59, Roderick a scris: > > > # iridium& > [2] 14714 > # *** autoupdate was enabled, overriding with false > iridium(14714) in free(): use after free 0x7e51b6a0 > > [2]Abort iridium (core dumped) > > Known issue. You'll need to try launching Iridium several times to eventually get it to start (sometimes 5 times in a row for me on i386). This issue was solved for the Chromium port shortly after the last release, so I'll guess the fix will trickle down to the Iridium port before the next release. (Someone running Iridium on -current to confirm/infirm?) After launching, the browser itself is quite solid, but tabs will crash from time on time, possibly because of memory constraints, as I've seen signs of major leaking (eg. with video streaming running for hours). One note on SeaMonkey, as it was mentioned in this thread… While the interface may seem bloated, the browser is currently the leanest full-featured one, in my experience. First of all the Mozilla-based rendering engine is not that bad to start with. Also SeaMonkey still uses only one process for everything, so it's not that memory-intensive. Being based on GTK+ 2.x also helps in this regard when compared to its GTK+ 3.x siblings. If you also need a full-featured mail client (as in capable of correctly rendering HTML junk, checking SMIME/PGP signatures etc.) and an IRC client, you'll get to take even more advantage of its monolithic design. I have used it successfully for years on old hardware. The OpenBSD port is very solid, thanks to the excellent work of Landry Breuil. To get the latest version, you'll need to run -current though, and even then, not all the latest Firefox security fixes will be included, as Seamonkey's development is slower. So beware of all the security implications of this, maybe compensate with NoScript and other tricks. As a side note, have noticed Firefox Quantum made strides in reducing memory consumption and has also become much snappier on OpenBSD for me. I'm typing this on a 9-year old desktop which struggled with latest ESR. To the point that sound in other apps (think light media players such as Deadbeef or ffplay) was sometimes chopped when closing heavy tabs in Firefox (confused as to why, this old workhorse has 8GB of RAM and a, premium at the time, Intel SSD). If you are interested in trying Firefox Quantum on 6.2, you should follow the instructions at https://undeadly.org/cgi?action=article&sid=20170425173917. signature.asc Description: OpenPGP digital signature
Re: Removing FUSE would theoretically make a system more secure?
Hello, "> And what are you defending against?" there was/is a great guy that investigated the security of the BSDs, reported a few bugs too: https://www.youtube.com/watch?v=rRg2vuwF1hY&feature=youtu.be&t=1522 that lead to ex.: https://ftp.openbsd.org/pub/OpenBSD/patches/6.1/common/017_fuse.patch.sig So would the mentioned method, by removing the "grep -i fuse /sys/conf/GENERIC" and doing re-compile would "disable FUSE"? Thanks for the syspatch/relinking hint, I forgot about them if I touch the kernel! Thanks! > Sent: Sunday, January 28, 2018 at 5:15 AM > From: mar...@martinbrandenburg.com > To: misc@openbsd.org, whoonet...@mail.com > Subject: Re: Removing FUSE would theoretically make a system more secure? > > > afaik if I would remove the lines that contains "FUSE" and "fuse" from > > /sys/conf/GENERIC and re-compile the kernel, that would mean, there will be > > no more FUSE support in my kernel after reboot. > > > > If so, would this step help to make my system more secure? Ex.: from a > > future FUSE related security issue? > > > > just asking theoretically, since I don't use FUSE related stuff, so > > thinking of that is unneeded. > > > > or it would just create an unsupported kernel which didn't had any tests > > regarding the missing fuse and maybe cause bigger issues and security > > issues vs. if I wouldn't touched it? > > I daresay that removing FUSE support will make you invulnerable to any > kind of bug in FUSE. jca has already given you an outline of the > reasons to believe such a bug, if it exists, is rather unlikely to be > exploitable. > > You had better consider what you're giving up when you make this change. > You won't be able to use FUSE. You won't be able to use syspatch. I'm > not sure how it affects kernel relinking. You'll have to build your > kernels yourself on all architectures you run for each release and every > kernel-related erratum. You'll have to maintain your changes. You > can't just say "I'm not sure" as I just did. You'll have to take > responsibility for the possibility that running a non-standard > configuration may introduce bugs. > > And what are you defending against? Somebody has to get root or a way > to mount filesystems without root. We'll assume he's got a way to mount > filesystems without root, because if he had a way to get root, he > wouldn't need bother with anything else. Then he's got to have his FUSE > exploit which gives him root. Since he probably doesn't have an account > on your system, he's got to have a third exploit to start running code > to begin with. > > Defense in depth is good, but this isn't worth the effort on your part. > > Your security need only be good enough to require an attacker spend more > than he's willing to spend. > > Martin > >
Re: Segmentation fault / firefox (core dumped)
Just a hint: http://www.youtube.com/watch?v=FzJJbNRErVQ&t=30m38s
Re: Removing FUSE would theoretically make a system more secure?
On Sun, Jan 28, 2018 at 06:11:51PM +0100, who one wrote: > Hello, > > "> And what are you defending against?" > > there was/is a great guy that investigated the security of the BSDs, reported > a few bugs too: > > https://www.youtube.com/watch?v=rRg2vuwF1hY&feature=youtu.be&t=1522 > > that lead to ex.: > > https://ftp.openbsd.org/pub/OpenBSD/patches/6.1/common/017_fuse.patch.sig > [...] By that logic, you've just disabled a piece of code that someone (Helg) is actively working on and that has security issues fixed. What makes you so sure there are no deadly bugs in, say, the FAT code? Or drivers for rare-ish network cards? Or the ~120k lines of code that make up the driver for Intel graphics cards? Of course running less code means less of an attack surface. Just make sure you're actually improving security if that's your goal, not just diddling around on the fringes of your system and feeling secure because Fuse is disabled while you're running Chrome which has access to your ~/.ssh/id_ed25519 or ~/.bitcoin/wallet.dat. > [...] > So would the mentioned method, by removing the "grep -i fuse > /sys/conf/GENERIC" and doing re-compile would "disable FUSE"? > [...] If would. But as already mentioned by other people, the barriers to Fuse are relatively high (You need code exec as root to fiddle with /dev/fuse0), while code you're actually running may have more of an impact on your security situation. -- Gregor
Re: "uhub1: device problem, disabling port 1" on Zenbook
On Sun, Jan 28, 2018 at 4:23 AM, Maximilian Pichler wrote: > I'm trying to install OpenBSD 6.2 on a Zenbook (UX390UA) but it is > unable to find the installer USB key (after booting from it). The key > is connected via the USB-A/C adapter/hub that comes with the laptop. > The same hardware works fine under Linux. > $ ls /dev/*sd1* > ls: /dev/*sd1*: No such file or directory the RAMDISK kernel is extremely space-constrained, so its /dev directory is not fully populated. When you reach the "(I)nstall, (U)pgrade, (A)utoinstall or (S)hell?" prompt, enter S then type the following commands to create the sd1 device entries: # cd /etc # ./MAKEDEV sd1 # exit You will then be returned to the installer and you should be able to proceed normally. -ken
Re: gzip compression and httpd/relayd
Am Sun, 28 Jan 2018 10:18:30 +0100 schrieb Thuban : > > > Yes it's possible. Make sure to set the appriopriate HTTP headers > > aswell with relayd: read "Accept-Encoding" and if it's acceptable > > set "Content-Encoding". > > Indeed, it works. > > relayd.conf : > > match response header "Accept-Encoding" value "gzip" > match response header set "Content-Encoding" value "gzip" > > Then : > > cd /var/www/htdocs/site > gzip style.css && mv style.css.gz style.css > > Now, open URL pointing to style.css, and here you go. > > However, all your files must be gzipped, or the browser is unhappy. > > Thanks a lot. > Interesting... Thank you
Re: van Sprundel
Sun, 28 Jan 2018 15:11:41 +0100 Hiltjo Posthuma > On Sun, Jan 28, 2018 at 12:56:26PM +, Andy Lemin wrote: > > Really, did he actually post any real vulnerabilities to OpenBSD! > > > > This article has to be govt propaganda.. > > > > https://www.csoonline.com/article/3250653/open-source-tools/is-the-bsd-os-dying-some-security-researchers-think-so.amp.html > > > > I was laughing with tears when I read this.. > > > > Hey, > > Maybe I shouldn't reply, but I feel this is insulting to the amazing work of > Van Sprundel. I've also seen better nuanced articles about the same > presentation talk. > > Sources: > - https://www.openbsd.org/errata60.html (the batch of patches on August 3 > 2017). > - http://undeadly.org/cgi?action=article&sid=20170804053102 > - Slides: > https://media.defcon.org/DEF%20CON%2025/DEF%20CON%2025%20presentations/DEFCON-25-Ilja-van-Sprundel-BSD-Kern-Vulns.pdf > - https://www.openbsd.org/errata56.html (earlier work). > > Please do more research before you post. > Hi Hiltjo, His 2017-12-29 talk was obviously an old presentation, help him fix it. https://media.ccc.de/search/?q=sprundel https://media.ccc.de/v/34c3-8968-are_all_bsds_created_equally https://fahrplan.events.ccc.de/congress/2017/Fahrplan/events/8968.html We all know the BSDs are not sitting on bugs, stale data is misleading. Kind regards, Anton Lazarov
Good GPU for OpenBSD build?
Hello, I am considering building myself a new computer, and I would like to drive as many as four monitors with it. 3D performance doesn't matter much, I just would like to have a bunch of functioning screen real-estate. Do any of you all have any recommendations for video hardware that works well with OpenBSD and that supports up to four monitors (in my case)? From the lists of supported hardware on the radeon(4) and nv(4) manpages, it seems to me that the Radeon Hawaii R9 (290 & 390 I guess?) series is the newest/best hardware supported. Anyone have experience running that? Thanks, Currell
Re: "uhub1: device problem, disabling port 1" on Zenbook
On Sun, Jan 28, 2018 at 8:12 PM, Kenneth Gober wrote: > When you reach the "(I)nstall, (U)pgrade, (A)utoinstall or (S)hell?" > prompt, enter S then type the following commands to create the sd1 > device entries: > > # cd /etc > # ./MAKEDEV sd1 Thanks! I had confused the absence of the node with the absence of the drive. I'm assuming you meant: # cd /dev # sh ./MAKEDEV sd1 After more testing, it looks like there is non-deterministic behaviour: at each reboot either the thumb drive is recognized (i.e. sd1 appears in dmesg) or it isn't (no sd1 in dmesg, but "uhub1: device problem, disabling port 1"). Sometimes unplugging and replugging the hub or drive gets it recognized, but not always. At least this allowed me to install the system, after a lucky reboot...
Re: Good GPU for OpenBSD build?
I believe this is easy to read: https://www.openbsd.org/amd64.html Kernel drivers != X.org drivers
Re: vmm networking with ubuntu guest [SOLVED-ish]
On Tue, Jan 23, 2018 at 06:44:06AM -0800, Carlos Cardenas wrote: > On Tue, Jan 23, 2018 at 06:38:41PM +1100, tomr wrote: > > > > So. This email was written before I had tried an earlier LTS version of > > ubuntu as the VMM guest. May the details below help someone else in future! > > > > Whatever the problem was, my workaround was to use 16.04-LTS instead 17.10 > > > > t > > > > -- > > > > I'm trying to get an ubuntu guest running, but something is going wrong > > with its networking. Using the exact same vmd config (apart from disk > > images and lladdr), I can get both OpenBSD and alpine linux guests > > running just fine. > > Howdy. > > Thanks for reporting this. > > The issue at hand is that newer versions of ubuntu have an "updated" vionet > guest driver which is causing issues to the vionet driver in vmd. > > > +--+ > Carlos > Yes, I debugged this a few weeks back. It seems that the guest driver in 17.10 is not happy with being told it only has 1 entry in its ring. I got sidetracked with other things, but should be a simple fix if I get some time. -ml
Re: pcengines apu boards
On Wed, Jan 17, 2018 at 12:56:04PM +0100, Christopher Zimmermann wrote: > I have the same problem and have tried to hunt the bug, but failed so > far. Have you already identified the quirks linux and freebsd use to > fix this problem? No :(, I worked on it for a while but kernel hacking isn't my speciality. I don't think the specific quirks I was initially trying to port would have fixed it anyway, as they seemed mainly aimed at data transfers and I couldn't even get the miniPCI card to get hot plugged and detected while testing with an external miniPCI to USB adapter plugged into the internal EHCI header. I ended up just using the external adapter plugged into the xHCI ports exposed outside the case. Annoying not to be able to just have it inside the case, but it works like a champ in this configuration.
Re: Good GPU for OpenBSD build?
To save you the search for what the hell northern islands is: the best graphics support you'll have is a Kaby Lake processor without a graphics card. Failing that you want a high end Radeon HD6xxx card (Northern Islands.) Skylake processors may be the better option than those, thinking about it: the 6xxx cards are pushing 10 years old now.
Re: Good GPU for OpenBSD build?
Ok, thanks for the info. I may opt for the Radeon HD6xxx card as I would like to build with an AMD processor -- and I don't really need too much in the way of fancy graphics, just the ability to drive multiple monitors (which it looks like for example an HD6950 has) and watch youtube videos. -- Currell On Sun, Jan 28, 2018 at 8:50 PM, Daniel Wilkins wrote: > To save you the search for what the hell northern islands is: > the best graphics support you'll have is a Kaby Lake processor > without a graphics card. Failing that you want a high end > Radeon HD6xxx card (Northern Islands.) Skylake processors may > be the better option than those, thinking about it: the 6xxx > cards are pushing 10 years old now. >
Re: Good GPU for OpenBSD build?
Thanks for your response and link. Apology for my ignorance about Xorg drivers vs kernel drivers -- You are saying that the cards listed on the nv(4) and radeon(4) pages do not necessarily correspond to what actually will work, but instead just correspond to code that has been written in X.org that may or may not have the accompanying kernel support in OpenBSD to function, correct? For "radeon" for instance I see a bunch of files at /sys/dev/pci/drm/radeon -- I guess these files work in conjunction with the support in MESA/Xenocara in folders like xenocara/lib/mesa/src/gallium/drivers/radeon ? But perhaps for the nv(4) driver for instance there may or may not be actual kernel support in OpenBSD? Also if I were to plug in a card not listed on any of those lists (a late-model video card for instance), do you think graphics and multi-monitor support would work at all in general? My guess is that it would fall back to software rendering, but I don't know if there's some sort of lowest-common standard that allows the 2d graphics to work without acceleration somehow. Thanks for any input. -- Currell On Sun, Jan 28, 2018 at 6:39 PM, mazocomp wrote: > I believe this is easy to read: https://www.openbsd.org/amd64.html > Kernel drivers != X.org drivers >
Re: IKEv2 - Tunnel all internet traffic from gateway
On 2018-01-28, Daniel Ramos wrote: > This is a multi-part message in MIME format. > --20CEEB9B40C0DB09C5429C35 > Content-Type: text/plain; charset=utf-8; format=flowed > Content-Transfer-Encoding: 7bit > > Hi misc, > > I've been beating my head against the wall on and off for the last few > weeks - it's past time to ask for help. > > I'm trying to tunnel all internet traffic from my internal network > (192.168.2.0/24) through another internet-facing machine (10.1.1.0/24) > using IKEv2. After trying what seems to be every possibility of pf.conf > and iked.conf combinations, I just can't seem to get it right. My > closest attempt is to NAT all traffic from 192.168.2.0/24 to appear as > virtual IP 10.1.1.2 on the other side, which is then NAT'd out to the > internet as usual. The problem with this config is that ALL traffic, > including local traffic to 192.168.2.0/24, is tunneled. This is not > desired because I can no longer access my local gateway (192.168.2.1), > or any locally hosted services. > > What I think I need is to be able to specify something like "from > 10.1.1.2 (192.168.2.0/24) to !192.168.2.0/24" instead of "...to > 0.0.0.0/0" in my iked.conf, but this doesn't seem to be valid syntax. > Nor does limiting the tunnel to certain protos/ports, e.g. ... proto { > tcp udp } ... port { 53 80 443 }. It seems only one proto and port > combination is accepted by iked. I tried adding additional flows > manually - i.e. specifying only proto tcp ... port 80 in iked.conf and > feeding a file of additional flows via ipsecctl -F, but I receive errors > about bad syntax - even though I copied the lines from ipsecctl -sa. It > looks like only IKEv1 syntax is accepted there? What you need is a "bypass flow", I don't think it can be done from iked.conf but you can try this in ipsec.conf (adapt addresses as needed): flow from 192.168.46.48/28 to 192.168.46.48/28 type bypass ipsecctl -f /etc/ipsec.conf to load it at runtime, ipsec=YES in rc.conf.local to load at boot. Please follow-up to confirm whether it works for the archive, I've only done this combined with IKEv1 but I don't see a reason why it wouldn't work.