Re: defer routing table updates on link state changes
On 12/09/13(Thu) 13:50, Philip Guenther wrote: On Thu, Sep 12, 2013 at 10:19 AM, Mike Belopuhov m...@belopuhov.com wrote: ... either way, we need to move forward on this. we want to use if_index for the purpose of looking up the interface w/o a pointer to the ifnet. This sounds like just using a pid to identify processes and hoping they haven't wrapped around...and the places the kernel does that are wrong too**. If pointers are out because refcounting them to avoid dangling pointers leaves them impossible to reliably clean up in bounded time (i.e., you need weak pointers), then there should be a generation number to catch the wraps. IMO. Yes! It's really similar to pid for processes, except that interface indexes should not be recycled that often. I agree that having a generation number would help for the wrapping case, but for now I *guess* that the limit of USHRT_MAX interface indexes generated during an uptime before wrapping is enough to move forward. (I don't get why it's useful for tun0-in-layer3 mode to have the same if_index as tun0-in-layer2 mode. The properties are so different that there doesn't really seem to be continuity of identity between them.) Me neither, is there any reason for that before I start digging into it?
Re: Iso image integrity verification
Physical email is as susceptible to MITM attacks as network connections. I know a story of laptops entering the mail system and car springs coming out the other end in the same box. :-) Yes, the MITM was DPD. Great currier. I recommand it to everyone. NOT!
Re: Iso image integrity verification
Yes, the MITM was DPD. Great currier. I recommand it to everyone. NOT! ^courier
Re: defer routing table updates on link state changes
On 2013/09/13 09:10, Martin Pieuchot wrote: On 12/09/13(Thu) 13:50, Philip Guenther wrote: (I don't get why it's useful for tun0-in-layer3 mode to have the same if_index as tun0-in-layer2 mode. The properties are so different that there doesn't really seem to be continuity of identity between them.) Me neither, is there any reason for that before I start digging into it? I haven't checked, but it is possible that a program sets link0 mode itself and keeps using the old index number. OpenVPN would be the most likely candidate for this.
Re: Iso image integrity verification
On Fri, Sep 13, 2013 at 10:32:43AM +0300, Paul Irofti wrote: Yes, the MITM was DPD. Great currier. I recommand it to everyone. NOT! ^courier the two aren't necessarily mutually exclusive ;) - P -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: defer routing table updates on link state changes
On 12/09/13(Thu) 18:56, Henning Brauer wrote: * Mike Belopuhov m...@belopuhov.com [2013-09-12 17:54]: it makes no sense whatsoever, reyk. those indices can be easily stolen and nobody guarantees that if you create vlan10, vlan11, then destroy vlan10, create vlan12 and vlan10 that vlan10 will have the same index as before. in fact it might be a different interface created for a different purpose days after. who knows? if snmp client relies on this behavior, it's broken since we have never made any provisions regarding how we use those indices. correct. however, it is not reyk who's on drugs here, it's snmp itself. using the OS-private ifindex and making assumptions about it is the root problem. but since that's in the standards, there are only 2 possible solutions I see: -keep trying to please snmp in the way we assign ifindex That would involve modifying the actual code to not reuse the *last* but *first* free index ;) But it doesn't help at all for our problem, which means that we need another API to not pass pointers to interfaces in our kernel. -let snmpd (or sth else) make up ifindices just for that purpose That looks like the best solution to me. If a userland program want to expose following numbers, then it probably needs to create its own indexes anyway, even our actual in-kernel code doesn't guarantee that. In the end we need two different tables, one with an unique index per interface (to avoid passing pointers in kernel) and another one with the biggest index equals to the number of interfaces (to not confuse snmp). IMHO we don't need these two tables in the kernel. Martin
Re: Iso image integrity verification
Security itself is not the primary issue here. The issue is to easily prove an assessor without reasonable doubt that you are running the right thing. They will not worry about governments trying to break in with MITM signed ssl or about armies breaking in with the tanks. But they would worry about me not building the image the right way, someone tampering with the image or leaving the door unlocked at the server room. Also, they require people to take responsibility for the thing they do (in this case, CD images). On Fri, Sep 13, 2013 at 1:56 AM, Kenneth R Westerback kwesterb...@rogers.com wrote: On Thu, Sep 12, 2013 at 07:52:22PM +0300, Valentin Zagura wrote: There is no entity that owns or can be held responsible for the code, or is capable of providing a solid evidentuary path from commit to your hands. I thought if we buy the CDs we WILL get a solid evidentuary path from commit to our hands. So this isn't the case? Physical email is as susceptible to MITM attacks as network connections. I know a story of laptops entering the mail system and car springs coming out the other end in the same box. :-) CDs will give you the best evidentuary path available. Compiling everything yourself with a compiler and hardware you built from piles of dirt in a clean room would be better. And then you still have to worry about nano technology being slipped into the dirt. Ken On Wed, Sep 11, 2013 at 1:58 PM, Peter N. M. Hansteen pe...@bsdly.net wrote: On Wed, Sep 11, 2013 at 01:49:14PM +0300, Valentin Zagura wrote: We are going to use a OpenBSD system in a PCI-DSS compliant environment. Is there any way we can prove to our PCI-DSS assessor that the OpenBSD image we use for our installation can be checked so that it is the correct one (is not modified in a malicious way by a third party) ? Probably not what you want to hear, but starting with http://www.openbsd.org/orders.html is usually an excellent idea in this context. Verifiably delivered from a trusted source. A https link to some kind of ISO checksum or something similar (but using strong cryptography) I think would do it, but I could not find any (except a line in the FAQ stating If the men in black suits are out to get you, they're going to get you. which is not the case :) ) It's possible some of the more prominent entries on http://www.openbsd.org/support.html could be persuaded to provide something like that (M:Tier comes to mind, but why are they not on that page?) in exchange for a reasonable fee. But again, for -RELEASE, the CD sets are a good starting point. - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
more /dev/ugen*
While debugging a problem with pcscd from security/pcsc-lite
06361622 hotplug_libusb.c:514:HPAddHotPluggable() Adding USB device: 3:2:0
0191 hotplug_libusb.c:558:HPAddHotPluggable() libusb_open failed: -4
We (Damien and me) quickly found that the cause was:
16097 pcscdGIO fd 1 wrote 75 bytes
04421857 hotplug_libusb.c:514:HPAddHotPluggable() Adding USB device:
3:2:0
16097 pcscdRET write 75/0x4b
16097 pcscdCALL open(0x74d05fa7bd0,0x2O_RDWR)
16097 pcscdNAMI /dev/ugen2.00
16097 pcscdRET open -1 errno 2 No such file or directory
16097 pcscdCALL gettimeofday(0x74d05fa7320,0)
16097 pcscdSTRU struct timeval { 1379032621.501928 }
16097 pcscdRET gettimeofday 0
16097 pcscdCALL write(0x1,0x74cfc0cc000,0x49)
16097 pcscdGIO fd 1 wrote 73 bytes
0157 hotplug_libusb.c:558:HPAddHotPluggable() libusb_open failed:
-4
I think only two /dev/ugen* are too few, what about increasing the
number a bit?
Index: MAKEDEV.common
===
RCS file: /cvs/src/etc/MAKEDEV.common,v
retrieving revision 1.70
diff -u -p -u -p -r1.70 MAKEDEV.common
--- MAKEDEV.common 5 Sep 2013 06:36:16 - 1.70
+++ MAKEDEV.common 13 Sep 2013 08:14:54 -
@@ -183,7 +183,7 @@ target(usb, usb, 0, 1, 2, 3, 4, 5, 6, 7)
target(usb, urio, 0)dnl
target(usb, uhid, 0, 1, 2, 3)dnl
target(usb, ulpt, 0, 1)dnl
-target(usb, ugen, 0, 1)dnl
+target(usb, ugen, 0, 1, 2, 3)dnl
target(usb, ttyU, 0, 1, 2, 3)dnl
dnl
__devitem({-uall-}, uall, All USB devices,usb)dnl
Re: defer routing table updates on link state changes
On Fri, Sep 13, 2013 at 09:53:03AM +0200, Martin Pieuchot wrote: -let snmpd (or sth else) make up ifindices just for that purpose That looks like the best solution to me. If a userland program want to expose following numbers, then it probably needs to create its own indexes anyway, even our actual in-kernel code doesn't guarantee that. No, that's utterly stupid. The interface index is a value that is supposed to be consistent across the system. How should it be synced with other userland tools? How would you handle it in if_nametoindex and friends? As I said before: it is not a big issue for snmpd and I can live with the fact that your changes might confuse SNMP clients a bit. Just go ahead, but In the end we need two different tables, one with an unique index per interface (to avoid passing pointers in kernel) and another one with the biggest index equals to the number of interfaces (to not confuse snmp). IMHO we don't need these two tables in the kernel. please read the history: if_index _was_ created for SNMP. Then it was used for routing and other stuff. Now you want to use it as a PID for something else. Fine. But please stop claiming that SNMP is doing anything wrong with if_indexes when they were created FOR SNMP. Reyk
Re: Iso image integrity verification
* Valentin Zagura put...@gmail.com [2013-09-13 10:15]: Security itself is not the primary issue here. The issue is to easily prove an assessor without reasonable doubt that you are running the right thing. They will not worry about governments trying to break in with MITM signed ssl or about armies breaking in with the tanks. But they would worry about me not building the image the right way, someone tampering with the image or leaving the door unlocked at the server room. Also, they require people to take responsibility for the thing they do (in this case, CD images). buy the CD set. it's more than good enough for the PCI DSS theatre (been there). -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: defer routing table updates on link state changes
On 2013/09/13 09:53, Martin Pieuchot wrote: On 12/09/13(Thu) 18:56, Henning Brauer wrote: -let snmpd (or sth else) make up ifindices just for that purpose That looks like the best solution to me. If a userland program want to expose following numbers, then it probably needs to create its own indexes anyway, even our actual in-kernel code doesn't guarantee that. In the end we need two different tables, one with an unique index per interface (to avoid passing pointers in kernel) and another one with the biggest index equals to the number of interfaces (to not confuse snmp). IMHO we don't need these two tables in the kernel. Having snmpd keep its own table would have another advantage: if you add interfaces, you would be able to get new stable index numbers by just restarting snmpd, allowing you to update index numbers in monitoring systems without rebooting the kernel.
Re: defer routing table updates on link state changes
* Reyk Floeter r...@openbsd.org [2013-09-13 10:20]: please read the history: if_index _was_ created for SNMP. I'm not at all certain you got the history right there... -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: defer routing table updates on link state changes
On 13/09/13(Fri) 10:14, Reyk Floeter wrote:
On Fri, Sep 13, 2013 at 09:53:03AM +0200, Martin Pieuchot wrote:
-let snmpd (or sth else) make up ifindices just for that purpose
That looks like the best solution to me. If a userland program want
to expose following numbers, then it probably needs to create its own
indexes anyway, even our actual in-kernel code doesn't guarantee that.
No, that's utterly stupid. The interface index is a value that is
supposed to be consistent across the system. How should it be synced
with other userland tools? How would you handle it in if_nametoindex
and friends?
So what do *you* suggest which is not utterly stupid?
I can't see where it is written that the interface index should be
consistent, from the RFC 1156, I read:
ifIndex { ifEntry 1 }
A unique value for each interface. Its value ranges
between 1 and the value of ifNumber. The value for each
interface must remain constant at least from one re-
initialization of the entity's network management system
to the next re-initialization.
As I said before: it is not a big issue for snmpd and I can live with
the fact that your changes might confuse SNMP clients a bit. Just go
ahead, but
Well it looks like a big issue because you keep complaining.
Would you exclaiming what confusing SNMP clients means? What breaks?
Can it be solved? What is the technical problem here?
In the end we need two different tables, one with an unique index per
interface (to avoid passing pointers in kernel) and another one with
the biggest index equals to the number of interfaces (to not confuse
snmp). IMHO we don't need these two tables in the kernel.
please read the history: if_index _was_ created for SNMP. Then it was
used for routing and other stuff. Now you want to use it as a PID
for something else. Fine. But please stop claiming that SNMP is
doing anything wrong with if_indexes when they were created FOR SNMP.
I'm not clamming anything that SNMP is doing wrong, I'm not rewriting
history, I'm just saying that the actual index generation code is broken
for SNMP because it doesn't returns a value between 1 and the number of
interfaces.
Re: more /dev/ugen*
On 13/09/13(Fri) 10:17, David Coppa wrote:
While debugging a problem with pcscd from security/pcsc-lite
06361622 hotplug_libusb.c:514:HPAddHotPluggable() Adding USB device: 3:2:0
0191 hotplug_libusb.c:558:HPAddHotPluggable() libusb_open failed: -4
We (Damien and me) quickly found that the cause was:
16097 pcscdGIO fd 1 wrote 75 bytes
04421857 hotplug_libusb.c:514:HPAddHotPluggable() Adding USB device:
3:2:0
16097 pcscdRET write 75/0x4b
16097 pcscdCALL open(0x74d05fa7bd0,0x2O_RDWR)
16097 pcscdNAMI /dev/ugen2.00
Out of curiosity, can I see the dmesg for this machine? I'd like to
know which devices attach at ugen(4).
16097 pcscdRET open -1 errno 2 No such file or directory
16097 pcscdCALL gettimeofday(0x74d05fa7320,0)
16097 pcscdSTRU struct timeval { 1379032621.501928 }
16097 pcscdRET gettimeofday 0
16097 pcscdCALL write(0x1,0x74cfc0cc000,0x49)
16097 pcscdGIO fd 1 wrote 73 bytes
0157 hotplug_libusb.c:558:HPAddHotPluggable() libusb_open failed:
-4
I think only two /dev/ugen* are too few, what about increasing the
number a bit?
Makes sense to me, it's not too difficult to have more than 2 usb
devices attached as ugen(4) these days, for example a scanner,
a camera and a music player...
Index: MAKEDEV.common
===
RCS file: /cvs/src/etc/MAKEDEV.common,v
retrieving revision 1.70
diff -u -p -u -p -r1.70 MAKEDEV.common
--- MAKEDEV.common5 Sep 2013 06:36:16 - 1.70
+++ MAKEDEV.common13 Sep 2013 08:14:54 -
@@ -183,7 +183,7 @@ target(usb, usb, 0, 1, 2, 3, 4, 5, 6, 7)
target(usb, urio, 0)dnl
target(usb, uhid, 0, 1, 2, 3)dnl
target(usb, ulpt, 0, 1)dnl
-target(usb, ugen, 0, 1)dnl
+target(usb, ugen, 0, 1, 2, 3)dnl
target(usb, ttyU, 0, 1, 2, 3)dnl
dnl
__devitem({-uall-}, uall, All USB devices,usb)dnl
Re: more /dev/ugen*
On Fri, Sep 13, 2013 at 10:57 AM, Martin Pieuchot mpieuc...@nolizard.org wrote: Out of curiosity, can I see the dmesg for this machine? I'd like to know which devices attach at ugen(4). ask djm@ Makes sense to me, it's not too difficult to have more than 2 usb devices attached as ugen(4) these days, for example a scanner, a camera and a music player... exactly...
Re: defer routing table updates on link state changes
On Fri, Sep 13, 2013 at 10:45:57AM +0200, Martin Pieuchot wrote:
No, that's utterly stupid. The interface index is a value that is
supposed to be consistent across the system. How should it be synced
with other userland tools? How would you handle it in if_nametoindex
and friends?
So what do *you* suggest which is not utterly stupid?
I stopped suggesting things that get ignored.
I can't see where it is written that the interface index should be
consistent, from the RFC 1156, I read:
ifIndex { ifEntry 1 }
A unique value for each interface. Its value ranges
between 1 and the value of ifNumber. The value for each
interface must remain constant at least from one re-
initialization of the entity's network management system
to the next re-initialization.
I read your statement and read the RFC text and I totally don't get
how they fit together. Isn't the RFC saying the opposite of what
you're saying? I will get some coffee now and try to read it again
afterwards.
As I said before: it is not a big issue for snmpd and I can live with
the fact that your changes might confuse SNMP clients a bit. Just go
ahead, but
Well it looks like a big issue because you keep complaining.
Would you exclaiming what confusing SNMP clients means? What breaks?
Can it be solved? What is the technical problem here?
Well
In the end we need two different tables, one with an unique index per
interface (to avoid passing pointers in kernel) and another one with
the biggest index equals to the number of interfaces (to not confuse
snmp). IMHO we don't need these two tables in the kernel.
please read the history: if_index _was_ created for SNMP. Then it was
used for routing and other stuff. Now you want to use it as a PID
for something else. Fine. But please stop claiming that SNMP is
doing anything wrong with if_indexes when they were created FOR SNMP.
I'm not clamming anything that SNMP is doing wrong, I'm not rewriting
history, I'm just saying that the actual index generation code is broken
for SNMP because it doesn't returns a value between 1 and the number of
interfaces.
Yes, in theory if_index should be fixed and return a consistent number
between 1 and the number of interfaces. But this is obviously
difficult and I'm not sure if it's worth the effort. So the hack
that you're going to remove was a best effort. But putting another
interface index abstraction layer in userland (via snmpd or some
shared db) is just not the right way to do it. We either have a
reliable if_index from the kernel or we don't. But inventing another
thing in userland doesn't make sense to me.
So let's get back to the technical part:
- Do you even have to use if_index? Is it performance critical or
could you lookup the interface by name?
- I think introducing a new kernel-only if_id for your needs would be
the better approach. Then we could fix if_index to conform to the
definition between 1 and number of interfaces.
- But I can also live with a modified if_index that is unreliable.
What am I suggesting? In this situation: just continue.
Reyk
Re: more /dev/ugen*
On 2013/09/13 10:59, David Coppa wrote: On Fri, Sep 13, 2013 at 10:57 AM, Martin Pieuchot mpieuc...@nolizard.org wrote: Out of curiosity, can I see the dmesg for this machine? I'd like to know which devices attach at ugen(4). ask djm@ Makes sense to me, it's not too difficult to have more than 2 usb devices attached as ugen(4) these days, for example a scanner, a camera and a music player... exactly... Is 4 devices enough? This is typically a problem which is not very well reported to the user in error messages) - other things that might use this include wifi scanner, rtl-sdr, smartcard reader, rocket launcher :), etc.. So maybe 6 or 8 would make more sense?
Re: more /dev/ugen*
On Fri, Sep 13, 2013 at 11:19 AM, Stuart Henderson st...@openbsd.org wrote: On 2013/09/13 10:59, David Coppa wrote: On Fri, Sep 13, 2013 at 10:57 AM, Martin Pieuchot mpieuc...@nolizard.org wrote: Out of curiosity, can I see the dmesg for this machine? I'd like to know which devices attach at ugen(4). ask djm@ Makes sense to me, it's not too difficult to have more than 2 usb devices attached as ugen(4) these days, for example a scanner, a camera and a music player... exactly... Is 4 devices enough? This is typically a problem which is not very well reported to the user in error messages) - other things that might use this include wifi scanner, rtl-sdr, smartcard reader, rocket launcher :), etc.. So maybe 6 or 8 would make more sense? Sure. target(usb, ugen, 0, 1, 2, 3, 4, 5, 6, 7)dnl that's the axe to cut all eventual problems ;)
Re: more /dev/ugen*
On Fri, 13 Sep 2013, Martin Pieuchot wrote: 16097 pcscdNAMI /dev/ugen2.00 Out of curiosity, can I see the dmesg for this machine? I'd like to know which devices attach at ugen(4).s It's a Lenovo x61t. Two devices attach to ugen before I plug anything in, the built-in fingerprint reader (blech) and bluetooth: OpenBSD 5.4-current (GENERIC.MP) #27: Mon Aug 26 21:24:08 EST 2013 d...@mothra.mindrot.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8496283648 (8102MB) avail mem = 8262021120 (7879MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (63 entries) bios0: vendor LENOVO version 7SET36WW (1.22 ) date 11/27/2008 bios0: LENOVO 776773M acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT ECDT TCPA APIC MCFG HPET SLIC BOOT ASF! SSDT SSDT SSDT SSDT acpi0: wakeup devices LID_(S3) SLPB(S3) DURT(S3) IGBE(S4) EXP0(S4) EXP1(S4) EXP2(S4) EXP3(S4) EXP4(S4) PCI1(S4) USB0(S3) USB1(S3) USB2(S3) USB3(S3) USB4(S3) EHC0(S3) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM)2 Duo CPU L7500 @ 1.60GHz, 1795.79 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,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF cpu0: 4MB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 cpu0: apic clock running at 199MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM)2 Duo CPU L7500 @ 1.60GHz, 1596.01 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,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF cpu1: 4MB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 2, remapped to apid 1 acpimcfg0 at acpi0 addr 0xf000, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (AGP_) acpiprt2 at acpi0: bus 2 (EXP0) acpiprt3 at acpi0: bus 3 (EXP1) acpiprt4 at acpi0: bus -1 (EXP2) acpiprt5 at acpi0: bus -1 (EXP3) acpiprt6 at acpi0: bus -1 (EXP4) acpiprt7 at acpi0: bus 5 (PCI1) acpicpu0 at acpi0: C3, C2, C1, PSS acpicpu1 at acpi0: C3, C2, C1, PSS acpipwrres0 at acpi0: PUBS acpitz0 at acpi0: critical temperature is 127 degC acpitz1 at acpi0: critical temperature is 100 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpibat0 at acpi0: BAT0 model 93P5030 serial75 type LION oem SANYO acpibat1 at acpi0: BAT1 not present acpibat2 at acpi0: BAT2 not present acpiac0 at acpi0: AC unit online acpithinkpad0 at acpi0 acpidock0 at acpi0: GDCK not docked (0) cpu0: Enhanced SpeedStep 1795 MHz: speeds: 1601, 1600, 1200, 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 Intel GM965 Host rev 0x0c vga1 at pci0 dev 2 function 0 Intel GM965 Video rev 0x0c intagp0 at vga1 agp0 at intagp0: aperture at 0xe000, size 0x1000 inteldrm0 at vga1 drm0 at inteldrm0 intel_overlay_map_regs partial stub inteldrm0: 1024x768 wsdisplay0 at vga1 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) Intel GM965 Video rev 0x0c at pci0 dev 2 function 1 not configured em0 at pci0 dev 25 function 0 Intel ICH8 IGP M AMT rev 0x03: msi, address 00:16:d3:3e:ba:40 uhci0 at pci0 dev 26 function 0 Intel 82801H USB rev 0x03: apic 1 int 20 uhci1 at pci0 dev 26 function 1 Intel 82801H USB rev 0x03: apic 1 int 21 ehci0 at pci0 dev 26 function 7 Intel 82801H USB rev 0x03: apic 1 int 22 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 azalia0 at pci0 dev 27 function 0 Intel 82801H HD Audio rev 0x03: msi azalia0: codecs: Analog Devices AD1984, Conexant/0x2bfa, using Analog Devices AD1984 audio0 at azalia0 ppb0 at pci0 dev 28 function 0 Intel 82801H PCIE rev 0x03: msi pci1 at ppb0 bus 2 ppb1 at pci0 dev 28 function 1 Intel 82801H PCIE rev 0x03: msi pci2 at ppb1 bus 3 athn0 at pci2 dev 0 function 0 Atheros AR5418 rev 0x01: apic 1 int 17 athn0: MAC AR5418 rev 2, RF AR5133 (2T3R), ROM rev 8, address 00:21:63:2f:e9:e7 uhci2 at pci0 dev 29 function 0 Intel 82801H USB rev 0x03: apic 1 int 16 uhci3 at pci0 dev 29 function 1 Intel 82801H USB rev 0x03: apic 1 int 17 ehci1 at pci0 dev 29 function 7 Intel 82801H USB rev 0x03: apic 1 int 19 usb1 at ehci1: USB revision 2.0 uhub1 at usb1 Intel EHCI root hub rev 2.00/1.00 addr 1 ppb2 at pci0 dev 30 function 0 Intel 82801BAM Hub-to-PCI rev 0xf3 pci3 at ppb2 bus 5 cbb0 at pci3 dev 0 function 0 Ricoh 5C476 CardBus rev 0xba: apic 1 int 16 sdhc0 at pci3 dev 0 function 2 Ricoh 5C822 SD/MMC rev 0x21: apic 1 int 18 sdmmc0 at sdhc0 cardslot0 at cbb0 slot 0 flags 0 cardbus0 at cardslot0: bus 6 device 0 cacheline 0x8, lattimer 0xb0 pcmcia0 at cardslot0 pcib0 at pci0 dev 31 function 0 Intel 82801HEM LPC
Re: more /dev/ugen*
On Fri, Sep 13, 2013 at 4:01 PM, Kirill Bychkov ki...@linklevel.net wrote: On Fri, September 13, 2013 13:19, Stuart Henderson wrote: On 2013/09/13 10:59, David Coppa wrote: On Fri, Sep 13, 2013 at 10:57 AM, Martin Pieuchot mpieuc...@nolizard.org wrote: Out of curiosity, can I see the dmesg for this machine? I'd like to know which devices attach at ugen(4). ask djm@ Makes sense to me, it's not too difficult to have more than 2 usb devices attached as ugen(4) these days, for example a scanner, a camera and a music player... exactly... Is 4 devices enough? This is typically a problem which is not very well reported to the user in error messages) - other things that might use this include wifi scanner, rtl-sdr, smartcard reader, rocket launcher :), etc.. So maybe 6 or 8 would make more sense? Or even UPS ugen0 at uhub1 port 2 American Power Conversion Back-UPS RS 500 FW:30.j5.I USB FW:j5 rev 1.10/0.06 addr 2 8 is a good number. my 2 cents... Indeed. We settled on 8 as of now.
Re: more /dev/ugen*
In general, when we don't have enough of a device, we end up with clonable shit or something don't we ?
Re: Iso image integrity verification
We've all expressed reasonable doubt. In the US you can be assured that the USPS will open, scan, read, and deliver your mail. So it's reasonable to believe that they may also tamper with your openbsd CD's. Just buy the disks, let this thread die along with the stupidity of PCI-DSS (which I've danced the dance with for a great long while). On Fri, Sep 13, 2013 at 9:20 AM, Kenneth R Westerback kwesterb...@rogers.com wrote: On Fri, Sep 13, 2013 at 11:13:36AM +0300, Valentin Zagura wrote: Security itself is not the primary issue here. The issue is to easily prove an assessor without reasonable doubt that you are running the right thing. They will not worry about governments trying to break in with MITM signed ssl or about armies breaking in with the tanks. But they would worry about me not building the image the right way, someone tampering with the image or leaving the door unlocked at the server room. Also, they require people to take responsibility for the thing they do (in this case, CD images). easily prove and without reasonable doubt clash. To say the least. The entire thread has shown that all proposed courses of action, most of which are easy to use rather than easy to implement, do not remove any more reasonable doubt than the current arrangements. Unless one is a professor of metaphysico-theologo-cosmonigology like Dr. Pangloss. Which, I concede, many a security assessor may be. At least as far as reasonable doubt is understood by the OpenBSD community. And what other understanding can we apply? Ken
Re: more /dev/ugen*
Date: Fri, 13 Sep 2013 17:55:17 +0200 From: Marc Espie es...@nerim.net In general, when we don't have enough of a device, we end up with clonable shit or something don't we ? Not really. Cloneable devices are used to create per-open context.
Re: Iso image integrity verification
People, Let me mention my sadness at trying to research this. 1. The PCI-DDS v 2.0 pdf is behind a click through that proports to create a binding legal contract. So the boilerplate looked okay but there was a warning about the document mayhaps being a controlled munition. I was irritated and just gave up. 2. It appears that v 3.0 makes Valetin responsible for Theo. 3. I wonder about what chain of custody means internationally. Anyway I decided the real answer involves consultants. As a political and educational option this is a however a good opportunity to speak to a changing spirit of the time. That would be to buck the current rules and make OBSD plus packages trivial to remotely install on a win xp machine. I think this would be a good opportunity for some of your consultants to do a coordinated construction of site specific sets of packages and then provide newbie support. Blessings, Max On Sep 12, 2013 3:59 PM, Daniel Bolgheroni dan...@bolgh.eng.br wrote: On Thu, Sep 12, 2013 at 07:52:22PM +0300, Valentin Zagura wrote: I thought if we buy the CDs we WILL get a solid evidentuary path from commit to our hands. So this isn't the case? You'll be safe enough.
Re: more /dev/ugen*
On Fri, Sep 13, 2013 at 07:24:27PM +0200, Mark Kettenis wrote: Date: Fri, 13 Sep 2013 17:55:17 +0200 From: Marc Espie es...@nerim.net In general, when we don't have enough of a device, we end up with clonable shit or something don't we ? Not really. Cloneable devices are used to create per-open context. well, it seems to me that having a limit on the number of devices like usb stuff or something is somewhat wasteful. It would probably be nicer if it could adjust automatically (note that I have no idea how much more work this involves besides allocating the structures in the right location... but since usb hot-attaches after boot, I figure most of the work is already there).
Re: Iso image integrity verification
I think you're in trouble. Some of the software on the openbsd CDs was written by me, and I never made any promises it's safe to use on an important server. Not that you should trust me even if I did make such a promise. It's software you're getting from the Internet. Made by people from the Internet. On Fri, Sep 13, 2013 at 11:13, Valentin Zagura wrote: Security itself is not the primary issue here. The issue is to easily prove an assessor without reasonable doubt that you are running the right thing. They will not worry about governments trying to break in with MITM signed ssl or about armies breaking in with the tanks. But they would worry about me not building the image the right way, someone tampering with the image or leaving the door unlocked at the server room. Also, they require people to take responsibility for the thing they do (in this case, CD images). On Fri, Sep 13, 2013 at 1:56 AM, Kenneth R Westerback kwesterb...@rogers.com wrote: On Thu, Sep 12, 2013 at 07:52:22PM +0300, Valentin Zagura wrote: There is no entity that owns or can be held responsible for the code, or is capable of providing a solid evidentuary path from commit to your hands. I thought if we buy the CDs we WILL get a solid evidentuary path from commit to our hands. So this isn't the case? Physical email is as susceptible to MITM attacks as network connections. I know a story of laptops entering the mail system and car springs coming out the other end in the same box. :-) CDs will give you the best evidentuary path available. Compiling everything yourself with a compiler and hardware you built from piles of dirt in a clean room would be better. And then you still have to worry about nano technology being slipped into the dirt. Ken On Wed, Sep 11, 2013 at 1:58 PM, Peter N. M. Hansteen pe...@bsdly.net wrote: On Wed, Sep 11, 2013 at 01:49:14PM +0300, Valentin Zagura wrote: We are going to use a OpenBSD system in a PCI-DSS compliant environment. Is there any way we can prove to our PCI-DSS assessor that the OpenBSD image we use for our installation can be checked so that it is the correct one (is not modified in a malicious way by a third party) ? Probably not what you want to hear, but starting with http://www.openbsd.org/orders.html is usually an excellent idea in this context. Verifiably delivered from a trusted source. A https link to some kind of ISO checksum or something similar (but using strong cryptography) I think would do it, but I could not find any (except a line in the FAQ stating If the men in black suits are out to get you, they're going to get you. which is not the case :) ) It's possible some of the more prominent entries on http://www.openbsd.org/support.html could be persuaded to provide something like that (M:Tier comes to mind, but why are they not on that page?) in exchange for a reasonable fee. But again, for -RELEASE, the CD sets are a good starting point. - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: more /dev/ugen*
Not really. Cloneable devices are used to create per-open context. well, it seems to me that having a limit on the number of devices like usb stuff or something is somewhat wasteful. It would probably be nicer if it could adjust automatically (note that I have no idea how much more work this involves besides allocating the structures in the right location... but since usb hot-attaches after boot, I figure most of the work is already there). I sometimes wonder whether we could not provide a minimalist devfs: something that would union-mount over /dev and provide device nodes with default modes and owners for all currently attached devices, whenever the underlying fs does not provide the expected node. And chown, chgrp and mknod would be passed to the underlying filesystem, so that change in owner, group or permissions would be sticky. It's somewhere in my huge todolist. Volunteers welcome. Miod PS: and remember, the more /dev/ugen nodes, the more people can simultaneously sing ``Hey, Ugen'' in karakoe events.
Re: Iso image integrity verification
Commercial software is the same. They make it clear that no promises are made that the software is fit for any particular purpose in the EULA. My assumption is making such a promise would hold them accountable when it failed, and I doubt any company would find it profitable to invest in enough QA to make that statement. Especially when the closest alternative is for customers to pay for a support contract. Coming from a company that does lots of global credit card transactions (but no OBSD there...yet. :-) ), I have never heard of this validation of install media without reasonable doubt requirement. I've never bothered to read all of the DSS docs, but have skimmed through them. Perhaps it exists in such strict form and I am insulated from others in the company performing these tasks but I get the impression that either this guy is being given an especially hard time or has not realized that Install media is downloaded, or physical media purchased, directly from the vendor is probably good enough to meet the requirement. Install media downloaded from bittorrent or purchased on a street corner is what might raise some red flags... Valentin, If you're actually having to account for MITM, postal, etc. attacks on install media then the company has larger issues to which undeniably-secure install media will provide no additional protection. Stating that you get the install media directly from the vendor should be good enough. On Fri, Sep 13, 2013 at 9:09 PM, Ted Unangst t...@tedunangst.com wrote: I think you're in trouble. Some of the software on the openbsd CDs was written by me, and I never made any promises it's safe to use on an important server. Not that you should trust me even if I did make such a promise. It's software you're getting from the Internet. Made by people from the Internet. On Fri, Sep 13, 2013 at 11:13, Valentin Zagura wrote: Security itself is not the primary issue here. The issue is to easily prove an assessor without reasonable doubt that you are running the right thing. They will not worry about governments trying to break in with MITM signed ssl or about armies breaking in with the tanks. But they would worry about me not building the image the right way, someone tampering with the image or leaving the door unlocked at the server room. Also, they require people to take responsibility for the thing they do (in this case, CD images). On Fri, Sep 13, 2013 at 1:56 AM, Kenneth R Westerback kwesterb...@rogers.com wrote: On Thu, Sep 12, 2013 at 07:52:22PM +0300, Valentin Zagura wrote: There is no entity that owns or can be held responsible for the code, or is capable of providing a solid evidentuary path from commit to your hands. I thought if we buy the CDs we WILL get a solid evidentuary path from commit to our hands. So this isn't the case? Physical email is as susceptible to MITM attacks as network connections. I know a story of laptops entering the mail system and car springs coming out the other end in the same box. :-) CDs will give you the best evidentuary path available. Compiling everything yourself with a compiler and hardware you built from piles of dirt in a clean room would be better. And then you still have to worry about nano technology being slipped into the dirt. Ken On Wed, Sep 11, 2013 at 1:58 PM, Peter N. M. Hansteen pe...@bsdly.net wrote: On Wed, Sep 11, 2013 at 01:49:14PM +0300, Valentin Zagura wrote: We are going to use a OpenBSD system in a PCI-DSS compliant environment. Is there any way we can prove to our PCI-DSS assessor that the OpenBSD image we use for our installation can be checked so that it is the correct one (is not modified in a malicious way by a third party) ? Probably not what you want to hear, but starting with http://www.openbsd.org/orders.html is usually an excellent idea in this context. Verifiably delivered from a trusted source. A https link to some kind of ISO checksum or something similar (but using strong cryptography) I think would do it, but I could not find any (except a line in the FAQ stating If the men in black suits are out to get you, they're going to get you. which is not the case :) ) It's possible some of the more prominent entries on http://www.openbsd.org/support.html could be persuaded to provide something like that (M:Tier comes to mind, but why are they not on that page?) in exchange for a reasonable fee. But again, for -RELEASE, the CD sets are a good starting point. - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673
Re: defer routing table updates on link state changes
Reyk Floeter wrote: Yes, in theory if_index should be fixed and return a consistent number between 1 and the number of interfaces. But this is obviously difficult and I'm not sure if it's worth the effort. So the hack that you're going to remove was a best effort. But putting another interface index abstraction layer in userland (via snmpd or some shared db) is just not the right way to do it. We either have a reliable if_index from the kernel or we don't. But inventing another thing in userland doesn't make sense to me. If above theory doesn't dictate all interfaces must exist (it shouldn't because of hot-plug interfaces), kernel can operate on fixed predefined ifIndex table like this: tun ifIndex (only have 256 of them because of unit_no): 1 - 00:bd:xx:xx:xx:00 - tun0 256 - 00:bd:xx:xx:xx:ff - tun255 vether ifIndex (only have 65536 of them?): 257 - fe:e1:ba:d0:xx:xx - vether0 65,792 - fe:e1:ba:d0:xx:xx - vether65535 physical ifIndex (claim to support ~1M of physical interfaces): 65,793 - 00:25:90:xx:xx:aa - em0 65,794 - 00:25:90:xx:xx:ab - em1 1,179,906 - xx:xx:xx:xx:xx:xx - foo77 trunk ifIndex (claim to support ~17M of trunk interfaces, by unit_no): 1,179,907 - xx:xx:xx:xx:xx:xx - trunk0 19,005,699 - xx:xx:xx:xx:xx:xx - trunk1699 vlan ifIndex (claim to support ~280M of vlan interfaces, by unit_no): 19,005,700 - xx:xx:xx:xx:xx:xx - vlan0 304,218,372 - xx:xx:xx:xx:xx:xx - vlan27999 and so on, up to 2,147,483,647. IMO, cloners aren't so problematic (because of algorithmically controlled enumeration and unit number assignment) as physical interfaces are. I think, the best is to let ifIndexes be assigned to physical interfaces via ifconfig, but let cloners to do their assignments automatically. And do not let snmpd to operate on interface without an ifIndex: having no ifIndex means no interface available.
