Re: pf group and setgid

2017-03-12 Thread Jérôme FRGACIC

You seem to be equating the setgid bit with the concept of "start a
process with a different gid".

No, that's not what it does.  The setgid bit starts a new executable
with a disjoint mix of effective, saved, and real gid list, as well as
a gidlist.


Maybe it was not clear in my message but: no, I know that the setgid 
change only the egid of a process and keep the gid, and the list of 
other groups intact.



And that may have consequences.


This is exacly my question: which type of consequences in the case of an 
executable with the setgid bit set and owned by a group that only own 
this file and have only read and execute permission?


I'm not saying I'm better than others or that I can imagine all possible 
consequences of this practise, I only want to have an example and better 
understand why this is a dangerous practise with another answer than 
simply "this is bad", "this is dangerous" or "you are crazy". This is 
certainly true if you said so, but I want to know "why" and "how".


My motivation is simply curiosity. If I can't have an answer, well, I 
will experiment with ls as you said until I found one day my answer.




Re: doas(1) adjustable timeout length

2017-03-12 Thread Ted Unangst
bytevolc...@safe-mail.net wrote:
> On one box I test configuration edits and backups, I find myself using
> doas around once every 7-9 minutes, exceeding the 5 minute limit.
> Another box is basically a gateway, so I don't exceed 2 minutes between
> doas runs.

The timeout was originally 10 minutes, but changed to 5 after I discovered that
was the sudo default. I think increasing to 10 is reasonable, since it seems
likely other people also land in the 5-10 minute window, and it's not
dangerously long.



DDB "boot sync" or "boot dump" hangs

2017-03-12 Thread gwes

I'm trying to debug the following panic.
I can't get a crash dump.
At the DDB prompt, either "boot sync" or "boot dump"
the system prints "Syncing disks: 2" and nothing more.

I've tried:
  removing all disks and/or controllers other than
  the disk holding the root

  removing physical memory so it is 4G < swap space (5G)

  unplugging the offending USB device after the panic

  running 6.0 release, 6.0 stable, and the snapshot below

The panic and hang are identical for all cases.

Is there something obvious about my configuration which is
causing this?
Alternatively, is the panic known? It's 100% reproduceable.
I'll submit bug reports for both if that's the best approach.
I wanted to try to debug this myself to possibly get a fix
quickly.

thanks
Geoff Steckel

panic: ehci_device_clear_toggle: queue active
Stopped at  Debugger+0x9:   leave   
TIDPIDUID PRFLAGS PFLAGS  CPU COMMAND 

 * 2171   2171  0 0x3  00 avrdude 


Debugger() at Debugger+0x9
panic() at panic+0xfe
ehci_device_clear_toggle() at ehci_device_clear_toggle+0x2b
usbd_clear_endpoint_stall() at usbd_clear_endpoint_stall+0x24
ugen_do_read() at ugen_do_read+0x4e6
ugenread() at ugenread+0x48
spec_read() at spec_read+0x2c5
VOP_READ() at VOP_READ+0x3f
vn_read() at vn_read+0xa1
dofilereadv() at dofilereadv+0x204
sys_read() at sys_read+0x89
syscall() at syscall+0x27b
--- syscall (number 3) ---
end trace frame: 0x0, count: 3
0x108592d58a1a:


Mar 10 20:26:39 store /bsd: OpenBSD 6.1-beta (GENERIC.MP) #224: Thu Mar 
9 18:50:15 MST 2017
Mar 10 20:26:39 store /bsd: 
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Mar 10 20:26:39 store /bsd: real mem = 8466022400 (8073MB)
Mar 10 20:26:39 store /bsd: avail mem = 8204775424 (7824MB)
Mar 10 20:26:39 store /bsd: mpath0 at root
Mar 10 20:26:39 store /bsd: scsibus0 at mpath0: 256 targets
Mar 10 20:26:39 store /bsd: mainbus0 at root
Mar 10 20:26:39 store /bsd: bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb450 
(20 entries)
Mar 10 20:26:39 store /bsd: bios0: vendor American Megatrends Inc. 
version "4.6.5" date 06/05/2013

Mar 10 20:26:39 store /bsd: bios0: BIOSTAR Group NM70I-1037U
Mar 10 20:26:39 store /bsd: acpi0 at bios0: rev 2
Mar 10 20:26:39 store /bsd: acpi0: sleep states S0 S1 S4 S5
Mar 10 20:26:39 store /bsd: acpi0: tables DSDT FACP APIC FPDT MCFG HPET 
SSDT SSDT SSDT
Mar 10 20:26:39 store /bsd: acpi0: wakeup devices PS2K(S4) UAR1(S4) 
P0P1(S4) USB1(S4) USB2(S4) USB3(S4) USB4(S4) USB5(S4) USB6(S4) USB7(S4) 
PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) [...]

Mar 10 20:26:39 store /bsd: acpitimer0 at acpi0: 3579545 Hz, 24 bits
Mar 10 20:26:39 store /bsd: acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
Mar 10 20:26:39 store /bsd: cpu0 at mainbus0: apid 0 (boot processor)
Mar 10 20:26:39 store /bsd: cpu0: Intel(R) Celeron(R) CPU 1037U @ 
1.80GHz, 1796.21 MHz
Mar 10 20:26:39 store /bsd: 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT

Mar 10 20:26:39 store /bsd: cpu0: 256KB 64b/line 8-way L2 cache
Mar 10 20:26:39 store /bsd: cpu0: TSC frequency 1796209080 Hz
Mar 10 20:26:39 store /bsd: cpu0: smt 0, core 0, package 0
Mar 10 20:26:39 store /bsd: mtrr: Pentium Pro MTRR support, 10 var 
ranges, 88 fixed ranges

Mar 10 20:26:39 store /bsd: cpu0: apic clock running at 99MHz
Mar 10 20:26:39 store /bsd: cpu0: mwait min=64, max=64, 
C-substates=0.2.1.1.2, IBE

Mar 10 20:26:39 store /bsd: cpu1 at mainbus0: apid 2 (application processor)
Mar 10 20:26:39 store /bsd: cpu1: Intel(R) Celeron(R) CPU 1037U @ 
1.80GHz, 1795.92 MHz
Mar 10 20:26:39 store /bsd: 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT

Mar 10 20:26:39 store /bsd: cpu1: 256KB 64b/line 8-way L2 cache
Mar 10 20:26:39 store /bsd: cpu1: smt 0, core 1, package 0
Mar 10 20:26:39 store /bsd: ioapic0 at mainbus0: apid 2 pa 0xfec0, 
version 20, 24 pins

Mar 10 20:26:39 store /bsd: acpimcfg0 at acpi0 addr 0xf800, bus 0-63
Mar 10 20:26:39 store /bsd: acpihpet0 at acpi0: 14318179 Hz
Mar 10 20:26:39 store /bsd: acpiprt0 at acpi0: bus 0 (PCI0)
Mar 10 20:26:39 store /bsd: acpiprt1 at acpi0: bus -1 (P0P1)
Mar 10 20:26:39 store /bsd: acpiprt2 at acpi0: bus 2 (RP01)
Mar 10 20:26:39 store /bsd: acpiprt3 at acpi0: bus 3 (RP02)
Mar 10 20:26:39 store /bsd: acpiprt4 at acpi0: bus -1 (RP03)
Mar 10 20:26:39 store /bsd: acpiprt5 at acpi0: bus -1 (RP04)
Mar 10 20:26:39 store /bsd: acpiprt6 at acpi0: bus -1 (RP05)
Mar 10 20:26:39 store /bsd: acpiprt7 at acpi0: bus -1 (RP06)
Mar 10 20:26:39 store /bsd: acpiprt8 at acpi0

Re: doas(1) adjustable timeout length

2017-03-12 Thread bytevolcano
On one box I test configuration edits and backups, I find myself using
doas around once every 7-9 minutes, exceeding the 5 minute limit.
Another box is basically a gateway, so I don't exceed 2 minutes between
doas runs.

It would be nice to have the option of deviating from the default, and
the "persist" feature seems incomplete without the ability to adjust
the timeout from a fixed 5 minutes.
I didn't say anything until now, because I was under the
impression there was something else planned for the "persist" feature,
but there has I haven't seen anything about this in the mailing lists
since this: https://marc.info/?l=openbsd-tech&m=147314077009745

Since the first release with this feature will be 6.1, it seems logical
to make any syntax changes now rather than later. No kernel changes
needed here, since the timeout can be set with TIOCSETVERAUTH, so I
don't see any harm in giving admins the option of setting the timeout
with doas.conf instead of it being hard-coded into doas itself.

On Sun, 12 Mar 2017 10:20:46 -0600
"Theo de Raadt"  wrote:

> I'll ask the question: Why are you sure you need that?
> 
> > Are there plans (or perhaps code already being worked on) to allow
> > doas(1) 'persist' to have a different time other than 5 minutes? I
> > am thinking of writing a patch for this, but I do not want to
> > duplicate effort if the devs have other/similar plans ahead.
> > 
> > I would like to configure the timeout to be 1 minute on one of my
> > boxes, and 5-10 minutes on another box.
> > 
> > For instance, something like:
> > 
> > # 90-second persistence
> > permit persist=90 :wheel
> > permit nopass keepenv root
> > 
> > # 5-minute persistence
> > permit persist :captain
> > 
> > Or even:
> > 
> > # 90-seconds; timeout must be specified.
> > permit persist 90 :wheel  



Re: relayd redirect not working

2017-03-12 Thread Michael W. Lucas
On Sun, Mar 12, 2017 at 09:26:53AM +0100, Salvatore Cuzzilla wrote:
> Ciao Dave,
> 
> I'm also playing with relayd as a L7 gateway and as far as I can see from your
> config there is no CA and key configured. In order for HTTPS to work relayd
> needs to be able to do TLS inspection and of course you should redirect all
> your https traffic to port 8443 (using PF for example). If you check the
> pf.conf man page under both the sections RELAYS and Examples you should be
> able to find a lot of good hints.

He's using a redirect, not a relay, so it should work just fine. No L7
stuff here, only low-level IP.

Dave, looks OK to me. What does relayd -dvvv say? And relayctl sho sum ?

-- 
Michael W. LucasTwitter @mwlauthor 
nonfiction: https://www.michaelwlucas.com/
fiction: https://www.michaelwarrenlucas.com/
blog: http://blather.michaelwlucas.com/



Re: Firefox: Recenty instable

2017-03-12 Thread Thomas Weinbrenner
On Sun, Mar 12, 2017 at 11:19:18PM +0100, Stefan Wollny wrote:
> Hi there,
> 
> for the last 3~4 days (always running the latest of public
> amd64-current) firefox behaviour was kind of "unfamiliar" - regular
> crashes after a few minutes.

[...]
 
> Am I right supposing that the most likely answer will be "Wait for the
> next snap!"? :-)

I found this quite helpful.

https://marc.info/?l=openbsd-ports&m=148925156914633

Since raising datasize-cur in /etc/login.conf my firefox has stopped
crashing.



Firefox: Recenty instable

2017-03-12 Thread Stefan Wollny
Hi there,

for the last 3~4 days (always running the latest of public
amd64-current) firefox behaviour was kind of "unfamiliar" - regular
crashes after a few minutes.

Starting firefox in a xterm gave me this:
~ $ firefox
firefox:/usr/local/lib/libicuuc.so.12.0:
/usr/local/lib/libicudata.so.12.0 : WARNING: symbol(icudt58_dat) size
mismatch, relink your program
1489350944851   addons.update-checker   WARNUpdate manifest for
e10sroll...@mozilla.org did not contain an updates property
1489350944986   addons.update-checker   WARNUpdate manifest for
fire...@getpocket.com did not contain an updates property
1489350944998   addons.update-checker   WARNUpdate manifest for
webcom...@mozilla.org did not contain an updates property
1489350945009   addons.update-checker   WARNUpdate manifest for
aushel...@mozilla.org did not contain an updates property
1489350945022   addons.update-checker   WARNUpdate manifest for
{972ce4c6-7e08-4474-a285-3208198ce6fd} did not contain an updates property
Assertion failure: addr == p, at
/usr/obj/ports/firefox-52.0/firefox-52.0/js/src/jit/ProcessExecutableMemory.cpp:322
Segmentation fault (core dumped)

Am I right supposing that the most likely answer will be "Wait for the
next snap!"? :-)

Best,
STEFAN


OpenBSD 6.1-beta (GENERIC.MP) #7: Sat Mar 11 18:32:03 MST 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17079074816 (16287MB)
avail mem = 16556789760 (15789MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec080 (35 entries)
bios0: vendor American Megatrends Inc. version "1.03.06" date 06/25/2014
bios0: Notebook W65_67SZ
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT ASF! TCPA SSDT SSDT SSDT MCFG HPET
SSDT SSDT SSDT DMAR
acpi0: wakeup devices PXSX(S4) RP01(S4) PXSX(S4) PXSX(S4) RP03(S4)
PXSX(S4) RP04(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) GLAN(S4) EHC1(S3)
EHC2(S3) XHC_(S3) HDEF(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) Core(TM) i5-4210M CPU @ 2.60GHz, 2594.34 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,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: TSC frequency 2594337860 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) Core(TM) i5-4210M CPU @ 2.60GHz, 2594.00 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,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Core(TM) i5-4210M CPU @ 2.60GHz, 2594.00 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,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 1, core 0, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i5-4210M CPU @ 2.60GHz, 2594.00 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,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 2 (RP01)
acpiprt2 at acpi0: bus 3 (RP03)
acpiprt3 at acpi0: bus 4 (RP04)
acpiprt4 at acpi0: bus 1 (P0P2)
acpiprt5 at acpi0: bus -1 (P0PA)
acpiprt6 at acpi0: bus -1 (P0PB)
acpiprt7 at acpi0: bus 1 (PEG0)
acpiec0 at acpi0
acpicpu0 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS
acpicpu2 at acpi0: C2(200@148 mwait.1@0x

Re: pf group and setgid

2017-03-12 Thread Jiri B
On Sun, Mar 12, 2017 at 07:13:08PM +0100, Jrme FRGACIC wrote:
> Hi @misc,
> 
> I have a question about pf and its possibility to filter packets by process
> group: is it a reasonable practice to use setgid for add some rules that
> allow only specific programs to use some services? For example, only permit
> the ftp command and firefox to use HTTP and HTTPS services?
> 
> If I create a separate group for each program I want to allow, is there any
> additional risk induce by the use of the setgid? Also, does this practise
> can be helpful by adding a supplementary layer of protection or is it
> useless?
> 
> $ ls -l /usr/bin/ftp
> -r-xr-sr-x  1 root  ftpcmd  151168 Jul 26  2016 /usr/bin/ftp
> $ grep ftpcmd /etc/pf.conf
> pass out on if proto tcp from (if:0) to any port { 80,443 } group ftpcmd
> 
> Kind regards,
> 
> 
> Jérôme FRGACIC

Your problem is already solved - it is called 'proxy' :)

j.



Re: pf group and setgid

2017-03-12 Thread Theo de Raadt
> Could you be more precise on this point? I mean: if I correctly 
> understand, you said that this can induce unwanted behavior due to the 
> fact that, for example, firefox suppose it has the uid and gid of the 
> user who launch it (and not a different egid)?
> 
> If I'am right, does this can really mater if the egid is the one of a 
> group that only own one (executable) file in the whole system whith only 
> read and execute permission on it?

You seem to be equating the setgid bit with the concept of "start a
process with a different gid".

No, that's not what it does.  The setgid bit starts a new executable
with a disjoint mix of effective, saved, and real gid list, as well as
a gidlist.

And that may have consequences.  Maybe you think you can control all of
the details and control the consequences; in that case you wouldn't be
asking.  You are asking about doing this for a gigantic program like
firefox.  That approach is crazy, and doesn't match what pf is doing in
any case.



Re: pf group and setgid

2017-03-12 Thread Jérôme FRGACIC

Thanks for your reply.


You are providing a program with an additional gid.  The program has
not been coded be aware of that gid.  Two potentially different
filesystem views now exist within the program, depending on the g=rwx
bits of directories and files in the tree.  The program is no longer
operating in a world-view it was designed for.


Could you be more precise on this point? I mean: if I correctly 
understand, you said that this can induce unwanted behavior due to the 
fact that, for example, firefox suppose it has the uid and gid of the 
user who launch it (and not a different egid)?


If I'am right, does this can really mater if the egid is the one of a 
group that only own one (executable) file in the whole system whith only 
read and execute permission on it?




Re: pf group and setgid

2017-03-12 Thread Theo de Raadt
> Thanks for your reply.
> 
> > You are providing a program with an additional gid.  The program has
> > not been coded be aware of that gid.  Two potentially different
> > filesystem views now exist within the program, depending on the g=rwx
> > bits of directories and files in the tree.  The program is no longer
> > operating in a world-view it was designed for.
> 
> Could you be more precise on this point? I mean: if I correctly 
> understand, you said that this can induce unwanted behavior due to the 
> fact that, for example, firefox suppose it has the uid and gid of the 
> user who launch it (and not a different egid)?
> 
> If I'am right, does this can really mater if the egid is the one of a 
> group that only own one (executable) file in the whole system whith only 
> read and execute permission on it?

Make a copy of ls, and add the setgid bit to it.  Play around with it
for a while, including using chmod on various files and directories.

It shouldn't take you long to realize that setuid/setgid should only
be set on programs that are specifically written for that.



Re: relayd redirect not working

2017-03-12 Thread Dave Cohen
Thanks all, for the several helpful responses in this thread.

Here's what I currently have, in /etc/pf.conf.  Appears to work.  Although, I 
am rethinking my approach and may terminate TLS at httpd in the future.  Still 
it is nice for me to learn what is possible.

match in on egress proto tcp from any to (self) port  80 rdr-to 127.0.0.1 port 
8080 
match in on egress proto tcp from any to (self) port 443 rdr-to 127.0.0.1 port 
8443


To Salvatore Cuzzilla, note I was trying to use relayd for L3 redirect, which 
is why no CA or key configured.

To Kevin, I'm not trying to simply replace httpd with caddy.  Longer term I 
will be customizing the server, which I prefer to do in Go.

-Dave

On Sun, Mar 12, 2017, at 02:12 AM, Sebastien Marie wrote:
[snip]
> 
> pass in on egress proto tcp from any to (self) port  80 rdr-to 127.0.0.1 port 
> 8080
> pass in on egress proto tcp from any to (self) port 443 rdr-to 127.0.0.1 port 
> 8443
> 
> see pf.conf(5) and https://www.openbsd.org/faq/pf/rdr.html
> 
> -- 
> Sebastien Marie



Re: pf group and setgid

2017-03-12 Thread Theo de Raadt
> If I create a separate group for each program I want to allow, is there 
> any additional risk induce by the use of the setgid?

Yes, it introduces a risk.

You are providing a program with an additional gid.  The program has
not been coded be aware of that gid.  Two potentially different
filesystem views now exist within the program, depending on the g=rwx
bits of directories and files in the tre.  The program is no longer
operating in a world-view it was designed for.  

setuid and setgid aren't things one enables on unprepared code.



pf group and setgid

2017-03-12 Thread Jérôme FRGACIC

Hi @misc,

I have a question about pf and its possibility to filter packets by 
process group: is it a reasonable practice to use setgid for add some 
rules that allow only specific programs to use some services? For 
example, only permit the ftp command and firefox to use HTTP and HTTPS 
services?


If I create a separate group for each program I want to allow, is there 
any additional risk induce by the use of the setgid? Also, does this 
practise can be helpful by adding a supplementary layer of protection or 
is it useless?


$ ls -l /usr/bin/ftp
-r-xr-sr-x  1 root  ftpcmd  151168 Jul 26  2016 /usr/bin/ftp
$ grep ftpcmd /etc/pf.conf
pass out on if proto tcp from (if:0) to any port { 80,443 } group ftpcmd

Kind regards,


Jérôme FRGACIC

PS: I not subscribe to this list, so please add me as recipient if you 
reply.




project tunerd

2017-03-12 Thread Sam Flynn
This project is OpenBSD oriented - a use of the radio device driver

It is a program allowing web/HTTP control of a radio tuner card
It is a barebones HTTP server with ServerSentEvents (SSE) to notify
multiple client browsers of station/frequency changes

Published at github
https://github.com/dougmaus/tunerd

Sharing this in case anyone on openbsd might want to use it, or
expand/modify it.



Re: doas(1) adjustable timeout length

2017-03-12 Thread Theo de Raadt
I'll ask the question: Why are you sure you need that?

> Are there plans (or perhaps code already being worked on) to allow
> doas(1) 'persist' to have a different time other than 5 minutes? I am
> thinking of writing a patch for this, but I do not want to duplicate
> effort if the devs have other/similar plans ahead.
> 
> I would like to configure the timeout to be 1 minute on one of my
> boxes, and 5-10 minutes on another box.
> 
> For instance, something like:
> 
>   # 90-second persistence
>   permit persist=90 :wheel
>   permit nopass keepenv root
> 
>   # 5-minute persistence
>   permit persist :captain
> 
> Or even:
> 
>   # 90-seconds; timeout must be specified.
>   permit persist 90 :wheel



mpath for vioscsi disks

2017-03-12 Thread Jiri B
Is mpath doable for vioscsi disks? At least if running OpenBSD
on Linux KVM one could use iSCSI with Ceph backend and thus assing
two iSCSI luns as vioscsi disks for OpenBSD VM.

IIUC vioblk strips SCSI commands so it cannot be used for this.

I'm not also sure if we would use iSCSI luns directly inside that
OpenBSD VM and having them in mpath.

Any thoughts about this? Or about mpath with non-enteprise SAN
boxes?

j.



Re: For the super paranoid

2017-03-12 Thread bytevolcano
>From your link:

AMD replied: "Thanks for the inquiry. Currently we do not have
plans to release source code but you make a good argument for
reasons to do so. We will evaluate and find a way to work with
security vendors and the community to everyone's benefit." The
product manager for AMD, AMD_james, continued in response to a
follow-up comment that claims AMD is "not considering it all
but only want to appease the potential buyers." AMD_james
replied: "Thanks for the feedback. Please believe me that this
has CEO level attention and AMD is investigating the steps and
resources necessary to support this. It is not the work of a
minute, so please bear with us as we define what we can do."

In other words: the fourth millennium will arrive first.

On Sun, 12 Mar 2017 12:47:06 +0100 (CET)
I love BSDs  wrote:

> >In order for me to trust AMD's implementation, they first need to can
> >that ridiculous Platform "Security" Processor. It is as useless and
> >dangerous as Intel Management Engine, running unknown code.
>
> Who know, maybe they are going to open source their firmware?
>
https://news.slashdot.org/story/17/03/10/2048236/message-for-amd-open-psp-wil
l-improve-security-hinder-intel
>
> Anyway I recommend "Wait and see".



Re: For the super paranoid

2017-03-12 Thread I love BSDs
>In order for me to trust AMD's implementation, they first need to can
>that ridiculous Platform "Security" Processor. It is as useless and
>dangerous as Intel Management Engine, running unknown code.

Who know, maybe they are going to open source their firmware?
https://news.slashdot.org/story/17/03/10/2048236/message-for-amd-open-psp-will-improve-security-hinder-intel

Anyway I recommend "Wait and see".



doas(1) adjustable timeout length

2017-03-12 Thread bytevolcano
Hi,

Are there plans (or perhaps code already being worked on) to allow
doas(1) 'persist' to have a different time other than 5 minutes? I am
thinking of writing a patch for this, but I do not want to duplicate
effort if the devs have other/similar plans ahead.

I would like to configure the timeout to be 1 minute on one of my
boxes, and 5-10 minutes on another box.

For instance, something like:

# 90-second persistence
permit persist=90 :wheel
permit nopass keepenv root

# 5-minute persistence
permit persist :captain

Or even:

# 90-seconds; timeout must be specified.
permit persist 90 :wheel



Re: relayd redirect not working

2017-03-12 Thread Sebastien Marie
On Sat, Mar 11, 2017 at 09:48:27PM -0800, Dave Cohen wrote:
> I'm struggling to figure out why network traffic is not making it to a 
> service I'm running.
> 
> What I'm trying to do is serve http and https from a non-standard server.  
> (Called `caddy`, if you're curious).  I want to run this thing as non-root 
> user.  I'm not aware of any way to have the non-root user open ports 80 or 
> 443.  Which is great, so long as I can get traffic to those port to be 
> redirected to my server, which I have listening on 8080 and 8443 respectively.
> 
> I prefer the TLS traffic to 443 terminate at my server on 8443.  And I've 
> been trying to do this with relayd redirects.
> 
> [...]
> 
> My questions for this group are (a) is there a smarter way than what I'm 
> trying?  And if not (b) what am I doing wrong?  Thanks in advance for any 
> info!
> 

does pf(4) rules shouldn't be better for that, instead of using
relayd(8) ?

something like these (untested) rules:

pass in on egress proto tcp from any to (self) port  80 rdr-to 127.0.0.1 port 
8080
pass in on egress proto tcp from any to (self) port 443 rdr-to 127.0.0.1 port 
8443

see pf.conf(5) and https://www.openbsd.org/faq/pf/rdr.html

-- 
Sebastien Marie



Re: relayd redirect not working

2017-03-12 Thread Salvatore Cuzzilla
Ciao Dave,

I'm also playing with relayd as a L7 gateway and as far as I can see from your
config there is no CA and key configured. In order for HTTPS to work relayd
needs to be able to do TLS inspection and of course you should redirect all
your https traffic to port 8443 (using PF for example). If you check the
pf.conf man page under both the sections RELAYS and Examples you should be
able to find a lot of good hints.


Regards,
Salvatore.

> On 12 Mar 2017, at 06:48, Dave Cohen  wrote:
>
> I'm struggling to figure out why network traffic is not making it to a
service I'm running.
>
> What I'm trying to do is serve http and https from a non-standard server.
(Called `caddy`, if you're curious).  I want to run this thing as non-root
user.  I'm not aware of any way to have the non-root user open ports 80 or
443.  Which is great, so long as I can get traffic to those port to be
redirected to my server, which I have listening on 8080 and 8443
respectively.
>
> I prefer the TLS traffic to 443 terminate at my server on 8443.  And I've
been trying to do this with relayd redirects.
>
> Here's what I've tried, in /etc/relayd.conf:
>
> table  {127.0.0.1}
>
> redirect "https" {
>listen on 0.0.0.0 port 443
>forward to  port 8443 check icmp
> }
>
> redirect "http" {
>listen on 0.0.0.0 port 80
>forward to  port 8080 check icmp
> }
>
>
>
> With that configuration, traffic on port 80 works as expected, my server
responds.  But https traffic on port 443, as far as I can tell, never makes it
to my server listening on port 8443.  I'm not sure why the two redirects which
are so similar do not behave the same way.
>
> Possibly, the https redirect needs to use `route to` rather than `forward
to`.  When I tried that, relayd errors with "missing interface to route to".
I couldn't figure out reading `man relayd.conf` how to get past that error.
If anyone has a working example, please share.
>
> My questions for this group are (a) is there a smarter way than what I'm
trying?  And if not (b) what am I doing wrong?  Thanks in advance for any
info!
>
> -Dave