Re: Iso image integrity verification
Can the project wire an explosive booby trap inside the CD box to ensure that any sneaky postman is blown away by the awesomeness of openBSD ? (for a decent supplementary fee of course) On Thu, Sep 12, 2013 at 6:56 PM, 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 >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. > > > > > -- - () ascii ribbon campaign - against html e-mail /\
Re: Iso image integrity verification
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: Iso image integrity verification
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 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: defer routing table updates on link state changes
On Thu, Sep 12, 2013 at 06:59:13PM +0200, Mike Belopuhov wrote: > > Ok, let's stop this. I don't think you read what I replied before. I > > didn't say that we're static with if_indexes, just that we shouldn't > > make it worse. > > > > or implement persistent indices in the snmpd itself maybe? > Maybe. But this would create another layer of abstraction. And if_index is not just used by SNMP. > > I give up, but please read my next comment below. > > > >> >> > Isn't there any other way to do what you want without stopping to > >> >> > reuse the index? SNMP simply expects that if_indexes are fairly > >> >> > static, linear, and without holes. Why should we change that in > >> >> > OpenBSD? Is there any security reason to "randomize" the indexes - > >> >> > No. > >> >> > >> >> or snmp can simply stop assuming things. if_index wasn't created > >> >> for snmp in the first place. > > > > Actually, I think this assumption is wrong. I researched a little bit > > in BSD history: > > > > - RFC 1066 from August 1988 is one of the early SNMP RFC that mention > > IfIndex > > > > - 4.3BSD-Tahoe from June 1988 doesn't have if_index, I also didn't find > > in other early BSDs. > > > > - 4.3BSD-Reno from June 1990 does have it. You can even find a > > new comment "/* XXX fast fix for SNMP, going away soon */" on top of > > if.h. > > > > So it seems that if_index was added _for_ SNMP. > > > > i believe this comment refers to the inclusion of sys/time.h. > Yes, I know. But see: 1. 1988-06: 4.3BSD-Tahoe without if_index 2. 1988-08: SNMP 3. 1990-06: 4.3BSD-Reno with if_index, mentioning SNMP in if.h. I don't have the commit history, but this might indicate that there was some work to support SNMP and many new fields in struct ifnet have been added for SNMP. http://minnie.tuhs.org/cgi-bin/utree.pl?file1=4.3BSD-Reno/src/sys/net/if.h&file2=4.3BSD-Tahoe/usr/src/sys/net/if.h&print=1 reyk
Re: defer routing table updates on link state changes
On Thu, Sep 12, 2013 at 10:19 AM, Mike Belopuhov 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. (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.) Philip Guenther ** yes, fixing ptrace() reparenting back to the original is on my todo list.
Re: Iso image integrity verification
On Thu, Sep 12, 2013 at 09:22:51AM -0400, Kenneth R Westerback wrote: > On Thu, Sep 12, 2013 at 10:49:30AM +0200, InterNetX - Robert Garrett wrote: > > The real problem here is that in order to be added to certain lists > > of trusted PKI providers, you must be audited by security Assessors > > one of the things they look for is proof that the software your > > using isnt tampered with. > > > > It appears the OP is trying to solve that issue. EVEN using the CD > > is not enough to convince some of these people that the software is > > genuine and untampered with. > > > > pgp signed sha256 keys in a public accessible place should do it. > > > > Though it would seem to me, that if the sha signature is the same on > > all the mirrors through openbsds distribution channels that would be > > verification enough. As then you would have to break into a lot of > > systems ran by very pedantic, system admins in order to change it on > > all of them. > > > > But let me repeat it isnt the OPS idea of security that is > > important, its the idea of the people they are paying a lot of money > > to, and the rules implemented by such companies as Microsoft that > > are important here. > > And the ideas of the people they are paying a lot of money to are one or > more of > > a) wrong. > b) arbitrary. > c) unknown. > > As you say --- "... should do it.". And how will we know it does > it? Who will the security assessors accept as valid guarantors? > Theo? Bob? Austin? The Foundation? Resellers? Anybody running a > mirror? Some threshold number of developers? 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. > > And the OpenBSD community is not some collective Zelig. Let me post a link to a post by myself from 2007 referring a post by myself from 2002. http://www.mail-archive.com/misc@openbsd.org/msg52819.html These posts already mention the issues Ken is referring to. -Otto
Re: defer routing table updates on link state changes
On Thu, Sep 12, 2013 at 05:53:42PM +0200, Mike Belopuhov wrote: > looks like you misunderstand the problem we're dealing with here. > Sure, I do. You're trying to push one thing and you don't want to hear the concerns about a specific detail of it. > >> FWIW it would be interesting to modify tun(4) so that it doesn't > >> need to detach/reattach itself when switching between mode, this > >> would allow us to stop reusing the last index. > >> > > > > Or you could simply rewrite tun(4)? > > > > Isn't there any other way to do what you want without stopping to > > reuse the index? SNMP simply expects that if_indexes are fairly > > static, linear, and without holes. Why should we change that in > > OpenBSD? Is there any security reason to "randomize" the indexes - > > No. > > > > Reyk > > > > or snmp can simply stop assuming things. if_index wasn't created > for snmp in the first place. Of course, everyone else is wrong, let's change the world! IfIndex is used by SNMP since at least 1988 (RFC 1066) and many many tools have adopted it expecting this behaviour. Anyway, just go ahead and do the stuff. I don't care, it is not a big issue for snmpd. But I still don't see the point of changing the semantics instead of finding another way to do what you want. Unless there is a security issue or similar with if_indexes and changing it would actually improve something. Blah. Reyk
Re: defer routing table updates on link state changes
On 12 September 2013 18:48, Reyk Floeter wrote: > On Thu, Sep 12, 2013 at 06:28:15PM +0200, Mike Belopuhov wrote: >> > Sure, I do. You're trying to push one thing and you don't want to >> > hear the concerns about a specific detail of it. >> > >> >> with all respect, i think you don't. otherwise you wouldn't be asking >> the questions you're asking. >> >> we do hear your concerns, but since even before the change if_index >> was not static at all the way you seem to be implying snmp requires >> it, i don't see a situation drastically changing. if you create all >> the interfaces on startup or before you start snmpd and don't destroy/ >> re-create them nothing is changed. >> > > Ok, let's stop this. I don't think you read what I replied before. I > didn't say that we're static with if_indexes, just that we shouldn't > make it worse. > or implement persistent indices in the snmpd itself maybe? > I give up, but please read my next comment below. > >> >> > Isn't there any other way to do what you want without stopping to >> >> > reuse the index? SNMP simply expects that if_indexes are fairly >> >> > static, linear, and without holes. Why should we change that in >> >> > OpenBSD? Is there any security reason to "randomize" the indexes - >> >> > No. >> >> >> >> or snmp can simply stop assuming things. if_index wasn't created >> >> for snmp in the first place. > > Actually, I think this assumption is wrong. I researched a little bit > in BSD history: > > - RFC 1066 from August 1988 is one of the early SNMP RFC that mention IfIndex > > - 4.3BSD-Tahoe from June 1988 doesn't have if_index, I also didn't find > in other early BSDs. > > - 4.3BSD-Reno from June 1990 does have it. You can even find a > new comment "/* XXX fast fix for SNMP, going away soon */" on top of if.h. > > So it seems that if_index was added _for_ SNMP. > i believe this comment refers to the inclusion of sys/time.h. >> > Of course, everyone else is wrong, let's change the world! IfIndex is >> > used by SNMP since at least 1988 (RFC 1066) and many many tools have >> > adopted it expecting this behaviour. Anyway, just go ahead and do the >> > stuff. I don't care, it is not a big issue for snmpd. But I still >> > don't see the point of changing the semantics instead of finding >> > another way to do what you want. Unless there is a security issue or >> > similar with if_indexes and changing it would actually improve >> > something. Blah. >> >> no need to get upset. mpi's change does improve things. we want to >> make full use of if_index' initial design and use it as a reference >> to the interface in the mp network stack . it has nothing to do with >> a badly designed protocol from the eighties. > > Oh, come on. SNMP is as badly designed as many other things that > we're using every day. sure. > Do you suggest to rm snmpd because the > protocol is badly designed? > no, i don't. i merely suggest that if_index should not be used if persistent ifindex'es are required.
Re: defer routing table updates on link state changes
On 12 September 2013 19:07, Reyk Floeter wrote: > On Thu, Sep 12, 2013 at 06:59:13PM +0200, Mike Belopuhov wrote: >> > Ok, let's stop this. I don't think you read what I replied before. I >> > didn't say that we're static with if_indexes, just that we shouldn't >> > make it worse. >> > >> >> or implement persistent indices in the snmpd itself maybe? >> > > Maybe. But this would create another layer of abstraction. And > if_index is not just used by SNMP. > >> > I give up, but please read my next comment below. >> > >> >> >> > Isn't there any other way to do what you want without stopping to >> >> >> > reuse the index? SNMP simply expects that if_indexes are fairly >> >> >> > static, linear, and without holes. Why should we change that in >> >> >> > OpenBSD? Is there any security reason to "randomize" the indexes - >> >> >> > No. >> >> >> >> >> >> or snmp can simply stop assuming things. if_index wasn't created >> >> >> for snmp in the first place. >> > >> > Actually, I think this assumption is wrong. I researched a little bit >> > in BSD history: >> > >> > - RFC 1066 from August 1988 is one of the early SNMP RFC that mention >> > IfIndex >> > >> > - 4.3BSD-Tahoe from June 1988 doesn't have if_index, I also didn't find >> > in other early BSDs. >> > >> > - 4.3BSD-Reno from June 1990 does have it. You can even find a >> > new comment "/* XXX fast fix for SNMP, going away soon */" on top of >> > if.h. >> > >> > So it seems that if_index was added _for_ SNMP. >> > >> >> i believe this comment refers to the inclusion of sys/time.h. >> > > Yes, I know. But see: > > 1. 1988-06: 4.3BSD-Tahoe without if_index > 2. 1988-08: SNMP > 3. 1990-06: 4.3BSD-Reno with if_index, mentioning SNMP in if.h. > > I don't have the commit history, but this might indicate that there > was some work to support SNMP and many new fields in struct ifnet have > been added for SNMP. > > http://minnie.tuhs.org/cgi-bin/utree.pl?file1=4.3BSD-Reno/src/sys/net/if.h&file2=4.3BSD-Tahoe/usr/src/sys/net/if.h&print=1 > > reyk 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. should we implement additional indices for that or snmp problem will be dealt with? currently if you reuse an index and reuse the memory for the ifnet you may suddenly pick a new interface and perform an operation on it that might not necessarily make sense in the context.
Re: defer routing table updates on link state changes
* Mike Belopuhov [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 -let snmpd (or sth else) make up ifindices just for that purpose -- 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 12 September 2013 18:14, Reyk Floeter wrote: > On Thu, Sep 12, 2013 at 05:53:42PM +0200, Mike Belopuhov wrote: >> looks like you misunderstand the problem we're dealing with here. >> > > Sure, I do. You're trying to push one thing and you don't want to > hear the concerns about a specific detail of it. > with all respect, i think you don't. otherwise you wouldn't be asking the questions you're asking. we do hear your concerns, but since even before the change if_index was not static at all the way you seem to be implying snmp requires it, i don't see a situation drastically changing. if you create all the interfaces on startup or before you start snmpd and don't destroy/ re-create them nothing is changed. >> >> FWIW it would be interesting to modify tun(4) so that it doesn't >> >> need to detach/reattach itself when switching between mode, this >> >> would allow us to stop reusing the last index. >> >> >> > >> > Or you could simply rewrite tun(4)? >> > >> > Isn't there any other way to do what you want without stopping to >> > reuse the index? SNMP simply expects that if_indexes are fairly >> > static, linear, and without holes. Why should we change that in >> > OpenBSD? Is there any security reason to "randomize" the indexes - >> > No. >> > >> > Reyk >> > >> >> or snmp can simply stop assuming things. if_index wasn't created >> for snmp in the first place. > > Of course, everyone else is wrong, let's change the world! IfIndex is > used by SNMP since at least 1988 (RFC 1066) and many many tools have > adopted it expecting this behaviour. Anyway, just go ahead and do the > stuff. I don't care, it is not a big issue for snmpd. But I still > don't see the point of changing the semantics instead of finding > another way to do what you want. Unless there is a security issue or > similar with if_indexes and changing it would actually improve > something. Blah. > > Reyk no need to get upset. mpi's change does improve things. we want to make full use of if_index' initial design and use it as a reference to the interface in the mp network stack . it has nothing to do with a badly designed protocol from the eighties.
Re: Iso image integrity verification
> 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? On Wed, Sep 11, 2013 at 1:58 PM, Peter N. M. Hansteen 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: defer routing table updates on link state changes
On Thu, Sep 12, 2013 at 06:28:15PM +0200, Mike Belopuhov wrote: > > Sure, I do. You're trying to push one thing and you don't want to > > hear the concerns about a specific detail of it. > > > > with all respect, i think you don't. otherwise you wouldn't be asking > the questions you're asking. > > we do hear your concerns, but since even before the change if_index > was not static at all the way you seem to be implying snmp requires > it, i don't see a situation drastically changing. if you create all > the interfaces on startup or before you start snmpd and don't destroy/ > re-create them nothing is changed. > Ok, let's stop this. I don't think you read what I replied before. I didn't say that we're static with if_indexes, just that we shouldn't make it worse. I give up, but please read my next comment below. > >> > Isn't there any other way to do what you want without stopping to > >> > reuse the index? SNMP simply expects that if_indexes are fairly > >> > static, linear, and without holes. Why should we change that in > >> > OpenBSD? Is there any security reason to "randomize" the indexes - > >> > No. > >> > >> or snmp can simply stop assuming things. if_index wasn't created > >> for snmp in the first place. Actually, I think this assumption is wrong. I researched a little bit in BSD history: - RFC 1066 from August 1988 is one of the early SNMP RFC that mention IfIndex - 4.3BSD-Tahoe from June 1988 doesn't have if_index, I also didn't find in other early BSDs. - 4.3BSD-Reno from June 1990 does have it. You can even find a new comment "/* XXX fast fix for SNMP, going away soon */" on top of if.h. So it seems that if_index was added _for_ SNMP. > > Of course, everyone else is wrong, let's change the world! IfIndex is > > used by SNMP since at least 1988 (RFC 1066) and many many tools have > > adopted it expecting this behaviour. Anyway, just go ahead and do the > > stuff. I don't care, it is not a big issue for snmpd. But I still > > don't see the point of changing the semantics instead of finding > > another way to do what you want. Unless there is a security issue or > > similar with if_indexes and changing it would actually improve > > something. Blah. > > no need to get upset. mpi's change does improve things. we want to > make full use of if_index' initial design and use it as a reference > to the interface in the mp network stack . it has nothing to do with > a badly designed protocol from the eighties. Oh, come on. SNMP is as badly designed as many other things that we're using every day. Do you suggest to rm snmpd because the protocol is badly designed? Reyk
Re: defer routing table updates on link state changes
On 12 September 2013 18:28, Mike Belopuhov wrote: > On 12 September 2013 18:14, Reyk Floeter wrote: >> On Thu, Sep 12, 2013 at 05:53:42PM +0200, Mike Belopuhov wrote: >>> looks like you misunderstand the problem we're dealing with here. >>> >> >> Sure, I do. You're trying to push one thing and you don't want to >> hear the concerns about a specific detail of it. >> > > with all respect, i think you don't. otherwise you wouldn't be asking > the questions you're asking. > > we do hear your concerns, but since even before the change if_index > was not static at all the way you seem to be implying snmp requires > it, i don't see a situation drastically changing. if you create all > the interfaces on startup or before you start snmpd and don't destroy/ > re-create them nothing is changed. > perhaps truly persistent snmp ifindexes could be implemented in the snmpd itself via a new configuration option, i.e. "interface vlan1 index 1". you don't necessarily have to use the same ones system is using for it's own purposes.
Re: defer routing table updates on link state changes
On Thu, Sep 12, 2013 at 07:19:34PM +0200, Mike Belopuhov 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. > should we implement additional indices for that or snmp problem will > be dealt with? currently if you reuse an index and reuse the memory > for the ifnet you may suddenly pick a new interface and perform an > operation on it that might not necessarily make sense in the context. You should check all cloners and make sure that they don't have to be recreated for any of the options. tun(4) should be updated. I did it for vlan(4)/svlan(4) with rev 1.86 + 1.87 in 2011. Are there any others left? As an alternative to reusing if_index, it would even be nice to be able to completely reset the configuration of any interface without recreating it - even for physical interfaces like WLAN or Ethernet. This allows you to start over with the interface configuration without loosing its if_index or reference. Reyk
Re: defer routing table updates on link state changes
On 12 September 2013 17:31, Reyk Floeter wrote: > On Thu, Sep 12, 2013 at 05:18:39PM +0200, Martin Pieuchot wrote: >> > For example, you have to query the IfIndex via SNMP to get further >> > information, like the ifName or statistics, and most monitoring >> > systems would save interface information based on the index - they >> > would not recognize that tun0 with if_index 10 is the same interface >> > (from an OpenBSD point of view) as tun0 with an if_index 11. It is >> > not guaranteed in OpenBSD, but we shouldn't make it worse. >> >> All our interface drivers are associated to one index when they are >> attached and it does not change. >> >> The only thing is that tun(4) is special because internally when it >> switches from L3 to L2 or vice versa it detaches and reattaches itself. >> That's why this hack of reusing the last index is needed. >> > > It also matters if you create destroy and re-create any other cloner > interface (vlan, ...). > 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. >> But if I understand correctly what you're saying about querying the >> IfIndex, I find it even more dangerous to reuse the last index, >> because I can create a configuration where I change an interface >> while keeping the same index (with usb interfaces for example). >> > > I think that's nonsense. > looks like you misunderstand the problem we're dealing with here. >> FWIW it would be interesting to modify tun(4) so that it doesn't >> need to detach/reattach itself when switching between mode, this >> would allow us to stop reusing the last index. >> > > Or you could simply rewrite tun(4)? > > Isn't there any other way to do what you want without stopping to > reuse the index? SNMP simply expects that if_indexes are fairly > static, linear, and without holes. Why should we change that in > OpenBSD? Is there any security reason to "randomize" the indexes - > No. > > Reyk > or snmp can simply stop assuming things. if_index wasn't created for snmp in the first place.
Re: defer routing table updates on link state changes
On 12/09/13(Thu) 16:40, Reyk Floeter wrote: > On Thu, Sep 12, 2013 at 06:51:46AM +0200, Claudio Jeker wrote: > > On Tue, Aug 27, 2013 at 01:39:14PM +0200, Martin Pieuchot wrote: > > > I think that's the right approach but the current code generating > > > interfaces indexes is too clever from my point of view, it tries > > > to reuse the last index if possible. This could lead to some > > > funny races if we detach and reattach an interface before the > > > task get scheduled. > > > > > > So I'm ok with your diff if we avoid to reuse the last index too > > > soon. Diff below does that. > > > > We should not do that since this was done for tun(4) switching between > > modes without getting new ifindexes. It also reduces the holes in the > > ifindex array on system that dynamically allocate interfaces for e.g. > > VPNs. > > > > Claudio is right. > > The if_indexes are excessively used by the SNMP MIBs for various > interface-related values. I'm not just talking about the > implementation in snmpd(8), I'm talking about the actual standard MIBs > that use "ifIndex" values everywhere. Having dynamic / random / > inconsistent if_indexes confuse SNMP a lot. I'm not sure to understand. What do you mean by dynamic / random / inconsistent if_indexes? > For example, you have to query the IfIndex via SNMP to get further > information, like the ifName or statistics, and most monitoring > systems would save interface information based on the index - they > would not recognize that tun0 with if_index 10 is the same interface > (from an OpenBSD point of view) as tun0 with an if_index 11. It is > not guaranteed in OpenBSD, but we shouldn't make it worse. All our interface drivers are associated to one index when they are attached and it does not change. The only thing is that tun(4) is special because internally when it switches from L3 to L2 or vice versa it detaches and reattaches itself. That's why this hack of reusing the last index is needed. But if I understand correctly what you're saying about querying the IfIndex, I find it even more dangerous to reuse the last index, because I can create a configuration where I change an interface while keeping the same index (with usb interfaces for example). FWIW it would be interesting to modify tun(4) so that it doesn't need to detach/reattach itself when switching between mode, this would allow us to stop reusing the last index. Martin
Re: defer routing table updates on link state changes
On 12 September 2013 17:18, Martin Pieuchot wrote: > FWIW it would be interesting to modify tun(4) so that it doesn't > need to detach/reattach itself when switching between mode, this > would allow us to stop reusing the last index. > this definitely makes a lot of sense.
Re: defer routing table updates on link state changes
On Thu, Sep 12, 2013 at 05:18:39PM +0200, Martin Pieuchot wrote: > > For example, you have to query the IfIndex via SNMP to get further > > information, like the ifName or statistics, and most monitoring > > systems would save interface information based on the index - they > > would not recognize that tun0 with if_index 10 is the same interface > > (from an OpenBSD point of view) as tun0 with an if_index 11. It is > > not guaranteed in OpenBSD, but we shouldn't make it worse. > > All our interface drivers are associated to one index when they are > attached and it does not change. > > The only thing is that tun(4) is special because internally when it > switches from L3 to L2 or vice versa it detaches and reattaches itself. > That's why this hack of reusing the last index is needed. > It also matters if you create destroy and re-create any other cloner interface (vlan, ...). > But if I understand correctly what you're saying about querying the > IfIndex, I find it even more dangerous to reuse the last index, > because I can create a configuration where I change an interface > while keeping the same index (with usb interfaces for example). > I think that's nonsense. > FWIW it would be interesting to modify tun(4) so that it doesn't > need to detach/reattach itself when switching between mode, this > would allow us to stop reusing the last index. > Or you could simply rewrite tun(4)? Isn't there any other way to do what you want without stopping to reuse the index? SNMP simply expects that if_indexes are fairly static, linear, and without holes. Why should we change that in OpenBSD? Is there any security reason to "randomize" the indexes - No. Reyk
Re: defer routing table updates on link state changes
On Thu, Sep 12, 2013 at 06:51:46AM +0200, Claudio Jeker wrote: > On Tue, Aug 27, 2013 at 01:39:14PM +0200, Martin Pieuchot wrote: > > I think that's the right approach but the current code generating > > interfaces indexes is too clever from my point of view, it tries > > to reuse the last index if possible. This could lead to some > > funny races if we detach and reattach an interface before the > > task get scheduled. > > > > So I'm ok with your diff if we avoid to reuse the last index too > > soon. Diff below does that. > > We should not do that since this was done for tun(4) switching between > modes without getting new ifindexes. It also reduces the holes in the > ifindex array on system that dynamically allocate interfaces for e.g. > VPNs. > Claudio is right. The if_indexes are excessively used by the SNMP MIBs for various interface-related values. I'm not just talking about the implementation in snmpd(8), I'm talking about the actual standard MIBs that use "ifIndex" values everywhere. Having dynamic / random / inconsistent if_indexes confuse SNMP a lot. For example, you have to query the IfIndex via SNMP to get further information, like the ifName or statistics, and most monitoring systems would save interface information based on the index - they would not recognize that tun0 with if_index 10 is the same interface (from an OpenBSD point of view) as tun0 with an if_index 11. It is not guaranteed in OpenBSD, but we shouldn't make it worse. btw., just have a look on a system with net-snmpd's MIBs. On a Mac, which ships with Apple's version of net-snmp by default, go to /usr/share/snmp/mibs and run: $ grep -i ifindex * | wc -l 162 Reyk
Re: Iso image integrity verification
On Thu, Sep 12, 2013 at 10:49:30AM +0200, InterNetX - Robert Garrett wrote: > The real problem here is that in order to be added to certain lists > of trusted PKI providers, you must be audited by security Assessors > one of the things they look for is proof that the software your > using isnt tampered with. > > It appears the OP is trying to solve that issue. EVEN using the CD > is not enough to convince some of these people that the software is > genuine and untampered with. > > pgp signed sha256 keys in a public accessible place should do it. > > Though it would seem to me, that if the sha signature is the same on > all the mirrors through openbsds distribution channels that would be > verification enough. As then you would have to break into a lot of > systems ran by very pedantic, system admins in order to change it on > all of them. > > But let me repeat it isnt the OPS idea of security that is > important, its the idea of the people they are paying a lot of money > to, and the rules implemented by such companies as Microsoft that > are important here. And the ideas of the people they are paying a lot of money to are one or more of a) wrong. b) arbitrary. c) unknown. As you say --- "... should do it.". And how will we know it does it? Who will the security assessors accept as valid guarantors? Theo? Bob? Austin? The Foundation? Resellers? Anybody running a mirror? Some threshold number of developers? 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. And the OpenBSD community is not some collective Zelig. Ken > > RG > > On 09/11/2013 10:10 PM, Valentin Zagura wrote: > >I was saying that other projects do it in a way they feel comfortable with > >and maybe you will find a way to do it that you are comfortable with. > >Using https was one simple idea. I understand that you don't think that > >this adds any value but maybe there are other ways like signing with PGP, > >maybe using SSH somehow or having Theo de Raadt saying the SHA checksums on > >a video on youtube at each release :) or some other simple and effective > >way that you are comfortable with. > >I just wanted to point out that one can not easely show his security > >assessor that it has the right images using some "industry standard" ways, > >or someone living in a country that has an oppressive government and would > >download the image through tor could have some problems if the exit node is > >malicious. > >If you feel that any kind of verification is futile, it's ok, that would > >not stop us from buying the CDs. > > > > > >On Wed, Sep 11, 2013 at 10:32 PM, Kenneth R Westerback < > >kwesterb...@rogers.com> wrote: > > > >>On Wed, Sep 11, 2013 at 08:53:50PM +0300, Valentin Zagura wrote: > >>>I don't think I'm more paranoid than the average considering that Debian > >>>has a way to do this (http://www.debian.org/CD/verify), fedora has a > >>way to > >>>do this (https://fedoraproject.org/verify), even Freebsd has a way to do > >>>this ( https://www.freebsd.org/releases/9.1R/announce.html). > >> > >>So you're saying that less paranoid projects are doing it, so why doesn't > >>OpenBSD join the crowd and provide some fuzzy feel good but pointless > >>security theatre? :-) > >> > >>> > >>>The thought of being more paranoid than an OpenBSD guy is not very > >>>comfortable :) > >> > >>Don't worry. You're apparently not paranoid enough yet. The true practical > >>paranoid does not waste time on such mummery. > >> > >> Ken > >> > >>> > >>> > >>>On Wed, Sep 11, 2013 at 8:13 PM, Daniel Bolgheroni >>>wrote: > >>> > On Wed, Sep 11, 2013 at 03:17:20PM +0300, Valentin Zagura wrote: > >Yes, we know, but that file can also be easily compromised if it's > >>not > >available for download with a secure protocol (HTTPS) > > If you're paranoid, build your own hardware from the ground up, > including designing your own CPU and complementary circuits, download > all the sources, audit them all, compile and then run. > > You can't be fooled by wrong measurements of security. > > >> > > >
Re: Typo in nfs_boot.c
On Thu, Sep 12, 2013 at 1:33 PM, Eivind Evensen wrote: > Hello. > > Trying to figure out what I've done wrong to have a diskless setup > boot the kernel and then try to talk to a broadcast address rather than > the nfsserver, I saw this typo. > > Eivind > > > Index: sys/nfs/nfs_boot.c > === > RCS file: /cvs/src/sys/nfs/nfs_boot.c,v > retrieving revision 1.27 > diff -u -u -p -r1.27 nfs_boot.c > --- sys/nfs/nfs_boot.c 22 May 2013 09:13:36 - 1.27 > +++ sys/nfs/nfs_boot.c 12 Sep 2013 11:14:07 - > @@ -196,7 +196,7 @@ nfs_boot_init(struct nfs_diskless *nd, s > * Use the old broadcast address for the WHOAMI > * call because we do not yet know our netmask. > * The server address returned by the WHOAMI call > -* is used for all subsequent booptaram RPCs. > +* is used for all subsequent bootparam RPCs. > */ > bzero((caddr_t)&bp_sin, sizeof(bp_sin)); > bp_sin.sin_len = sizeof(bp_sin); > Thanks. jmc?
Typo in nfs_boot.c
Hello. Trying to figure out what I've done wrong to have a diskless setup boot the kernel and then try to talk to a broadcast address rather than the nfsserver, I saw this typo. Eivind Index: sys/nfs/nfs_boot.c === RCS file: /cvs/src/sys/nfs/nfs_boot.c,v retrieving revision 1.27 diff -u -u -p -r1.27 nfs_boot.c --- sys/nfs/nfs_boot.c 22 May 2013 09:13:36 - 1.27 +++ sys/nfs/nfs_boot.c 12 Sep 2013 11:14:07 - @@ -196,7 +196,7 @@ nfs_boot_init(struct nfs_diskless *nd, s * Use the old broadcast address for the WHOAMI * call because we do not yet know our netmask. * The server address returned by the WHOAMI call -* is used for all subsequent booptaram RPCs. +* is used for all subsequent bootparam RPCs. */ bzero((caddr_t)&bp_sin, sizeof(bp_sin)); bp_sin.sin_len = sizeof(bp_sin);
Re: osfp pfctl and states
On Thu, Sep 12, 2013 at 2:50 AM, Henning Brauer wrote: > * sven falempin [2013-09-11 22:30]: > > At his point <> is available. > > Lets assume pf_state got a "struct pf_osfp_enlist l_osfp" > > To get back the info from userland, doing > > > > Would a diff like this hurts ?? > > everything that grows the state hurts (last not least hurts > performance), so it has to be truly worth it. > I don't see that in this case. > > What about a separate system then ? Like logging the fp and the source IP from pf_osfp_fingerprint_hdr ? Or do someone have something else in mind to reach the goal ?
Re: Iso image integrity verification
The real problem here is that in order to be added to certain lists of trusted PKI providers, you must be audited by security Assessors one of the things they look for is proof that the software your using isnt tampered with. It appears the OP is trying to solve that issue. EVEN using the CD is not enough to convince some of these people that the software is genuine and untampered with. pgp signed sha256 keys in a public accessible place should do it. Though it would seem to me, that if the sha signature is the same on all the mirrors through openbsds distribution channels that would be verification enough. As then you would have to break into a lot of systems ran by very pedantic, system admins in order to change it on all of them. But let me repeat it isnt the OPS idea of security that is important, its the idea of the people they are paying a lot of money to, and the rules implemented by such companies as Microsoft that are important here. RG On 09/11/2013 10:10 PM, Valentin Zagura wrote: I was saying that other projects do it in a way they feel comfortable with and maybe you will find a way to do it that you are comfortable with. Using https was one simple idea. I understand that you don't think that this adds any value but maybe there are other ways like signing with PGP, maybe using SSH somehow or having Theo de Raadt saying the SHA checksums on a video on youtube at each release :) or some other simple and effective way that you are comfortable with. I just wanted to point out that one can not easely show his security assessor that it has the right images using some "industry standard" ways, or someone living in a country that has an oppressive government and would download the image through tor could have some problems if the exit node is malicious. If you feel that any kind of verification is futile, it's ok, that would not stop us from buying the CDs. On Wed, Sep 11, 2013 at 10:32 PM, Kenneth R Westerback < kwesterb...@rogers.com> wrote: On Wed, Sep 11, 2013 at 08:53:50PM +0300, Valentin Zagura wrote: I don't think I'm more paranoid than the average considering that Debian has a way to do this (http://www.debian.org/CD/verify), fedora has a way to do this (https://fedoraproject.org/verify), even Freebsd has a way to do this ( https://www.freebsd.org/releases/9.1R/announce.html). So you're saying that less paranoid projects are doing it, so why doesn't OpenBSD join the crowd and provide some fuzzy feel good but pointless security theatre? :-) The thought of being more paranoid than an OpenBSD guy is not very comfortable :) Don't worry. You're apparently not paranoid enough yet. The true practical paranoid does not waste time on such mummery. Ken On Wed, Sep 11, 2013 at 8:13 PM, Daniel Bolgheroni On Wed, Sep 11, 2013 at 03:17:20PM +0300, Valentin Zagura wrote: Yes, we know, but that file can also be easily compromised if it's not available for download with a secure protocol (HTTPS) If you're paranoid, build your own hardware from the ground up, including designing your own CPU and complementary circuits, download all the sources, audit them all, compile and then run. You can't be fooled by wrong measurements of security.
