Re: Code signing in OpenBSD
2007/12/5, Marco Peereboom [EMAIL PROTECTED]: have you ever wondered why openbsd doesn't do binary updates? And what are package updates? Does pkg_add -u even check an e.g. md5 or does it trust the server? Best Martin
Re: hoststated - some questions
[sent to wrong list] Also hoststatectl reload does not work for me. [EMAIL PROTECTED] root# hoststatectl reload command failed Expected behavior? Unfortunately, yes. reload currently does not work for layer7 (relay) configurations. it should be available before 4.3 though.
Re: Code signing in OpenBSD
On Thu, Dec 06, 2007 at 12:37:19PM +0800, Lars Hansson wrote: On Dec 6, 2007 2:46 AM, Rui Miguel Silva Seabra [EMAIL PROTECTED] wrote: Come on... twice a year and get the benefit of not being excluded from company policies which require digital signature of software downloaded through the internet. It's not really OpenBSD's problem that some companies implement pointless security policies. I'm not discussing wether its pointless or not, maybe you don't want OpenBSD to be used at all? Rui -- Grudnuk demand sustenance! Today is Setting Orange, the 48th day of The Aftermath in the YOLD 3173 + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...?
Re: Code signing in OpenBSD
On Wed, Dec 05, 2007 at 02:23:41PM -0600, Marco Peereboom wrote: blah blah blah have you ever wondered why openbsd doesn't do binary updates? I'm not talking about updates, I can read C. maybe you are now going to be able to figure out why we don't need complex signing mechanisms. You're ignoring that it is perhaps quite insane to expect anyone to verify every single line of code, and a (so far very much deserved) trust is given to the developers. Which is why I would very much like to be absolutely sure the CD I bought brought the release the developers intended to publish. This is not about downloading OpenBSD, but of having a quite measurable degree of trust that what you have is what you were supposed to have. Btw, it would be much better to use a hashing algorithm stronger than MD5, even on the file signed by an OpenPGP or X.509 certificate. Rui -- Wibble. Today is Setting Orange, the 48th day of The Aftermath in the YOLD 3173 + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...?
Re: Code signing in OpenBSD
Hi! On Wed, Dec 05, 2007 at 12:15:01PM -0500, bofh wrote: On Dec 5, 2007 11:46 AM, new_guy [EMAIL PROTECTED] wrote: Can you dismiss PKI and the benefits that OpenPGP signatures provide to your user community? Knowing that xyz binary is signed by OpenBSD for distribution or abc email came from an official OpenBSD source is a good thing. Trojaned binaries and forged emails happen. PKI can help mitigate this. The benefit of PKI is widely known and accepted and does not need to be rehashed here. I'm surprised that OpenBSD (the most secure OS I know of) does not use it, that's all I'm saying. I also thought there would be a real reason for not doing so and there may in fact be and I may just be unaware of it. What are the risks you are trying to address? One risk would be the plans of online surveillance of computers e.g. in Germany. One way to install surveillance even on OpenBSD would be to actively interfere with the internet connection with the surveilled person, in the man-in-the-middle sense, and inject trojanned code (Bundestrojaner) into the updates of the victim. Using OpenBSD CDs doesn't protect the victim from attacks like that that much because many people need ports/packages and to get fixes one virtually has to use -current most of the time, and to update -current, one often uses snapshots over non-secured transfers (ftp, rsync, source via cvsync/cvsup). The only exception I know of is anoncvs via ssh, but then, the CDs, IIRC, don't even ship with a known_hosts file for the anoncvs servers. As the talk about those online surveillance plans includes talk about tailored attacks for each victim, they could investigate which OS one uses and which ways of updating, so they could tailor their attack vector appropriately. Yes, *I*'d be vulnerable. I'd be not if I had a public key (and anoncvs known_hosts file) from CD, perhaps also cvsync with cryprographic integrity protection and public key (fingerprints) from CD, etc. So the online surveillance stuff would perhaps not only affect Windoze boxen as some people would come to think, even though the installation of a trojan is, of course, usually much easier for Windoze than for OpenBSD (or even a Linux installation if people with some skills operate them). Yes, of course cryptographic integrity protection wouldn't secure OpenBSD against all kinds of attack vectors, but against *some*. Yes, it comes at a cost. And I don't know whether the cost is really worth while... But I question whether it's really sound to just dismiss it beforehand. [...] Kind regards, Hannah.
Re: Code signing in OpenBSD
Hi! On Wed, Dec 05, 2007 at 01:24:49PM -0700, Bob Beck wrote: If you want a secure binary. buy an official CD.. This is what most people do. PKI requires infrastructure that would cost OpenBSD money and developer time. Official CD's keep OpenBSD alive. Doesn't help you if you want fixes for ports/packages or even the base OS. Once you want that, you have to update over the net, and as I said in my other mail, here you have no clear protection. Or do the CDs at least carry a known_hosts file for the anoncvs servers, inbetween? [...] Kind regards, Hannah.
Re: Code signing in OpenBSD
Hi! On Wed, Dec 05, 2007 at 06:46:15PM -0500, STeve Andre' wrote: [...] You know, you're descending into a recursive loop of if, if, if... and it never ends. OF COURSE if someone breaks into the site they could do things--once you've lost control of your site all bets are off. I dare say that someone breaking into a site might find all the appropriate tools to re-sign things, too, and do the spoof that way. If I released code with cryptographic signatures, I'd not leave a secret key file, nor a passphrase on the servers with the master web/ftp site. I'd sign on a box you can't access from the master site (nor the mirrors). So, no, the attacker would *not* gain access to signing tools (ok, yes, the tools, perhaps, like gpg or openssl, but not the key material). --STeve Andre' Kind regards, Hannah.
Re: Code signing in OpenBSD
Hannah Schroeter wrote: ... As the talk about those online surveillance plans includes talk about tailored attacks for each victim, they could investigate which OS one uses and which ways of updating, so they could tailor their attack vector appropriately. ... Some of this is mitigated in that when using OpenBSD, the connections to the repositories is signed. Though, it looks like HTTP transfers are not, and there is the question of getting the initial installation packages. If the installation process (from the purchased CDs) had a list of the public keys for the official mirror sites, then that would go a long way. Having the installation process pre-load the keys into the data for the ssh, ftp and afs clients would be even fancier. -Lars
Re: Code signing in OpenBSD
On 2007/12/06 13:12, Lars Noodin wrote: If the installation process (from the purchased CDs) had a list of the public keys for the official mirror sites, then that would go a long way. That would make it rather hard to revoke a key if there ever was a problem.
Re: Code signing in OpenBSD
Hi! On Thu, Dec 06, 2007 at 11:23:37AM +, Stuart Henderson wrote: On 2007/12/06 13:12, Lars Noodin wrote: If the installation process (from the purchased CDs) had a list of the public keys for the official mirror sites, then that would go a long way. That would make it rather hard to revoke a key if there ever was a problem. Key revocation lists in some form? If it's gpg/OpenPGP, instruct users to update from keyservers, one will notice when there're incompatibilities between the key from CD and the one from the keyserver, but one will also get the revocation from the keyserver. And if one buys every CD, there's the time window of half a year even without a key revocation infrastructure. Kind regards, Hannah.
Re: Code signing in OpenBSD
Hi! On Thu, Dec 06, 2007 at 01:12:02PM +0200, Lars Noodin wrote: Hannah Schroeter wrote: ... As the talk about those online surveillance plans includes talk about tailored attacks for each victim, they could investigate which OS one uses and which ways of updating, so they could tailor their attack vector appropriately. ... Some of this is mitigated in that when using OpenBSD, the connections to the repositories is signed. Though, it looks like HTTP transfers are not, and there is the question of getting the initial installation packages. Have I missed something? Last time I checked, it was plain http/ftp for retrieving the base tarballs as well as the packages. [...] Kind regards, Hannah.
Re: /var/log/messages permissions in 4.2
Douglas A. Tutty wrote: On Tue, Dec 04, 2007 at 02:30:28PM -0800, Bryan Irvine wrote: What would be the rationale for 640? ;) Well according to cvs log: it can be easily changed if you like it another way. millert, So I guess one rationale might be as simple as because ;) Does anything get posted to the log that a normal user should not see? I suppose it depends on the machine's context. Can traffic analysis on the log be used to determine what another user is doing any more than watching top? If you're concerned about normal users reading logs, you need to look at those logs and determine why you are concerned and determine the implcations of those concerns. Doug. The other question: Does the stuff there need to be seen so often that administrative users might be tempted to do a sudo -s over sudo more ..., and then do something stupid that would have been a non-event if they weren't root? Difficult to maintain does NOT equal secure. Difficult to maintain usually means improperly maintained, and that usually means insecure. IF you are producing messages output that the general users should NOT be seeing, go ahead, change the access permissions! If you look at the number of systems that either have 1) only administrative users or 2) have nothing secret going to /var/log/messages you have probably covered the vast majority of OpenBSD systems. So, I don't want to see the vast majority of systems made more difficult to administer and perhaps prompting the user to live as root more than needed. Glancing through the /var/log/messages files on a few of my machines, I found nothing I wouldn't be more than happy to post to the Internet, other than the rather anemic specs might be a bit embarrassing, but I found that I was glad I didn't have to have root privs to look at them. Nick.
Open BSD Physical Storage
Hi, Currently I am facing a small problem in OpenBSD. I want to get the information about the total physical Storage and the partition table (mounted and unmounted). Please let me know if there is any way out for getting this information. -- View this message in context: http://www.nabble.com/Open-BSD-Physical-Storage-tf4956022.html#a14192231 Sent from the openbsd user - misc mailing list archive at Nabble.com.
PF and queuing question
hey,
I have a question on how to best limit traffic with pf. The main
goal is not so much to limit bandwidth to a lower point all the
time but more to prevent a runaway process (or user) from
drowning the rest.
Since i do not have the means for extensive testing i hope to
get some pointers before going down a path that would only waste
time and resources. I have the following situation (simplified):
/-vlan1 ==1Gb== desktops
internet ==512Kb==bge0 PF
\-vlan2 ==1Gb== production
I want to make sure production has at least 256Kb both upload as
download on the internet connection.
1) I know it will not stop flooding of the line by 3rd parties. This is
not the goal
of the rules. The goal is to prevent a download initiated by a server or
user
from taking up all the download bandwidth
2) I was thinking of using a shared queue on vlan1 and vlan2 but I could
not find
any documentation whether that is possible at all.
Would the following work and actually limit download traffic? If not
then I guess
I will have to create separate download queues of max 400Kb so ensure at
least
some bandwidth remains for the other side.
altq on bge0 cbq bandwidth 512Kb queue { ext-prod, ext-desktop }
altq on vlan1 cbq bandwidth 1Gb queue { download, default-desktop }
altq on vlan2 cbq bandwidth 1Gb queue { download, default-prod }
queue download bandwidth 512Kb { download_prod, download_desktop }
queue download_prod bandwidth 50% priority 3 cbq(borrow)
queue download_desktop bandwidth 50% priority 1 cbq(borrow)
pass in quick on bge0 from any to production keep state queue
download_prod
pass out quick on vlan2 from any to production keep state queue ext-prod
pass in quick on vlan2 from production to any keep state queue ext-prod
pass out quick on vlan2 from production to any keep state queue
download_prod
pass in quick on bge0 from any to desktop keep state queue
download_desktop
pass out quick on vlan2 from any to desktop keep state queue ext-desktop
pass in quick on vlan2 from desktop to any keep state queue ext-desktop
pass out quick on vlan2 from desktop to any keep state queue
download_desktop
Is this idea going in the right direction or is there a much better way
to do this?
Thanks,
Stefan
Re: Open BSD Physical Storage
Hi! On Thu, Dec 06, 2007 at 05:21:08AM -0800, Shachi Rai wrote: Currently I am facing a small problem in OpenBSD. I want to get the information about the total physical Storage and the partition table (mounted and unmounted). Please let me know if there is any way out for getting this information. I don't exactly understand what you really want. But I guess you want to check which disks exist: grep '^[sw]d' /var/run/dmesg.log (I guess that should cover most disk devices, save for very exotic stuff and floppy disks). For exact information, see fdisk(8), disklabel(8), and df(1). For potential mounts, see fstab(5), for actual mounts, see mount(8). Kind regards, Hannah.
Re: Open BSD Physical Storage
On Thu, 6 Dec 2007 05:21:08 -0800 (PST), Shachi Rai wrote Hi, Currently I am facing a small problem in OpenBSD. I want to get the information about the total physical Storage and the partition table (mounted and unmounted). Please let me know if there is any way out for getting this information. Disklabel information, which includes the physical drive (partition c) can be obtained from the disklabel(8) command. If the drive has non-OpenBSD MBR partitions, *and* the disklabel was built after those MBR partitions were created, they will have assigned partitions in the disklabel. Show, in gigabytes, the layout of SCSI drive #0: # disklabel -p g sd0 Show, in megabytes, the layout of IDE/ATA drive #1: # disklabel -p m wd1 Show, in gigabytes/megabytes/kilobytes as needed, the capacity and current utilization of all mounted disks: $ df -h
Re: Open BSD Physical Storage
Hi, Great to see your reply, I would like to explain you in detail, I am currently writing a java code which tries to find out the total physical storage of an OpenBSD machine. Infact I would like to know the complete partition table in an OPenBSD machine. I have gone through the disklabel and fdisk command but both these command take the device name as a parameter. So my first question would be to know all the devices which are attached and may or may not be mounted. Once this is obtained, I would run the above commands to get the information about each device. Or Is there any option which would directly give the complete physical storage information. Hannah Schroeter wrote: Hi! On Thu, Dec 06, 2007 at 05:21:08AM -0800, Shachi Rai wrote: Currently I am facing a small problem in OpenBSD. I want to get the information about the total physical Storage and the partition table (mounted and unmounted). Please let me know if there is any way out for getting this information. I don't exactly understand what you really want. But I guess you want to check which disks exist: grep '^[sw]d' /var/run/dmesg.log (I guess that should cover most disk devices, save for very exotic stuff and floppy disks). For exact information, see fdisk(8), disklabel(8), and df(1). For potential mounts, see fstab(5), for actual mounts, see mount(8). Kind regards, Hannah. -- View this message in context: http://www.nabble.com/Open-BSD-Physical-Storage-tf4956022.html#a14192828 Sent from the openbsd user - misc mailing list archive at Nabble.com.
Re: Open BSD Physical Storage
Shachi Rai wrote: Hi, Great to see your reply, I would like to explain you in detail, I am currently writing a java code which tries to find out the total physical storage of an OpenBSD machine. Infact I would like to know the complete partition table in an OPenBSD machine. I have gone through the disklabel and fdisk command but both these command take the device name as a parameter. So my first question would be to know all the devices which are attached and may or may not be mounted. Once this is obtained, I would run the above commands to get the information about each device. Try `sysctl -n hw.disknames' then run disklabel on each of them That might give you what you want. /Alexander
Re: Open BSD Physical Storage
On Thu, 6 Dec 2007 05:57:17 -0800 (PST), Shachi Rai wrote ...So my first question would be to know all the devices which are attached... $ sysctl hw.disknames .. and may or may not be mounted $ df
Re: Code signing in OpenBSD
Hannah Schroeter wrote: ... AFS is also encrypted, but unless its used to get all the tarballs and make them accessible locally (e.g. make a cd) it's not a help during the installation. I don't know enough about AFS to say anything about how to secure it from the beginning on. I'm not very knowledgeable, but have been looking at the documenation lately: http://www.openafs.org/pages/doc/AdminGuide/auagd007.htm#HDRWQ75 ... Given the existence of Windows servers (aka compromised machines) on many networks, there are many chances for traffic to be intercepted, often even DNS. So man-in-the-middle attacks appear to be theoretically easy during the first part of an OpenBSD network installation. Yes, alas. And especially, for government legal interception, where they could legally enlist help from ISPs. So, intentional (corporate or government agreement with ISP) or unintentional (use of M$ on ISP DNS server), could allow the initial installation to become compromised, perhaps in a hard-to-detect way. None of this seems to be solved in the installation guide: http://openbsd.org/faq/faq4.html Again, it looks like it might come down to keys or fingerprints and that the network install might be depreciated. Rather, download, verify, then install. -Lars
Re: Open BSD Physical Storage
On 2007/12/06 05:57, Shachi Rai wrote: I have gone through the disklabel and fdisk command but both these command take the device name as a parameter. So my first question would be to know all the devices which are attached and may or may not be mounted. sysctl hw.disknames
Re: Code signing in OpenBSD
At this point, it's probably a good idea to point out there's a paper called Trusting Trust about your everyday C compiler... On 12/6/07, Lars Noodin [EMAIL PROTECTED] wrote: Hannah Schroeter wrote: ... AFS is also encrypted, but unless its used to get all the tarballs and make them accessible locally (e.g. make a cd) it's not a help during the installation. I don't know enough about AFS to say anything about how to secure it from the beginning on. I'm not very knowledgeable, but have been looking at the documenation lately: http://www.openafs.org/pages/doc/AdminGuide/auagd007.htm#HDRWQ75 ... Given the existence of Windows servers (aka compromised machines) on many networks, there are many chances for traffic to be intercepted, often even DNS. So man-in-the-middle attacks appear to be theoretically easy during the first part of an OpenBSD network installation. Yes, alas. And especially, for government legal interception, where they could legally enlist help from ISPs. So, intentional (corporate or government agreement with ISP) or unintentional (use of M$ on ISP DNS server), could allow the initial installation to become compromised, perhaps in a hard-to-detect way. None of this seems to be solved in the installation guide: http://openbsd.org/faq/faq4.html Again, it looks like it might come down to keys or fingerprints and that the network install might be depreciated. Rather, download, verify, then install. -Lars -- http://www.glumbert.com/media/shift http://www.youtube.com/watch?v=tGvHNNOLnCk This officer's men seem to follow him merely out of idle curiosity. -- Sandhurst officer cadet evaluation. Securing an environment of Windows platforms from abuse - external or internal - is akin to trying to install sprinklers in a fireworks factory where smoking on the job is permitted. -- Gene Spafford
Re: Code signing in OpenBSD
On Thu, Dec 06, 2007 at 11:48:55AM +0100, Hannah Schroeter wrote: One risk would be the plans of online surveillance of computers e.g. in Germany. One way to install surveillance even on OpenBSD would be to actively interfere with the internet connection with the surveilled person, in the man-in-the-middle sense, and inject trojanned code (Bundestrojaner) into the updates of the victim. Using software from any source without interference from an all-pervasive government is a very special, but unfortunatly today, a very real issue for many people around the world. To be secure, you have to get pieces of the puzzle over multiple paths. It all can't come via the net since then you're open to man-in-the-middle. Key-revocation announcements could come over the net (via an announce list) but the new key would then have to come over a second channel. One second-channel option is the q6mth CD issue, which could include a new public key and e.g. known-hosts fingerprints. This is vulnerable to a very determined man-in-the-middle who can replicate and then alter the CD before it arrives to you in the mail. Another option is a trusted courier flying to Alberta and get a CD from the OpenBSD store (yeah, right). In fact, likely any other technological option (e.g. an answering machine in Alberta that spits out the alphanumerics of the current master public key) is still suceptible. If every piece of information you receive is filter through your government, is there any hand-shaking protocol that can allow you to establish a verified information connection (not necessarily encrypted)? I don't think so. Sure, Debian has signed .debs that use gpg as a back end (the system is called apt-key), it relies on you trusting the fist key that you get from them. Since Debian doesn't actually mail out its own CDs, everything is off its mirrors. apt-key only 'protects' you from a later man-in-the-middle. I think that this is the central 'problem' that people are dancing around. Personally, if this thread is to continue, I would like to see it move from a Why doesn't OpenBSD do things this way? to a What are the threat models for OpenBSD identity theft and how can we protect ourselves?. Doug.
Re: Code signing in OpenBSD
bofh wrote: At this point, it's probably a good idea to point out there's a paper called Trusting Trust about your everyday C compiler... Yeah. It recently disappeared from the ACM's web site after 11+ years of availability: http://www.acm.org/classics/oct95/ There is, fortunately, the author's copy: http://cm.bell-labs.com/who/ken/trust.html There is an interesting follow up: http://www.dwheeler.com/trusting-trust/ summary of the followup: http://www.schneier.com/blog/archives/2006/01/countering_trus.html The bottom line, however, is that having and using the source is not optional. Thus, patches are provided in OpenBSD as source... But, starting from an initial set of some binaries is adequate for many uses, just as long as we can make reasonably sure that those binaries come from who they are supposed to / we expect them to. The install process ought to be fairly clear about the origin, authenticity and integrity of those initial binaries. No need to build on more of a sand foundation than necessary. -Lars
Re: /var/log/messages permissions in 4.2
On Thu, Dec 06, 2007 at 07:05:07AM -0500, Nick Holland wrote: Douglas A. Tutty wrote: On Tue, Dec 04, 2007 at 02:30:28PM -0800, Bryan Irvine wrote: What would be the rationale for 640? ;) Well according to cvs log: it can be easily changed if you like it another way. millert, So I guess one rationale might be as simple as because ;) Does anything get posted to the log that a normal user should not see? I suppose it depends on the machine's context. Can traffic analysis on the log be used to determine what another user is doing any more than watching top? If you're concerned about normal users reading logs, you need to look at those logs and determine why you are concerned and determine the implcations of those concerns. The other question: Does the stuff there need to be seen so often that administrative users might be tempted to do a sudo -s over sudo more ..., and then do something stupid that would have been a non-event if they weren't root? Difficult to maintain does NOT equal secure. Difficult to maintain usually means improperly maintained, and that usually means insecure. IF you are producing messages output that the general users should NOT be seeing, go ahead, change the access permissions! If you look at the number of systems that either have 1) only administrative users or 2) have nothing secret going to /var/log/messages you have probably covered the vast majority of OpenBSD systems. So, I don't want to see the vast majority of systems made more difficult to administer and perhaps prompting the user to live as root more than needed. Glancing through the /var/log/messages files on a few of my machines, I found nothing I wouldn't be more than happy to post to the Internet, other than the rather anemic specs might be a bit embarrassing, but I found that I was glad I didn't have to have root privs to look at them. I think you may have overstated things a bit. They are readable by group wheel. Anyone who you could set up with sudo to read the logs could be in group wheel. Unless you have layers of admins, but then you would probably add an 'adm' group and change the file's group from wheel to adm. Doug.
Re: Code signing in OpenBSD
Douglas A. Tutty wrote: Using software from any source without interference from an all-pervasive government is a very special,... It's not all about governments. Corporate espionage is probably a larger, more active threat, especially to OpenBSD. cui bono? If we assume for the sake of argument that the printed CDs are ok, then there is at least one method for distributing keys and/or building a web of trust. -Lars
Re: OpenBSD4.1 IPSEC - transport_send_messages: giving up on exchange
We've got similar problems about a year ago, when we deployed a massive installation of vpn/ipsec clients based on isakmpd. When testing the client robustness to a series of events, like physically disconnecting network cables, simulating power failures and such, we saw the same pattern. Our solution was to use an external program to send simple icmp packets to our internal network and restart isakmpd once detecting the tunnel is down. A web search has showed us that tunnel recreation is complex and frequently involves non-standard implemmentations. Sometimes, this process fails and it should be considered an external watchdog to be on the safe side. So we cooked an in-house solution using monit to restart isakmpd in case of failure. Obviously you'll need to define a simple set of rules to classify a connection as failed. snip Okey, all vpn comes up normally but.. the problem is: At random time, the tunnel turn down and dont come up again ! snip
Re: Code signing in OpenBSD
You forgot one option. Invite Theo to give a talk, and ask him to bring the CDs. If you can't trust Theo's CDs, all hope is lost. Just need to make sure there're some mountains around for Theo to go climb. If you live on a flatland, then, sorry, you're doomed. On 12/6/07, Douglas A. Tutty [EMAIL PROTECTED] wrote: On Thu, Dec 06, 2007 at 11:48:55AM +0100, Hannah Schroeter wrote: One risk would be the plans of online surveillance of computers e.g. in Germany. One way to install surveillance even on OpenBSD would be to actively interfere with the internet connection with the surveilled person, in the man-in-the-middle sense, and inject trojanned code (Bundestrojaner) into the updates of the victim. Using software from any source without interference from an all-pervasive government is a very special, but unfortunatly today, a very real issue for many people around the world. To be secure, you have to get pieces of the puzzle over multiple paths. It all can't come via the net since then you're open to man-in-the-middle. Key-revocation announcements could come over the net (via an announce list) but the new key would then have to come over a second channel. One second-channel option is the q6mth CD issue, which could include a new public key and e.g. known-hosts fingerprints. This is vulnerable to a very determined man-in-the-middle who can replicate and then alter the CD before it arrives to you in the mail. Another option is a trusted courier flying to Alberta and get a CD from the OpenBSD store (yeah, right). In fact, likely any other technological option (e.g. an answering machine in Alberta that spits out the alphanumerics of the current master public key) is still suceptible. If every piece of information you receive is filter through your government, is there any hand-shaking protocol that can allow you to establish a verified information connection (not necessarily encrypted)? I don't think so. Sure, Debian has signed .debs that use gpg as a back end (the system is called apt-key), it relies on you trusting the fist key that you get from them. Since Debian doesn't actually mail out its own CDs, everything is off its mirrors. apt-key only 'protects' you from a later man-in-the-middle. I think that this is the central 'problem' that people are dancing around. Personally, if this thread is to continue, I would like to see it move from a Why doesn't OpenBSD do things this way? to a What are the threat models for OpenBSD identity theft and how can we protect ourselves?. Doug. -- http://www.glumbert.com/media/shift http://www.youtube.com/watch?v=tGvHNNOLnCk This officer's men seem to follow him merely out of idle curiosity. -- Sandhurst officer cadet evaluation. Securing an environment of Windows platforms from abuse - external or internal - is akin to trying to install sprinklers in a fireworks factory where smoking on the job is permitted. -- Gene Spafford
Re: HP ProLiant DL320 v. Sun Fire V125
Hi, sorry for the late response, the mail just got marked as junk :( KM enabling acpi How exactly do you do it? Mine acpi-related lines are its already in the default kernel, not sure if its enabled by default. # config -ef /bsd.mp ... ukc enable acpi 414 acpi0 enabled KM enabling write cache for wd0 in the system with: KM # atactl wd0 writecacheenable Where do you put these command? For now I just ran it manually (and tested the result). I think it makes sense to activate the write cache before checking (and possibly recovering) RAIDframe devices, but rc.secure and rc.local are being called after that. Is it a good idea to put these atactl commands to /etc/rc right before #Configure ccd devices line? i ran it manually as well, and i guess you're right, even though i would not touch /etc/rc, since its part of the core system and i guess its not supposed to be changed by the user dunno if there is a sysctl and or other way to enable it at boot time, maybe also config -ef /bsd? KM Compaq iLO rev 0x03 at pci6 dev 4 function 0 not configured KM Compaq iLO rev 0x03 at pci6 dev 4 function 2 not configured KM uhci4 at pci6 dev 4 function 4 Hewlett-Packard USB rev 0x00: apic 8 int 23 (irq 11) KM Hewlett-Packard IPMI rev 0x00 at pci6 dev 4 function 6 not configured KM usb1 at uhci4: USB revision 1.0 KM uhub1 at usb1 Hewlett-Packard UHCI root hub rev 1.00/1.00 addr 1 Did you do something special about uhci*? Mine is giving errors on two computers already. Sometimes it even crashes to ddb: maybe try to disable it in the kernel config # config -ef /bsd.mp ... ukc disable uhci 139 uhci* disabled Also, does iLO 2 Remote Console (a Java one) work for you? we dont use it. sorry. Best Kai
Re: Code signing in OpenBSD
That's why I always hand enter, in binary, by toggling switches on the front of my box[1] when I start a new system. [1]. What, you never pressed the power button On 12/6/07, Lars Noodin [EMAIL PROTECTED] wrote: bofh wrote: At this point, it's probably a good idea to point out there's a paper called Trusting Trust about your everyday C compiler... Yeah. It recently disappeared from the ACM's web site after 11+ years of availability: http://www.acm.org/classics/oct95/ There is, fortunately, the author's copy: http://cm.bell-labs.com/who/ken/trust.html There is an interesting follow up: http://www.dwheeler.com/trusting-trust/ summary of the followup: http://www.schneier.com/blog/archives/2006/01/countering_trus.html The bottom line, however, is that having and using the source is not optional. Thus, patches are provided in OpenBSD as source... But, starting from an initial set of some binaries is adequate for many uses, just as long as we can make reasonably sure that those binaries come from who they are supposed to / we expect them to. The install process ought to be fairly clear about the origin, authenticity and integrity of those initial binaries. No need to build on more of a sand foundation than necessary. -Lars -- http://www.glumbert.com/media/shift http://www.youtube.com/watch?v=tGvHNNOLnCk This officer's men seem to follow him merely out of idle curiosity. -- Sandhurst officer cadet evaluation. Securing an environment of Windows platforms from abuse - external or internal - is akin to trying to install sprinklers in a fireworks factory where smoking on the job is permitted. -- Gene Spafford
Re: Code signing in OpenBSD
hitler already On Thu, Dec 06, 2007 at 05:24:40PM +0200, Lars Nood??n wrote: Douglas A. Tutty wrote: Using software from any source without interference from an all-pervasive government is a very special,... It's not all about governments. Corporate espionage is probably a larger, more active threat, especially to OpenBSD. cui bono? If we assume for the sake of argument that the printed CDs are ok, then there is at least one method for distributing keys and/or building a web of trust. -Lars
softraid todo
Several people have asked me about what the softraid todo is. I published such a list at: http://www.peereboom.us/softraid_todo.txt It isn't 100% complete but has most major and minor items.
Re: Code signing in OpenBSD
On Thu, Dec 06, 2007 at 09:08:56AM -0600, Marco Peereboom wrote: hitler already Here is yours : ++ | 1 Godwin point | ++ Bye -- unzip ; strip ; touch ; grep ; find ; finger ; mount ; fsck ; more ; yes ; fsck ; umount ; sleep
Re: Code signing in OpenBSD
Come on... twice a year and get the benefit of not being excluded from company policies which require digital signature of software downloaded through the internet. It's not really OpenBSD's problem that some companies implement pointless security policies. I'm not discussing wether its pointless or not, maybe you don't want OpenBSD to be used at all? You make it sound like OpenBSD is a vendor that is actively marketing to these companies and that cannot make a sale because it is not meeting a specific set of criteria in your requirements docs. Tell you what. I am sure there are a number of individuals on the list who own or work at companies that would be more than happy to provide your employer with a custom-built set of installation binaries and packages, signed for your digital pleasure. I expect bi-annual costs, including overhead like lawyers, errors and omissions insurance, etc, to run mid-5-figures per release. Minimum 5 release contract. Expect much re-writing of contract clauses. If there is indeed that much value derived in your organization from the use of OpenBSD, then this will be a paltry sum to pay. I am fairly confident that Oracle and Sun and SAP likely aren't PKI'ing their updates from their websites. Oh wait. Are those excluded from the company policy because you have a contract in place? I went through a similar policy a few years ago while doing Sarbanes-Oxley consulting. The lawyers and auditors were screaming for validation of free software, like Perl. After many months of having tantrums, they, along with management, finally realized that going down this path would be tantamount to try to chip away all the morter keeping a brick building together. The effects on the integrity of the structure (corporate, in this case) would be too great to keep pursuing this line of thought. That policy was abandoned because it was costing more to implement than the perceived risks they believed they could mitigate. (i.e. - they had to think in practical terms) Shortly afterward, I went back to steel-toed-boots engineering, where risks models really matter because you're trying to ensure that people don't get killed, that the environment doesn't get polluted, that you don't destroy assets and that you don't impact production. Digital signatures are pretty irrelevant when you need to be concerned about an explosion that could potentially wipe out a few hundred million in infrastructure in the space of a few city blocks. Or when an H2S leak can kill you and your crew in the matter of a few breaths. If it's that important, shut up and hack. Or otherwise just shut up.
Re: Code signing in OpenBSD
On 06 NN5N: 2007, at 5:39 N N , bofh wrote: You forgot one option. Invite Theo to give a talk, and ask him to bring the CDs. If you can't trust Theo's CDs, all hope is lost. And how would you know that it is indeed Theo and not someone that looks like him? I think that blood samples and DNA tests is the only way to go here. Just need to make sure there're some mountains around for Theo to go climb. If you live on a flatland, then, sorry, you're doomed. On 12/6/07, Douglas A. Tutty [EMAIL PROTECTED] wrote: On Thu, Dec 06, 2007 at 11:48:55AM +0100, Hannah Schroeter wrote: One risk would be the plans of online surveillance of computers e.g. in Germany. One way to install surveillance even on OpenBSD would be to actively interfere with the internet connection with the surveilled person, in the man-in-the-middle sense, and inject trojanned code (Bundestrojaner) into the updates of the victim. Using software from any source without interference from an all-pervasive government is a very special, but unfortunatly today, a very real issue for many people around the world. To be secure, you have to get pieces of the puzzle over multiple paths. It all can't come via the net since then you're open to man-in-the-middle. Key-revocation announcements could come over the net (via an announce list) but the new key would then have to come over a second channel. One second-channel option is the q6mth CD issue, which could include a new public key and e.g. known-hosts fingerprints. This is vulnerable to a very determined man-in-the-middle who can replicate and then alter the CD before it arrives to you in the mail. Another option is a trusted courier flying to Alberta and get a CD from the OpenBSD store (yeah, right). In fact, likely any other technological option (e.g. an answering machine in Alberta that spits out the alphanumerics of the current master public key) is still suceptible. If every piece of information you receive is filter through your government, is there any hand-shaking protocol that can allow you to establish a verified information connection (not necessarily encrypted)? I don't think so. Sure, Debian has signed .debs that use gpg as a back end (the system is called apt-key), it relies on you trusting the fist key that you get from them. Since Debian doesn't actually mail out its own CDs, everything is off its mirrors. apt-key only 'protects' you from a later man-in-the-middle. I think that this is the central 'problem' that people are dancing around. Personally, if this thread is to continue, I would like to see it move from a Why doesn't OpenBSD do things this way? to a What are the threat models for OpenBSD identity theft and how can we protect ourselves?. Doug. -- http://www.glumbert.com/media/shift http://www.youtube.com/watch?v=tGvHNNOLnCk This officer's men seem to follow him merely out of idle curiosity. -- Sandhurst officer cadet evaluation. Securing an environment of Windows platforms from abuse - external or internal - is akin to trying to install sprinklers in a fireworks factory where smoking on the job is permitted. -- Gene Spafford
Re: A necessary evil: snmpd(8) and snmpctl(8)
On Wed, 05 Dec 2007 22:32:45 +0700, Jason George [EMAIL PROTECTED] wrote: Hi! I just imported snmpd(8) and snmpctl(8), an initial attempt to implement a new SNMP daemon for OpenBSD. SNMP is the Simple Network Management Protocol and it is still very commonly used in corporate networks, by network vendors, and in network management systems (NMS). SNMP is very essential for me since I'm using it at work; our security appliances based on OpenBSD need to integrate into various SNMP scenarios. We had to use net-snmp for this; the BSD license is good but the code is very bad and full of ancient cruft and portability glue. Then there were many problems with the net-snmp port in OpenBSD, people reported 90% CPU usage on -misc, crashes, bugs, ...it was just a pain. Thank you! Thank you! Thank you! Well, finally.. my net-snmp 5.4p1 on 4.2 box keeps dying.. 5.4.1 eating my cpus.. how can we test it? -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: Code signing in OpenBSD
Code signing by blood. ISAGN. Sorry marc - had to do it On 12/6/07, Jeff I. Ragland [EMAIL PROTECTED] wrote: On 06 Dej 2007, at 5:39 LL, bofh wrote: You forgot one option. Invite Theo to give a talk, and ask him to bring the CDs. If you can't trust Theo's CDs, all hope is lost. And how would you know that it is indeed Theo and not someone that looks like him? I think that blood samples and DNA tests is the only way to go here. Just need to make sure there're some mountains around for Theo to go climb. If you live on a flatland, then, sorry, you're doomed. On 12/6/07, Douglas A. Tutty [EMAIL PROTECTED] wrote: On Thu, Dec 06, 2007 at 11:48:55AM +0100, Hannah Schroeter wrote: One risk would be the plans of online surveillance of computers e.g. in Germany. One way to install surveillance even on OpenBSD would be to actively interfere with the internet connection with the surveilled person, in the man-in-the-middle sense, and inject trojanned code (Bundestrojaner) into the updates of the victim. Using software from any source without interference from an all-pervasive government is a very special, but unfortunatly today, a very real issue for many people around the world. To be secure, you have to get pieces of the puzzle over multiple paths. It all can't come via the net since then you're open to man-in-the-middle. Key-revocation announcements could come over the net (via an announce list) but the new key would then have to come over a second channel. One second-channel option is the q6mth CD issue, which could include a new public key and e.g. known-hosts fingerprints. This is vulnerable to a very determined man-in-the-middle who can replicate and then alter the CD before it arrives to you in the mail. Another option is a trusted courier flying to Alberta and get a CD from the OpenBSD store (yeah, right). In fact, likely any other technological option (e.g. an answering machine in Alberta that spits out the alphanumerics of the current master public key) is still suceptible. If every piece of information you receive is filter through your government, is there any hand-shaking protocol that can allow you to establish a verified information connection (not necessarily encrypted)? I don't think so. Sure, Debian has signed .debs that use gpg as a back end (the system is called apt-key), it relies on you trusting the fist key that you get from them. Since Debian doesn't actually mail out its own CDs, everything is off its mirrors. apt-key only 'protects' you from a later man-in-the-middle. I think that this is the central 'problem' that people are dancing around. Personally, if this thread is to continue, I would like to see it move from a Why doesn't OpenBSD do things this way? to a What are the threat models for OpenBSD identity theft and how can we protect ourselves?. Doug. -- http://www.glumbert.com/media/shift http://www.youtube.com/watch?v=tGvHNNOLnCk This officer's men seem to follow him merely out of idle curiosity. -- Sandhurst officer cadet evaluation. Securing an environment of Windows platforms from abuse - external or internal - is akin to trying to install sprinklers in a fireworks factory where smoking on the job is permitted. -- Gene Spafford -- http://www.glumbert.com/media/shift http://www.youtube.com/watch?v=tGvHNNOLnCk This officer's men seem to follow him merely out of idle curiosity. -- Sandhurst officer cadet evaluation. Securing an environment of Windows platforms from abuse - external or internal - is akin to trying to install sprinklers in a fireworks factory where smoking on the job is permitted. -- Gene Spafford
Hoststated + overload
Hey All, I was wondering is it possible to use pf + max-src-conn-rate + overload with hoststated? In manual there is nothing about that, but maybe if you define tables in hoststated, but not a service and in PF you use just rdr with hoststated tables (something similar to spamd tables?). Anyone has any ideas on that? Dane
Re: Code signing in OpenBSD
On Thu, Dec 06, 2007 at 09:39:35AM -0600, bofh wrote: You forgot one option. Invite Theo to give a talk, and ask him to bring the CDs. If you can't trust Theo's CDs, all hope is lost. He doesn't have to bring the CDs, just in the speach give the MD5 (or other more secure [sha?} sum for an .iso file made from those CDs. Buy the CD, create an image, calc the md5. Compare with Theo's speach. Doug.
Re: Code signing in OpenBSD
On Thu, Dec 06, 2007 at 05:24:40PM +0200, Lars Nood??n wrote: Douglas A. Tutty wrote: Using software from any source without interference from an all-pervasive government is a very special,... It's not all about governments. Corporate espionage is probably a larger, more active threat, especially to OpenBSD. True, but a single source of corporate espionage can't attack the mail, phone, fax, and internet (e.g. ftp) all at the same time. cui bono? If we assume for the sake of argument that the printed CDs are ok, then there is at least one method for distributing keys and/or building a web of trust. -Lars Doug.
Re: Code signing in OpenBSD
Hi! On Thu, Dec 06, 2007 at 11:23:37AM +, Stuart Henderson wrote: On 2007/12/06 13:12, Lars Noodin wrote: If the installation process (from the purchased CDs) had a list of the public keys for the official mirror sites, then that would go a long way. That would make it rather hard to revoke a key if there ever was a problem. Key revocation lists in some form? If it's gpg/OpenPGP, instruct users to update from keyservers, one will notice when there're incompatibilities between the key from CD and the one from the keyserver, but one will also get the revocation from the keyserver. And if one buys every CD, there's the time window of half a year even without a key revocation infrastructure. Kind regards, Hannah. Why not start selling public key lists from the order site, then those who care can order one (or more) CD(s) and a separately delivered (set of) public key lists (in sealed envelopes). Otherwise ordering CDs will suffice. When a key is revoked (announced somewhere) or incompatibilities occur order a new (set of) list(s). Then there is the problem of the lists being replaced by some new list by the postman, thus ordering a set of lists instead of only one. Have them delivered by different couriers, if all of them replaces the list you will probably know. Now, that will require a lot of work, and a lot of money (a lot of fuss for a piece of paper) to scare most people off. Problem solved. Brad, you really did start some thread. Starting with a rather innocent question. Interesting reading though. My best to all of you, Daniel
Re: Code signing in OpenBSD
bofh wrote: Code signing by blood. ISAGN. Sorry marc - had to do it what if theo is a person of interest, has his endpoint surveilled and his key and passphrase are compromised? if somebody stole a pint of blood, that could go a long way in your proposed plan... short of having a web of trust, meeting people in person to sign their keys and assuming private keys and passphrases have not been compromised, you're pretty much SOL here. best bet is to use anoncvs and verify your cvs server's public key in person, but even that is a PITA. if massive databases of key fingerprint collisions exist MITM is very real even with a key fingerprint, multiple fingerprints make this much harder. if anyone has a non-trivial quantum computer or remote viewing really works, the gig is pretty much up anyhow. jy-p cinches his tinfoil hat and returns to following the yellow brick road... On 12/6/07, Jeff I. Ragland [EMAIL PROTECTED] wrote: On 06 Dej 2007, at 5:39 LL, bofh wrote: You forgot one option. Invite Theo to give a talk, and ask him to bring the CDs. If you can't trust Theo's CDs, all hope is lost. And how would you know that it is indeed Theo and not someone that looks like him? I think that blood samples and DNA tests is the only way to go here. Just need to make sure there're some mountains around for Theo to go climb. If you live on a flatland, then, sorry, you're doomed. On 12/6/07, Douglas A. Tutty [EMAIL PROTECTED] wrote: On Thu, Dec 06, 2007 at 11:48:55AM +0100, Hannah Schroeter wrote: One risk would be the plans of online surveillance of computers e.g. in Germany. One way to install surveillance even on OpenBSD would be to actively interfere with the internet connection with the surveilled person, in the man-in-the-middle sense, and inject trojanned code (Bundestrojaner) into the updates of the victim. Using software from any source without interference from an all-pervasive government is a very special, but unfortunatly today, a very real issue for many people around the world. To be secure, you have to get pieces of the puzzle over multiple paths. It all can't come via the net since then you're open to man-in-the-middle. Key-revocation announcements could come over the net (via an announce list) but the new key would then have to come over a second channel. One second-channel option is the q6mth CD issue, which could include a new public key and e.g. known-hosts fingerprints. This is vulnerable to a very determined man-in-the-middle who can replicate and then alter the CD before it arrives to you in the mail. Another option is a trusted courier flying to Alberta and get a CD from the OpenBSD store (yeah, right). In fact, likely any other technological option (e.g. an answering machine in Alberta that spits out the alphanumerics of the current master public key) is still suceptible. If every piece of information you receive is filter through your government, is there any hand-shaking protocol that can allow you to establish a verified information connection (not necessarily encrypted)? I don't think so. Sure, Debian has signed .debs that use gpg as a back end (the system is called apt-key), it relies on you trusting the fist key that you get from them. Since Debian doesn't actually mail out its own CDs, everything is off its mirrors. apt-key only 'protects' you from a later man-in-the-middle. I think that this is the central 'problem' that people are dancing around. Personally, if this thread is to continue, I would like to see it move from a Why doesn't OpenBSD do things this way? to a What are the threat models for OpenBSD identity theft and how can we protect ourselves?. Doug. -- http://www.glumbert.com/media/shift http://www.youtube.com/watch?v=tGvHNNOLnCk This officer's men seem to follow him merely out of idle curiosity. -- Sandhurst officer cadet evaluation. Securing an environment of Windows platforms from abuse - external or internal - is akin to trying to install sprinklers in a fireworks factory where smoking on the job is permitted. -- Gene Spafford
Re: Code signing in OpenBSD
Ted Unangst wrote: give it a rest guys. Ted says everything is ok. We can pack up and call it a day, knowing that everything's settled once and for all. Seriously, if the process has been already worked out, then point to where it is written up. Maybe we're not looking in the right part of the FAQ. -Lars
Re: Code signing in OpenBSD
give it a rest guys. has anyone ever actually been the victim of some government/corporate/the man attack where they slipped trojan openbsd binaries to you? do you have any idea how hard it really is to mount such an attack? without being detected? and what's the trojan going to do? copy all your secrets to their national citizen oppression center? how do they get their nefarious packets through your firewall without notice? i've download openbsd onto various machines from at least 5 mirrors using 9 isps in 5 countries over the course of 7 years. and you're telling me that every single time, somebody out there was feeding me the bad bits? because if they screwed up even a single time, i could use the good machine to detect the tainted ones. get real.
Re: Code signing in OpenBSD
Since this thread is both TOP and BOTTOM posted, I am going UPPER MIDDLE post. bofh wrote: Code signing by blood. ISAGN. Sorry marc - had to do it what if theo is a person of interest, has his endpoint surveilled and his key and passphrase are compromised? if somebody stole a pint of blood, that could go a long way in your proposed plan... short of having a web of trust, meeting people in person to sign their keys and assuming private keys and passphrases have not been compromised, you're pretty much SOL here. best bet is to use anoncvs and verify your cvs server's public key in person, but even that is a PITA. if massive databases of key fingerprint collisions exist MITM is very real even with a key fingerprint, multiple fingerprints make this much harder. if anyone has a non-trivial quantum computer or remote viewing really works, the gig is pretty much up anyhow. jy-p cinches his tinfoil hat and returns to following the yellow brick road... Like Keyser Soze, Theo has neither blood nor DNA. Except for me at beer last night, no one has ever seen Theo. So everyone's point is moot. On 12/6/07, Jeff I. Ragland [EMAIL PROTECTED] wrote: On 06 Dej 2007, at 5:39 LL, bofh wrote: You forgot one option. Invite Theo to give a talk, and ask him to bring the CDs. If you can't trust Theo's CDs, all hope is lost. And how would you know that it is indeed Theo and not someone that looks like him? I think that blood samples and DNA tests is the only way to go here. Just need to make sure there're some mountains around for Theo to go climb. If you live on a flatland, then, sorry, you're doomed. On 12/6/07, Douglas A. Tutty [EMAIL PROTECTED] wrote: On Thu, Dec 06, 2007 at 11:48:55AM +0100, Hannah Schroeter wrote: One risk would be the plans of online surveillance of computers e.g. in Germany. One way to install surveillance even on OpenBSD would be to actively interfere with the internet connection with the surveilled person, in the man-in-the-middle sense, and inject trojanned code (Bundestrojaner) into the updates of the victim. Using software from any source without interference from an all-pervasive government is a very special, but unfortunatly today, a very real issue for many people around the world. To be secure, you have to get pieces of the puzzle over multiple paths. It all can't come via the net since then you're open to man-in-the-middle. Key-revocation announcements could come over the net (via an announce list) but the new key would then have to come over a second channel. One second-channel option is the q6mth CD issue, which could include a new public key and e.g. known-hosts fingerprints. This is vulnerable to a very determined man-in-the-middle who can replicate and then alter the CD before it arrives to you in the mail. Another option is a trusted courier flying to Alberta and get a CD from the OpenBSD store (yeah, right). In fact, likely any other technological option (e.g. an answering machine in Alberta that spits out the alphanumerics of the current master public key) is still suceptible. If every piece of information you receive is filter through your government, is there any hand-shaking protocol that can allow you to establish a verified information connection (not necessarily encrypted)? I don't think so. Sure, Debian has signed .debs that use gpg as a back end (the system is called apt-key), it relies on you trusting the fist key that you get from them. Since Debian doesn't actually mail out its own CDs, everything is off its mirrors. apt-key only 'protects' you from a later man-in-the-middle. I think that this is the central 'problem' that people are dancing around. Personally, if this thread is to continue, I would like to see it move from a Why doesn't OpenBSD do things this way? to a What are the threat models for OpenBSD identity theft and how can we protect ourselves?. Doug. -- http://www.glumbert.com/media/shift http://www.youtube.com/watch?v=tGvHNNOLnCk This officer's men seem to follow him merely out of idle curiosity. -- Sandhurst officer cadet evaluation. Securing an environment of Windows platforms from abuse - external or internal - is akin to trying to install sprinklers in a fireworks factory where smoking on the job is permitted. -- Gene Spafford
Re: Code signing in OpenBSD
On Thu, 6 Dec 2007 09:51:16 -0500, Douglas A. Tutty [EMAIL PROTECTED] said: Personally, if this thread is to continue, I would like to see it move from a Why doesn't OpenBSD do things this way? to a What are the threat models for OpenBSD identity theft and how can we protect ourselves?. Please don't. I am getting tired of deleting this stupid thread. The project has been around for more than ten years. Do you think the devs are so completely clueless about security that they haven't already thought about this? Actually, a couple of the devs have already spoken up on this topic and gave you the answer so please shut up already. Sorry for adding to the talk talk talking, but people like Theo actually read all this crap and it's wasting their time.
Re: Code signing in OpenBSD
do you have any idea how hard it really is to mount such an attack? without being detected? and what's the trojan going to do? copy all your secrets to their national citizen oppression center? how do they get their nefarious packets through your firewall without notice? Of course they won't do that. The US government has rules about what it can collect and put in it's own databases and use. Forward thinking people put careful rules in place preventing the government from legally playing big brother... Of course it has no such rules about what data in private databases it can in retrieve and use. The brownshirts can pretty much go in there and get anything they want anytime. Forward thinking people kind of had the blinders on about that one. Wow that Google toolbar sure is nice... ;) -Bob
Re: Code signing in OpenBSD
HITLER AND MORE HITLER On Thu, Dec 06, 2007 at 08:28:21PM +0200, Lars Nood??n wrote: Ted Unangst wrote: give it a rest guys. Ted says everything is ok. We can pack up and call it a day, knowing that everything's settled once and for all. Seriously, if the process has been already worked out, then point to where it is written up. Maybe we're not looking in the right part of the FAQ. -Lars
Re: Code signing in OpenBSD
there seems to be a fine, pink mist in the air. some time ago the matter comprising this mist was a live and healthy horse. On Thu, Dec 06, 2007 at 12:39:39PM -0600, Marco Peereboom wrote: HITLER AND MORE HITLER On Thu, Dec 06, 2007 at 08:28:21PM +0200, Lars Nood??n wrote: Ted Unangst wrote: give it a rest guys. Ted says everything is ok. We can pack up and call it a day, knowing that everything's settled once and for all. Seriously, if the process has been already worked out, then point to where it is written up. Maybe we're not looking in the right part of the FAQ. -Lars -- Christopher Linn celinn at mtu.edu | By no means shall either the CEC System Administrator II | or MTU be held in any way liable Center for Experimental Computation | for any opinions or conjecture I Michigan Technological University | hold to or imply to hold herein.
Re: Code signing in OpenBSD
Ok. So Christopher, Marco, and Ted have spoken up to inform the list that they do not know an answer. Christopher Linn wrote: there seems to be a fine, pink mist in the air. ... To be sure the topic has been covered earlier, but just where are there relevant message archives, presentations or documents finding a practical solution to the problem of getting an initial set of binaries? -Lars
Re: Code signing in OpenBSD
On Thursday 06 December 2007 05:52:46 Hannah Schroeter wrote: Hi! On Wed, Dec 05, 2007 at 06:46:15PM -0500, STeve Andre' wrote: [...] You know, you're descending into a recursive loop of if, if, if... and it never ends. OF COURSE if someone breaks into the site they could do things--once you've lost control of your site all bets are off. I dare say that someone breaking into a site might find all the appropriate tools to re-sign things, too, and do the spoof that way. If I released code with cryptographic signatures, I'd not leave a secret key file, nor a passphrase on the servers with the master web/ftp site. I'd sign on a box you can't access from the master site (nor the mirrors). So, no, the attacker would *not* gain access to signing tools (ok, yes, the tools, perhaps, like gpg or openssl, but not the key material). --STeve Andre' Kind regards, Hannah. Heh--you're intelligent. But I know of two places where everything was stored on the one machine, and I think one of those sites still hasn't gotten it through their heads that this isn't a good idea. --STeve Andre'
Re: Skype on the OpenBSD
Lars NoodC)n [EMAIL PROTECTED] wrote: http://forum.skype.com/index.php?showtopic=95261 I have no intention of refueling this debate but I found this an interesting read some time ago: paper by Garfinkel http://skypetips.internetvisitation.org/files/VoIP%20and%20Skype.pdf your link is mostly about Ubuntu users concerned that skype reads /etc/password and greps their .mozilla profiles for proxy settings, which when all is said and done is probably the least of their worries. as for other posts, openwengo does not currently support encryption, and is developed partly by a French company, last I heard French governments were not exactly friendly towards strong crypto. also, wengo do have a vested interest in bashing skype. cheers, mike
Re: Code signing in OpenBSD
On Thu, Dec 06, 2007 at 09:39:59PM +0200, Lars Nood??n wrote: Ok. So Christopher, Marco, and Ted have spoken up to inform the list that they do not know an answer. You can't possibly be this dense. Let me try to spell it out. YOU see an issue WE don't. That makes YOU responsible for fixing it. All reasons have been given to you why this is not even remotely a good idea however you keep coming back for more. So again you care we don't; how does that make that OUR responsibility? Christopher Linn wrote: there seems to be a fine, pink mist in the air. ... To be sure the topic has been covered earlier, but just where are there relevant message archives, presentations or documents finding a practical solution to the problem of getting an initial set of binaries? You can't. Either get over it or use an operating system with a trusted vendor like Microsoft or Apple. That pesky Open Source stuff can't be trusted because its on the internets. -Lars
Hardware recommendations for OpenBSD carp router/firewall machines
Does anyone have recommendations on server hardware for setting up a redundant OpenBSD firewall? Right now our network handles several million HTTP requests per day, and we expect that to continue growing. I expect a simple pair of Dell rackmounted servers should handle this easily, but I thought I'd solicit feedback from the firewall experts on misc@ first. :-) Thanks!
alpha server hardware (AS1200) available for donation in Munich area
Hi Folks, I'm back again. I have two AS1200 (AlphaServers) to donate. They're nice machines, but I don't use them. One has two 400MHz CPUs (B3007-AA) and 512MB RAM, the other has one 533MHz CPU (B3007-CA) and 256MB RAM. They have lots of disks internally (2 and 4GB drives). They have several SCSI controllers installed and are in fact set up to operate as a TruCluster with shared storage, which is housed on two BA356 StorageWorks shelves stuffed with 2 and 4GB drives. If someone were interested in running this as a TruCluster, I also have two MemoryChannel cards and a cable. TruCluster traditionally uses MemoryChannel as its cluster interconnect. It can, however, use a standard ethernet P2P connection. Each system has two 100mbit ethernet controllers installed. The boxes are also fitted with redundant power supplies. Dimensions of a AS1200: height=47cm, width=36cm, depth=60cm For a photo see (one system is stacked on top of the other!): http://www.spielwiese.de/rob/Pictures/as1200-1000x1504.jpg I live in Munich, and posting them would be prohibitively expensive, I suspect. any interest? If yes, please contact me ASAP. Rob Urban Here is the output of show config for each system: dual-400MHz config: -- P00show config Digital Equipment Corporation AlphaServer 1200 Console V5.7-4 OpenVMS PALcode V1.21-2, Digital UNIX PALcode V1.23-2 Module Type RevName System Motherboard 0 mthrbrd0 Memory 512 MB DIMM 0 mem0 CPU (4MB Cache) 30001 cpu0 CPU (4MB Cache) 30001 cpu1 Bridge (IOD0/IOD1) 600 0032 iod0/iod1 PCI Motherboard a saddle0 Bus 0 iod0 (PCI0) Slot Option Name Type RevName 1 PCEB 4828086 0015 pceb0 2 S3 Trio64/Trio32 88115333 0044 vga0 3 DECchip 21140-AA 910110020 tulip0 4 DEC KZPSA81011 pks0 Bus 1 pceb0 (EISA Bridge connected to iod0, slot 1) Slot Option Name Type RevName Bus 0 iod1 (PCI1) Slot Option Name Type RevName 1 NCR 53C810 110000002 ncr0 2 QLogic ISP10X0 10201077 0005 isp0 3 NCR 53C810 110000002 ncr1 4 DE600-AA 12298086 0008 ei0 single-533MHz config: -- P00show config Compaq Computer Corporation AlphaServer 1200 Console V6.0-4 OpenVMS PALcode V1.21-2, Digital UNIX PALcode V1.23-2 Module Type RevName System Motherboard 0 mthrbrd0 Memory 64 MB DIMM 0 mem0 Memory 64 MB DIMM 0 mem1 Memory 64 MB DIMM 0 mem2 Memory 64 MB DIMM 0 mem3 CPU (4MB Cache) 30003 cpu0 Bridge (IOD0/IOD1) 600 0032 iod0/iod1 PCI Motherboard a saddle0 Bus 0 iod0 (PCI0) Slot Option Name Type RevName 1 PCEB 4828086 0015 pceb0 2 S3 Trio64/Trio32 88115333 0054 vga0 3 DE500-BA 191011 0030 tulip0 4 DEC KZPSA81011 pks0 Bus 1 pceb0 (EISA Bridge connected to iod0, slot 1) Slot Option Name Type RevName Bus 0 iod1 (PCI1) Slot Option Name Type RevName 1 NCR 53C810 110000002 ncr0 2 QLogic ISP10X0 10201077 0005 isp0 3 DEC PCI MC 181011 000E mc0 4 DE600-AA 12298086 0008 ei0
Re: Intel(R) Core(TM)2 Duo CPU E6550 freeze on core 2 duo
On 06/12/2007, Benoit Chesneau [EMAIL PROTECTED] wrote: Hi all, HAve currently problem with a server based on Intel(R) Core(TM)2 Duo CPU E6550 with a Realtek 8168 ( re(4) ). It freeze after some random time. I don't know why. No log about it. I tried to : - enable acpi - force the carde in 100baseTX But without any success yet. Hard to test anyway because this is a remote machine and can't check it from the rescue mode since this rescue mode is under freebsd. Any idee ? Anyone used such machine yet ? Here is a dmesg : http://babilu.metavers.net/dmesg/dmesg_enlil_20071206.txt http://kerneltrap.org/mailarchive/openbsd-misc/2007/10/21/349821 http://cvs.openbsd.org/cgi-bin/query-pr-wrapper?full=yesnumbers=5504 No patch yet. As these boxes are pretty popular, if someone writes one, they'll be a hero. :) C.
Re: Code signing in OpenBSD
Daniel Bosk wrote: Brad, you really did start some thread. Starting with a rather innocent question. Interesting reading though. My best to all of you, Daniel Thanks, I love OpenBSD. I see the lack of signed code and signed communication as a potential security issue. It *has* happened to other projects and I'd hate to see it happen to OpenBSD. I'd love to see PKI (specifically developer key pairs) incorporated into OpenBSD at some point... it's such a great project that produces a great product! Whatever happens, I will continue buying the CDs, T-shirts and telling my IT buddies to use it!!! All the best, A guy who claims to be Brad Tilley :) -- View this message in context: http://www.nabble.com/Code-signing-in-OpenBSD-tf4947207.html#a14204037 Sent from the openbsd user - misc mailing list archive at Nabble.com.
serial switch available for donation (Munich)
Hi Folks, I have an ancient, but fully functional pizza-box like device from Pan Dacom (V.24 Umschalter), which has 9 DB25 female connectors on the back, and 8 toggle pushbuttons on the front. One of the DB25 connectors is the input, and is connected to one or more of the other eight DB25 connectors, depending on which buttons are toggled on on the front. any interest? Rob Urban
reporting of flowd data
hi list, i'm looking for a reporting tool that can read the output of /var/log/flowd or the ascii data of flowd-reader. has anyone an idea ? thanks thomas
Note on pfctl: cannot allocate memory from spamd-setup
I'm running spamd in blacklist mode, and it started running out of memory today. It turns out the lists are getting close to the default limit: # /usr/libexec/spamd-setup -b -d Getting http://www.openbsd.org/spamd/traplist.gz blacklist uatraps 157348 entries Getting http://www.openbsd.org/spamd/nixspam.gz blacklist nixspam 40035 entries Getting http://www.openbsd.org/spamd/chinacidr.txt.gz blacklist china 431 entries Getting http://www.openbsd.org/spamd/koreacidr.txt.gz blacklist korea 270 entries That comes to 198084, and the default is 20. One solution is to put: set limit table-entries [value] in pf.conf.
Re: Code signing in OpenBSD
Paranoia is a disease... it distorts your thinking and your logical faculty. I'd be more concerned about THAT if I were in your position. It's stupid to rework the infrastructure to support signing, especially considering the benefits (none.) Plus, you have to trust the OpenBSD developers (GASP!) And think of all the other ways you could be compromised, which most are much easier to implement. Hardware keyloggers Social engineers Bad passwords Physical Security? etc. And just what are they going to get? Do you have some sort of cloak-and-dagger data on your box? -- Travers Buda
Re: Skype on the OpenBSD
I'm running wengo 2.1.2, and under the security tab on the configuration page there is an option for call encryption - WengoPhone can encrypt calls using the AES 128-bits encryption system and Diffie-Hellman for key exchange.
seeking hardware token recommendations
would like to lock random users out of the services that are hosted on machines here and remember LLNL, etc, using a RSA secureID to effect this back in the day: you had to enter your secureID string before being able to ssh into your user account through the firewall. i am aware that the secureID uses a closed-source algorithm to generate its codes and is thus, IMO, not a desirable solution. the goal is to allow only users with (1) a hardware token and (2) the correct passwords to access services (IMAPS, etc) on openbsd machines. a list of OTPs would be sufficient if i didn't think i'd end up regularly issuing new lists to users. if there is any good solution of the sort i describe above, i would appreciate pointers from more knowledgeable folks. cheers, jake --
Doctor Listing
Here's what we're offering for this week: Current Doctors in the USA 788,217 in total * 17,132 emails 34 primary and secondary specialties 16 different sortable fields Pharmaceutical Companies in the US 47,000 personal emails and names of decision makers American Hospital Directory Full data for all the major positions in more than 7k facilities Extensive List of Dentists in the US A complete Database or dentists and related services (valued at $399) Listing of US Chiropractors Complete data for all chiropractors in the US (a $250 value) Price for this week only = $398 for all 5 datasets reply to: [EMAIL PROTECTED] valid thru Dec 7
