Re: lookup option in /etc/resolv.conf ignored
Darrin Chandler wrote: > On Wed, Oct 24, 2007 at 11:46:34PM -0400, Brian wrote: >> Make sure you have restarted Firefox after making changes to >> /etc/resolv.conf. Specifically, the application-level DNS cache will >> contain old data if you have not restarted it. This bit me for 3 >> minutes straight after needing to redirect an address. > > I dislike Firefox's caching behavior. My nameservers cache just fine and > they are speedy enough by themselves. Firefox's cache is just another > level of expirations to go through. So I disable it completely. Here's > the cross-platform method, if you should wish to do so: > > In about:config, two new integer entried: > network.dnsCacheExpiration -> 0 > network.dnsCacheEntries -> 0 DNS caching in browsers is (was) meant to provide 'DNS pinning' in order to prevent malicious sites from bypassing browser 'same domain' policy when accessing other/internal servers. Since there are several ways to bypass this protection [1] perhaps it is not that critical to disable it. It is good to be aware of the implications though. Can [1] http://crypto.stanford.edu/dns/
Java problems on 4.1
Since some time ago it became impossible to run JVMs on my 4.1 box. I can't seem to figure out what's wrong, probably something easy and stupid... [EMAIL PROTECTED] /usr/local/jdk-1.5.0/bin/java& [1] 28689 [EMAIL PROTECTED] # # An unexpected error has been detected by HotSpot Virtual Machine: # # Internal Error (4F533F4253440E4350500060), pid=28689, tid=0x7cfba000 # # Java VM: Java HotSpot(TM) Client VM (1.5.0-p1-_24_oct_2006_19_53 mixed mode, ) # An error report file with more information is saved as hs_err_pid28689.log [EMAIL PROTECTED] kill -9 %1 [EMAIL PROTECTED] ## at this point, process becomes irresponsive [1]+ Killed /usr/local/jdk-1.5.0/bin/java [EMAIL PROTECTED] cat hs_err_pid28689.log # # An unexpected error has been detected by HotSpot Virtual Machine: # # Internal Error (4F533F4253440E4350500060), pid=28689, tid=0x7cfba000 # # Java VM: Java HotSpot(TM) Client VM (1.5.0-p1-_24_oct_2006_19_53 mixed mode, ) --- T H R E A D --- Current thread (0x85818a00): JavaThread [_thread_in_vm] Stack: [0xcf40,0xcf80) [error occurred during error reporting, step 110, id 0xb] [EMAIL PROTECTED] Let me know if dmesg, or ktrace output is can be helpful... 1.4 fails almost the same way, 1.3 dumps a core. 1.3-linux seems to work, but fails with OOM on attempting to allocate a 32k array, and ulimit -v is ~512Mb This is with latest ports for JDKs and redhat-base. Thanks ! -- With best of best regards Pawel S. Veselov
Re: Failure starting Gnome - OpenBSD 4.2
Matthieu Herrb wrote: > David H. Lynch Jr. wrote: > >> I have tried to install Gnome on two different machines running >> OpenBSD 4.2. >> The first machine ran Gnome fine under OpenBSD 4.1 (though there >> were other problems) >> >> One both machines - fresh installs gdm starts I can attempt to logon >> but I get a fatal error after logging on >> and a request to look in ~/.xsession for further information. >> > > This indicates that your session exited for some reason, probably an > error in your sessions startup script (.xsession or some thing else in > gnome case). > > >> after acknowledging X restarts, I can do a failsafe terminal login >> but nothing else. >> I have looked in ~/.xsession as well as the X/gdm logs in /var/log >> and the rest of the logs and can find no indications of a problem. >> >> A clue would be greatly appreciated. >> >> > > Please provide more precise informations, *exact* copies of the error > messages you see for instance, and more details on what files were > edited in your home directory. > > Also misc@ or ports@ mmailing lists are more appropriate for this kind > of questions. > I was able to trace things further. It failed trying to open gnome-session. Somehow despite the fact that I thought i had installed X and gnome, somethings were missed. Unfortunately that lead to a new problem. When trying to install/re-install gnome I am getting missing expat dependency issues all over the place. With a bit of force I have been able to get things loaded anyway - but can't get expat. Now it is bombing trying to load libexpat.so.9 - which is not anywhere on my system. I found some messages suggesting that there are libexpat issues with 4.2 though theey sugest I can get it from xbase42.tgz but I can not find it there. Where can find libxpat and how can I persuade pkg_add that it is installed ?
Help needed to get PF working
Hi,
I'm currently trying to configure small home network:
ADSL > Server / Firewall > Desktop
Now I'm working on building a proper firewall to my server. So far the
situation is following:
- Servers internet connection works
- Desktop receives IP, nameserver and default route from server's
DHCP service.
-Desktop can connect to server by SSH but can't connect to anything beyond
that.
Server's fxp0 gets dynamic IP from ISP and fxp1 uses static IP.
What I need:
-server running the most common services available to public. Then some
services available only to LAN.
-Desktop will only run games as client and will use the servers private
services
Here's my current pf.conf:
### MACROS ###
ext_if="fxp0"
lan_if="fxp1"
server_ip="xxx.xxx.xxx.xxx"
pri_ports="{ 20,21,22,25,80,110,113,123,443,2049,3306,6660,6669,6900:6999,8080}"
# Ports open on server to LAN
pub_ports="{ 20,21,22,25,80,110,113,123,443,6900:6999,8080}" # Ports
open on server to internet
game_ports="27000:27040
lan_ip="xxx.xxx.xxx.xxx"
p180_ip="xxx.xxx.xxx.xxx"
### TABLES ###
table persist
table persist
table const {10.0.0.0/8, 176.16.0.0/12, 192.168.0.0/16}
### OPTIONS ###
set skip on lo
set block-policy return
set optimization normal
set loginterface fxp0
set limit { states 5, frags 10 } # Are these good limits, I
have 4GB RAM?
### TRAFFIC NORMALIZATION ###
scrub in all fragment reassemble
### BANDWIDTH MANAGEMENT ###
### TRANSLATION ###
nat-anchor "ftp-proxy/*"
nat on $ext_if from !($ext_if) to any -> ($ext_if)
### REDIRECTION ###
rdr-anchor "ftp-proxy/*"
rdr pass on $lan_if proto tcp to port ftp -> 127.0.0.1 port 8021
rdr pass on $ext_if proto tcp from any to any port smtp -> 127.0.0.1 port 8025
no rdr on $ext_if proto tcp from to any port smtp
rdr on $ext_if inet proto {tcp,udp} from any to ($ext_if) port
$game_ports -> $p180_ip
rdr on $lan_if inet proto {tcp,udp} from $lan_ip to any -> ($ext_if)
### ANCHORS ###
anchor "ftp-proxy/*"
### PACKET FILTERING ###
# Block rules
block in all# Default to block all incoming and outgoing traffic
block out all
# Antispoof
antispoof quick log for { lo $lan_if }
# Incoming traffic
pass in on $ext_if proto {tcp,udp} from port $game_ports to $p180_ip
#pass quick on $lan_if no state
pass in on $ext_if proto {tcp,udp} to ($ext_if) port $pub_ports
pass in log on $lan_if proto {tcp,udp} from ($lan_if) port $pri_ports
to $server_ip
pass in on $lan_if proto {tcp,udp} from any to any keep state
# Outgoing traffic
pass out log on $ext_if proto {tcp,udp} from ($ext_if) to port $pub_ports
pass out on $ext_if proto {tcp,udp,icmp} from $lan_ip to any
How to change the pf.conf to allow desktop traffic to access the internet?
I have tried some solutions like removing the default block rules but it
still didn't work and I'm starting to run out of ideas.
Re: Keyboard/Mouse problem OpenBSD 4.2
Peter Hessler wrote: > try enabling acpi at the bootloader prompt.. > > boot -c > enable acpi > exit > Thanks ! that did the trick. > On 2007 Oct 24 (Wed) at 13:58:29 -0400 (-0400), David H. Lynch Jr. wrote: > :I am trying to complete a new install of OpenBSD 4.2 on an HP > :Pavillion dv8000. > : > :Inside X the glidepad is extremely eratic and virtually > :uncontrolable - but an external USB mouse works fine. > :Even without X running the Keyboard is prone to random fits of > :repeating charaters. It does not do that all the time, > : but the likelyhood of typing a complete command without atleast one > :letter repeating anywhere from 3 to 15 times is slim. > :Methodically hunt and pecking each individual key very slowly helps > :but does nto cure the problem. > : > :I do not have this problem running Ubuntu Linux (or windows) on the > :same machine - but I do get exactly the same behavior if I boot from a > :iux system rescue disk. > : > :My guess is that both the glidepad and keyboard are on PS/2 hardware > :internally and there is some PS/2 related configuration value that needs > :tweaked. But I have no clue where to look. > : > :A clue would be greatly appreciated. > : > > -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. "Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction." Albert Einstein
Re: About Xen: maybe a reiterative question but ..
Kevin Stam wrote: > ... failed to satisfactorily explain why running a specific application > in a VM is more secure then running it in a standard OS. It's nonsense that > you think it's more secure that way. It saves a lot of money, yes -- you > don't necessarily want a separate box just to run an application - but > that's not the debate here. The debate is about security, and I'm amazed > that you think a virtual environment is somehow more secure then a dedicated > non-virtual environment... Like I mentioned earlier, security has several contexts. He could well be talking about job security, if he's the only one who knows how it is set up. While probably the least, or at least one of the least, technically skilled people here, I did spend a lot of time this spring reading up on virtualization and paravirtualization. *My* conclusion was that the main, and maybe only, place that virtualization can help is in restoration after a compromise, assuming one makes snapshots, etc. That and maybe load balancing / resource usage to help uptime. Keeping people out, or data in? Nah. Probably no more than spreading out over different architectures. However, adding an extra layer otherwise made little sense and is probably not more effective than sysjail or something like that. Paravirtualization, *might* help in some cases, since the guest os must be ported, but again the host is native and once you reach the host... -Lars
Re: pgt/Netgear WG511
On 10/24/07, Jonathan Gray <[EMAIL PROTECTED]> wrote: > On Wed, Oct 24, 2007 at 12:32:19PM -0600, Daniel Melameth wrote: > > I have, what appears to be, v1 of this card, but I get the following from > > dmesg--even when booting from the latest snapshot of cd42.iso: > > > > Intersil, ISL3890, -, - (manufacturer 0xb, product 0x3890) "Intersil Prism > > GT/Duette" rev 0x01 at cardbus1 dev 0 function 0 not configured > > > > I'm not certain how to update pcidevs and related to accurately reflect this > > (I noticed product 0x3890 is already in pcidevs.h), so some advice is > > appreciated. > > Try see what comes up after an install, the Prism GT driver (pgt) is > not enabled on ramdisks/cds due to firmware license restrictions. Thank you Jonathan--this did the trick. I quickly installed the latest snapshot, pkg_added the firmware and I now have: pgt0 at cardbus1 dev 0 function 0 "Intersil, ISL3890, -": irq 11
Re: About Xen: maybe a reiterative question but ..
On 10/24/07, L. V. Lammert <[EMAIL PROTECTED]> wrote: > Virtualization provides near absolute security - DOM0 is not visible to > the user at all, only passing network traffic and handling kernel calls. > The security comes about in that each DOMU is totally isolated from the > the others, while the core DOM0 is isolated from any attacks. And this increases the security for the hosted (DomU) OS's exactly how? You know, the BIOS is safe from attack too, at least as much as Dom0 is, and each machine on my network is, amazingly enough, also totally isolated from each other. > Nobpdy has to write any code to understand that - the secuity benefits > are ovbious to everyone from the PHBs to the admins. Actually they aren't. What are the "obvious" security benefits? I'm not saying there aren't benefits, just that I can't see any obvious security benefits. --- Lars Hansson
Re: About Xen: maybe a reiterative question but ..
On 10/24/07, L. V. Lammert <[EMAIL PROTECTED]> wrote: > I have no clue what you're trying to say??? The original comment was the > the number of vulnerabilities is a inverse measure of the security risk > associated with a given OS. Please stop feeding this trolling. LV you should know better -- if it is LV -- then again you are known for odd spurts. How are your twe drivers coming along?
Re: lookup option in /etc/resolv.conf ignored
On Wed, Oct 24, 2007 at 11:46:34PM -0400, Brian wrote: > Make sure you have restarted Firefox after making changes to > /etc/resolv.conf. Specifically, the application-level DNS cache will > contain old data if you have not restarted it. This bit me for 3 > minutes straight after needing to redirect an address. I dislike Firefox's caching behavior. My nameservers cache just fine and they are speedy enough by themselves. Firefox's cache is just another level of expirations to go through. So I disable it completely. Here's the cross-platform method, if you should wish to do so: In about:config, two new integer entried: network.dnsCacheExpiration-> 0 network.dnsCacheEntries -> 0 -- Darrin Chandler| Phoenix BSD User Group | MetaBUG [EMAIL PROTECTED] | http://phxbug.org/ | http://metabug.org/ http://www.stilyagin.com/ | Daemons in the Desert | Global BUG Federation
Re: pgt/Netgear WG511
On Wed, Oct 24, 2007 at 12:32:19PM -0600, Daniel Melameth wrote: > I have, what appears to be, v1 of this card, but I get the following from > dmesg--even when booting from the latest snapshot of cd42.iso: > > > > Intersil, ISL3890, -, - (manufacturer 0xb, product 0x3890) "Intersil Prism > GT/Duette" rev 0x01 at cardbus1 dev 0 function 0 not configured > > > > I'm not certain how to update pcidevs and related to accurately reflect this > (I noticed product 0x3890 is already in pcidevs.h), so some advice is > appreciated. > > > > Thanks. Try see what comes up after an install, the Prism GT driver (pgt) is not enabled on ramdisks/cds due to firmware license restrictions.
Re: lookup option in /etc/resolv.conf ignored
Make sure you have restarted Firefox after making changes to /etc/resolv.conf. Specifically, the application-level DNS cache will contain old data if you have not restarted it. This bit me for 3 minutes straight after needing to redirect an address. Karel Kulhavy wrote: > I want to make my OS return 127.0.0.1 on google-analytics.com and > ad.doubleclick.net to speed up the work with Sourceforge. > > I put > 127.0.0.1 google-analytics.com > 127.0.0.1 ad.doubleclick.net > into /etc/hosts > > and checked that /etc/resolv.conf contains > lookup file bind > > According to man resolv.conf this should result in /etc/hosts having priority > over the DNS system. However, it simply doesn't work. Both Firefox and the > "host" command behave as if I didn't do anything. > > Why doesn't it work when man resolv.conf says it should? > > CL< [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: new dell install completed, but...
thanks for the response. I'll give that a read, and a try. where are you getting 4.2? the web site only shows 4.1 as being released. metajunkie On 10/24/07, Nick Holland <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > all, > > > > I'm happy to read whatever I need to, in order to get this system > > running. I come before this list humbly. Please don't flame my ass > > with RTFMs :) > > > > I have a new Dell Optiplex 745 with an Intel Core 2 Duo. > > > > this system completed the install. Now on boot it hangs after: > > wskbd1: connecting to wsdisplay0 > > > > the only issue I had during install was that the on-board nic would > > not grab a dhcp address - but the pci nic did. > > > > how can I troubleshoot this further? I followed the FAQ for the > > install - and I've looked at the common issues after install. > > > > years ago I had an issue with a piece of hardware that I had to > > exclude. but I don't recall how I got into that particular "sub > > system" to deactivate it. Is there something I can do at the boot > > prompt? > > > > Humbly yours, > > > > Metajunkie > > > > First, make sure you are trying a snapshot, not 4.1 or older. If > you are using 4.2, still try a snapshot, a lot has happened since > 4.2 already. If that fixes your problem, you are done. (the onboard > NIC problem is hinting to me that you are using an older version). > > If that doesn't, the good news is since it installed with the bsd.rd > kernel but won't run GENERIC, it is probably just a matter of turning > the right device driver off. GENERIC has more in it than bsd.rd does. > > http://www.openbsd.org/faq/faq5.html#BootConfig (see the next two > sections as well, which are also appropriate for you) > > I don't recall if I ever installed OpenBSD on a 745. Certainly did > a fair amount with a 620 (which worked fine). > > Nick. > -- 010101010101010101010101010101010 010101010101010101010101010101010 0101010101 Meta Junkie 101010101010 010101010101010101010101010101010 010101010101010101010101010100101
Re: About Xen: maybe a reiterative question but ..
> only an idiot would think that separatey > physical machines would NOT increase security Many IBM PCs vs IBM mainframe Many mailboxes vs Fort Knox. Many avenues of attack vs few. People learn to count in kindergarden.
Re: new dell install completed, but...
On Wed, Oct 24, 2007 at 08:55:14PM -0400, Nick Holland wrote: > [EMAIL PROTECTED] wrote: > > I have a new Dell Optiplex 745 with an Intel Core 2 Duo. > > > > this system completed the install. Now on boot it hangs after: > > wskbd1: connecting to wsdisplay0 > > > > the only issue I had during install was that the on-board nic would > > not grab a dhcp address - but the pci nic did. > > > > how can I troubleshoot this further? I followed the FAQ for the > > install - and I've looked at the common issues after install. > > > > years ago I had an issue with a piece of hardware that I had to > > exclude. but I don't recall how I got into that particular "sub > > system" to deactivate it. Is there something I can do at the boot > > prompt? > > First, make sure you are trying a snapshot, not 4.1 or older. If > you are using 4.2, still try a snapshot, a lot has happened since > 4.2 already. If that fixes your problem, you are done. (the onboard > NIC problem is hinting to me that you are using an older version). > > If that doesn't, the good news is since it installed with the bsd.rd > kernel but won't run GENERIC, it is probably just a matter of turning > the right device driver off. GENERIC has more in it than bsd.rd does. If you boot the installer, you can read the dmesg from the bsd.rd. At least then you'll know what _not_ to turn off to get the system to boot. > > http://www.openbsd.org/faq/faq5.html#BootConfig (see the next two > sections as well, which are also appropriate for you) Doug.
Re: About Xen: maybe a reiterative question but ..
On Wed, 24 Oct 2007, Brian wrote: > All of the theoretical attack vectors are exactly that: theoretical. > But by adding complex layers does not guarantee any increase in security. They aren't theoretical, they have been demonstrated. Read the paper: http://taviso.decsystem.org/virtsec.pdf
Re: About Xen: maybe a reiterative question but ..
On Wed, Oct 24, 2007 at 08:20:59PM -0500, L. V. Lammert wrote: > On Wed, 24 Oct 2007, Darrin Chandler wrote: > > On Wed, Oct 24, 2007 at 05:44:37PM -0500, L. V. Lammert wrote: > > > At 05:27 PM 10/24/2007 -0500, Tony Abernethy wrote: > > >> L. V. Lammert wrote: > > >> > > > > > > Wow, such intelligence Now we get crap instead of ostrich logic. > > > Sheesh. > > > > Actually, that's a fair assessment at this point. > > > Agreed! You misunderstood my meaning, and I suspect you did it on purpose. > > As someone who reads this list and would like to know more about > > virtualization, pros and cons, I ask you to put more actual meat into > > your posts if you're going to continue. As it stands, fits > > all too well. > > > As you agreed to earlier, your ostrich logic is truly amazing. I haven't been part of this thread until now. I don't have an agenda here, I'd just like something more meaningful on the topic. Apparently I'm not going to get that from you. Ok. I'll keep reading, though, because I'm learning some things from other people who're making some sense and giving reasons. -- Darrin Chandler| Phoenix BSD User Group | MetaBUG [EMAIL PROTECTED] | http://phxbug.org/ | http://metabug.org/ http://www.stilyagin.com/ | Daemons in the Desert | Global BUG Federation
Re: About Xen: maybe a reiterative question but ..
On Wed, 24 Oct 2007, L. V. Lammert wrote: > I still stand by my original statement. Running application 'domains' in > VMs instead of on a single server increases security. It no worse security-wise to run applications on VMs rather than on the one OS, but that isn't the only choice - is it? You obviously didn't read Tavis' virtualisation security paper. VM escape vulnerabilites are not theoretical. Tavis found vulnerabilities in every VM he tested using only a couple of fuzzers. Please stop pretending that virtualisation is about security, it isn't. The benefits are cost savings and decoupling applications from hardware. -d
Re: About Xen: maybe a reiterative question but ..
> The entire point is this: You cannot increase security by putting more > things on one physical server. You can run your different 'Application > Domains' on different physical servers. That is much closer to security > than through obscurity. And when physical servers cost less than some vmware licenses Then it is even more dumb to defend such stupid practices.
Re: About Xen: maybe a reiterative question but ..
On Oct 24, 2007, at 9:20 PM, L. V. Lammert wrote: On Wed, 24 Oct 2007, Darrin Chandler wrote: Looking at what you've written, you seem to consider OpenBSD to be pretty secure. By extension, let's assume the developers, and Theo in particular, have some darned good knowledge about security and some priorities in that regard. Then, when Theo and developers (and others in this community) weigh in and tell you that virtualization is not more secure, but less, you continue and continue. Well, since a lot of people on this list like to continue diverting the discussion way out in space with far reaching, unrelated tangential arguments, I can only say that this discussion has descend well below any level of utilization. You apparently missed my post. Allow me to re-summarize the situation. There is *nothing* in any virtualization software that makes having it *more secure* than not having it at all. Is that direct enough for you? --- Jason Dixon DixonGroup Consulting http://www.dixongroup.net
Re: About Xen: maybe a reiterative question but ..
L. V. Lammert wrote: The more discrete the security model (i.e. File/Print users are not valid on the httpd server) the better. There's something I think you don't see here. Let's assume, for a moment, that you have a VM host running two guests, one OpenBSD, one Windows. Now, the OpenBSD box is reasonably secure. The Windows box, perhaps, is not quite so secure. An attacker compromises your Windows box. He discovers that the machine is running in a VM, and uses a vulnerability in the virtualization server to execute code on the host itself. Now, he can edit the memory of the OpenBSD guest, read/copy the disk, whatever. Even encryption doesn't help, you can just read the keys out of RAM. The OpenBSD guest is completely compromised, without exploiting any vulnerability in OpenBSD itself. Theo's point (I think) is that x86 virtualization is so hopelessly complex that there's no way a human could account for every possible attack. That's why x86 virtualization reduces security. I use VMware all the time, I just don't pretend it's a way to increase security.
Re: About Xen: maybe a reiterative question but ..
L. V. Lammert wrote: > On Wed, 24 Oct 2007, Brian wrote: > >> Hi! >> >> I think you are missing the point about x86 hardware being a mess. Theo >> made an excellent point about the architecture itself having so many >> filthy quirks. If a VM is compromised through any means, that attacker >> can now leverage the dirty architecture to bypass the hypervisors >> (supposed) isolation techniques. If the attacker can utilize the VM to >> infiltrate the hypervisor, even more damage can be done. >> >> The entire point is this: You cannot increase security by putting more >> things on one physical server. You can run your different 'Application >> Domains' on different physical servers. That is much closer to security >> than through obscurity. >> >> -Brian >> > Hi! > > Sorry, it's YOU that missed the point! I never said or made any comparison > to physical machines - the entirety of that I said is: > > "Running services/application domains in VMs increases security." As I > said in a previous email, only an idiot would think that separatey > physical machines would NOT increase security, and I give this crowd much > more credit than that so I did not bother to include such information. > > I still stand by my original statement. Running application 'domains' in > VMs instead of on a single server increases security. > > Lee Quoted directly from your first e-mail on this subject: "Virtualization provides near absolute security - DOM0 is not visible to the user at all, only passing network traffic and handling kernel calls. The security comes about in that each DOMU is totally isolated from the the others, while the core DOM0 is isolated from any attacks." Your first sentence is provoking these responses. You cannot make this claim unless you are 100% certain the virtualization layer is bug free. If theres a bug in the virtualization layer that allows a NORMAL USER [1] in any of the guests to compromise the VM layer, host, or any of the guests, the user has just escalated his privileges through a vector that would never have been there outside of this VM environment. Do you see what we're saying now? You are adding a complex layer of software to isolate things, when in fact you have no guarantee this layer cannot cause an escalation by a normal user. All of the theoretical attack vectors are exactly that: theoretical. But by adding complex layers does not guarantee any increase in security. If your application 'domains' are properly isolated on a single server, by privilege separation and chroot'ing processes, all you have left to worry about is that NORMAL USER escalating his privileges through some unknown bug in the OS you choose to run. You do not have to worry about the complex VM layer having its own set of unknown bugs. So, in the end, you are still not getting the point. There are possible attack vectors in both single server setups, and virtualized setups. By making the claim that security is increased by virtualizing is fundamentally wrong. You just don't know of or have heard of any significant holes in the virtualization layers yet (minus vmware tools). -Brian [1] Think Dom0's job of virtualizing hardware for the guests. If there is some obscure bug in the Dom0's code, it could be possible for the normal user inside the guest to provoke this bug through the guest OS into causing DoS or possibly worse. I don't know of any bugs myself, but the attack vector may exist and can become an entire class of security holes. [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: About Xen: maybe a reiterative question but ..
On 10/24/07, L. V. Lammert <[EMAIL PROTECTED]> wrote: > Sorry, it's YOU that missed the point! I never said or made any comparison > to physical machines - the entirety of that I said is: > > "Running services/application domains in VMs increases security." As I > said in a previous email, only an idiot would think that separatey > physical machines would NOT increase security, and I give this crowd much > more credit than that so I did not bother to include such information. > > I still stand by my original statement. Running application 'domains' in > VMs instead of on a single server increases security. What you're saying, appears to be: 1) 3 applications in one OS - less secure. 2) 3 applications in 3 physical servers - more secure 3) 3 applications in 3 virtual servers each running one OS - in between #1 and #2 for security What the others are telling you is that you are wrong. While there is a continuum, is it closer to #1 or #2? I believe it is closer to #1. This is because, nobody has done an independent security audit of the VMWare ESX platform. When we say something is more secure, we can show it in 2 ways - a track history, like openbsd, or some 3rd party verification, fips, orange book, certification, whatever. ESX's recent history is extremely damaging. Again, go look up all the advisories. Taking over a guest allows taking over a host?!?!?! Where is your "separation" again?! And yes, you did not specify VMWare in your statement. But the vulnerabilities being exploited in VMWare shows that the same kind of attacks can be made against other VMs. And you do understand the history of how the x86 platform came to be, right? IBM wanted to dip their toe in that "microcomputer" thing that had the world so excited. Gave the head guy 9 months, or kill the project. So, the revisionists now adays say "we use off the shelf products to be compatible" is bullshit, they had a strict time limit, and could design and fab their own cpu and other things. Looked around, checked out the motorola and intel CPUs. Hey, lookie here, the intel cpu's spec book comes with an appendix full of interesting shit. Look, they even have a simple design for a microcomputer you can build with their cpu. So, IBM basically took that design, and built a PC, and sold it. Why do you think while IRQ 5 has higher priority than 6 (lower IRQ has higher priorty), but IRQ 10 has higher priority than IRQ 5?!?! Because the original design had *8* slots, and *8* IRQs, but a bunch was taken up by the system, and so you couldn't actually use all 8 slots. So, in PC/XT, they kludged something in. And then the 8088 -> 8086 or thereabouts happened, what did Intel do? Gee, we have this 32 bits of memory space, should we let them use it all? Nah, just use 20 bits and mask the rest of that shit out. So, the PC we have today is full of legacy shit, each piece lovingly crafted on top of another, built like a freaking tower. So, when Theo says the hardware itself is shit, and impossible to virtualize, I believe him. And when he says x86 virtualization is shits because of the hardware, I believe him. And when Secunia comes out with all its advisories against ESX, wow, I guess Theo did know what he was talking about. -- "This officer's men seem to follow him merely out of idle curiosity." -- Sandhurst officer cadet evaluation.
Re: About Xen: maybe a reiterative question but ..
On 10/24/07, Henning Brauer <[EMAIL PROTECTED]> wrote: > * Darren Spruell <[EMAIL PROTECTED]> [2007-10-24 21:48]: > > Remember back 10-ish years ago when VLANs were being touted as the > > ultimate network segmentation technology by marketers of managed > > switches? And now everyone hopefully realizes that while VLANs > > technically do offer network segmentation, it's really rudimentary and > > cannot be relied on for truly reliable security due to various layer 2 > > attacks that subvert them? > > err, that is a very bad comparision. I am not aware of any "layer2 > attacks" (you probably mean vlan hopping things) that work against any > half reasonable configured switch from the last 10 years. > heck, these days even everybody except cisco has sane defaults. > (well, I dunno about those cheap switches, admittedly) I agree, the key is the reasonably configured part. Vlan hopping, STP attacks, etc. and Cisco particularly. Even if Cisco is (now) one of the few to not have sane defaults, they're common enough for it to be a concern. And consider all the devices (even from good vendors) that are behind on firmware (where the defaults weren't yet sane). If this wasn't the case, Yersinia wouldn't be nearly as interesting as it is. > this comparision is wrong on another basis: vlans are dead simple, just > a tiny and simple header before the ethernet segment. virtualization is > certainly not. Yeah, I was commenting mainly on the flawed "silver bullet" mentality that some LAN admins have with the "if I have VLANs, my hosts are automatically perfectly segmented" mindset rather than the implementation/design itself. Sadly, the average LAN admin these days, at least in the states, isn't smart enough to understand the nuances. DS
Re: About Xen: maybe a reiterative question but ..
On Wed, 24 Oct 2007, Jeremy Huiskamp wrote: > On 24-Oct-07, at 5:59 PM, L. V. Lammert wrote: > > At 03:31 PM 10/24/2007 -0600, Theo de Raadt wrote: > >> You must be more qualified with regards to the actual code than I am > >> because I flat out don't believe this at all. > > > > Believe what? OBSD is secure? I thought you were proud of the > > project? Sheesh! If our leader doesn't believe OBSD is secure, we > > ALL better be running for cover. Linux, anyone? > > So you judge the security of the operating system by how many > (possibly brash) risks its developers are willing to take with it? > Huh? What does that have to do with the number of known exploits for a given OS? A simple measure of an OS 'security' is the simple metrics of known exploits that have been identified. Certainly OBSD ranks high on the list, which is one reason why we're here. Certailny good developers are important and appreciated. The fact that Microshaft crap has hundreds or thousands of vulnerabilities is the other extreme of the list. > That's counter-intuitive. If I'm looking for security, I'd rather > get my software from a developer who isn't satisfied because (s)he is > more likely to work harder to improve it and be much more careful > while doing it. If confidence is all that matters, then heck, lets > get rid of all the privilege separation and other risk-minimizing > techniques because you don't need them when your code is flawless right? > I have no clue what you're trying to say??? The original comment was the the number of vulnerabilities is a inverse measure of the security risk associated with a given OS. Lee Leland V. Lammert[EMAIL PROTECTED] Chief Scientist Omnitec Corporation Network/Internet Consultants www.omnitec.net
Re: About Xen: maybe a reiterative question but ..
On Wed, 24 Oct 2007, Darrin Chandler wrote: > On Wed, Oct 24, 2007 at 05:44:37PM -0500, L. V. Lammert wrote: > > At 05:27 PM 10/24/2007 -0500, Tony Abernethy wrote: > >> L. V. Lammert wrote: > >> > > > > Wow, such intelligence Now we get crap instead of ostrich logic. > > Sheesh. > > Actually, that's a fair assessment at this point. > Agreed! > Looking at what you've written, you seem to consider OpenBSD to be > pretty secure. By extension, let's assume the developers, and Theo in > particular, have some darned good knowledge about security and some > priorities in that regard. Then, when Theo and developers (and others in > this community) weigh in and tell you that virtualization is not more > secure, but less, you continue and continue. > Well, since a lot of people on this list like to continue diverting the discussion way out in space with far reaching, unrelated tangential arguments, I can only say that this discussion has descend well below any level of utilization. So far, nobody has bother to substiante the argument against the hypothesis, so the past 50 posts or so have just been entertainment. > As someone who doesn't know a great deal about virtualization, I can > tell you that you're not convincing me of anything with your arguments. > I feel confident in saying that you're not convincing any of the devs, > either. And I doubt you've done much for this cause with the list > members at large. > > So what the hell are you doing? Just flaming now? Gave up trying to show > something and just trying to get a few jabs in? > The points were made, and have been stated on at least numerous occasions. Nobody has offerred any logic to refute them, only mis-directing the disussion by bring more and more off-topic distractions. > As someone who reads this list and would like to know more about > virtualization, pros and cons, I ask you to put more actual meat into > your posts if you're going to continue. As it stands, fits > all too well. > As you agreed to earlier, your ostrich logic is truly amazing. Lee == Leland V. Lammert[EMAIL PROTECTED] Chief Scientist Omnitec Corporation Network/Internet Consultants www.omnitec.net
Re: About Xen: maybe a reiterative question but ..
On Wed, 24 Oct 2007, Brian wrote: > Hi! > > I think you are missing the point about x86 hardware being a mess. Theo > made an excellent point about the architecture itself having so many > filthy quirks. If a VM is compromised through any means, that attacker > can now leverage the dirty architecture to bypass the hypervisors > (supposed) isolation techniques. If the attacker can utilize the VM to > infiltrate the hypervisor, even more damage can be done. > > The entire point is this: You cannot increase security by putting more > things on one physical server. You can run your different 'Application > Domains' on different physical servers. That is much closer to security > than through obscurity. > > -Brian > Hi! Sorry, it's YOU that missed the point! I never said or made any comparison to physical machines - the entirety of that I said is: "Running services/application domains in VMs increases security." As I said in a previous email, only an idiot would think that separatey physical machines would NOT increase security, and I give this crowd much more credit than that so I did not bother to include such information. I still stand by my original statement. Running application 'domains' in VMs instead of on a single server increases security. Lee
Re: Problem with raid 1 in server dell
Josi Christian Rodrmguez wrote:
> Hi list,
> My system was freeze and when reboot show:
>
> /dev/rsd0a: file system is clean;not checking
> /dev/rsd0d: file system is clean;not checking
> /dev/rsd0e: file system is clean;not checking
> /dev/rsd0g: INCORRECT BLOCK COUNT I=2699655 (20 should be 16) (CORRECTED)
> PARTIALLY TRUNCATED INODE I=19268881
> /dev/rsd0g:UNEXPECTED INCONSISTENCY; RUN fsck_ffs MANUALLY.
> THE FOLLOWING FILE SYSTEN HAD AN UNEXPECTED INCOSISTENCY:
> ffs: /dev/rsd0g(/var)
> Automatic File system check failed: help!
> Enter pathname of shell or RETURN for sh:
>
>
>
> I think this problem is for incompatibility with raid controler SAS5IR, but in
> the openbsd page say this hardware is support.
> I have two harddisk SATA Raid 1
You haven't convinced me of an actual problem here.
Your file system on sd0a is messed up (it happens when you have
lockups like you say you did) but why do you say it is not compatible?
Nick.
>
> dmesg
>
> OpenBSD 4.1-stable (GENERIC.MP) #0: Wed Oct 10 10:43:00 MDT 2007
> [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC.MP
> cpu0: Intel(R) Xeon(R) CPU 3050 @ 2.13GHz ("GenuineIntel" 686-class) 2.14 GHz
> cpu0:
> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
> H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,CX16,
> xTPR
> real mem = 2146795520 (2096480K)
> avail mem = 1952034816 (1906284K)
> using 4278 buffers containing 107462656 bytes (104944K) of memory
> mainbus0 (root)
> bios0 at mainbus0: AT/286+ BIOS, date 04/04/07, BIOS32 rev. 0 @ 0xffe90,
> SMBIOS rev. 2.4 @ 0xfa5b0 (48 entries)
> bios0: Dell Computer Corporation PowerEdge 860
> pcibios0 at bios0: rev 2.1 @ 0xf/0x1
> pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfba60/176 (9 entries)
> pcibios0: PCI Interrupt Router at 000:31:0 ("Intel 82801GB LPC" rev 0x00)
> pcibios0: PCI bus #7 is the last bus
> bios0: ROM list: 0xc/0x9000 0xc9000/0x1000 0xca000/0x5c00 0xd/0x1800
> 0xec000/0x4000!
> acpi at mainbus0 not configured
> ipmi0 at mainbus0: version 1.5 interface KCS iobase 0xca8/8 spacing 4
> mainbus0: Intel MP Specification (Version 1.4)
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: apic clock running at 266 MHz
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: Intel(R) Xeon(R) CPU 3050 @ 2.13GHz ("GenuineIntel" 686-class) 2.14 GHz
> cpu1:
> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
> H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,CX16,
> xTPR
> mainbus0: bus 0 is type PCI
> mainbus0: bus 1 is type PCI
> mainbus0: bus 2 is type PCI
> mainbus0: bus 3 is type PCI
> mainbus0: bus 4 is type PCI
> mainbus0: bus 5 is type PCI
> mainbus0: bus 6 is type PCI
> mainbus0: bus 7 is type PCI
> mainbus0: bus 8 is type ISA
> ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
> ioapic0: misconfigured as apic 0, remapped to apid 2
> pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
> pchb0 at pci0 dev 0 function 0 "Intel E7230 MCH" rev 0x00
> ppb0 at pci0 dev 1 function 0 "Intel E7230 PCIE" rev 0x00
> pci1 at ppb0 bus 1
> ppb1 at pci1 dev 0 function 0 "Intel PCIE-PCIE" rev 0x09
> pci2 at ppb1 bus 2
> mpi0 at pci2 dev 8 function 0 "Symbios Logic SAS1068" rev 0x01: apic 2 int 16
> (irq 5)
> scsibus0 at mpi0: 112 targets
> sd0 at scsibus0 targ 0 lun 0: SCSI3 0/direct fixed
> sd0: 237464MB, 237464 cyl, 16 head, 128 sec, 512 bytes/sec, 486326272 sec
> total
> "Intel IOxAPIC" rev 0x09 at pci1 dev 0 function 1 not configured
> ppb2 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x01
> pci3 at ppb2 bus 3
> ppb3 at pci3 dev 0 function 0 "ServerWorks PCIE-PCIX" rev 0xc3
> pci4 at ppb3 bus 4
> bnx0 at pci4 dev 0 function 0 "Broadcom BCM5708" rev 0x12: apic 2 int 16 (irq
> 5)
> ppb4 at pci0 dev 28 function 4 "Intel 82801G PCIE" rev 0x01
> pci5 at ppb4 bus 5
> bge0 at pci5 dev 0 function 0 "Broadcom BCM5721" rev 0x11, BCM5750 B1
> (0x4101): apic 2 int 16 (irq 5), address 00:19:b9:f7:a7:0a
> brgphy0 at bge0 phy 1: BCM5750 10/100/1000baseT PHY, rev. 0
> ppb5 at pci0 dev 28 function 5 "Intel 82801G PCIE" rev 0x01
> pci6 at ppb5 bus 6
> bge1 at pci6 dev 0 function 0 "Broadcom BCM5721" rev 0x11, BCM5750 B1
> (0x4101): apic 2 int 17 (irq 3), address 00:19:b9:f7:a7:0b
> brgphy1 at bge1 phy 1: BCM5750 10/100/1000baseT PHY, rev. 0
> uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x01: apic 2 int 20
> (irq 11)
> usb0 at uhci0: USB revision 1.0
> uhub0 at usb0
> uhub0: Intel UHCI root hub, rev 1.00/1.00, addr 1
> uhub0: 2 ports with 2 removable, self powered
> uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x01: apic 2 int 21
> (irq 10)
> usb1 at uhci1: USB revision 1.0
> uhub1 at usb1
> uhub1: Intel UHCI root hub, rev 1.00/1.00, addr 1
> uhub1: 2 ports with 2 removable, self powered
> uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev 0x01: apic 2 int 22
> (irq 6)
> usb2 at uhci2: USB revision 1.0
> uhub2 at usb2
> uhub2: Intel UHCI roo
Re: About Xen: maybe a reiterative question but ..
L. V. Lammert <[EMAIL PROTECTED]> wrote: >> > If not, then security issues compound due to multiple guest OSs and >> each set >> > of inherent vulnerabilities. >> >>security issues and protections do not add up like numbers. > > Sure they do. If I'm running Windoze as a guest OS, there are hundreds or > thousands of possible vulnerabilities. If I'm runng OBSD as a guest OS, > guess what (I hope you don't have to??) - few to none. There is no way to > 'compound threat [interaction]', but that doesn't detract from the basic > truth - the lower the risk/number of vulnerabilities of the OS, the better > off you are. As a corollary, you might also say that there is no way to > improve the security of a server without improving the security of the OS. This has *nothing* to do with VM security. The issue with VM security is that: 1. if any guest is compromised you all guests and the host are in danger. 2. if any user or admininstrator of a guest is malicious, all guests and the host is in danger. This threat is NOT because of any possible interaction (network/services etc.) between the guests and/or the host. It is because of a completely different attack vector, the VM system. The 'virtual hardware' that *all* host and guest OS systems implicitly trust to behave well can be subverted. You should NEVER trust a virtual machine to properly isolate the guests. It is a good approximation to having separate boxes, but it is NOT a security barrier. >> > No matter how you twist the logic, however, a VM provides a good level of >> > application domain security, from the standpoint that each set of domain >> > users and applications can only see the services provided within that >> > domain guest OS. >> >>The phrase "application domain security" is a cover-up statement that >>means "I have already decided to run the multiple things on one box >>because I am cheap, and I need to invent reasons why I can continue >>doing so". > > Huh?? Do you know what an application domain is? Guess not - here's a > definition: > > Application + Users + Access Method = Application Domain > > Examples: File/Print, httpd, DB, . . . > > The more discrete the security model (i.e. File/Print users are not valid > on the httpd server) the better. What you try to describe in a somewhat clumsy and round about way corresponds to moving different "applications" to their respective/isolated machines. This is actually a good thing to do for security. However, depending on the applications and the interactions between them, you may sometimes end up being with a more complex/less secure architecture. But this is not the point. What you fail to realize is that, when you try to implement this using a VM system, you actually break the isolation. The fact that well behaved applications and OS's work peacefully side by side under a VM setup DOES NOT mean that a malicious program and/or user is not able to break that isolation. Consider a web application login form with an SQL injection vulnerability. It validates the users and works perfectly fine %100 of the time, passes all tests. Denies incorrect passwords etc. UNTIL one malicious user decides to enter ' or 1=1;-- as his password. In a VM system the security of the *entire* system depends on the weakest link in only one of the OS's. To continue your example, you can install as many OpenBSD guests as you like. It takes one windows/linux whatever guest to break them all. That is why the protections do not 'add up'. Can
Re: new dell install completed, but...
[EMAIL PROTECTED] wrote: > all, > > I'm happy to read whatever I need to, in order to get this system > running. I come before this list humbly. Please don't flame my ass > with RTFMs :) > > I have a new Dell Optiplex 745 with an Intel Core 2 Duo. > > this system completed the install. Now on boot it hangs after: > wskbd1: connecting to wsdisplay0 > > the only issue I had during install was that the on-board nic would > not grab a dhcp address - but the pci nic did. > > how can I troubleshoot this further? I followed the FAQ for the > install - and I've looked at the common issues after install. > > years ago I had an issue with a piece of hardware that I had to > exclude. but I don't recall how I got into that particular "sub > system" to deactivate it. Is there something I can do at the boot > prompt? > > Humbly yours, > > Metajunkie > First, make sure you are trying a snapshot, not 4.1 or older. If you are using 4.2, still try a snapshot, a lot has happened since 4.2 already. If that fixes your problem, you are done. (the onboard NIC problem is hinting to me that you are using an older version). If that doesn't, the good news is since it installed with the bsd.rd kernel but won't run GENERIC, it is probably just a matter of turning the right device driver off. GENERIC has more in it than bsd.rd does. http://www.openbsd.org/faq/faq5.html#BootConfig (see the next two sections as well, which are also appropriate for you) I don't recall if I ever installed OpenBSD on a 745. Certainly did a fair amount with a 620 (which worked fine). Nick.
Re: Problem with disk size
Jon Sjvstedt wrote: > Hello all! > > I have an OpenBSD-box with two 250G drives inside (and some SCSI). Trying > to use one of the drives as a whole gave this from disklabel > > > $ sudo disklabel -p g wd0 > [snip] don't snip. > 16 partitions: > # sizeoffset fstype [fsize bsize cpg] > c:233.8G 0.0G unused 0 0 # Cyl 0-486343 > d:233.8G 0.0G 4.2BSD 2048 16384 16 # Cyl > 0*-486343* > > but df -h says: > > /dev/wd0d 7.8G7.4G4.2M 100% > > and I cant create any new files on the drive. What could be the problem > here? Any hints appreciated. > > dmesg attached. thanks for the dmesg. You tried darned hard to obscure this (I really don't care how many G your disk is, I care about which sectors you are using), but it does appear that you opted to not properly partition your disk. The fact that you didn't show the output of fdisk causes me to believe you knew it, though you may not have recognized the significance. ;) Your OpenBSD subpartition appears to start at sector zero. Bad idea. This means, whether by design or by accident, you don't have an fdisk partition table (aka, MBR) on the disk. Also a bad idea. On some platforms, i386 is one of them, you must use fdisk partitions, and your disklabel partitions must start at a one track offset (in your case, probably 63 sectors). When you don't follow the rules, ugly things happen. It isn't the size of the disk, it's the way it's laid out that is giving you problems. See faq14.html... Nick.
Re: About Xen: maybe a reiterative question but ..
On Wed, Oct 24, 2007 at 05:44:37PM -0500, L. V. Lammert wrote: > At 05:27 PM 10/24/2007 -0500, Tony Abernethy wrote: >> L. V. Lammert wrote: >> > > Wow, such intelligence Now we get crap instead of ostrich logic. > Sheesh. Actually, that's a fair assessment at this point. Looking at what you've written, you seem to consider OpenBSD to be pretty secure. By extension, let's assume the developers, and Theo in particular, have some darned good knowledge about security and some priorities in that regard. Then, when Theo and developers (and others in this community) weigh in and tell you that virtualization is not more secure, but less, you continue and continue. As someone who doesn't know a great deal about virtualization, I can tell you that you're not convincing me of anything with your arguments. I feel confident in saying that you're not convincing any of the devs, either. And I doubt you've done much for this cause with the list members at large. So what the hell are you doing? Just flaming now? Gave up trying to show something and just trying to get a few jabs in? As someone who reads this list and would like to know more about virtualization, pros and cons, I ask you to put more actual meat into your posts if you're going to continue. As it stands, fits all too well. -- Darrin Chandler| Phoenix BSD User Group | MetaBUG [EMAIL PROTECTED] | http://phxbug.org/ | http://metabug.org/ http://www.stilyagin.com/ | Daemons in the Desert | Global BUG Federation
Re: About Xen: maybe a reiterative question but ..
Hi! I think you are missing the point about x86 hardware being a mess. Theo made an excellent point about the architecture itself having so many filthy quirks. If a VM is compromised through any means, that attacker can now leverage the dirty architecture to bypass the hypervisors (supposed) isolation techniques. If the attacker can utilize the VM to infiltrate the hypervisor, even more damage can be done. The entire point is this: You cannot increase security by putting more things on one physical server. You can run your different 'Application Domains' on different physical servers. That is much closer to security than through obscurity. -Brian L. V. Lammert wrote: > At 03:31 PM 10/24/2007 -0600, Theo de Raadt wrote: >> > Certainly there is a small, compount risk increase due to multiple OS >> > images involved, but the OS images must be analyzed independently >> FIRST, >> > and THOSE risks addressed. >> >> Certainly you pulled that assesment out of your ass. > > I thought it was obvious, .. but I know you have beter things on your > mind. I DO mind you liking my ass, however - ain't gonna happen. > >> > **IF** OBSD were available as a host OS, that would be good security. >> >> You must be more qualified with regards to the actual code than I am >> because I flat out don't believe this at all. > > Believe what? OBSD is secure? I thought you were proud of the project? > Sheesh! If our leader doesn't believe OBSD is secure, we ALL better be > running for cover. Linux, anyone? > > If you're saying that OBSD will never be modified to run AS a XEN > hypervisor, that's probably a true statement. No need to corrupt a > decent OS with GPL s/w. > >> > If not, then security issues compound due to multiple guest OSs and >> each set >> > of inherent vulnerabilities. >> >> security issues and protections do not add up like numbers. > > Sure they do. If I'm running Windoze as a guest OS, there are hundreds > or thousands of possible vulnerabilities. If I'm runng OBSD as a guest > OS, guess what (I hope you don't have to??) - few to none. There is no > way to 'compound threat [interaction]', but that doesn't detract from > the basic truth - the lower the risk/number of vulnerabilities of the > OS, the better off you are. As a corollary, you might also say that > there is no way to improve the security of a server without improving > the security of the OS. > >> > No matter how you twist the logic, however, a VM provides a good >> level of >> > application domain security, from the standpoint that each set of >> domain >> > users and applications can only see the services provided within that >> > domain guest OS. >> >> The phrase "application domain security" is a cover-up statement that >> means "I have already decided to run the multiple things on one box >> because I am cheap, and I need to invent reasons why I can continue >> doing so". > > Huh?? Do you know what an application domain is? Guess not - here's a > definition: > > Application + Users + Access Method = Application Domain > > Examples: File/Print, httpd, DB, . . . > > The more discrete the security model (i.e. File/Print users are not > valid on the httpd server) the better. > > Lee [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
sanely designed hardware?
After enjoying the Xen thread, and the comments about the horrid mess that is x86 hardware design, I'm wondering what hardware on which OpenBSD will run _is_ well designed. Who makes a hardware architecture that is open (enough) that OpenBSD can run fully on it, that has good performance. I'm assuming that its not COTS an so will cost more than x86. Note that I'm not asking: who makes good hardware on which we can then run Xen. I'm talking about a solid piece of hardware on which to run one and only one OpenBSD. Doug.
Re: About Xen: maybe a reiterative question but ..
On 24-Oct-07, at 5:59 PM, L. V. Lammert wrote: At 03:31 PM 10/24/2007 -0600, Theo de Raadt wrote: You must be more qualified with regards to the actual code than I am because I flat out don't believe this at all. Believe what? OBSD is secure? I thought you were proud of the project? Sheesh! If our leader doesn't believe OBSD is secure, we ALL better be running for cover. Linux, anyone? So you judge the security of the operating system by how many (possibly brash) risks its developers are willing to take with it? That's counter-intuitive. If I'm looking for security, I'd rather get my software from a developer who isn't satisfied because (s)he is more likely to work harder to improve it and be much more careful while doing it. If confidence is all that matters, then heck, lets get rid of all the privilege separation and other risk-minimizing techniques because you don't need them when your code is flawless right?
Re: How can i boot a bsd.rd from windows 2000 ?
Christopher Bianchi skrev: Hello everyone. My situation is this: i've a laptop, a Sharp pc-ax10 with Windows 2000 preinstalled , without cdrom, floppy. I wish install OpenBSD on it. Naturally bios can't boot from USB. So i've thinked to boot the bsd.rd , but how ? The faq explain the procedure from an older OpenBSD operating system... i've Windows 2000 on it. Is it possible ? and if is possible, in which way ? Where i must put the bsd.rd and in which way i can boot from him ? If all other booting possibilities were unavailable, I'd try this (though I cannot say for sure it'd work): first: BACKUP BACKUP BACKUP BACKUP BACKUP BACKUP BACKUP BACKUP BACKUP BACKUP BACKUP BACKUP BACKUP BACKUP BACKUP BACKUP BACKUP BACKUP BACKUP BACKUP (well no, I would probably not, but it's strongly recommended) and then, - make room for bsd partition with e.g. Partition Magic. - create a primary partition (of any type) to use for the OpenBSD install. You'll probably have to change the type to A6 in fdisk during the OpenBSD install. - create a virtual machine in vmware that uses the physical disk and a virtual cdrom (with mounted installXX.iso). Install openbsd carefully TO THE FREE'D PARTITION ONLY - do NOT ``use the entire disk for openbsd''! (Yes, this requires some fiddling with fdisk manually, but having a Windows tool creating the partition with the right offset and size helps a lot - then you only need to change the type). - After the installation is done, copy the mbr (as per the FAQ mentioned earlier in the thread) to the windows machine via network, usb stick, whatever. - Throw the mbr into 'C:\openbsd.mbr' and fix C:\boot.ini (FAQ too). - Boot your favourite os and don't forget: BACKUP BACKUP BACKUP BACKUP BACKUP BACKUP BACKUP BACKUP BACKUP BACKUP BACKUP BACKUP BACKUP BACKUP BACKUP BACKUP BACKUP BACKUP BACKUP BACKUP cheers /Alexander
Problem with disk size
Hello all!
I have an OpenBSD-box with two 250G drives inside (and some SCSI). Trying
to use one of the drives as a whole gave this from disklabel
$ sudo disklabel -p g wd0
[snip]
16 partitions:
# sizeoffset fstype [fsize bsize cpg]
c:233.8G 0.0G unused 0 0 # Cyl 0
-486343
d:233.8G 0.0G 4.2BSD 2048 16384 16 # Cyl
0*-486343*
but df -h says:
/dev/wd0d 7.8G7.4G4.2M 100%
and I cant create any new files on the drive. What could be the problem
here? Any hints appreciated.
dmesg attached.
<>
Jon Sjvstedt _O_
OpenBSD 3.9 (GENERIC) #617: Thu Mar 2 02:26:48 MST 2006
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel Pentium III ("GenuineIntel" 686-class) 665 MHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE
real mem = 536387584 (523816K)
avail mem = 482426880 (471120K)
using 4278 buffers containing 26923008 bytes (26292K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+(00) BIOS, date 05/31/00, BIOS32 rev. 0 @ 0xfdae0
apm0 at bios0: Power Management spec V1.2
apm0: AC on, battery charge unknown
apm0: flags 30102 dobusy 0 doidle 1
pcibios0 at bios0: rev 2.1 @ 0xf/0x1
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf7710/176 (9 entries)
pcibios0: PCI Interrupt Router at 000:07:0 ("VIA VT82C686 ISA" rev 0x00)
pcibios0: PCI bus #1 is the last bus
bios0: ROM list: 0xc/0x1 0xd/0x8000
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 "VIA VT82C691 PCI" rev 0xc4
ppb0 at pci0 dev 1 function 0 "VIA VT82C598 AGP" rev 0x00
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 "NVIDIA Riva TNT2" rev 0x15
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
pcib0 at pci0 dev 7 function 0 "VIA VT82C686 ISA" rev 0x1b
uhci0 at pci0 dev 7 function 2 "VIA VT83C572 USB" rev 0x0e: irq 12
usb0 at uhci0: USB revision 1.0
uhub0 at usb0
uhub0: VIA UHCI root hub, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhci1 at pci0 dev 7 function 3 "VIA VT83C572 USB" rev 0x0e: irq 12
usb1 at uhci1: USB revision 1.0
uhub1 at usb1
uhub1: VIA UHCI root hub, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
viaenv0 at pci0 dev 7 function 4 "VIA VT82C686 SMBus" rev 0x20
ahc0 at pci0 dev 9 function 0 "Adaptec AHA-2940U" rev 0x00: irq 10
scsibus0 at ahc0: 16 targets
sd0 at scsibus0 targ 0 lun 0: SCSI2 0/direct fixed
sd0: 8683MB, 6962 cyl, 12 head, 212 sec, 512 bytes/sec, 17783240 sec total
sd1 at scsibus0 targ 1 lun 0: SCSI2 0/direct fixed
sd1: 8683MB, 6962 cyl, 12 head, 212 sec, 512 bytes/sec, 17783240 sec total
sd2 at scsibus0 targ 2 lun 0: SCSI3 0/direct fixed
sd2: 8748MB, 11474 cyl, 5 head, 312 sec, 512 bytes/sec, 17916240 sec total
cd0 at scsibus0 targ 3 lun 0: SCSI4 5/cdrom
removable
pciide0 at pci0 dev 10 function 0 "CMD Technology PCI0680" rev 0x02
pciide0: bus-master DMA support present
pciide0: channel 0 configured to native-PCI mode
pciide0: using irq 9 for native-PCI interrupt
wd0 at pciide0 channel 0 drive 0:
wd0: 16-sector PIO, LBA48, 239372MB, 490234752 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5
pciide0: channel 1 configured to native-PCI mode
wd1 at pciide0 channel 1 drive 0:
wd1: 16-sector PIO, LBA48, 239372MB, 490234752 sectors
wd1(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 5
dc0 at pci0 dev 11 function 0 "Davicom DM9102" rev 0x31: irq 12, address
00:80:ad:72:3b:17
amphy0 at dc0 phy 1: DM9102 10/100 PHY, rev. 0
emu0 at pci0 dev 12 function 0 "Creative Labs SoundBlaster Live" rev 0x05: irq
11
ac97: codec id 0x54524123 (TriTech Microelectronics TR28602)
audio0 at emu0
"Creative Labs PCI Gameport Joystick" rev 0x05 at pci0 dev 12 function 1 not
configured
isa0 at pcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
midi0 at pcppi0:
spkr0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
npx0 at isa0 port 0xf0/16: using exception 16
pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
pccom1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec
isapnp0 at isa0 port 0x279: read port 0x203
"Maxi Sound 64 Series, ESS8600, , " at isapnp0 port 0x800/8 not configured
"Maxi Sound 64 Series, ESS8601, , " at isapnp0 port 0x220/16,0x388/4,0x300/2
irq 5 drq 1,0 not configured
"Maxi Sound 64 Series, ESS8602, , " at isapnp0 port 0x201/1 not configured
"Maxi Sound 64 Series, ESS8603, , " at isapnp0 port 0x330/6 irq 5 not configured
biomask f765 netmask f765 ttymask f7e7
pctr: 686-class user-level performance counters enabled
mtrr: Pentium Pro MTRR support
ahc0: target 0 using 16bit transfers
ahc0: target 0 synchronous
Re: About Xen: maybe a reiterative question but ..
On Oct 24, 2007, at 3:41 PM, Theo de Raadt wrote: > We know what a VM operating system has to do to deal with the PC > architecture. It is too complex to get perfectly right. I concur with this assessment and the discussion of actual x86 PC implementation vs. 390 architecture which led up to it. -- Jack J. Woehr Director of Development Absolute Performance, Inc. [EMAIL PROTECTED] 303-443-7000 ext. 527
new dell install completed, but...
all, I'm happy to read whatever I need to, in order to get this system running. I come before this list humbly. Please don't flame my ass with RTFMs :) I have a new Dell Optiplex 745 with an Intel Core 2 Duo. this system completed the install. Now on boot it hangs after: wskbd1: connecting to wsdisplay0 the only issue I had during install was that the on-board nic would not grab a dhcp address - but the pci nic did. how can I troubleshoot this further? I followed the FAQ for the install - and I've looked at the common issues after install. years ago I had an issue with a piece of hardware that I had to exclude. but I don't recall how I got into that particular "sub system" to deactivate it. Is there something I can do at the boot prompt? Humbly yours, Metajunkie -- 010101010101010101010101010101010 010101010101010101010101010101010 0101010101 Meta Junkie 101010101010 010101010101010101010101010101010 010101010101010101010101010100101
Re: About Xen: maybe a reiterative question but ..
At 05:27 PM 10/24/2007 -0500, Tony Abernethy wrote: L. V. Lammert wrote: Wow, such intelligence Now we get crap instead of ostrich logic. Sheesh. Lee
Re: About Xen: maybe a reiterative question but ..
Paul de Weerd wrote: > Why compare this to all departments on one machine, all on the same > OS ? That's not a fair comparison. "Why"? Because that's what happens *anyway*. -- Matthew Weigel hacker [EMAIL PROTECTED]
Re: About Xen: maybe a reiterative question but ..
L. V. Lammert wrote:
Re: About Xen: maybe a reiterative question but ..
* L. V. Lammert <[EMAIL PROTECTED]> [2007-10-25 00:11]: > At 11:26 PM 10/24/2007 +0200, Henning Brauer wrote: >> * L. V. Lammert <[EMAIL PROTECTED]> [2007-10-24 23:22]: >> > Running >> > different application domains on separate VMs provides isolation BETWEEN >> > those application domains. >> >> no, it does not. > > Is that your ostrich response? it has been pointed out several times that virtualization does not provide the isolation you keep talking about. you keep repeating it does. just like vmware marketing & co. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
Re: About Xen: maybe a reiterative question but ..
At 11:26 PM 10/24/2007 +0200, Henning Brauer wrote: * L. V. Lammert <[EMAIL PROTECTED]> [2007-10-24 23:22]: > Running > different application domains on separate VMs provides isolation BETWEEN > those application domains. no, it does not. Is that your ostrich response? Lee
Re: About Xen: maybe a reiterative question but ..
At 03:31 PM 10/24/2007 -0600, Theo de Raadt wrote: > Certainly there is a small, compount risk increase due to multiple OS > images involved, but the OS images must be analyzed independently FIRST, > and THOSE risks addressed. Certainly you pulled that assesment out of your ass. I thought it was obvious, .. but I know you have beter things on your mind. I DO mind you liking my ass, however - ain't gonna happen. > **IF** OBSD were available as a host OS, that would be good security. You must be more qualified with regards to the actual code than I am because I flat out don't believe this at all. Believe what? OBSD is secure? I thought you were proud of the project? Sheesh! If our leader doesn't believe OBSD is secure, we ALL better be running for cover. Linux, anyone? If you're saying that OBSD will never be modified to run AS a XEN hypervisor, that's probably a true statement. No need to corrupt a decent OS with GPL s/w. > If not, then security issues compound due to multiple guest OSs and each set > of inherent vulnerabilities. security issues and protections do not add up like numbers. Sure they do. If I'm running Windoze as a guest OS, there are hundreds or thousands of possible vulnerabilities. If I'm runng OBSD as a guest OS, guess what (I hope you don't have to??) - few to none. There is no way to 'compound threat [interaction]', but that doesn't detract from the basic truth - the lower the risk/number of vulnerabilities of the OS, the better off you are. As a corollary, you might also say that there is no way to improve the security of a server without improving the security of the OS. > No matter how you twist the logic, however, a VM provides a good level of > application domain security, from the standpoint that each set of domain > users and applications can only see the services provided within that > domain guest OS. The phrase "application domain security" is a cover-up statement that means "I have already decided to run the multiple things on one box because I am cheap, and I need to invent reasons why I can continue doing so". Huh?? Do you know what an application domain is? Guess not - here's a definition: Application + Users + Access Method = Application Domain Examples: File/Print, httpd, DB, . . . The more discrete the security model (i.e. File/Print users are not valid on the httpd server) the better. Lee
Re: About Xen: maybe a reiterative question but ..
> You have failed to satisfactorily explain why running a specific application > in a VM is more secure then running it in a standard OS. It's nonsense that > you think it's more secure that way. It saves a lot of money, yes -- you > don't necessarily want a separate box just to run an application - but > that's not the debate here. The debate is about security, and I'm amazed > that you think a virtual environment is somehow more secure then a dedicated > non-virtual environment. It's that extra 4MB of poo code, that is what makes it more secure. It's slippery and sticky at the same time, so that the application attackers slip and slide and fall into the page boundaries. If the actual hardware let us do more isolation than we do today, we would actually do it in our operating system. The problem is the hardware DOES NOT actually give us more isolation abilities, therefore the VM does not actually do anything what the say they do. While x86 hardware has the same page-protection hardware that an IBM 390 architecture machine has, modern PC machines are a mess. They are architecturally so dirty, that parts of the video, keyboard, and other IO devices are interfaced with even to do simple things like context switching processes and handling interrupts. Those of us who have experience with the gory bits of the x86 architecture can clearly say that we know what would be involved in virtualizing it, and if it was so simple, we would not still be fixing bugs in the exact same area in our operating system going on 12 years. We know what a VM operating system has to do to deal with the PC architecture. It is too complex to get perfectly right. And now you've entered into the layered approach where *any error* in the PC model exposed to the client operating system is not just a crashing bug -- it is now exploitable. It might be nice, but it is stupid. And anyone who thinks there is any security advantage at any level knows nothing about PC architecture.
Re: A (pf?) puzzler -- a single device invisible on the other side of an IPsec tunnel
knitti wrote: On 10/19/07, Stephen Bosch <[EMAIL PROTECTED]> wrote: Other things I've tried: - moving the Jetdirect to a different port on the same physical switch - a variety of static and dynamic IPs in the subnet I also forwarded the external port 9100 to this print server and tried to access it from a public host, but this didn't work either. This leads me to suspect a peculiar interaction between OpenBSD 4.1 and this particular print server. Of course, it might well be the fault of HP's IP stack, but I've already talked to them at great length and got pretty much nowhere: "We don't support JetDirect over WAN connections." look with tcpdump, whether the packets of the printserver look like you expect. perhaps it only has a ttl of 1 or 2 ;-) No -- the damn thing is doing ARP for the remote address, even though it has a gateway configured. The stupid thing is that this same model of printer works on another network, same configuration -- except the local VPN endpoint is a SonicWall. -Stephen-
Re: multimode fiber card recs for OpenBGPD
On Wed, Oct 24, 2007 at 10:25:32PM +0200, Henning Brauer wrote: > * N.J. Thomas <[EMAIL PROTECTED]> [2007-10-24 19:28]: > > I have two servers that I would like to setup to run OpenBGPD for our > > border routers. > > > > I need to find a supported PCIe (not PCI-X) fiber card that runs > > multi-mode and a supported PCIe (not PCI-X) fiber card that runs > > single-mode. (One of our providers is coming to us with mm, the other > > with sm.) > > > > A dual port card is preferable, but we will take single port cards if > > those are the only ones available. > > > > Any recommendations? The supported cards page on the OpenBSD site only > > lists PCI-X cards. > > i have some pcie-ems, there are pcie-bnxs, and certainly others. fibre > limits your options. i usually terminate wan fibres on a switch and use > copper or plain sx (really just copper these days) to the routers - has > the disadvantage that you don't see link state changes directly, has > the advantage of added flexibility and just connecting two machines for > redundancy reasons (details differ a lot depending on environment). > > that said, it shouldn't be too hard to find a pcie-sx card. lx could > get hairy. > > http://www.transtec.co.uk/ they have em(4) based cards with sx and lx (lx only as pci-x for some strange reason). The also offer msk(4) cards with sx and lx but those are pci-x only. -- :wq Claudio
Re: About Xen: maybe a reiterative question but ..
> Certainly there is a small, compount risk increase due to multiple OS > images involved, but the OS images must be analyzed independently FIRST, > and THOSE risks addressed. Certainly you pulled that assesment out of your ass. > **IF** OBSD were available as a host OS, that would be good security. You must be more qualified with regards to the actual code than I am because I flat out don't believe this at all. > If > not, then security issues compound due to multiple guest OSs and each set > of inherent vulnerabilities. security issues and protections do not add up like numbers. > No matter how you twist the logic, however, a VM provides a good level of > application domain security, from the standpoint that each set of domain > users and applications can only see the services provided within that > domain guest OS. The phrase "application domain security" is a cover-up statement that means "I have already decided to run the multiple things on one box because I am cheap, and I need to invent reasons why I can continue doing so".
Re: About Xen: maybe a reiterative question but ..
* L. V. Lammert <[EMAIL PROTECTED]> [2007-10-24 23:22]: > Running > different application domains on separate VMs provides isolation BETWEEN > those application domains. no, it does not. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
Re: About Xen: maybe a reiterative question but ..
Theo de Raadt wrote:
The security benefits are at the "ability to buy a steak for dinner"
level.
I vote to add it to theo.c.
Thanks
Daniel
Index: src/usr.bin/mg/theo.c
===
RCS file: /cvs/src/usr.bin/mg/theo.c,v
retrieving revision 1.101
diff -u -p -r1.101 theo.c
--- src/usr.bin/mg/theo.c 28 Aug 2007 17:57:16 - 1.101
+++ src/usr.bin/mg/theo.c 24 Oct 2007 21:19:08 -
@@ -147,6 +147,7 @@ static const char *talk[] = {
"cache aliasing is a problem that would have stopped in 1992 if
someone had killed about 5 people who worked at Sun.",
"Don't spread rumours about me being gentle.",
"If municipal water filtering equipment was built by the gcc
developers, the western world would be dead by now.",
+ "The security benefits are at the 'ability to buy a steak for
dinner' level.",
};
static const int ntalk = sizeof(talk)/sizeof(talk[0]);
Re: About Xen: maybe a reiterative question but ..
On Wed, 24 Oct 2007, Theo de Raadt wrote: > > At 12:03 PM 10/24/2007 -0600, Theo de Raadt wrote: > > > > > > Anything we can do to increase security, *including* setting up VMs (of > > > any > > > > flavor) is an improvement [that also increased hardware utilization]. > > > > > >This last sentence is such a lie. > > > > That depends on your viewpoint. There certainly may be some issues at the > > OS level (which have been mentioned previously), however the majority of VM > > applications benefit from security *isolation*, which has nothing to do > > with security issues of the underlying OS, and that was the viewpoint I was > > communicating. > > The ends justify the means, even if the means don't actually perform as > you declare? > Huh? What does circular logic have to do with a simple statement? Running different application domains on separate VMs provides isolation BETWEEN those application domains. That's security by anyone's definition. The fact is that the OS level security is *separate*, and could be an issue has nothing to do with the point I'm making. What if the client OS were Windoze? The security of that OS is crap, and we all know it. Any sane sysadmin will have a good firewall in front of that machine, whether it's running in a VM or on separate hardware. What if the client OS were Linux with AppArmor? SE Linux is a BIG improvement over regular Linux, and WAY more secure than ANY product from Redmond. Certainly there is a small, compount risk increase due to multiple OS images involved, but the OS images must be analyzed independently FIRST, and THOSE risks addressed. **IF** OBSD were available as a host OS, that would be good security. If not, then security issues compound due to multiple guest OSs and each set of inherent vulnerabilities. No matter how you twist the logic, however, a VM provides a good level of application domain security, from the standpoint that each set of domain users and applications can only see the services provided within that domain guest OS. Lee Leland V. Lammert[EMAIL PROTECTED] Chief Scientist Omnitec Corporation Network/Internet Consultants www.omnitec.net
Re: About Xen: maybe a reiterative question but ..
You have failed to satisfactorily explain why running a specific application in a VM is more secure then running it in a standard OS. It's nonsense that you think it's more secure that way. It saves a lot of money, yes -- you don't necessarily want a separate box just to run an application - but that's not the debate here. The debate is about security, and I'm amazed that you think a virtual environment is somehow more secure then a dedicated non-virtual environment. On 10/24/07, L. V. Lammert <[EMAIL PROTECTED]> wrote: > > On Wed, 24 Oct 2007, Theo de Raadt wrote: > > > > The security benefits are at the application level, *NOT* at the OS > level. > > > > What hogwash. > > > > The security benefits are at the "ability to buy a steak for dinner" > > level. > > > Nah, I like steak, I hate enterprise computing. > > > You've already made the decision to decrease security by > > de-compartmentalizing onto one physical box, so you are just thrilled > > with the ability to decrease security more by de-compartmentalizing > > the software further. > > > Quite the opposite!! A VM provides a safe, sane, decently > compartmentalized way to run a specific application domain. It's obvious > we have different viewpoints, but both are equally valid - your's from the > OS, mine from the application. > > Lee > > > Leland V. Lammert[EMAIL PROTECTED] > Chief Scientist Omnitec Corporation > Network/Internet Consultants www.omnitec.net >
Re: About Xen: maybe a reiterative question but ..
On Oct 24, 2007, at 4:16 PM, Henning Brauer <[EMAIL PROTECTED]> wrote: * Darren Spruell <[EMAIL PROTECTED]> [2007-10-24 21:48]: Remember back 10-ish years ago when VLANs were being touted as the ultimate network segmentation technology by marketers of managed switches? And now everyone hopefully realizes that while VLANs technically do offer network segmentation, it's really rudimentary and cannot be relied on for truly reliable security due to various layer 2 attacks that subvert them? err, that is a very bad comparision. I am not aware of any "layer2 attacks" (you probably mean vlan hopping things) that work against any half reasonable configured switch from the last 10 years. heck, these days even everybody except cisco has sane defaults. (well, I dunno about those cheap switches, admittedly) this comparision is wrong on another basis: vlans are dead simple, just a tiny and simple header before the ethernet segment. virtualization is certainly not. That simply segmenting networks with VLANs can't be considering to fully isolate them? without bad config errors (that are getting harder to make, except on cisco, they got the semantics completely wrong and stupid defaults) and usedcorrectly, yes, VLANs perfectly isolate network segments. Why does this continue to pop up in misc@ every year? --- Jason Dixon DixonGroup Consulting http://www.dixongroup.net
Re: About Xen: maybe a reiterative question but ..
On 10/24/07, Henning Brauer <[EMAIL PROTECTED]> wrote: > without bad config errors (that are getting harder to make, except on > cisco, they got the semantics completely wrong and stupid defaults) and > usedcorrectly, yes, VLANs perfectly isolate network segments. I'm curious about this. Do you have any pointers I can go look up? Thanx! -- "This officer's men seem to follow him merely out of idle curiosity." -- Sandhurst officer cadet evaluation.
Re: Network Time Synchronization using timed or ntpd or a Combination?
Boris Goldberg wrote: [snip] > There are pros and cons in the "demon" and in the "cron" schema. I > decided to use cron and I know why. Every sysadmin/architect should make > that decision for *his* systems (and know why). "Home users" should > probably stay with the default (ntpd), but they are usually using Windows > and cheap "hardware" firewalls anyway. ;) [snip] I hate beating a dead horse, but this one needs one more whack. OpenNTPD runs as a 'daemon,' yes, but it does so using privilege separation and other goodies. The network code runs as a normal user, isolated from other users. This is superior to running rdate AS ROOT from a cronjob. OpenNTPD does not open any TCP or UDP ports by default. It is true that rdate has about 63% less lines of code than ntpd and is older, and may have had more code audits performed; However, ntpd is new code, written with security in mind, runs as a normal user (privilege separated for the most part) and has superior time keeping ability. Your advice about not running a daemon if it's possible to do the task otherwise may be true with a (bloated) daemon such as ntp.org ntpd, however, with OpenNTPD the tables are turned. It is far safer to run the 'daemon' than to perform the task otherwise. That being said, it is up to the individual users to decide what to do. Hopefully this above explanation will help those who don't necessarily understand the risks of running programs as root vice daemons which execute code with proper separation of privileges. -Brian [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: About Xen: maybe a reiterative question but ..
On Wed, 24 Oct 2007, Theo de Raadt wrote: > > The security benefits are at the application level, *NOT* at the OS level. > > What hogwash. > > The security benefits are at the "ability to buy a steak for dinner" > level. > Nah, I like steak, I hate enterprise computing. > You've already made the decision to decrease security by > de-compartmentalizing onto one physical box, so you are just thrilled > with the ability to decrease security more by de-compartmentalizing > the software further. > Quite the opposite!! A VM provides a safe, sane, decently compartmentalized way to run a specific application domain. It's obvious we have different viewpoints, but both are equally valid - your's from the OS, mine from the application. Lee Leland V. Lammert[EMAIL PROTECTED] Chief Scientist Omnitec Corporation Network/Internet Consultants www.omnitec.net
Re: About Xen: maybe a reiterative question but ..
It's a very simple concept. There is *nothing* in any virtualization software that makes having it *more secure* than not having it at all. Period. --- Jason Dixon DixonGroup Consulting http://www.dixongroup.net
Re: About Xen: maybe a reiterative question but ..
* Darren Spruell <[EMAIL PROTECTED]> [2007-10-24 21:48]: > Remember back 10-ish years ago when VLANs were being touted as the > ultimate network segmentation technology by marketers of managed > switches? And now everyone hopefully realizes that while VLANs > technically do offer network segmentation, it's really rudimentary and > cannot be relied on for truly reliable security due to various layer 2 > attacks that subvert them? err, that is a very bad comparision. I am not aware of any "layer2 attacks" (you probably mean vlan hopping things) that work against any half reasonable configured switch from the last 10 years. heck, these days even everybody except cisco has sane defaults. (well, I dunno about those cheap switches, admittedly) this comparision is wrong on another basis: vlans are dead simple, just a tiny and simple header before the ethernet segment. virtualization is certainly not. > That simply segmenting networks with > VLANs can't be considering to fully isolate them? without bad config errors (that are getting harder to make, except on cisco, they got the semantics completely wrong and stupid defaults) and usedcorrectly, yes, VLANs perfectly isolate network segments. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
Re: multimode fiber card recs for OpenBGPD
* N.J. Thomas <[EMAIL PROTECTED]> [2007-10-24 19:28]: > I have two servers that I would like to setup to run OpenBGPD for our > border routers. > > I need to find a supported PCIe (not PCI-X) fiber card that runs > multi-mode and a supported PCIe (not PCI-X) fiber card that runs > single-mode. (One of our providers is coming to us with mm, the other > with sm.) > > A dual port card is preferable, but we will take single port cards if > those are the only ones available. > > Any recommendations? The supported cards page on the OpenBSD site only > lists PCI-X cards. i have some pcie-ems, there are pcie-bnxs, and certainly others. fibre limits your options. i usually terminate wan fibres on a switch and use copper or plain sx (really just copper these days) to the routers - has the disadvantage that you don't see link state changes directly, has the advantage of added flexibility and just connecting two machines for redundancy reasons (details differ a lot depending on environment). that said, it shouldn't be too hard to find a pcie-sx card. lx could get hairy. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
Re: About Xen: maybe a reiterative question but ..
On 10/24/07, Jack J. Woehr <[EMAIL PROTECTED]> wrote: > All things being equal, the safest base installations in the universe > would be those whose user instances were encased in some kind of > solid VM and whose base instance administrators were provided > with and followed best practices. My VM: The World. -- "This officer's men seem to follow him merely out of idle curiosity." -- Sandhurst officer cadet evaluation.
Re: LDAP users
Linus SwCFCB$las schrieb: OpenBSD doesn't include an LDAP module though so you'd have to write your own, details for how to do so is in the login.conf(5) man page. Or perhaps you can google something, someone else has probably built one already. login_ldap no longer in ports?
Re: About Xen: maybe a reiterative question but ..
> The security benefits are at the application level, *NOT* at the OS level. What hogwash. The security benefits are at the "ability to buy a steak for dinner" level. You've already made the decision to decrease security by de-compartmentalizing onto one physical box, so you are just thrilled with the ability to decrease security more by de-compartmentalizing the software further.
Re: About Xen: maybe a reiterative question but ..
On 10/24/07, L. V. Lammert <[EMAIL PROTECTED]> wrote: > At 12:03 PM 10/24/2007 -0600, Theo de Raadt wrote: > > > > Anything we can do to increase security, *including* setting up VMs (of > > any > > > flavor) is an improvement [that also increased hardware utilization]. > > > >This last sentence is such a lie. > > That depends on your viewpoint. There certainly may be some issues at the > OS level (which have been mentioned previously), however the majority of VM > applications benefit from security *isolation*, which has nothing to do > with security issues of the underlying OS, and that was the viewpoint I was > communicating. > > For example, say you have three departments within a company: Marketing, > Development, Production. Allowing each department to maintain their own > server instance allows each department to have their own users, home > directory configuration, samba (possibly) network config & authorization, > separate file/print sharing domain, etc. This is called a "tangent." It has nothing to do with the reliable security aspects of segmentation via virtualization. The point you may try making here is that by segmenting your servers into individual instances for each department, rather than having all departments on a shared server, an attack against one department's server doesn't affect the other. _In theory_, that's true. _In reality_, this is only a surface assumption as without strong segmentation at the network level to separate a compromised department from another department, the attacker can compromise the other departments' servers from the first one and have the same result. Remember back 10-ish years ago when VLANs were being touted as the ultimate network segmentation technology by marketers of managed switches? And now everyone hopefully realizes that while VLANs technically do offer network segmentation, it's really rudimentary and cannot be relied on for truly reliable security due to various layer 2 attacks that subvert them? Or that if there's any communication conduits that allows one to talk to the other, that can simply be leveraged to subvert security? That simply segmenting networks with VLANs can't be considering to fully isolate them? That when people want solid assurance of isolating hosts they often still air gap them? That is the point that VM-based segmentation is at right now. This isn't supposed to be a remedial lesson on network architectures; you're supposed to pick up the parallels to separation of systems/applications via VM technology. VM based segmentation or isolation (whichever buzzword you prefer ATM) is fine on the surface level, but please stop acting as if it is a security measure. People much smarter than $you are blowing that idea out of the water right now. http://www.intelguardians.com/ndss.pdf http://www.pauldotcom.com/2007/08/27/pauldotcom_security_weekly_int_1.html http://www.cutawaysecurity.com/blog/archives/170 (read Ed Skoudis' comment on this post) DS
Re: Network Time Synchronization using timed or ntpd or a Combination?
Hello Marc, Wednesday, October 24, 2007, 1:13:23 PM, you wrote: >> May be it makes sense to set "-ncv" as a default behavior of rdate, but >> there is should be a way to synchronize time without running a demon (don't >> understand why are people so aggressive about that) if you don't need >> up-to-second synchronization (in my case modern hardware goes less than a >> second off per day, and really old hardware - less than 10 seconds). MB> You don't understand the implications of changing the time of a computer MB> at runtime. I believe I do. :) There are pros and cons in the "demon" and in the "cron" schema. I decided to use cron and I know why. Every sysadmin/architect should make that decision for *his* systems (and know why). "Home users" should probably stay with the default (ntpd), but they are usually using Windows and cheap "hardware" firewalls anyway. ;) MB> If either case is acceptable depends on the software that runs on the MB> computer. Exactly. And I believe that "usual" case is not a cluster, monetary transaction server or traffic control system. MB> A computer that controls an insulin pump probably should run at MB> constant speed whereas a computer that does a task at a certain time MB> should not skip time units. Have you seen an insulin pump ran by OpenBSD system? ;) Give me some *real* examples (if you want to). MB> If a cronjob runs at 17:10 and at 17:00 your wise cronjob sets the time MB> to 17:20, cron will not start that job. First of all, this is not a *real* case again. I was talking about 10 seconds a day, not 20 minutes. If your *production* hardware goes 20 minutes off a day you will probably replace it (I believe, for new hardware it's a "warranty" case). Second of all, I've seen that behavior (with much smaller time adjustments) on SCO, but OpenBSD handles it pretty good - my cron doesn't repeat itself after adjusting time back. -- Best regards, Borismailto:[EMAIL PROTECTED]
Re: About Xen: maybe a reiterative question but ..
Can Erkin Acar wrote: > L. V. Lammert wrote: >> At 05:12 PM 10/24/2007 +0200, Henning Brauer wrote: >>> * L. V. Lammert <[EMAIL PROTECTED]> [2007-10-24 16:46]: Virtualization provides near absolute security - DOM0 is not visible to the user at all, only passing network traffic and handling kernel calls. The security comes about in that each DOMU is totally isolated from the the others, while the core DOM0 is isolated from any attacks. >>> dream on. >>> that is what marketing wants to tell you. >>> in fact the isolation is incredibly poor. >> Sorry, the kernel hacking world is pretty far removed from 'enterprise >> reality' !! >> In reality, there are tons of SMEs out there using MS Crap and other risky >> software! The few security risks you cite for XEN are negligable by >> comparison. > > When all this crap/risky software is running on separate boxes, you only > have > the network as an attack path to the other crap. This path is well > understood, > and there are established policies, best practices, tools that you can > use to > control and monitor your network. Contrariwise, there is *some* security benefit to running all the services virtualized, compared to running all the services on the same machine but *not* virtualized. In that case, though, you're not getting any improved resource utilization, and you're going with a very complicated and unaudited system (with arbitrary code execution bugs coming to light *this month*) to achieve "improved security." You can achieve a lot of the promises of virtualized servers (with fewer moving parts, and more code audits) using chroot and login classes to run many services on a single big machine. -- Matthew Weigel hacker [EMAIL PROTECTED]
Re: Network Time Synchronization using timed or ntpd or a Combination?
* Marc Balmer <[EMAIL PROTECTED]> [2007-10-24 20:25]: > Boris Goldberg wrote: > >> May be it makes sense to set "-ncv" as a default behavior of rdate, >> but >> there is should be a way to synchronize time without running a demon >> (don't >> understand why are people so aggressive about that) if you don't >> need >> up-to-second synchronization (in my case modern hardware goes less than >> a >> second off per day, and really old hardware - less than 10 seconds). > > You don't understand the implications of changing the time of a computer > at runtime. > > Time can be seen a continuum whos axis can be stretched or compressed or > as series of time units with fixed length. In the first case the > computer clock runs faster or slower, but no time unit is lost. In the > second case the computer runs at constant speed, but time units can be > lost. that is NOT the damn point, rdate can use adjtime. > If either case is acceptable depends on the software that runs on the > computer. A computer that controls an insulin pump probably should > run at constant speed whereas a computer that does a task at a certain > time should not skip time units. If a cronjob runs at 17:10 and at > 17:00 your wise cronjob sets the time to 17:20, cron will not start that > job. > > See? bad example, since cron is the worst example you could pick, it is reasonably smart trying to deal with time jumps. but it DOES NOT in the first place using rdate -a. yet, ntpd is STILL a way better solution, but don't spread fud to push it either, it doesn't need that. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
Re: About Xen: maybe a reiterative question but ..
On Wed, Oct 24, 2007 at 01:41:38PM -0500, L. V. Lammert wrote: | For example, say you have three departments within a company: Marketing, | Development, Production. Allowing each department to maintain their own | server instance allows each department to have their own users, home | directory configuration, samba (possibly) network config & authorization, | separate file/print sharing domain, etc. | | That is simple not doable with a single OS, yet with a reasonable priced of | h/w all can be maintained on one platform. | | The security benefits are at the application level, *NOT* at the OS level. Let's have a look at the case. Three departments all on one machine, each under one VM. Why compare this to all departments on one machine, all on the same OS ? That's not a fair comparison. Compare your one machine with 3 VMs to three machines. What do you think is more secure ? If you really, honestly think that the one machine/3 VM's solution is more secure, I'm actually very interested in your reasoning for this. You seperate and isolate each department on their own machine. As secure as the OS and/or application running on that machine. Now you join three machines into one machine with three VMs, adding a layer of complexity/code that is quite useful (as it saves on hardware costs) but maybe not very mature yet. How does that joining *add* security ? Please elaborate. Cheers, Paul 'WEiRD' de Weerd -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: Network Time Synchronization using timed or ntpd or a Combination?
* Paul de Weerd <[EMAIL PROTECTED]> [2007-10-24 19:28]: > On Wed, Oct 24, 2007 at 10:47:45AM -0500, Boris Goldberg wrote: > | May be it makes sense to set "-ncv" as a default behavior of rdate, but > | there is should be a way to synchronize time without running a demon (don't > | understand why are people so aggressive about that) if you don't need > | up-to-second synchronization (in my case modern hardware goes less than a > | second off per day, and really old hardware - less than 10 seconds). > > The problem here is the jump in time. You repeat a second or more (if > you have to jump back) or skip some (if you jump forward). This may > not be a problem for you in particular, but is considered bad in > general. rdate can use adjtime, so that point is moot. > Another issue is the fact that the server you're syncing to may not be > perfectly sync'ed itself. Or maybe there's some (assymmetrical) delay > in the network. This may make time on your machine somewhat off (this > isn't as big a problem as the previous, IMO). this is the key. rdate sets/skews the clock based on a single reply. which might get affected badly by network issues or whatever, or be spoofed, or... ntpd doesn't have that problem at all - last not least it never uses less than 8 packets to form a single update (just picking that one as example, there is more it can do, because it can develop thing over TIME instead of a single one-shot update & exit. and it fixes the clock frequency permanently using adjtick. rdate doesn't. > And it's totally unneccessary, simply run ntpd and be done > with it. exactly. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
Re: About Xen: maybe a reiterative question but ..
> At 12:03 PM 10/24/2007 -0600, Theo de Raadt wrote: > > > > Anything we can do to increase security, *including* setting up VMs (of > > any > > > flavor) is an improvement [that also increased hardware utilization]. > > > >This last sentence is such a lie. > > That depends on your viewpoint. There certainly may be some issues at the > OS level (which have been mentioned previously), however the majority of VM > applications benefit from security *isolation*, which has nothing to do > with security issues of the underlying OS, and that was the viewpoint I was > communicating. The ends justify the means, even if the means don't actually perform as you declare? > For example, say you have three departments within a company: Marketing, > Development, Production. Allowing each department to maintain their own > server instance allows each department to have their own users, home > directory configuration, samba (possibly) network config & authorization, > separate file/print sharing domain, etc. > > That is simple not doable with a single OS, yet with a reasonable priced of > h/w all can be maintained on one platform. > > The security benefits are at the application level, *NOT* at the OS level. This has NOTHING to do with security. You are just saving pennies. You did zero actual security assessment, so you are just talking out of your ass. > >If people were saying: > > > > "Yes, it increased hardware utilization, and the nasty > > security impact might be low" > > > >it would be fine. > > > >But instead we have many uneducated people saying: > > > >"Yes, it increased hardware utilization, and it improved security > > too". > > > >And that's complete and utter bullshit. > > Perhaps more correctly: > > "Yes, it increased hardware utilization, and it improves > security/isolation between different work domains" > > However few outside this community would have any comprehension of the > difference. You're so full of it. There is no security/isolation. You are making it up out of thin air to justify the pennies you saved. It's a total lie.
Re: About Xen: maybe a reiterative question but ..
L. V. Lammert wrote: > At 05:12 PM 10/24/2007 +0200, Henning Brauer wrote: >>* L. V. Lammert <[EMAIL PROTECTED]> [2007-10-24 16:46]: >> > Virtualization provides near absolute security - DOM0 is not visible to >> > the user at all, only passing network traffic and handling kernel calls. >> > The security comes about in that each DOMU is totally isolated from the >> > the others, while the core DOM0 is isolated from any attacks. >> >>dream on. >>that is what marketing wants to tell you. >>in fact the isolation is incredibly poor. > > Sorry, the kernel hacking world is pretty far removed from 'enterprise > reality' !! > In reality, there are tons of SMEs out there using MS Crap and other risky > software! The few security risks you cite for XEN are negligable by > comparison. When all this crap/risky software is running on separate boxes, you only have the network as an attack path to the other crap. This path is well understood, and there are established policies, best practices, tools that you can use to control and monitor your network. Now, when you put all this crap onto the same hardware, you remove the well known and trusted hardware from underneath the already crappy setups, and introduce a (possibly crappy/unknown) software layer that claims to provide isolation. Advantages: 1. buzzword compliance 2. some 'cool features' like snapshots and migration 3. perhaps better utilize the (high performance/ultra expensive) hardware you just bought to gain 1 & 2. Disadvantages: 1. isolation between the systems is in fact *reduced* 2. whole new attack paths through the VM system are introduced: you get access to the host OS, not necessarily through a guest, you compromise ALL guests. 3. A compromised guest could, at the very least cause stability problems and DoS affecting ALL the guests, at worst compromising the host OS. > Anything we can do to increase security, *including* setting up VMs (of any > flavor) is an improvement [that also increased hardware utilization]. You do not get security improvements out of using a VM system at all. Look at the list above. This is *not* some kernel hackers' out of the world scenario. This is just common sense and security best practices that every enterprise should be aware of. You do have some benefits in terms of management and flexibility, and perhaps faster recovery. VMs are invaluable for development/testing. But there is absolutely *no* security improvement at all. You may accept the risks in favor of the benefits to your business, but do not claim that you are actually improving the security. Can
Re: HP ProLiant DL320 v. Sun Fire V125
Hello evo,
Wednesday, October 24, 2007, 12:51:13 AM, you wrote:
e> I'm choosing firewall/proxy/mail-gateway hardware running (of course)
e> OpenBSD for medium office and my shortlist is:
e> (a) HP ProLiant DL320 and (b) Sun Fire V125
I'm upgrading my servers/firewalls to HP ProLiant DL320 G5, and the
experience... isn't easy. First of all you need to allow acpi in an MP
kernel, otherwise it's slow and unstable (it's disabled by default and not
really documented).
Then you have couple more issues I couldn't resolve yet:
Fists - uhci (uhci4 in my case) giving an error during boot and shutdown:
OpenBSD 4.2-stable (GENERIC) #1: Thu Oct 18 12:35:10 CDT 2007
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Pentium(R) D CPU 3.00GHz ("GenuineIntel" 686-class) 3.01 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,EST,CNXT-ID,CX16,xTPR
real mem = 1071640576 (1021MB)
avail mem = 1028595712 (980MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 12/31/99, BIOS32 rev. 0 @ 0xf, SMBIOS
rev. 2.3 @ 0xee000 (47 entries)
bios0: vendor HP version "W04" date 04/06/2007
bios0: HP ProLiant DL320 G5
pcibios0 at bios0: rev 3.0 @ 0xf/0x2000
pcibios0: PCI BIOS has 7 Interrupt Routing table entries
pcibios0: PCI Interrupt Router at 000:31:0 ("Intel 82801GB LPC" rev 0x00)
pcibios0: PCI bus #7 is the last bus
bios0: ROM list: 0xc/0xb000 0xcc400/0x1000 0xcd400/0x1000 0xce400/0x3400!
0xe6000/0x2000!
acpi at mainbus0 not configured
ipmi0 at mainbus0: version 2.0 interface KCS iobase 0xca2/2 spacing 1
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 "Intel E7230 MCH" rev 0xc0
ppb0 at pci0 dev 1 function 0 "Intel E7230 PCIE" rev 0xc0
pci1 at ppb0 bus 1
ppb1 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x01
pci2 at ppb1 bus 2
ppb2 at pci2 dev 0 function 0 "ServerWorks PCIE-PCIX" rev 0xb5
pci3 at ppb2 bus 3
bge0 at pci3 dev 4 function 0 "Broadcom BCM5714" rev 0xa3, BCM5715 A3 (0x9003):
irq 11, address 00:1b:78:07:c9:9a
brgphy0 at bge0 phy 1: BCM5714 10/100/1000baseT PHY, rev. 0
bge1 at pci3 dev 4 function 1 "Broadcom BCM5714" rev 0xa3, BCM5715 A3 (0x9003):
irq 10, address 00:1b:78:07:c9:9b
brgphy1 at bge1 phy 1: BCM5714 10/100/1000baseT PHY, rev. 0
ppb3 at pci3 dev 8 function 0 "ServerWorks HT-1000 PCIX" rev 0xb4
pci4 at ppb3 bus 4
ppb4 at pci0 dev 28 function 4 "Intel 82801G PCIE" rev 0x01
pci5 at ppb4 bus 5
em0 at pci5 dev 0 function 0 "Intel PRO/1000 PT (82571EB)" rev 0x06: irq 11,
address 00:1b:78:57:58:e0
em1 at pci5 dev 0 function 1 "Intel PRO/1000 PT (82571EB)" rev 0x06: irq 10,
address 00:1b:78:57:58:e1
ppb5 at pci0 dev 28 function 5 "Intel 82801G PCIE" rev 0x01
pci6 at ppb5 bus 6
uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x01: irq 5
uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x01: irq 5
uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev 0x01: irq 5
uhci3 at pci0 dev 29 function 3 "Intel 82801GB USB" rev 0x01: irq 5
ehci0 at pci0 dev 29 function 7 "Intel 82801GB USB" rev 0x01: irq 5
usb0 at ehci0: USB revision 2.0
uhub0 at usb0: Intel EHCI root hub, rev 2.00/1.00, addr 1
ppb6 at pci0 dev 30 function 0 "Intel 82801BA AGP" rev 0xe1
pci7 at ppb6 bus 7
vga1 at pci7 dev 3 function 0 "ATI ES1000" rev 0x02
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
"Compaq iLO" rev 0x03 at pci7 dev 4 function 0 not configured
"Compaq iLO" rev 0x03 at pci7 dev 4 function 2 not configured
uhci4 at pci7 dev 4 function 4 "Hewlett-Packard USB" rev 0x00: irq 11
uhci4: cannot stop
"Hewlett-Packard IPMI" rev 0x00 at pci7 dev 4 function 6 not configured
usb1 at uhci4: USB revision 1.0
uhub1 at usb1: Hewlett-Packard UHCI root hub, rev 1.00/1.00, addr 1
ichpcib0 at pci0 dev 31 function 0 "Intel 82801GB LPC" rev 0x01: PM disabled
pciide0 at pci0 dev 31 function 1 "Intel 82801GB IDE" rev 0x01: DMA, channel 0
configured to compatibility, channel 1 configured to compatibility
pciide0: channel 0 disabled (no drives)
pciide0: channel 1 disabled (no drives)
pciide1 at pci0 dev 31 function 2 "Intel 82801GB SATA" rev 0x01: DMA, channel 0
configured to native-PCI, channel 1 configured to native-PCI
pciide1: using irq 7 for native-PCI interrupt
wd0 at pciide1 channel 0 drive 0:
wd0: 16-sector PIO, LBA48, 152627MB, 312581808 sectors
wd0(pciide1:0:0): using PIO mode 4, Ultra-DMA mode 5
usb2 at uhci0: USB revision 1.0
uhub2 at usb2: Intel UHCI root hub, rev 1.00/1.00, addr 1
usb3 at uhci1: USB revision 1.0
uhub3 at usb3: Intel UHCI root hub, rev 1.00/1.00, addr 1
usb4 at uhci2: USB revision 1.0
uhub4 at usb4: Intel UHCI root hub, rev 1.00/1.00, addr 1
usb5 at uhci3: USB revision 1.0
uhub5 at usb5: Intel UHCI root hub, rev 1.00/1.00, addr 1
isa0 at ichpcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 fo
Re: About Xen: maybe a reiterative question but ..
At 12:03 PM 10/24/2007 -0600, Theo de Raadt wrote: > Anything we can do to increase security, *including* setting up VMs (of any > flavor) is an improvement [that also increased hardware utilization]. This last sentence is such a lie. That depends on your viewpoint. There certainly may be some issues at the OS level (which have been mentioned previously), however the majority of VM applications benefit from security *isolation*, which has nothing to do with security issues of the underlying OS, and that was the viewpoint I was communicating. For example, say you have three departments within a company: Marketing, Development, Production. Allowing each department to maintain their own server instance allows each department to have their own users, home directory configuration, samba (possibly) network config & authorization, separate file/print sharing domain, etc. That is simple not doable with a single OS, yet with a reasonable priced of h/w all can be maintained on one platform. The security benefits are at the application level, *NOT* at the OS level. If people were saying: "Yes, it increased hardware utilization, and the nasty security impact might be low" it would be fine. But instead we have many uneducated people saying: "Yes, it increased hardware utilization, and it improved security too". And that's complete and utter bullshit. Perhaps more correctly: "Yes, it increased hardware utilization, and it improves security/isolation between different work domains" However few outside this community would have any comprehension of the difference. Lee
pgt/Netgear WG511
I have, what appears to be, v1 of this card, but I get the following from dmesg--even when booting from the latest snapshot of cd42.iso: Intersil, ISL3890, -, - (manufacturer 0xb, product 0x3890) "Intersil Prism GT/Duette" rev 0x01 at cardbus1 dev 0 function 0 not configured I'm not certain how to update pcidevs and related to accurately reflect this (I noticed product 0x3890 is already in pcidevs.h), so some advice is appreciated. Thanks.
Re: Question about 4.2 Package availability
Hi Joe, > If I've installed OpenBSD 4.2 and I need a specific package (in this > case, net-smpd) which is not available on the CD, I must wait until > 4.2 is officially released. Then I can get the packages I need from > the ftp site. Yes. (Or you build it from ports. Still, 4.2 is very much unreleased at this moment.) HTH... Nico
Re: Network Time Synchronization using timed or ntpd or a Combination?
Boris Goldberg wrote: May be it makes sense to set "-ncv" as a default behavior of rdate, but there is should be a way to synchronize time without running a demon (don't understand why are people so aggressive about that) if you don't need up-to-second synchronization (in my case modern hardware goes less than a second off per day, and really old hardware - less than 10 seconds). You don't understand the implications of changing the time of a computer at runtime. Time can be seen a continuum whos axis can be stretched or compressed or as series of time units with fixed length. In the first case the computer clock runs faster or slower, but no time unit is lost. In the second case the computer runs at constant speed, but time units can be lost. If either case is acceptable depends on the software that runs on the computer. A computer that controls an insulin pump probably should run at constant speed whereas a computer that does a task at a certain time should not skip time units. If a cronjob runs at 17:10 and at 17:00 your wise cronjob sets the time to 17:20, cron will not start that job. See?
Question about 4.2 Package availability
I just wanted to confirm the following: If I've installed OpenBSD 4.2 and I need a specific package (in this case, net-smpd) which is not available on the CD, I must wait until 4.2 is officially released. Then I can get the packages I need from the ftp site.
Re: About Xen: maybe a reiterative question but ..
On 10/24/07, Christoph Egger <[EMAIL PROTECTED]> wrote: > - aio(2) support creaking along. > - POSIX ptsname() (this is used in a python binding module) dunno. > - newer gcc version due to a structure padding bug with > an alignment attribute hidden in a typedef (this is fixed in gcc 3.4) > I use gcc 4.2 from the ports FYI. can you tell me which structure? attribute packed/aligned should never be used on typedefs because of this. it's one of those astounding things that gcc compiles, but then neglects to warn that it completely ignores the attribute. > Oh, a libc header cleanup is nice to have. I don't know why uvm kernel headers > should be in /usr/include/uvm/, for example. so that userland programs can talk to the kernel. what's the problem? they're not in the way are they? (where else would they go?)
Re: About Xen: maybe a reiterative question but ..
> At 05:12 PM 10/24/2007 +0200, Henning Brauer wrote: > >* L. V. Lammert <[EMAIL PROTECTED]> [2007-10-24 16:46]: > > > Virtualization provides near absolute security - DOM0 is not visible to > > > the user at all, only passing network traffic and handling kernel calls. > > > The security comes about in that each DOMU is totally isolated from the > > > the others, while the core DOM0 is isolated from any attacks. > > > >dream on. > >that is what marketing wants to tell you. > >in fact the isolation is incredibly poor. > > Sorry, the kernel hacking world is pretty far removed from 'enterprise > reality' !! > In reality, there are tons of SMEs out there using MS Crap and other risky > software! The few security risks you cite for XEN are negligable by > comparison. > > Anything we can do to increase security, *including* setting up VMs (of any > flavor) is an improvement [that also increased hardware utilization]. This last sentence is such a lie. The fact is that you, and most of the other fanboys, only care about the [that also increased hardware utilization]. The yammering about security is just one thing -- job security. You've got to be able to sell increased harwdare utilization in a way that does not hang you up at the end of the day. If people were saying: "Yes, it increased hardware utilization, and the nasty security impact might be low" it would be fine. But instead we have many uneducated people saying: "Yes, it increased hardware utilization, and it improved security too". And that's complete and utter bullshit.
Re: About Xen: maybe a reiterative question but ..
I am just astounded by how some people who love "virtualization" keep making the same mistakes. Are you even listening? > Practice also. XEN is a great tool for 'duplicating' a machine in an > entererprise environment (IME running 'user level' tools for hundreds or > thousands of users). Separating applications is invaluable, and the ^^ Who said it actually seperates? > ability to do a machine restore in minutes, using the most recent data > from a local SAN is also a major advantage. > > Nobody in the XEN (or VM) world in their right mind would put a VM on the > 'Net without significant protection (an OBSD PF machine, perhaps), and > I'm certainly not suggesting that. > > Remember that there is more than one world from a technology standpoint! > The vast majority of the SME marketspace (where we operate) is heavily > infiltrated with MS crap; OTOH, OBSD is the only choice for public > servers, or as a front-end to other OSs. The virtualization space > will have to mature significanty, if ever, to meet the security standards > of OBSD. > > In the meantime, virtualization provides a great solution for those > applications that benefit from running separately & isolated, while ^ You believe it does seperation and isolation? > maximizing h/w utilization. This, it does do. But the people who want to maximize hw utilization are trying to lie to themselves about the security aspects. You can't run more code and then have less failures.
Re: About Xen: maybe a reiterative question but ..
At 05:12 PM 10/24/2007 +0200, Henning Brauer wrote: * L. V. Lammert <[EMAIL PROTECTED]> [2007-10-24 16:46]: > Virtualization provides near absolute security - DOM0 is not visible to > the user at all, only passing network traffic and handling kernel calls. > The security comes about in that each DOMU is totally isolated from the > the others, while the core DOM0 is isolated from any attacks. dream on. that is what marketing wants to tell you. in fact the isolation is incredibly poor. Sorry, the kernel hacking world is pretty far removed from 'enterprise reality' !! In reality, there are tons of SMEs out there using MS Crap and other risky software! The few security risks you cite for XEN are negligable by comparison. Anything we can do to increase security, *including* setting up VMs (of any flavor) is an improvement [that also increased hardware utilization]. Lee
Re: About Xen: maybe a reiterative question but ..
Bottom-line is, the more complicated your setup gets, the more chances you get to fuck-up. All that stuff about extra permissions, extra layers. Each thingie you add you need to configure. And you won't be 100%, not all the time. So, Xen is just another opportunity to get fucked. Instead of designing security, you add another plugin, wave your magic wand, and say `this is improved security' (take your deepest booming voice, if you want to be convincing). Security theater, once again.
Re: About Xen: maybe a reiterative question but ..
On Wed, 24 Oct 2007, Paul de Weerd wrote: > On Wed, Oct 24, 2007 at 08:31:26AM -0500, L. V. Lammert wrote: > | On Wed, 24 Oct 2007, Henning Brauer wrote: > | > | > * [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2007-10-24 03:03]: > | > > Virtualization seems to have a lot of security benefits > | > > | > seems? > | > to whom? > | > > | Virtualization provides near absolute security - DOM0 is not visible to > | the user at all, only passing network traffic and handling kernel calls. > | The security comes about in that each DOMU is totally isolated from the > | the others, while the core DOM0 is isolated from any attacks. > > This is the theory. > Practice also. XEN is a great tool for 'duplicating' a machine in an entererprise environment (IME running 'user level' tools for hundreds or thousands of users). Separating applications is invaluable, and the ability to do a machine restore in minutes, using the most recent data from a local SAN is also a major advantage. Nobody in the XEN (or VM) world in their right mind would put a VM on the 'Net without significant protection (an OBSD PF machine, perhaps), and I'm certainly not suggesting that. Remember that there is more than one world from a technology standpoint! The vast majority of the SME marketspace (where we operate) is heavily infiltrated with MS crap; OTOH, OBSD is the only choice for public servers, or as a front-end to other OSs. The virtualization space will have to mature significanty, if ever, to meet the security standards of OBSD. In the meantime, virtualization provides a great solution for those applications that benefit from running separately & isolated, while maximizing h/w utilization. Lee Leland V. Lammert[EMAIL PROTECTED] Chief Scientist Omnitec Corporation Network/Internet Consultants www.omnitec.net
Re: Network Time Synchronization using timed or ntpd or a Combination?
On Wed, Oct 24, 2007 at 10:47:45AM -0500, Boris Goldberg wrote: | May be it makes sense to set "-ncv" as a default behavior of rdate, but | there is should be a way to synchronize time without running a demon (don't | understand why are people so aggressive about that) if you don't need | up-to-second synchronization (in my case modern hardware goes less than a | second off per day, and really old hardware - less than 10 seconds). The problem here is the jump in time. You repeat a second or more (if you have to jump back) or skip some (if you jump forward). This may not be a problem for you in particular, but is considered bad in general. Another issue is the fact that the server you're syncing to may not be perfectly sync'ed itself. Or maybe there's some (assymmetrical) delay in the network. This may make time on your machine somewhat off (this isn't as big a problem as the previous, IMO). And it's totally unneccessary, simply run ntpd and be done with it. It solves all the problems with syncing every once in a while, and as I indicated in my earlier mail, I don't see any of the problems with running another daemon on my machines that you described. It's small, uses proven security techniques and is still reasonably simple. But hey, if using rdate from a cron is your thing, dont let me get in your way. I used to do this before we had OpenNTPD too, since I wasn't really happy with ntp.org's daemon. If you're not really happy with OpenNTPD, more power to you ! But I dont think it's a good practice to do so, so suggesting it to others on this mailinglist will get you some replies from opponents of your solution... Cheers, Paul 'WEiRD' de Weerd -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
multimode fiber card recs for OpenBGPD
I have two servers that I would like to setup to run OpenBGPD for our border routers. I need to find a supported PCIe (not PCI-X) fiber card that runs multi-mode and a supported PCIe (not PCI-X) fiber card that runs single-mode. (One of our providers is coming to us with mm, the other with sm.) A dual port card is preferable, but we will take single port cards if those are the only ones available. Any recommendations? The supported cards page on the OpenBSD site only lists PCI-X cards. thanks, Thomas -- N.J. Thomas [EMAIL PROTECTED] Etiamsi occiderit me, in ipso sperabo
Re: About Xen: maybe a reiterative question but ..
On Oct 24, 2007, at 10:59 AM, Theo de Raadt wrote: > You don't > build better security by building another gigantic layer. That > is obvious to anyone who actually works in the field. Having worked in REAL VM :-) (IBM VM/ESA now z/VM) it isn't per se about security like we mean security ... preventing cracking attempts ... it is about isolation of processes. Isolation of processes does contribute to security but it's not the only point of flexion. In practice, mainframe VM varies greatly in security from installation to installation ... the protection of processes from one another in the VM operating system is as hardware/software perfect as the wit and skill of humankind can provide ... but I've found VM installations with accounts like USER passwd USER :-( All things being equal, the safest base installations in the universe would be those whose user instances were encased in some kind of solid VM and whose base instance administrators were provided with and followed best practices. In re that "solid" VM ... As Theo pointed out the other day, the Intel hardware support for virtualization is less than complete, i.e., less mature than the 35-year-old support for virtualization in the IBM 370/390 architecture. So we still gots a ways to go. -- Jack J. Woehr Director of Development Absolute Performance, Inc. [EMAIL PROTECTED] 303-443-7000 ext. 527
Re: About Xen: maybe a reiterative question but ..
> In the scientific cluster computing and enterprise spaces, it's > already well demonstrated, by many, many practitioners in those fields > [3], that virtualization is a very, very good tool. So what? Someone showed up here and said it is actually all about security. That is obviously false to anyone skilled in the field. You don't build better security by building another gigantic layer. That is obvious to anyone who actually works in the field. The people who are being fooled are just being 'users'. They need it, so they invent all sorts of judgements to make it OK.
Re: About Xen: maybe a reiterative question but ..
On 10/24/07, Paul de Weerd <[EMAIL PROTECTED]> wrote: > This is the theory. In theory, there's no bugs in OpenBSD. In > practice, many of the commits to the tree are not new features/drivers > but actual bugfixes. Read the paper by Tavis Ormandy, referenced by > Theo. There is a real problem with virtualization. Until all bugs are When you read Ormandy's paper, referenced by Damien Miller, in regards to Xen, you find: 1. Ormandy states that Xen's design is congruent with good security 2. Ormandy doesn't actually demonstrate a Dom0 -> DomU escalation, and in fact, didn't test any HVMs at all. 3. Qemu compromises != Xen HVM Qemu compromises Furthermore: 1. Upstream patches already exist [1] in response to Ormandy's bug report [2] > fixed, virtualization is worse than real hardware. And it'll be hard > to prove all the bugs are fixed. Unless you are using a purely functional language implemented directly on provably correct hardware, it's impossible to (mathematically) prove a program is free of bugs. Since you want to solve real-world problems, you make a tradeoff between features you want and issues you can live with. OpenBSD is very, very, very good at security. On the other hand, if you want to program a fast, parallelized quantum gravity model to run on a large cluster of OpenMosix nodes, it's not the right tool for the job. In the scientific cluster computing and enterprise spaces, it's already well demonstrated, by many, many practitioners in those fields [3], that virtualization is a very, very good tool. > Paul 'WEiRD' de Weerd [1] https://launchpad.net/ubuntu/+source/xen-3.1/ [2] http://secunia.com/advisories/26986/ [3] In addition to my own work, I can point to colleagues and organizations, for example, http://cse.ucdavis.edu and http://immunetolerance.org Adam -- "Invincibility is in oneself, vulnerability in the opponent." -- Sun Tzu
Re: max-src-conn-rate rule question
David,
I would take a look at adding synproxy to your rules before worrying about
max-src-states. Synproxy will allow max-src-conn-rate to work more
reliably.
By default, pf(4) passes packets that are part of a tcp(4) handshake be-
tween the endpoints. The synproxy state option can be used to cause pf(4)
itself to complete the handshake with the active endpoint, perform a
handshake with the passive endpoint, and then forward packets between the
endpoints.
No packets are sent to the passive endpoint before the active endpoint
has completed the handshake, hence so-called SYN floods with spoofed source
addresses will not reach the passive endpoint, as the sender can't complete
the handshake.
The proxy is transparent to both endpoints, they each see a single
connection from/to the other endpoint. pf(4) chooses random initial se-
quence numbers for both handshakes. Once the handshakes are completed, the
sequence number modulators (see previous section) are used to translate
further packets of the connection. Synproxy state includes modulate state.
(pf.conf man page)
--
Calomel @ http://calomel.org
On Tue, Oct 23, 2007 at 11:23:05PM -0500, david l goodrich wrote:
>On Tue, Oct 23, 2007 at 05:46:45PM -0400, Calomel wrote:
>> David,
>>
>> Was the offending client completing the 3-way handshake everytime it
>> connected?
>>
>> For stateful TCP connections, limits on established connections (connec-
>> tions which have completed the TCP 3-way handshake) can also be enforced
>> per source IP. The max-src-conn-rate / limit the rate of
>> new connections over a time interval. The connection rate is an
>> approximation calculated as a moving average.
>>
>> You may also want to use synproxy for ssh and take a look at
>> max-src-states. I have examples here: http://calomel.org/pf_config.html
>
>I didn't respond to this until now, because I wanted to do some
>research first. As the hosts that are being blocked by this
>aren't hosts I control, I needed to set up some access on the
>outside.
>
>So it looks like i can run 'nmap -sS -p22 25.103.82.80/28' until
>doomsday and it will always show as a passed connection.
>
>But when i start telnetting to port 22 on machines in this
>subnet, the fourth 'telnet' connection is blocked, no matter
>which host I hit previously. So I think that you are correct
>in that the attackers are not initially completing the 3-way
>handshake, and are thus not tripping the filter.
>
>I'll look in to max-src-states, but I think now that I've shown
>that the actual "attack" (if that's what they are) attempts are
>blocked properly, I'm not terribly concerned if they can scan the
>subnet.
>
>Thanks,
> --david
>
>>
>> --
>> Calomel @ http://calomel.org
>>
>> On Tue, Oct 23, 2007 at 03:58:52PM -0500, david l goodrich wrote:
>> >Nobody? Sad, it's still doing it.
>> >
>> >
>> >On Sun, Oct 21, 2007 at 02:22:43PM -0500, david l goodrich wrote:
>> >> I've set up a max-src-conn-rate rule on my gateway router to
>> >> mitigate brute-force ssh attacks. This router protects a /28
>> >> subnet, 25.108.82.80/28.
>> >>
>> >> The relevant rules:
>> >>
>> >> # pfctl -sr | grep attack
>> >> block drop in log quick proto tcp from to any
>> >> pass in log proto tcp from any to any port = ssh keep state
>> >> (source-track rule, max-src-conn-rate 3/30, overload
>> >> flush global, src.track 30)
>> >> #
>> >>
>> >> What the three columns of output in the below tcpdump output are:
>> >> timestamp, rule action, and target host. As you can tell from
>> >> the tcpdump command, the sending host is the same in all cases,
>> >> 208.53.147.204
>> >>
>> >> # tcpdump -enr /var/log/pflog host 208.53.147.204 \
>> >> > | awk '{print $1,$4,$11}' | sed s/.22:// | head -30
>> >> reading from file /var/log/pflog, link-type PFLOG (OpenBSD pflog file)
>> >> 12:09:45.849594 pass 25.103.82.80
>> >> 12:09:45.850279 pass 25.103.82.82
>> >> 12:09:45.850827 pass 25.103.82.83
>> >> 12:09:45.851310 pass 25.103.82.84
>> >> 12:09:45.852003 pass 25.103.82.85
>> >> 12:09:45.852496 pass 25.103.82.86
>> >> 12:09:45.853007 pass 25.103.82.87
>> >> 12:09:45.866580 pass 25.103.82.88
>> >> 12:09:45.867345 pass 25.103.82.89
>> >> 12:09:45.868339 pass 25.103.82.92
>> >> 12:09:45.902389 pass 25.103.82.95
>> >> 12:25:52.632295 pass 25.103.82.80
>> >> 12:25:52.632973 pass 25.103.82.82
>> >> 12:25:52.648804 pass 25.103.82.83
>> >> 12:25:52.684792 pass 25.103.82.84
>> >> 12:25:52.687989 pass 25.103.82.85
>> >> 12:25:52.688652 pass 25.103.82.86
>> >> 12:25:52.690882 pass 25.103.82.87
>> >> 12:25:52.691371 pass 25.103.82.88
>> >> 12:25:52.692290 pass 25.103.82.89
>> >> 12:25:52.695340 pass 25.103.82.92
>> >> 12:25:52.698864 pass 25.103.82.95
>> >> 13:08:36.949178 pass 25.103.82.87
>> >> 13:08:38.864585 pass 25.103.82.87
>> >> 13:08:40.452215 pass 25.103.82.87
>> >> 13:08:42.038388 pass 25.103.82.87
>> >> 13:08:46.923469 block 25.103.82.88
>> >> 13:08:49.922116 block 25.103.82.88
>> >> 13:08:50.212040 block 25.103.82.87
>> >> 13:08:51.099435
Re: Network Time Synchronization using timed or ntpd or a Combination?
Hello Clint, Tuesday, October 23, 2007, 5:36:15 PM, you wrote: CP> From what I have read in this thread, it looks like only one guy CP> prefers the old timed and rdate tools. A few are even telling him he is CP> giving bad advice when promoting the usage of these tools. Henning CP> mentioned that rdate and timed are pretty much useless and others have CP> said that timed is obsolete. So why don't we remove them from the source CP> tree? I've never suggested (or mentioned) the timed. Of course I was talking about the "-n" mode of rdate (as a replacement to ntpdate like Paul de Weerd was suggesting in this thread). May be it makes sense to set "-ncv" as a default behavior of rdate, but there is should be a way to synchronize time without running a demon (don't understand why are people so aggressive about that) if you don't need up-to-second synchronization (in my case modern hardware goes less than a second off per day, and really old hardware - less than 10 seconds). -- Best regards, Borismailto:[EMAIL PROTECTED]
Re: About Xen: maybe a reiterative question but ..
Christoph Egger wrote:
On Wednesday 24 October 2007 17:25:25 Artur Grabowski wrote:
Christoph Egger <[EMAIL PROTECTED]> writes:
So I'm going to guess the answer is "No, integrating xen
paravirtualization is not a project priority at this time. Also, where
are your diffs?"
The OpenBSD/Xen source is at http://hg.recoil.org/openbsd-xen-sys.hg
Unfortunately, Anil has troubles with the availability of the server.
I rely on having a willing OpenBSD developer who commits the patches I
send to him. But as long as there is none, it doesn't go in.
I'm willing to stretch as far as saying: This might be interesting for
some testing purposes for kernel hackers if Xen could be hosted on
OpenBSD.
But this doesn't mean that I'm even close to volunteering doing the
job. It just would be cool to have if it doesn't break stuff.
//art
Actually it is good to find NULL-pointer (mostly use-after-free) bugs,
that are hard to find on real hardware.
Believe me or not: OpenBSD has tons of them.
Christoph
Christoph,
One question about your Xen port: is it possible to compile a xen
para-virtualized openbsd kernel to launch a clean OpenBSD 4.1 or 4.2 install??
Thanks for your great job Christoph.
--
CL Martinez
carlopmart {at} gmail {d0t} com
spamdb expire value gets default value instead of spamd_flag value (-G)
Hi, When testing greylisting with synchronizing we noticed the following strange behavior: Machine A (10.100.64.234) is the machine we receive mail through. Machine B (10.100.64.233) is synced through spamd Check out the expire value on machine A after the state have gone from Grey to White! It has taken the default 36 days ahead instead of our 2 hour (testvalue) from spamd_flags!! But Machine B (the passive "brother" which gets synced through spamd-sync) behaves as it should!? spamdb (A): WHITE|10.100.64.199|||1193231843|1193232057|1196342528|3|1 spamdb (B): WHITE|10.100.64.199|||1193231843|1193232057|1193239279|3|1 pf.conf: no rdr inet proto tcp from to any port smtp rdr pass inet proto tcp from ! to $ext_if:0 port smtp -> 127.0.0.1 port spamd pass in quick log on $ext_if proto tcp from any to ($ext_if) port $public_tcp pass in log on $int_if proto tcp from to ($int_if) port $sec_tcp /etc/rc.conf.local (B) pf=YES syslogd_flags="-a /var/spool/postfix/dev/log" spamd_flags="-y fxp0 -Y 10.100.64.234 -G 3:1:2" spamlogd_flags="-i fxp0 -Y 10.100.64.234" /etc/rc.conf.local (A) pf=YES syslogd_flags="-a /var/spool/postfix/dev/log" spamd_flags="-y fxp0 -Y 10.100.64.233 -G 3:1:2" spamlogd_flags="-i fxp0 -Y 10.100.64.233" --- Probably some small "feature" to fix Regards Claes Strvm
Re: About Xen: maybe a reiterative question but ..
On Wed, 24 Oct 2007, L. V. Lammert wrote: >Virtualization provides near absolute security - DOM0 is not visible to >the user at all, only passing network traffic and handling kernel calls. >The security comes about in that each DOMU is totally isolated from the >the others, while the core DOM0 is isolated from any attacks. In theory, you're correct. In practice there are (at least) four questions which all must be answered in the affirmative for this to be true: 1) Does the hardware architecture provide all of the hooks needed to implement virtualization? 2) Does the specific hardware correctly implement that architecture? 3) Does the virtualization software architecture properly implement virtualization? 4) Does the specific software correctly implement that architecture? Answering any of those questions takes both a lot of work and, all too often, access to information which is not generally available. And if any of the answers is 'no', the security of anything run under that virtualization may be fatally compromised -- no matter how secure that software may be when run standalone. Dave -- Dave Anderson <[EMAIL PROTECTED]>
Re: About Xen: maybe a reiterative question but ..
On Wednesday 24 October 2007 17:25:25 Artur Grabowski wrote: > Christoph Egger <[EMAIL PROTECTED]> writes: > > > So I'm going to guess the answer is "No, integrating xen > > > paravirtualization is not a project priority at this time. Also, where > > > are your diffs?" > > > > The OpenBSD/Xen source is at http://hg.recoil.org/openbsd-xen-sys.hg > > Unfortunately, Anil has troubles with the availability of the server. > > > > I rely on having a willing OpenBSD developer who commits the patches I > > send to him. But as long as there is none, it doesn't go in. > > I'm willing to stretch as far as saying: This might be interesting for > some testing purposes for kernel hackers if Xen could be hosted on > OpenBSD. > > But this doesn't mean that I'm even close to volunteering doing the > job. It just would be cool to have if it doesn't break stuff. > > //art Actually it is good to find NULL-pointer (mostly use-after-free) bugs, that are hard to find on real hardware. Believe me or not: OpenBSD has tons of them. Christoph
Wake on LAN, tcpdump weirdness with two ethernet interfaces
I'm noticing some strangeness in conjunction with WOL(*), which seems not to be working and am not sure where the problem lies(**). The machine launching the packets has two interfaces, re0 and em0, with the receiving machine connected to re0. The machine does not wake up either using port 9 or port 4. A bit of strangeness in the diagnostics is that tcpdump appears not to register and packets from or to re0. It does not catch any packets on re0, even from nmap -P0 -e re0 -T5 a.b.c.d tcpdump -i re0 ip proto 17 whereas the following catches packets, even from wol, when sent to addresses on em0. tcpdump -i em0 ip proto 17 Route shows the following: Internet: Destination GatewayFlagsRefs UseMtu Interface a.b.c.d 00:0f:1f:78:82:07 UHLc1 8629 - re0 and when the machine is already on, I can ping and connect via ssh. pfctl -s rules are as simple as possible: scrub in all fragment reassemble pass in all flags S/SA keep state pass out all flags S/SA keep state What's up with tcpdump and, more importantly, wol? -Lars (*) Installed using pgk_add: http://www.openbsd.org/4.1_packages/i386/wol-0.7.1p1.tgz-long.html (**) Hardware is a Dell DHP on which I've set the BIOS to allow remote wakeup and have the lowpower mode (which hinders remote wakeup) off.
Re: About Xen: maybe a reiterative question but ..
Christoph Egger <[EMAIL PROTECTED]> writes: > > So I'm going to guess the answer is "No, integrating xen > > paravirtualization is not a project priority at this time. Also, where > > are your diffs?" > > The OpenBSD/Xen source is at http://hg.recoil.org/openbsd-xen-sys.hg > Unfortunately, Anil has troubles with the availability of the server. > > I rely on having a willing OpenBSD developer who commits the patches I send > to him. But as long as there is none, it doesn't go in. I'm willing to stretch as far as saying: This might be interesting for some testing purposes for kernel hackers if Xen could be hosted on OpenBSD. But this doesn't mean that I'm even close to volunteering doing the job. It just would be cool to have if it doesn't break stuff. //art
Re: About Xen: maybe a reiterative question but ..
* L. V. Lammert <[EMAIL PROTECTED]> [2007-10-24 16:46]: > Virtualization provides near absolute security - DOM0 is not visible to > the user at all, only passing network traffic and handling kernel calls. > The security comes about in that each DOMU is totally isolated from the > the others, while the core DOM0 is isolated from any attacks. dream on. that is what marketing wants to tell you. in fact the isolation is incredibly poor. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
Re: About Xen: maybe a reiterative question but ..
On Wednesday 24 October 2007 16:14:19 Chris Kuethe wrote: > On 10/24/07, carlopmart <[EMAIL PROTECTED]> wrote: > > Dear sirs please: I will return to my original question. I just wondered > > if xen will be included into the OpenBSD's kernel to act as a > > para-virtualized DomU or not. Nothing more. I will not go into issues of > > the type is insecure or not. > > > > Theo, or somebody from developer team: Will be para-virtualized domU xen > > kernel included on next OpenBSD release (4.3?) or not?? I only want to > > know this... > > Not unless someone actually writes the code to do it. Notice the > extreme number of people with openbsd.org email addresses jumping up > and down, volunteering to do it (hint: none). Possibly not even if > someone writes the code. Diffs are not always merged. They should be > good diffs that improve OpenBSD. Notice the number of people with > openbsd.org email addresses who are not convinced that doing this a) > will improve OpenBSD and b) won't actually hurt. > > So I'm going to guess the answer is "No, integrating xen > paravirtualization is not a project priority at this time. Also, where > are your diffs?" The OpenBSD/Xen source is at http://hg.recoil.org/openbsd-xen-sys.hg Unfortunately, Anil has troubles with the availability of the server. I rely on having a willing OpenBSD developer who commits the patches I send to him. But as long as there is none, it doesn't go in. Christoph
Re: About Xen: maybe a reiterative question but ..
On Tuesday 23 October 2007 18:22:00 ropers wrote:
> Hi Christoph,
>
> Right now, on the OpenBSD misc mailing list, there is this discussion:
> http://www.sigmasoft.com/~openbsd/archives/html/openbsd-misc/2007-10/thread
>s.html#01149 about OpenBSD/Xen.
>
> We last spoke last year, when I put your BSDtalk interview transcript
> online at http://ropersonline.com/openbsd/xen .
>
> It seems to me that most people on the misc mailing list currently are
> not very aware of your OpenBSD Xen port. Could I possibly ask you to
> participate in the discussion? I feel that you (and Theo) are the only
> guys who can provide authoritative answers on the issue.
>
> Some of the questions that I feel are unclear are:
> - Was your porting work fully completed? IIRC it was, but please clarify.
DomU support is ready. Dom0 is work in progress.
(apart from use-after-free bugs in MI buffer-cache and filesystem code,
which damages filesystem.)
Dom0 is work in progress, but is stalling on a NULL-pointer bug
in uvm_pglistalloc_simple().
This code piece in the kernel reproduces this crash:
void foo(void)
{
struct pglist mlist;
uvm_pglistalloc(PAGE_SIZE * 64, 0, 0x, 0, 0, &mlist, 64, 0);
}
I didn't investigate further into this, because I have put my focus
on the xen-kernel and xen-tools to compile on OpenBSD and NetBSD
out-of-the-box. To finish this task, I need some things in OpenBSD:
- aio(2) support
- POSIX ptsname() (this is used in a python binding module)
- newer gcc version due to a structure padding bug with
an alignment attribute hidden in a typedef (this is fixed in gcc 3.4)
I use gcc 4.2 from the ports FYI.
- I need i386 headers and libc on OpenBSD/amd64 for 64bit builds.
gcc -m32 defines __i386__ so it is possible to distinguish if a
#include must provide 32bit or 64bit integer type definitions.
Oh, a libc header cleanup is nice to have. I don't know why uvm kernel headers
should be in /usr/include/uvm/, for example.
> - Is your port still being maintained? Can it be run with OpenBSD
> -current or 4.2?
4.1. It needs an update. Maybe some of the nasty MI bugs are gone.
> - It seems to me that your port didn't achieve wide recognition and
> acclaim because of a lack of publicity.
I'm not a marketing guy.
> - AFAIK your OpenBSD/Xen port code hasn't found its way into the
> official OpenBSD distribution. Is this correct?
yes.
> - Are there any reasons why your code didn't go into the official
> OpenBSD distro? Was it lack of awareness? Have you ever talked to Theo
> and/or other central OpenBSD people?
I haven't found someone who is willing to commit the diffs.
> - Is there any hope that your port might still become part of the
> official OpenBSD distribution?
> (Theo: Could you possibly comment as well?)
I don't know.
> I'd personally be very interested to see your port become part of the
> official distribution, but I sadly can't code myself, so all I can do
> is ask and hope. :)
>
> Once again, thanks for your hard work. :)
You're welcome.
> Many thanks in advance and kind regards,
> Jens Ropers
Re: About Xen: maybe a reiterative question but ..
On Wed, Oct 24, 2007 at 08:31:26AM -0500, L. V. Lammert wrote: | On Wed, 24 Oct 2007, Henning Brauer wrote: | | > * [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2007-10-24 03:03]: | > > Virtualization seems to have a lot of security benefits | > | > seems? | > to whom? | > | Virtualization provides near absolute security - DOM0 is not visible to | the user at all, only passing network traffic and handling kernel calls. | The security comes about in that each DOMU is totally isolated from the | the others, while the core DOM0 is isolated from any attacks. This is the theory. In theory, there's no bugs in OpenBSD. In practice, many of the commits to the tree are not new features/drivers but actual bugfixes. Read the paper by Tavis Ormandy, referenced by Theo. There is a real problem with virtualization. Until all bugs are fixed, virtualization is worse than real hardware. And it'll be hard to prove all the bugs are fixed. Cheers, Paul 'WEiRD' de Weerd -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
