Re: what is the maximum length of username?
On Thursday, 29 December 2005 at 12:41:29 -0700, Theo de Raadt wrote: Is it advisable to change the definition to increase the maximum length? No. I strongly advise you against that. I won't attempt to do that. Thanks, Zoong
Re: 256 ip: bridge or router
On Tue, Jan 03, 2006 at 12:37:29PM +0100, Pailloncy Jean-Gerard wrote: And also wrote: The two cables came from two routers of my provider. The two ips (a.b.c.1 and a.b.c.2) are in the same vlan on the two different routers. Broadcast should work. So on outside, a CARP should be the simple thing I have to do. Thank you for the information. I do not understand how the packets coming from the gateway a.b.c.1-2 are able to reach the routers a.b.c.3-4 on the CARP address a.b.c.5. The routing table on a.b.c.[12] will simply tell them to push everything for a.b.c.0/24 out of some interface. It's then up to whatever is attached to that interface to provide routing. (Discarding complicated stuff, routing tables basically look up an IP address and tell the kernel what interface to use to send packets for that IP address.) Per se, it's very much possible to rename your routers a.b.c.253 and a.b.c.254. Numbering them a.b.c.[34] is easiest, which is generally a good thing, but it is quite possible. In this case, a (virtual) CARP interface is attached. I'm afraid I don't know much about vlans, so you're on your own there - but it shouldn't be too difficult. There are many good books that deal with such topics, BTW; I'm afraid I can't give recommendations, aside from the fact that Tanenbaum's 'Computer Networks' is very good, but a little too thorough if you just want to make stuff work. Joachim
NFS-Question (nfs-server timeouts..?)
Hi everybody, I've a question related to NFS. I#ve 2 PCs at home. One is a Server (NFS) running 3.8 and the other is my workstation running current. Server provides a NFS-Share. Let's call it /nfs Workstation mounts the NFS-Share into /mnt/nfs If the Workstation calculates something and I power off the Server to save some energy and power on this system later the workstation will NOT be able to read/write anything to the NFS-Share. It will simply report: nfs server server:/nfs: not responding The workstation will not hang but the shell where I did e.g. ls /mnt/nfs hangs and can't get killed anyway. Even a sudo umount -f /mnt/nfs stoped working and reported the same error-message. I would say it's a Bug in the NFS-Implementation because it should handle such things. My fstab-entry is: server:/nfs on /mnt/nfs type nfs (nodev, nosuid, v3, tcp, soft, intr, timeo=100) So there IS a timeout specified but it wont help. The only solution is to reboot the workstation. So is this a Problem related to NFS or did I missed anything??? It seams just during a reboot the timeout is noticed so after ~some seconds the machine will reboot. I've the same issues with an 3.8 Client so it shouldn't be current-related. Kind regards, Sebastian
Re: DadOS - sys shutdown with XDM
Hello! On Tue, Jan 03, 2006 at 03:24:22AM -0800, J.C. Roberts wrote: My dad (68 years old) has finally succeeded in destroying/infecteding his MS-Windows NT4 box, in spite of my best efforts to secure the darn thing (e.g. No MSIE, No Microsoft Networking, stripped of just about everything MS-ish and with tons of hand made patches, behind an openbsd firewall... and so on and so forth). It lasted a good four years in the hands of a typical user that hates computers, clicks on everything and still expects everything to just work and work properly. 4 years w/o infection isn't that bad for windoze... :-) [...] The first thing I did was add a flag file to my dad's home directory and made sure he cant modify or delete it. # touch /home/dad/.xshutdown # chown root:wheel /home/dad/.xshutdown # chmod 400 /home/dad/.xshutdown Since /etc/X11/xdm/TakeConsole runs with root permission on every user logout to prevent /dev/console sniffing I modified it to perform the shutdown if the flag file is found in the users home directory. # cat /etc/X11/xdm/TakeConsole #!/bin/sh # Reassign ownership of the console to root, this should disallow # assignment of console output to any random users's xterm # $Xorg: TakeConsole,v 1.3 2000/08/17 19:54:17 cpqbld Exp $ # $OpenBSD: TakeConsole,v 1.3 2004/11/03 00:22:21 matthieu Exp $ # chmod 622 /dev/console chown root /dev/console /usr/X11R6/bin/sessreg -d -l $DISPLAY -u /var/run/utmp \ -x /usr/X11R6/lib/X11/xdm/Xservers $USER if [ -f $HOME/.xshutdown ]; then shutdown -hp now fi # This approach works perfectly but my questions are: Is there anything wrong with this approach? Is there's a better way to deal with the problem? I know no better way offhand. It looks hacky, but it'll keep working I guess. I know it's a holy war topic, but do you have a recommendation for an email client he could use? kmail is quite usable and it'll be the mail client best integrated into the rest of your dad's desktop, if he's gonna use the OpenBSD/KDE box. thanks, jcr Kind regards, Hannah.
Re: 256 ip: bridge or router
On Tue, Jan 03, 2006 at 12:37:29PM +0100, Pailloncy Jean-Gerard wrote: And also wrote: The two cables came from two routers of my provider. The two ips (a.b.c.1 and a.b.c.2) are in the same vlan on the two different routers. Broadcast should work. So on outside, a CARP should be the simple thing I have to do. Thank you for the information. I do not understand how the packets coming from the gateway a.b.c.1-2 are able to reach the routers a.b.c.3-4 on the CARP address a.b.c.5. The routing table on a.b.c.[12] will simply tell them to push everything for a.b.c.0/24 out of some interface. It's then up to whatever is attached to that interface to provide routing. (Discarding complicated stuff, routing tables basically look up an IP address and tell the kernel what interface to use to send packets for that IP address.) This all depends how things are connected to the ISP. From 'broadcast should work' and the talk of vlans, it sounds like either there are two ISP-provided routers on the LAN, or it's ethernet-presented and ARP is running over the link. In either of these cases, it will be necessary to either add routes on the ISP routers (which might not be possible, it depends on the ISP), or to proxy-arp (not especially attractive), or to run the firewalls as bridges (probably with STP). Either way it's probably best to discuss this with the ISP. They almost certainly have other customers who want to route traffic via their own firewall. CARP doesn't really affect anything, except that you need a couple of additional addresses outside the firewall. From previous posts ...: The external interface should be assigned, say, a.b.c.3 resp. a.b.c.4. Give them a netmask of 255.255.255.247. This will allow you 8 This should be .248 (.247 doesn't make sense as a netmask). Now, since more specific entries trump more generic, the Soekrises will route a.b.c.0/28 to the outside routers .248 is /29 For this setup, the ISP would have to configure their routers with 255.255.255.248 netmask on the interface, and add a static route to a.b.c.0/24 via the CARP address. imho it is confusing to have overlapping netmasks and if e.g. the ISP has to do emergency work on the routers, there's more likely to be a problem this way. The other method is to have the small subnet for the ISP routers and the routing-firewalls that is separate from the main block, e.g. d.e.f.0/29 d.e.f.1 ISP router1 d.e.f.2 ISP router2 d.e.f.4 local router1 d.e.f.5 local router2 d.e.f.6 local CARP address On d.e.f.1 and d.e.f.2, the ISP would add a route sending a.b.c.0/24 traffic to d.e.f.6
Possible bridge bug
Hello all, Could someone explain this behaviour? When an IP address is assigned to a bridge member interface, an arp broadcast request to this interface bypasses bridge filter rules. But, an arp unicast request is blocked as it should. Setup: 192.168.1.1(00:aa:bb:01:02:03) --pcn0-[bridge]-pcn3-- 192.168.1.15(00:0c:29:b3:fa:3a) Configuration: bridge0: flags=41UP,RUNNING Configuration: priority 32768 hellotime 2 fwddelay 15 maxage 20 Interfaces: pcn3 flags=4BLOCKNONIP port 4 ifpriority 128 ifcost 55 pass in on pcn3 src 00:0c:29:b3:fa:3a dst 00:aa:bb:01:02:03 block in on pcn3 pass out on pcn3 src 00:aa:bb:01:02:03 dst 00:0c:29:b3:fa:3a block out on pcn3 pcn1 flags=4BLOCKNONIP port 2 ifpriority 128 ifcost 55 pcn0 flags=3LEARNING,DISCOVER port 1 ifpriority 128 ifcost 55 Addresses (max cache: 100, timeout: 240): 00:0c:29:b3:fa:3a pcn3 0 flags=1STATIC 00:aa:bb:01:02:03 pcn0 1 flags=0 00:0c:29:a3:6d:69 pcn1 0 flags=1STATIC lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 33224 groups: lo inet 127.0.0.1 netmask 0xff00 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x8 pcn0: flags=8b43UP,BROADCAST,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST mtu 1500 lladdr 00:0c:29:c7:1c:1c groups: egress media: Ethernet autoselect (autoselect) inet 192.168.1.2 netmask 0xff00 broadcast 192.168.1.255 inet6 fe80::20c:29ff:fec7:1c1c%pcn0 prefixlen 64 scopeid 0x1 pcn1: flags=8b43UP,BROADCAST,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST mtu 1500 lladdr 00:0c:29:c7:1c:26 media: Ethernet autoselect (autoselect) inet6 fe80::20c:29ff:fec7:1c26%pcn1 prefixlen 64 scopeid 0x2 pcn2: flags=8802BROADCAST,SIMPLEX,MULTICAST mtu 1500 lladdr 00:0c:29:c7:1c:30 media: Ethernet autoselect (autoselect) pcn3: flags=8b43UP,BROADCAST,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST mtu 1500 lladdr 00:0c:29:c7:1c:3a media: Ethernet autoselect (autoselect) inet6 fe80::20c:29ff:fec7:1c3a%pcn3 prefixlen 64 scopeid 0x4 pflog0: flags=141UP,RUNNING,PROMISC mtu 33224 pfsync0: flags=0 mtu 1348 enc0: flags=0 mtu 1536 bridge0: flags=41UP,RUNNING mtu 1500 groups: bridge Command on 192.168.1.15: arping 192.168.1.2 ARPING 192.168.1.2 from 192.168.1.15 eth0 Unicast reply from 192.168.1.2 [00:0C:29:C7:1C:1C] Sent 4 probes (1 broadcast(s)) Received 1 response(s) TCPDUMP on pcn3: 17:57:27.358385 0:c:29:b3:fa:3a ff:ff:ff:ff:ff:ff 0806 60: arp who-has 192.168.1.2 (ff:ff:ff:ff:ff:ff) tell 192.168.1.15 17:57:27.358502 0:c:29:c7:1c:1c 0:c:29:b3:fa:3a 0806 60: arp reply 192.168.1.2 is-at 0:c:29:c7:1c:1c 17:57:28.911213 0:c:29:b3:fa:3a 0:c:29:c7:1c:1c 0806 60: arp who-has 192.168.1.2 (0:c:29:c7:1c:1c) tell 192.168.1.15 17:57:30.556387 0:c:29:b3:fa:3a 0:c:29:c7:1c:1c 0806 60: arp who-has 192.168.1.2 (0:c:29:c7:1c:1c) tell 192.168.1.15 17:57:32.405283 0:c:29:b3:fa:3a 0:c:29:c7:1c:1c 0806 60: arp who-has 192.168.1.2 (0:c:29:c7:1c:1c) tell 192.168.1.15
Re: Possible bridge bug
Could someone explain this behaviour? When an IP address is assigned to a bridge member interface, an arp broadcast request to this interface bypasses bridge filter rules. But, an arp unicast request is blocked as it should. If you can, it might be helpful to confirm this somewhere other than with vmware virtual nics, just to rule out the possibility of vmware's networking doing something unexpected. If you must use vmware, maybe you could try USB nics and have them attach to the VM via the virtual-USB instead.
Postfix, fatal: Cross-device link
Hi there, I think I know the answer to this, just wanted to double check before I re-partioned. As postfix runs chrooted in /var/spool/postfix, is it therfore impractable to have this arrangement: $ fgrep postfix /etc/fstab /dev/wd0m /var/spool/postfixffs rw,nodev,nosuid,noexec,softdep,noatime 0 2 /dev/wd1d /var/spool/postfix/deferred ffs rw,nodev,nosuid,noexec,softdep,noatime 0 2 Jan 3 13:56:02 monaro postfix/qmgr[11640]: 010517: from=[EMAIL PROTECTED], size=3197 , nrcpt=1 (queue active) Jan 3 13:56:27 monaro postfix/anvil[9873]: statistics: max connection rate 1/60s for (smtp:192.43.244.163) at Jan 3 13:52:5 3 Jan 3 13:56:27 monaro postfix/anvil[9873]: statistics: max connection count 1 for (smtp:192.43.244.163) at Jan 3 13:52:53 Jan 3 13:56:27 monaro postfix/anvil[9873]: statistics: max cache size 1 at Jan 3 13:52:53 Jan 3 13:56:32 monaro postfix/smtp[5863]: connect to kingswood.kepax.co.uk[192.168.253.20]: Operation timed out (port 25) Jan 3 13:56:32 monaro postfix/smtp[5863]: 010517: to=[EMAIL PROTECTED], relay=none, delay=218, status=deferred (co nnect to kingswood.kepax.co.uk[192.168.253.20]: Operation timed out) Jan 3 13:56:32 monaro postfix/qmgr[11640]: fatal: qmgr_active_defer: rename 010517 from active to deferred: Cross-device lin k Jan 3 13:56:33 monaro postfix/master[18486]: warning: process /usr/local/libexec/postfix/qmgr pid 11640 exit status 1 Jan 3 14:01:02 monaro postfix/qmgr[29897]: 010517: from=[EMAIL PROTECTED], size=3197 , nrcpt=1 (queue active) When I googled, I found threads about MySQL library problems, nothing about spools, but it looks like the solution is the same: put it all on the same slice, no? Craig.
Re: Postfix, fatal: Cross-device link
I think I know the answer to this, just wanted to double check before I re-partioned. As postfix runs chrooted in /var/spool/postfix, is it therfore impractable to have this arrangement: chroot isn't involved. Have you thought about what you're asking it to do when it has to move a mail item between queues? Jan 3 13:56:32 monaro postfix/qmgr[11640]: fatal: qmgr_active_defer: rename 010517 from active to deferred: Cross-device link
Re: Possible bridge bug
Stuart Henderson wrote: Could someone explain this behaviour? When an IP address is assigned to a bridge member interface, an arp broadcast request to this interface bypasses bridge filter rules. But, an arp unicast request is blocked as it should. If you can, it might be helpful to confirm this somewhere other than with vmware virtual nics, just to rule out the possibility of vmware's networking doing something unexpected. If you must use vmware, maybe you could try USB nics and have them attach to the VM via the virtual-USB instead. I don't have access to 'real' machines right now. (Replaced all heavy iron with virtual machines...) Could somebody confirm this behaviour?
Re: 256 ip: bridge or router
On Tue, Jan 03, 2006 at 02:42:56PM +, Stuart Henderson wrote: On Tue, Jan 03, 2006 at 12:37:29PM +0100, Pailloncy Jean-Gerard wrote: And also wrote: The two cables came from two routers of my provider. The two ips (a.b.c.1 and a.b.c.2) are in the same vlan on the two different routers. Broadcast should work. So on outside, a CARP should be the simple thing I have to do. Thank you for the information. I do not understand how the packets coming from the gateway a.b.c.1-2 are able to reach the routers a.b.c.3-4 on the CARP address a.b.c.5. The routing table on a.b.c.[12] will simply tell them to push everything for a.b.c.0/24 out of some interface. It's then up to whatever is attached to that interface to provide routing. (Discarding complicated stuff, routing tables basically look up an IP address and tell the kernel what interface to use to send packets for that IP address.) This all depends how things are connected to the ISP. From 'broadcast should work' and the talk of vlans, it sounds like either there are two ISP-provided routers on the LAN, or it's ethernet-presented and ARP is running over the link. In either of these cases, it will be necessary to either add routes on the ISP routers (which might not be possible, it depends on the ISP), or to proxy-arp (not especially attractive), or to run the firewalls as bridges (probably with STP). From previous posts ...: The external interface should be assigned, say, a.b.c.3 resp. a.b.c.4. Give them a netmask of 255.255.255.247. This will allow you 8 This should be .248 (.247 doesn't make sense as a netmask). Now, since more specific entries trump more generic, the Soekrises will route a.b.c.0/28 to the outside routers .248 is /29 Yes, and yes. Oops. snip: 'use a different subnet for the routers' That's a lot easier, of course - but outside the scope of the original question, i.e. it's cheating! ;-) Thanks for the corrections! Joachim (Note to self: don't post nontrivial networking stuff without reading it over, even when in a hurry.)
Re: DadOS - sys shutdown with XDM
On Tue, 3 Jan 2006, Joachim Schipper wrote: Basically, all mail clients suck. And the one that sucks less is not very newbie-friendly. Joachim Hehehe, I agree. However, I have used a few graphical clients that weren't too bad. Evolution, Thunderbird, and Sylpheed-Claws. A few weeks ago I tried to load Evolution on a box but had problems. Never had problems with the other two. Thunderbird is probably a little more user friendly than Sylpheed-Claws tho. -- Terry
APIC
Hello. Does OpenBSD 3.8 use the APIC (Advanced Programmable Interrupt Controller) ? Some cards, e,g telephony and framegrabbers have issues with the limited standard XT 16 IRQ's. APIC motherboards give you 24 or more (I've seen as many as 101) interrupts. Besides doing a dmesg | grep irq, is there another way at seeing the assigned interrupts. e.g. For Linux cat /proc/interrupts reveals:- Dell PowerEdge 2850 (dual Xeon) cat /proc/interrupts CPU0 CPU1 0:6184515 72IO-APIC-edge timer 1: 8 1IO-APIC-edge i8042 9: 0 0 IO-APIC-level acpi 12: 65 1IO-APIC-edge i8042 14: 11 2IO-APIC-edge ide0 46: 19595 1 IO-APIC-level megaraid 64: 66366 1 IO-APIC-level eth0 65: 77045 1 IO-APIC-level eth1 101: 6113521 1 IO-APIC-level wctdm NMI: 1 0 LOC: 6184694 6184698 ERR: 0 MIS: 0 Regards...Martin
Re: Postfix, fatal: Cross-device link
On Tue, Jan 03, 2006 at 03:36:51PM +, Craig Skinner wrote: Hi there, I think I know the answer to this, just wanted to double check before I re-partioned. As postfix runs chrooted in /var/spool/postfix, is it therfore impractable to have this arrangement: $ fgrep postfix /etc/fstab /dev/wd0m /var/spool/postfixffs rw,nodev,nosuid,noexec,softdep,noatime 0 2 /dev/wd1d /var/spool/postfix/deferred ffs rw,nodev,nosuid,noexec,softdep,noatime 0 2 Jan 3 13:56:02 monaro postfix/qmgr[11640]: 010517: from=[EMAIL PROTECTED], size=3197 , nrcpt=1 (queue active) Jan 3 13:56:32 monaro postfix/smtp[5863]: connect to kingswood.kepax.co.uk[192.168.253.20]: Operation timed out (port 25) Jan 3 13:56:32 monaro postfix/smtp[5863]: 010517: to=[EMAIL PROTECTED], relay=none, delay=218, status=deferred (co nnect to kingswood.kepax.co.uk[192.168.253.20]: Operation timed out) Jan 3 13:56:32 monaro postfix/qmgr[11640]: fatal: qmgr_active_defer: rename 010517 from active to deferred: Cross-device lin k When I googled, I found threads about MySQL library problems, nothing about spools, but it looks like the solution is the same: put it all on the same slice, no? Yes. What you want to do is not theoretically impossible, but it is highly impractical. Postfix manages its spool by moving files about; move is quick within a filesystem, but no faster than copy across filesystems. (And postfix has apparently chosen not to support this at all.) So this is, indeed, not a good idea. If both disks are of similar speed, you might want to run a RAID. Joachim
Re: NFS-Question (nfs-server timeouts..?)
On Tue, Jan 03, 2006 at 02:43:22PM +0100, Sebastian Rother wrote: Hi everybody, snip nfs server server:/nfs: not responding The workstation will not hang but the shell where I did e.g. ls /mnt/nfs hangs and can't get killed anyway. Even a sudo umount -f /mnt/nfs stoped working and reported the same error-message. I would say it's a Bug in the NFS-Implementation because it should handle such things. My fstab-entry is: server:/nfs on /mnt/nfs type nfs (nodev, nosuid, v3, tcp, soft, intr, timeo=100) So there IS a timeout specified but it wont help. The only solution is to reboot the workstation. So is this a Problem related to NFS or did I missed anything??? It seams just during a reboot the timeout is noticed so after ~some seconds the machine will reboot. I've the same issues with an 3.8 Client so it shouldn't be current-related. Kind regards, Sebastian I have a really _hack_ solution, just mount it again, it won't hurt (at least it didn't hurt me so far): /dev/wd1a on / type ffs (local, noatime, softdep) /dev/wd1d on /tmp type ffs (local, noatime, nodev, nosuid, softdep) /dev/wd1g on /usr type ffs (local, noatime, nodev, softdep) /dev/wd1e on /var type ffs (local, noatime, nodev, nosuid, softdep) /dev/wd1h on /home type ffs (local, noatime, nodev, nosuid, softdep) 10.xxx.xxx.xx:/NETDISK on /mnt/NETDISK type nfs (v3, tcp, soft, intr, timeo=100) 10.xxx.xxx.xx:/NETDISK on /mnt/NETDISK type nfs (v3, tcp, soft, intr, timeo=100) 10.xxx.xxx.xx:/NETDISK on /mnt/NETDISK type nfs (v3, tcp, soft, intr, timeo=100) 10.xxx.xxx.xx:/NETDISK on /mnt/NETDISK type nfs (v3, tcp, soft, intr, timeo=100) 10.xxx.xxx.xx:/NETDISK on /mnt/NETDISK type nfs (v3, tcp, soft, intr, timeo=100) 10.xxx.xxx.xx:/NETDISK on /mnt/NETDISK type nfs (v3, tcp, soft, intr, timeo=100) 10.xxx.xxx.xx:/NETDISK on /mnt/NETDISK type nfs (v3, tcp, soft, intr, timeo=100) ... many more ... ... well it is _terrible_ to do that, but it works. I got this behavior/problem since 3.6, thus I don't have a clue if it is the way NFS is supposed to work, which would suck. Or if it is a bug in the implementation, which would suck as well, but could be fixed. I always thought that it is because I have my NFS secured through a VPN, but it seems it isn't a bug of that combination, but rather general. jm2c Regards, ahb
Re: APIC
Does OpenBSD 3.8 use the APIC (Advanced Programmable Interrupt Controller) ? yes, but only with the bsd.mp kernel.
Re: multi-port NIC cards
--- martin [EMAIL PROTECTED] wrote: Hi. I just ordered both the Mikrotik Routerboard 44 ($89) and the Soekris lan1641 ($95). Both 4-port NIC boards. I'll let you know how the perform. I'm also puzzled by the claims of performance issues and saturating the bus PCI bus previously mentioned as the original PCI (33MHz) has approx. 1 Gbit performance and these cards have 4x100 Mbit chips and therfore will only use 400 Mbits maximum of the 1 Gbit bus. Is someone confusing bits and bytes ? Regards...Martin
Re: Postfix, fatal: Cross-device link
On Tue, Jan 03, 2006 at 04:59:18PM +0100, Joachim Schipper wrote: Yes. What you want to do is not theoretically impossible, but it is highly impractical. Postfix manages its spool by moving files about; move is quick within a filesystem, but no faster than copy across filesystems. (And postfix has apparently chosen not to support this at all.) So this is, indeed, not a good idea. If both disks are of similar speed, you might want to run a RAID. I set it up this way because normally deferred is not used, so I put that on a spare disk I had. As wd0 is always spun up, I thought I could get away with putting the smaller active spools on the main disk. I'll move /var/spool/postfix in its entirety to the spare disk. Cheers, Craig.
Re: APIC
On 1/3/06, martin [EMAIL PROTECTED] wrote: Besides doing a dmesg | grep irq, is there another way at seeing the assigned interrupts. # vmstat -i -- ach
Re: NFS-Question (nfs-server timeouts..?)
On Tue, 3 Jan 2006, Sebastian Rother wrote: Hi everybody, I've a question related to NFS. I#ve 2 PCs at home. One is a Server (NFS) running 3.8 and the other is my workstation running current. Server provides a NFS-Share. Let's call it /nfs Workstation mounts the NFS-Share into /mnt/nfs If the Workstation calculates something and I power off the Server to save some energy and power on this system later the workstation will NOT be able to read/write anything to the NFS-Share. It will simply report: nfs server server:/nfs: not responding The workstation will not hang but the shell where I did e.g. ls /mnt/nfs hangs and can't get killed anyway. Even a sudo umount -f /mnt/nfs stoped working and reported the same error-message. I would say it's a Bug in the NFS-Implementation because it should handle such things. My fstab-entry is: server:/nfs on /mnt/nfs type nfs (nodev, nosuid, v3, tcp, soft, intr, timeo=100) So there IS a timeout specified but it wont help. The only solution is to reboot the workstation. So is this a Problem related to NFS or did I missed anything??? It seams just during a reboot the timeout is noticed so after ~some seconds the machine will reboot. I've the same issues with an 3.8 Client so it shouldn't be current-related. A workaround is probably not to use tcp. I use udp here (with standard options), and my clients recover nicely after a server powerdown/powerup. -Otto
Re: APIC
martin [EMAIL PROTECTED] wrote: Besides doing a dmesg | grep irq, is there another way at seeing the assigned interrupts. e.g. For Linux cat /proc/interrupts reveals:- vmstat(8) vmstat -zi
Re: NFS-Question (nfs-server timeouts..?)
On Tue, 3 Jan 2006 17:27:27 +0100 (CET) Otto Moerbeek [EMAIL PROTECTED] wrote: On Tue, 3 Jan 2006, Sebastian Rother wrote: Hi everybody, I've a question related to NFS. I#ve 2 PCs at home. One is a Server (NFS) running 3.8 and the other is my workstation running current. Server provides a NFS-Share. Let's call it /nfs Workstation mounts the NFS-Share into /mnt/nfs If the Workstation calculates something and I power off the Server to save some energy and power on this system later the workstation will NOT be able to read/write anything to the NFS-Share. It will simply report: nfs server server:/nfs: not responding The workstation will not hang but the shell where I did e.g. ls /mnt/nfs hangs and can't get killed anyway. Even a sudo umount -f /mnt/nfs stoped working and reported the same error-message. I would say it's a Bug in the NFS-Implementation because it should handle such things. My fstab-entry is: server:/nfs on /mnt/nfs type nfs (nodev, nosuid, v3, tcp, soft, intr, timeo=100) So there IS a timeout specified but it wont help. The only solution is to reboot the workstation. So is this a Problem related to NFS or did I missed anything??? It seams just during a reboot the timeout is noticed so after ~some seconds the machine will reboot. I've the same issues with an 3.8 Client so it shouldn't be current-related. A workaround is probably not to use tcp. I use udp here (with standard options), and my clients recover nicely after a server powerdown/powerup. -Otto That maybe true (I need to test it) but it's a Bug in the NFS-Implementation (again..) anyway. :-/ I'll test it soon. Thanks for the advice! Kind regards, Sebastian
Re: tar(1) File is too long for ustar
On Mon, Jan 02, 2006 at 11:31:13PM +0100, Otto Moerbeek wrote: OK, then the cpio man page in -current is in error. That's my mistake, I asked jmc@ to change it to 64GB where it is actually 8GB, cpio doesn't add a space or null termination on the 12th digit so it should be ok, only tar and ustar were off. When I looked at it I must have looked at tar_rd() and saw it use asc_ul() which doesn't care much for the terminator and didn't look at tar_wr() which uses uqd_oct() that adds the terminator thus shortening the amount of digits for the octal value. Here is the updated patch: Index: cpio.1 === RCS file: /cvs/src/bin/pax/cpio.1,v retrieving revision 1.22 diff -u -r1.22 cpio.1 --- cpio.1 15 Nov 2005 00:00:28 - 1.22 +++ cpio.1 3 Jan 2006 16:54:12 - @@ -292,8 +292,8 @@ .It bcpio Ta 4 Gigabytes .It sv4cpio Ta 4 Gigabytes .It cpio Ta 8 Gigabytes -.It tar Ta 64 Gigabytes -.It ustar Ta 64 Gigabytes +.It tar Ta 8 Gigabytes +.It ustar Ta 8 Gigabytes .El .Sh BUGS The CUT HERE --- BTW, to solve the OP problem: try using dump(8) instead of tar(1). -Otto Sorry for the misinformation which was caused by me. -peter
Re: tar(1) File is too long for ustar
On Tue, Jan 03, 2006 at 06:03:16PM +0100, Peter Philipp wrote: Index: cpio.1 === RCS file: /cvs/src/bin/pax/cpio.1,v retrieving revision 1.22 diff -u -r1.22 cpio.1 --- cpio.1 15 Nov 2005 00:00:28 - 1.22 +++ cpio.1 3 Jan 2006 16:54:12 - @@ -292,8 +292,8 @@ .It bcpio Ta 4 Gigabytes .It sv4cpio Ta 4 Gigabytes .It cpio Ta 8 Gigabytes -.It tar Ta 64 Gigabytes -.It ustar Ta 64 Gigabytes +.It tar Ta 8 Gigabytes +.It ustar Ta 8 Gigabytes .El .Sh BUGS The ok, fixed now. jmc
Re: Gallery on OpenBSD 3.8: resolv.conf needed for email registration through remote smtp
Chris Zakelj wrote:
Justin H Haynes wrote:
Thanks Nick Holmes and misc for
http://www.openbsdsupport.org/GalleryInChroot.html. It was very
helpful in getting Gallery working in OpenBSD in the chrooted Apache
environment for me. However, I need to use an external smtp server to
handle registration emails. I was getting this error message in my
logs when I tried to use the registration feature:
[Mon Jan 2 10:23:57 2006] [error] PHP Warning: fsockopen():
php_network_getaddresses: gethostbyname failed in
/htdocs/gallery/classes/Mail/smtp.php on line 87
[Mon Jan 2 10:23:57 2006] [error] PHP Warning: fsockopen(): unable
to connect to smtp-server.houston.rr.com:25 in
/htdocs/gallery/classes/Mail/smtp.php on line 87
So I just copied resolv.conf to /var/www/etc/resolv.conf and it now
works just fine.
So, Nick, if you feel like modifying your script:
patch gallery-openbsd-chroot-install.sh EOF
103a104
mkdir -p /var/www/etc
114a116,118
echo 'Copying resolv.conf...'
cd /var/www/etc
cp /etc/resolv.conf .
EOF
Thanks again,
Justin H Haynes
Not sure that just copying /etc/resolv.conf wholesale without sanity
checking is such a good idea... folks on dynamic IP's (PPPoE and cable,
for instance) may have ISPs who assign DNS service based on which IP
address the client gets. A better idea may be to append a couple of the
OpenNIC (or other 3rd party DNS service) Tier 2 DNS servers to
/var/www/etc/resolv.conf or /v/w/e/r.c.tail.
Good Idea. Actually, since everyone may not even need this little hack,
I've just changed it to create in /var/www/etc/:
resolv.conf.local
resolv.conf.OpenNIC
Then users can copy one if they need it. here is a diff to the original
script.
Also, ./secure.sh is on its own line in the original script. I've left
this alone here, as it doesn't hurt anything, and it's probably a good
idea anyway.
patch gallery-openbsd-chroot-install.sh EOF
64c64,72
#16After it's all working, cd to /var/www/htdocs/gallery and run
---
#16For Email functionality, you may need a resolv.conf in the
# chrooted environment if you are using a remote smtp server.
# This script will have placed two files in /var/www/etc:
# resolv.conf.local (from /etc), and resolv.conf.OpenNIC (from
# OpenNIC. If you need one, then just
# cd /var/www/etc
# cp one of those resolv.conf
# (1/3/2006: Justin at Haynes dot net)
#17After it's all working, cd to /var/www/htdocs/gallery and run
103a112
mkdir -p /var/www/etc
104a114,118
# Get nameservers from OpenNIC.
#
echo Getting nameservers from OpenNIC
cd /var/www/etc/
lynx -dump http://www.opennic.unrated.net/cgi-bin/get_tier2_txt.sh | grep -v ^$ | awk
'{print nameserver $2}' resolv.conf.OpenNIC
114a129,131
echo 'Copying resolv.conf...'
cd /var/www/etc
cp /etc/resolv.conf resolv.conf.local
EOF
Re: Gallery on OpenBSD 3.8: resolv.conf needed for email registration through remote smtp
On Tue, Jan 03, 2006 at 10:34:48AM -0600, Justin H Haynes wrote:
Chris Zakelj wrote:
Good Idea. Actually, since everyone may not even need this little hack,
I've just changed it to create in /var/www/etc/:
resolv.conf.local
resolv.conf.OpenNIC
Then users can copy one if they need it. here is a diff to the original
script.
patch gallery-openbsd-chroot-install.sh EOF
64c64,72
#16After it's all working, cd to /var/www/htdocs/gallery and run
---
#16For Email functionality, you may need a resolv.conf in the
# chrooted environment if you are using a remote smtp server.
# This script will have placed two files in /var/www/etc:
# resolv.conf.local (from /etc), and resolv.conf.OpenNIC (from
# OpenNIC. If you need one, then just
# cd /var/www/etc
# cp one of those resolv.conf
# (1/3/2006: Justin at Haynes dot net)
#17After it's all working, cd to /var/www/htdocs/gallery and run
103a112
mkdir -p /var/www/etc
104a114,118
# Get nameservers from OpenNIC.
#
echo Getting nameservers from OpenNIC
cd /var/www/etc/
lynx -dump http://www.opennic.unrated.net/cgi-bin/get_tier2_txt.sh | grep
-v ^$ | awk '{print nameserver $2}' resolv.conf.OpenNIC
114a129,131
echo 'Copying resolv.conf...'
cd /var/www/etc
cp /etc/resolv.conf resolv.conf.local
EOF
I'm afraid this'll result in lots of questions on [EMAIL PROTECTED] I, for one,
would be stumped as to why I'd want OpenNIC.
It might be worthwhile noting that if your nameservers change a lot, it
might be a good idea to put OpenNIC servers in chroot'ed resolv.conf
files, as those will always be accessible and functional.
(Alternatively, copy /etc/resolv.conf after each change - isn't there a
dhclient hook for such a thing?)
Joachim
Re: DadOS - sys shutdown with XDM
On Tue, Jan 03, 2006 at 12:45:46PM -0500, Michael Erdely wrote: On 1/3/06, Joachim Schipper [EMAIL PROTECTED] wrote: Since /etc/X11/xdm/TakeConsole runs with root permission on every user logout to prevent /dev/console sniffing I modified it to perform the shutdown if the flag file is found in the users home directory. This approach works perfectly but my questions are: Is there anything wrong with this approach? Is there's a better way to deal with the problem? This is a hack. It will work, untill you upgrade X11 without being very careful. Why not just configure sudo to allow access to /sbin/halt without a password from user dad? Of course, you then alter the KDE menu to do it your way. And/or place a two-line shell script in ~dad/bin/halt: Add dad to the operator group which can run /sbin/shutdown without sudo. That's not a very good idea. $ ls -la /dev/wd* brw-r- 1 root operator0, 0 Nov 2 18:20 /dev/wd0a brw-r- 1 root operator0, 1 Nov 2 18:20 /dev/wd0b brw-r- 1 root operator0, 2 Nov 2 18:20 /dev/wd0c more brw-r- 1 root operator0, 15 Nov 2 18:20 /dev/wd0p brw-r- 1 root operator0, 16 Nov 2 18:19 /dev/wd1a and so on And operator has more priviliges; more than enough to trash the system, if he wants to, or to get root, if he is somewhat skilled. Far better to just change a single line in /etc/sudoers. Joachim
OpenBGPd filters
Hi and happy new year to all,
I try to apply a nexthop blackhole filter without success on OpenBSD 3.8.
I receive the bogon list from cymru and try to force blackholing of the
routes without success. Here is my configuration :
group BGPBogon {
remote-as 65333
announcenone
multihop255
set localpref 999
neighbor x.x.x.x {
descr BGP-Bogon
local-address y.y.y.y
}
}
Later I apply the filter :
match from group BGPBogon community 65333:888 set nexthop blackhole
I tried several combinations with the reject keyword and without community
filter also, but routes are installed in the fib with a valid nexthop anyway
and the server sends the packets for those routes. I even tried to force the
nexthop at the group level without success ... !
If someone can explain me what I'm missing - any help welcome ;-)
--
Sylvain COUTANT
ADVISEO
http://www.adviseo.fr/
http://www.open-sp.fr/
Re: DadOS - sys shutdown with XDM
On Tue, Jan 03, 2006 at 07:04:36PM +0100, Joachim Schipper wrote: On Tue, Jan 03, 2006 at 12:45:46PM -0500, Michael Erdely wrote: Add dad to the operator group which can run /sbin/shutdown without sudo. That's not a very good idea. $ ls -la /dev/wd* brw-r- 1 root operator0, 0 Nov 2 18:20 /dev/wd0a brw-r- 1 root operator0, 1 Nov 2 18:20 /dev/wd0b brw-r- 1 root operator0, 2 Nov 2 18:20 /dev/wd0c more brw-r- 1 root operator0, 15 Nov 2 18:20 /dev/wd0p brw-r- 1 root operator0, 16 Nov 2 18:19 /dev/wd1a and so on And operator has more priviliges; more than enough to trash the system, if he wants to, or to get root, if he is somewhat skilled. Far better to just change a single line in /etc/sudoers. while i don't disagree with your advice, could you still advice me on messing things up with operator privileges, as i'm curious... because i can't see how being able to read disks will give out enough information to do either Juha
vnconfig strange behaviour (or my mistake?)
Hi all, sorry for bothering. My problem is as follows: 0. 3.8 GENERIC 1. I am creating 1.5Gb all-zeroes file with dd 2. vnconfig -ck /dev/svnd0c file.img 3. fdisk -e /dev/rsvnd0c 4. dislabel -E /dev/rsvnd0c 5. newfs /dev/rsvnd0c 6. mount /dev/svnd0c /mnt 7. copying in files into /mnt And after this the file.img becomes like 800Gb on the filesystem. df shows that /mnt size is 1.5 as expected. Is it a sign of a bad disk (I have tried this on several different partitions, with two different machines - still the same), or I am overlooking something way to obviuous. Would be grateful for any of your comments, suggestions. Vladas
Re: vnconfig strange behaviour (or my mistake?)
On Wed, 4 Jan 2006, Vladas Urbonas wrote: Hi all, sorry for bothering. My problem is as follows: 0. 3.8 GENERIC 1. I am creating 1.5Gb all-zeroes file with dd 2. vnconfig -ck /dev/svnd0c file.img 3. fdisk -e /dev/rsvnd0c use fdisk -i svnd0, much easier. 4. dislabel -E /dev/rsvnd0c disklabel -E svnd0, delete extisting 'a' partition and recreate with default values. 5. newfs /dev/rsvnd0c Use /dev/rsvnd0a 6. mount /dev/svnd0c /mnt 7. copying in files into /mnt And after this the file.img becomes like 800Gb on the filesystem. df shows that /mnt size is 1.5 as expected. Is it a sign of a bad disk (I have tried this on several different partitions, with two different machines - still the same), or I am overlooking something way to obviuous. Would be grateful for any of your comments, suggestions. Vladas
upgrading packages with pkg_add -u and pkg_add -r
I really appreciate this work. Until it is complete, here are a few quick and dirty things I do to make the upgrade process a little easier. Probably common sense to many, but I'll share it all the same: https://justinhaynes.com/weblog/package-updates-in-openbsd-38/ -Justin
OT: software testing envinronment
Hello folks, sorry for being OT, but i have written some code and would like to test it on 64 bit little/big endian box and have none to try. Would it be the case some here kind enough to provide me with shell access? I am seeking not only OBSD environments. Thanks a lot for your time and cooperation. Best regards.
Re: Blowfish still good enough?
On 12/31/05, Travers Buda [EMAIL PROTECTED] wrote: The Nazis thought their Enigma machine was perfect. Do you know why Enigma was broken? Primarily because the operators didn't follow procedure and made a series of other mistakes (This doesn't seem too important). As is typical, the problem was not with the crypto, it was with the idiots using it.
Re: DadOS - sys shutdown with XDM
The first thing I did was add a flag file to my dad's home directory and made sure he cant modify or delete it. # touch /home/dad/.xshutdown # chown root:wheel /home/dad/.xshutdown # chmod 400 /home/dad/.xshutdown login: dad password: dadsbox $ ls -l .xshutdown -r1 root wheel 0 Jan 3 11:11 .xshutdown dadsbox $ mv .xshutdown /tmp dadsbox $ echo :-) :-) Assuming, of course, that /tmp and /home are one partition. --patrick
Re: Time on amd64
are you running ntpd? are you running ntpd with the kernel adjtime patch i posted to tech a few days ago? On 1/1/06, Cyrus Lopez [EMAIL PROTECTED] wrote: I have a machine with a sempron64 and it seems that time is a tad bit too fast. Every minute it skips ahead about 15-20 seconds. After about 10 minutes it's several minutes ahead of the real time. For now I've set a cron job to rdate time.nist.gov every 5 minutes. This is on OpenBSD 3.8 with the generic kernel and no other special modifications. Is there anything I can possibly do to fix this little glitch (perhaps something via sysctl?) or is it a problem in the code somewhere? Any help would be greatly appreciated, thanks. - Cyrus
Re: Blowfish still good enough?
Ted Unangst wrote: On 12/31/05, Travers Buda [EMAIL PROTECTED] wrote: The Nazis thought their Enigma machine was perfect. Do you know why Enigma was broken? Primarily because the operators didn't follow procedure and made a series of other mistakes (This doesn't seem too important). As is typical, the problem was not with the crypto, it was with the idiots using it. I guess any encryption algorithm is limited by entropy. Given that most users choose bad passwords, the algorithm doesn't matter that much. What is the point of trillions of possible keys when people choose from only a few hundred thousand? I'd just say no to any passwords.
Re: spamd and spews1
Spews seems to be having some issues. www.spews.org refuses connections from here. The spews list will be updated once their site is again reachable from www.openbsd.org -Bob * Bryan Irvine [EMAIL PROTECTED] [2005-12-30 10:49]: Recently the spews1 file that gets downloaded from openbsd.org started having a zero size. Is the spews list no longer being updated? --Bryan -- | | | The ASCII Fork Campaign \|/ against gratuitous use of threads. |
Re: Time on amd64
On Tuesday 03 January 2006 15:16, Ted Unangst wrote: are you running ntpd? are you running ntpd with the kernel adjtime patch i posted to tech a few days ago? On 1/1/06, Cyrus Lopez [EMAIL PROTECTED] wrote: I have a machine with a sempron64 and it seems that time is a tad bit too fast. Every minute it skips ahead about 15-20 seconds. After about 10 minutes it's several minutes ahead of the real time. For now I've set a cron job to rdate time.nist.gov every 5 minutes. This is on OpenBSD 3.8 with the generic kernel and no other special modifications. Is there anything I can possibly do to fix this little glitch (perhaps something via sysctl?) or is it a problem in the code somewhere? Any help would be greatly appreciated, thanks. - Cyrus I missed your original post. What is the make/model of the computer. There is a known issue on some machines with the clock running fast with AMD/ATI on Linux. It *might* be the same with OpenBSD. Gateway MX7515m AMD/ATI bug - clock runs at double speed http://bugzilla.kernel.org/show_bug.cgi?id=3927 I used - noapictimer at boot on my Linux notebook to fix the issue. Not sure that's going to help. But if it is a hardware issue, that may be enough of a start for a developer to help. Provide your hardware info. Regards...Martin
Re: APIC
On Tuesday, January 3, martin wrote: Does OpenBSD 3.8 use the APIC (Advanced Programmable Interrupt Controller) ? In bsd.mp, yes. Some cards, e,g telephony and framegrabbers have issues with the limited standard XT 16 IRQ's. How so? APIC motherboards give you 24 or more (I've seen as many as 101) interrupts. Sure, let's see... You'd need 24 / 4 (A, B, C, and D) = 6 PCI slots. I suppose that's doable on a MB. Why you'd need 101 interrupt pins is beyond me... Besides doing a dmesg | grep irq, is there another way at seeing the assigned interrupts. e.g. For Linux cat /proc/interrupts reveals:- Dell PowerEdge 2850 (dual Xeon) cat /proc/interrupts CPU0 CPU1 0:6184515 72IO-APIC-edge timer 1: 8 1IO-APIC-edge i8042 9: 0 0 IO-APIC-level acpi 12: 65 1IO-APIC-edge i8042 14: 11 2IO-APIC-edge ide0 46: 19595 1 IO-APIC-level megaraid 64: 66366 1 IO-APIC-level eth0 65: 77045 1 IO-APIC-level eth1 101: 6113521 1 IO-APIC-level wctdm NMI: 1 0 LOC: 6184694 6184698 ERR: 0 MIS: 0 Ok, you've got 4 level, and 4 edge triggered interrupts. In order to manage these, you need at least 5 pins (ok, 2 would do, but I'll say that each edge should have it's own), and at most 8. Your APIC is not going to help in the department much over the older style PIC. It does tend to be faster though... --Toby.
Re: DadOS - sys shutdown with XDM
On Tue, Jan 03, 2006 at 08:24:44PM +0200, Juha Erkkila wrote: On Tue, Jan 03, 2006 at 07:04:36PM +0100, Joachim Schipper wrote: On Tue, Jan 03, 2006 at 12:45:46PM -0500, Michael Erdely wrote: Add dad to the operator group which can run /sbin/shutdown without sudo. That's not a very good idea. $ ls -la /dev/wd* brw-r- 1 root operator0, 0 Nov 2 18:20 /dev/wd0a brw-r- 1 root operator0, 1 Nov 2 18:20 /dev/wd0b brw-r- 1 root operator0, 2 Nov 2 18:20 /dev/wd0c more brw-r- 1 root operator0, 15 Nov 2 18:20 /dev/wd0p brw-r- 1 root operator0, 16 Nov 2 18:19 /dev/wd1a and so on And operator has more priviliges; more than enough to trash the system, if he wants to, or to get root, if he is somewhat skilled. Far better to just change a single line in /etc/sudoers. while i don't disagree with your advice, could you still advice me on messing things up with operator privileges, as i'm curious... because i can't see how being able to read disks will give out enough information to do either Hmm, I must admit that the group operator has less priviliges than I'd have expected. Sorry, I really should check my suspicions. The most absolute is a nasty DoS called /sbin/halt, but since that was the intention we'll let that slip. There are also less obvious ways to DoS a machine, but since we can already shut it down there's no reason to annoy people a little - after all, you can annoy them a lot. And I don't see any obvious way to get the operator group to help with that. The second most nasty attack is getting /etc/master.passwd and running a cracking tool on it - this will yield any weak passwords easily. This is rather obvious, but if using weak passwords can be very dangerous. /etc/master.passwd uses rather strong encryption, but other password files are typically easier to crack. This would be rather annoying on a shared machine, but since this is a single-user system there's usually little extra access to be gained. If the system uses backup tapes, the user operator can overwrite them. This can be quite disastrous, but I'm fairly certain this isn't much of a problem in this case. And that's about it. The group operator can read all files on the system, which would be rather nasty in a multi-user setup where the documents are confidential or at least private, but since that's not the case I don't see too much of a problem. Sorry! Joachim
stupid sata raid question
Is there a good/cheap SATA RAID card that doesn't use that retarded soft RAID? In other words, will this card present itself to OBSD at install as a single disk? http://www.lsilogic.com/products/megaraid/sata_150_4.html --Bryan
Re: stupid sata raid question
On Tue, 3 Jan 2006, Bryan Irvine wrote: Is there a good/cheap SATA RAID card that doesn't use that retarded soft RAID? In other words, will this card present itself to OBSD at install as a single disk? http://www.lsilogic.com/products/megaraid/sata_150_4.html yes, -Otto
Re: Two internet connections, carp and tun
Hello, You should consider getting more public IP addresses as you need three public addresses on each external connection, ideally. I can't. But I can put the two external interfaces on the same physical lan and add ip alias addresses. I can also plug other interfaces on the external lans since I have 5 physical interfaces on each box. ++ ++ | c1 |__|Internet| ++ ++ | | +--+ | carp if | +--+ | | +-++-+ | ob1 || ob2 | +-++-+ | | +--+ | carp if | +--+ |__| | +---+ | smtp1 | +---+ You could look at the pf I posted a couple of days ago, there is one slight problem with it and sending existing states, but everything else appears ok. I thank you very much for the link. The problem now is that ob1 and ob2 have two different internet access: - ob1 runs pppoe and gets its internet address via a tun0 interface on a physical sis0 interface. - ob2 is behind an adsl box doing the internet access and has an intRAnet address (on sis0), but everything arriving on the real public address is forwarded to ob2 so we can consider its intranet address 192.168.3.1 is equivalent to the internet address. So now the question is how can I tell ob2 and ob1 to have a working carp address on the ob1 tun0 ? May be I can't. Thanks in advance. -- Au revoir,02 99 64 31 77 06 20 79 76 06 Gilles Lamiral. France, Chavagne (35310) 08 72 27 33 66
Re: DadOS - sys shutdown with XDM
Hello! On Tue, Jan 03, 2006 at 11:15:46AM -0800, patrick ~ wrote: The first thing I did was add a flag file to my dad's home directory and made sure he cant modify or delete it. # touch /home/dad/.xshutdown # chown root:wheel /home/dad/.xshutdown # chmod 400 /home/dad/.xshutdown login: dad password: dadsbox $ ls -l .xshutdown -r1 root wheel 0 Jan 3 11:11 .xshutdown dadsbox $ mv .xshutdown /tmp dadsbox $ echo :-) :-) Assuming, of course, that /tmp and /home are one partition. If not, mv .xshutdown .xnoshutdown is enough too. But then, chflags schg .xshutdown may be enough. --patrick Kind regards, Hannah.
Re: CGD
On 1/3/06, Ted Unangst [EMAIL PROTECTED] wrote: On 1/2/06, Travers Buda [EMAIL PROTECTED] wrote: You've made it very clear that CGD won't be imported into OpenBSD, yet you've never explained why, or why you ported it in the first place. Care to let us in on why? I expect your reply will be a short no just like a few of your replys to this subject. For what it is worth, I'm asking. Because, like everyone else, you've failed to pass the articulation test. http://marc.theaimsgroup.com/?l=openbsd-miscm=112534721521131w=2 OK, I'll try, because I'd be interested in using it on OpenBSD. Since I won't be able to do it myself, any or no answer will qualify ;) cgd gives users some choice over how to build their encrypted partition. you're able to use different ciphers. you're able to use passphrases or keyfiles (with some tricks one could also do this in OpenBSD, but it'd be a hack and far easier to screw up) you're able to change your passphrase without reencrypting your container. in the unlikely case of a cipher getting broken, you have the possibility to switch instantly, using a tool you know with stable code an the same way you configured it. this is the way it appears. if there are any reasons, why cgd shouldn't be used at all I'd be more than interested to hear them. if there are any reasons not to port this to OpenBSD, nobody will die not knowing them. --knitti
VPN packets not passing remote gateway
I'm testing a new VPN tunnel using ipsecadm and manual keying. Everything looks ok, but packets aren't making it to enc0 and beyond on the remote side (either way). I can watch the packet count increment on the relevant pass rules (see below), so I know it's making it all the way up to remote enc0. Examples below taken while pinging from 10.100.0.113 to 10.50.0.99. 10.100.0/24 - 206.xxx.174.124 - internet - 66.xxx.215.162 - 10.50.0/24 Info from the West side... # ipsecadm show sadb_dump: satype esp vers 2 len 26 seq 0 pid 0 sa: spi 0x100a auth hmac-sha1 enc 3des-cbc state mature replay 0 flags 0 lifetime_cur: alloc 0 bytes 146244 add 1136311234 first 1136311235 x_lifetime_lastuse: alloc 0 bytes 0 add 0 first 1136325471 address_src: 206.xxx.174.124 address_dst: 66.xxx.215.162 key_auth: bits 160: 1234123412341234123412341234123412341234 key_encrypt: bits 192: 638063806380638063806380638063806380638063806380 # netstat -rn -fencap Routing tables Encap: Source Port DestinationPort Proto SA(Address/ Proto/Type/Direction) 10.50.0/24 0 10.100.0/24 0 0 66.xxx. 215.162/50/require/in 10.100.0/24 0 10.50.0/24 0 0 66.xxx. 215.162/50/require/out # pfctl -vsr | grep -A1 enc pass quick on enc0 all keep state [ Evaluations: 85790 Packets: 1538 Bytes: 129192 States: 1 ] # pfctl -vsr | grep -A1 esp pass in on vlan0 inet proto esp from 66.xxx.215.162 to 206.xxx. 174.124 keep state [ Evaluations: 6660 Packets: 0 Bytes: 0 States: 0 ] pass out on vlan0 inet proto esp from 206.xxx.174.124 to 66.xxx. 215.162 keep state [ Evaluations: 28519 Packets: 1611 Bytes: 219096 States: 1 ] And from the East side... # ipsecadm show sadb_dump: satype esp vers 2 len 26 seq 0 pid 0 sa: spi 0x100a auth hmac-sha1 enc 3des-cbc state mature replay 0 flags 0 lifetime_cur: alloc 0 bytes 12096 add 1136311232 first 1136311447 x_lifetime_lastuse: alloc 0 bytes 0 add 0 first 1136317131 address_src: 66.xxx.215.162 address_dst: 206.xxx.174.124 key_auth: bits 160: 1234123412341234123412341234123412341234 key_encrypt: bits 192: 638063806380638063806380638063806380638063806380 # netstat -rn -fencap Routing tables Encap: Source Port DestinationPort Proto SA(Address/ Proto/Type/Direction) 10.100.0/24 0 10.50.0/24 0 0 206.xxx. 174.124/50/require/in 10.50.0/24 0 10.100.0/24 0 0 206.xxx. 174.124/50/require/out # pfctl -vsr | grep -A1 enc pass quick on enc0 all [ Evaluations: 141193Packets: 144 Bytes: 12096 States: 0 ] # pfctl -vsr | grep -A1 esp pass in on em0 inet proto esp from 206.xxx.174.124 to 66.xxx.215.162 keep state [ Evaluations: 287 Packets: 2035 Bytes: 276760 States: 1 ] pass out on em0 inet proto esp from 66.xxx.215.162 to 206.xxx.174.124 keep state [ Evaluations: 2494 Packets: 181 Bytes: 24616 States: 0 ] Thanks, -- Jason Dixon DixonGroup Consulting http://www.dixongroup.net
Re: DadOS - sys shutdown with XDM
On Tue, 3 Jan 2006 20:24:44 +0200, Juha Erkkila [EMAIL PROTECTED] wrote: On Tue, Jan 03, 2006 at 07:04:36PM +0100, Joachim Schipper wrote: On Tue, Jan 03, 2006 at 12:45:46PM -0500, Michael Erdely wrote: Add dad to the operator group which can run /sbin/shutdown without sudo. That's not a very good idea. $ ls -la /dev/wd* brw-r- 1 root operator0, 0 Nov 2 18:20 /dev/wd0a brw-r- 1 root operator0, 1 Nov 2 18:20 /dev/wd0b brw-r- 1 root operator0, 2 Nov 2 18:20 /dev/wd0c more brw-r- 1 root operator0, 15 Nov 2 18:20 /dev/wd0p brw-r- 1 root operator0, 16 Nov 2 18:19 /dev/wd1a and so on And operator has more priviliges; more than enough to trash the system, if he wants to, or to get root, if he is somewhat skilled. Far better to just change a single line in /etc/sudoers. while i don't disagree with your advice, could you still advice me on messing things up with operator privileges, as i'm curious... because i can't see how being able to read disks will give out enough information to do either Juha The ability to read any file on the system is a *clear* violation of the Principle of Least Privilege. Let's say, for the sake of argument, that the user account is some how compromised; Do you really want the attacker to be able to read every file on the system? -Obviously, letting a user account read everything makes it easier for the attacker to escalate their privileges. The rule of thumb for granting privileges is simple; avoid granting permissions whenever possible. jcr
Re: DadOS - sys shutdown with XDM
On Tuesday 03 January 2006 17:11, J.C. Roberts wrote: The rule of thumb for granting privileges is simple; avoid granting permissions whenever possible. Check the ownership/privileges on /tmp/.X11-unix/X0 after you start kde or Xorg. Also check the ownership/privileges on the /dev/[pt]typ* pair allocated to any konsole session running under kde on openbsd. -- Lose, v., experience a loss, get rid of, lose the weight Loose, adj., not tight, let go, free, loose clothing
learning to code - suggestions needed
Hello list members. I'd like to direct this post to those that develop code for OpenBSD. I'd like a start developing software, and in turn, contribute to projects like OpenBSD and others. Right now, I'm working as a sysadmin/infosec person. I can write some simple perl and shell scripts, but that's about it. Do you have any recommendations on how I should get started? * Community college courses? * College courses? * Self-study books? I am aware that it will take a number of years before I can contribute quality code. I'm asking the OpenBSD folks for recommendations because I think the project goals are conducive to writing good software. I also think the quality of code in this project is superior to the alternatives. Any help or recommendations would be appreciated. -joe
Re: CGD
Ted Unangst wrote: On 1/2/06, Travers Buda [EMAIL PROTECTED] wrote: You've made it very clear that CGD won't be imported into OpenBSD, yet you've never explained why, or why you ported it in the first place. Care to let us in on why? I expect your reply will be a short no just like a few of your replys to this subject. For what it is worth, I'm asking. Because, like everyone else, you've failed to pass the articulation test. http://marc.theaimsgroup.com/?l=openbsd-miscm=112534721521131w=2 on a related subject: what's keeping that diff you did to add salting to vnconfig from hitting the tree? (or something like it) /kami
Re: Blowfish still good enough?
Ted Unangst wrote: On 12/31/05, Travers Buda [EMAIL PROTECTED] wrote: The Nazis thought their Enigma machine was perfect. Do you know why Enigma was broken? Primarily because the operators didn't follow procedure and made a series of other mistakes (This doesn't seem too important). As is typical, the problem was not with the crypto, it was with the idiots using it. Related to the Enigma: They had to Write Heil Hitler or HH at the End of every message. So it's a neat example for a known plaintext attack. :-)) related to svnds: Yes OpenBSD uses Blowfish and yes it si secure and YES it could be blf with 448Bit. But OpenBSD uses (as far as I know) just 128Bit. Blowfish is secure but Twofish is faster and as secure as Blowfish. At least if there some quant. computers 128Bit will not save ya day anymore. The question is not Is blowfish still secure enought. It is more: Why can't the user choose how strong the data will get encrypted? An ideal algorithm for user-accounts would be secure and slow as hell. But then such an algorithm would just be usefull to protect the user-passwords Blowfish is a good compromise but Twofish would be indeed also neat too because it's faster (importent for data-encryption) in software then AES (Rijandel). And if I'm allowed to wish me something for next x-mas: A better solution to encrypt whole disks would be nice. Maybe also using the AES-Engine from the VIA CPUs for this job. Or just a way to encrypt the disks where I could choose some parameters of the algorithm (Bits, Rounds..)... FreeBSD has a nice way (geom) to encrypt whole disks (just from the point of the usebility). Kind regards, Sebastian p.s. Bruce Schneier wouldn't develop an algorithm if he would still think that Blowfish (an algorithm from 1993 and puplished 1994) would still be the best choice for the next 10-30 years.
Re: learning to code - suggestions needed
I asked a similar question on here recently and had some good books recommended to me. This relates to C programming. http://marc.theaimsgroup.com/?l=openbsd-miscm=113596339716980w=2 As a starting point, until my books arrive, I have been working from this online primer, which is getting me going: http://www.its.strath.ac.uk/courses/c/ Hope that helps in some way. Good luck. Craig On Tue, 2006-01-03 at 14:35 -0800, Joe S wrote: Hello list members. I'd like to direct this post to those that develop code for OpenBSD. I'd like a start developing software, and in turn, contribute to projects like OpenBSD and others. Right now, I'm working as a sysadmin/infosec person. I can write some simple perl and shell scripts, but that's about it. Do you have any recommendations on how I should get started? * Community college courses? * College courses? * Self-study books? I am aware that it will take a number of years before I can contribute quality code. I'm asking the OpenBSD folks for recommendations because I think the project goals are conducive to writing good software. I also think the quality of code in this project is superior to the alternatives. Any help or recommendations would be appreciated. -joe
Re: DadOS - sys shutdown with XDM
On Tue, 3 Jan 2006 15:03:31 +0100, Hannah Schroeter [EMAIL PROTECTED] wrote: On Tue, Jan 03, 2006 at 03:24:22AM -0800, J.C. Roberts wrote: My dad (68 years old) has finally succeeded in destroying/infecteding his MS-Windows NT4 box, in spite of my best efforts to secure the darn thing (e.g. No MSIE, No Microsoft Networking, stripped of just about everything MS-ish and with tons of hand made patches, behind an openbsd firewall... and so on and so forth). It lasted a good four years in the hands of a typical user that hates computers, clicks on everything and still expects everything to just work and work properly. 4 years w/o infection isn't that bad for windoze... :-) Most people would be amazed what is actually possible with Win32. My current record is six+ years but calling the result of my efforts Microsoft Windows is a bit of a stretch: [EMAIL PROTECTED] ~ $ ls -lF / ls: /pagefile.sys: No such file or directory total 784 -r-xr-xr-x1 Administ None0 Jul 5 2003 IO.SYS* -r-xr-xr-x1 Administ None0 Jul 5 2003 MSDOS.SYS* -rwxrwxrwx1 Administ None34468 Dec 7 1999 NTDETECT.COM* -rwxrwxrwx1 Administ None 214416 Dec 7 1999 NTLDR* drwxrwxrwx+ 3 Administ None0 Aug 18 2003 RECYCLER/ drwxrwxrwx+ 15 Administ None12288 Oct 26 13:12 _media_/ drwxrwxrwx+ 3 Administ None0 Sep 7 12:10 _test/ -rwxrwxrwx1 Administ None 6808 Oct 28 02:10 _viminfo* drwxrwxrwx+ 104 Administ None28672 Nov 26 01:36 app/ drwxrwxrwx+ 177 Administ None81920 Dec 31 02:50 arc/ drwxrwxrwx+ 4 Administ None 4096 Jun 23 2004 bcd/ drwxrwxrwx+ 3 Administ None 303104 Aug 18 05:58 bin/ -r-xr-xr-x1 Administ None 286 Jul 5 2003 boot.ini* -rwxrwxrwx1 Administ None 8192 Jul 2 2003 bootsec.bin* -rwxrwxrwx1 Administ None 8192 Aug 15 2003 bootsec2.bin* drwxrwxrwx+ 2 Administ None0 Nov 26 02:07 cad/ -rwxrwxrwx1 Administ None 51 Aug 18 05:52 cygwin.bat* -rwxrwxrwx1 Administ None 766 Jul 12 2003 cygwin.ico* drwxrwxrwx+ 21 Administ None24576 Sep 28 06:23 etc/ drwxrwxrwx+ 8 Administ None 4096 Apr 20 2004 home/ drwxrwxrwx+ 28 Administ None77824 Aug 15 2003 lib/ -rwxrwxrwx1 Administ None24576 Jan 7 2003 mkbt.exe* -rwxrwxrwx1 Administ None 368756 Jun 2 2004 mkbt.idb* drwxrwxrwx+ 2 Administ None 8192 Nov 8 22:47 pcbenv/ drwxrwxrwx+ 2 Administ None 4096 Dec 14 11:09 pix/ drwxrwxrwx+ 2 Administ None0 Aug 15 2003 sbin/ drwxrwxrwx+ 25 Administ None12288 Dec 23 22:10 src/ drwxrwxrwx+ 3 Administ None 8192 Nov 25 23:06 src_arc/ drwxrwxrwx+ 4 Administ None40960 Jan 3 12:18 tmp/ drwxrwxrwx+ 23 Administ None 4096 Aug 15 2003 usr/ drwxrwxrwx+ 12 Administ None 4096 Aug 15 2003 var/ drwxrwxrwx+ 3 Administ None 8192 Aug 11 04:48 vey/ drwxrwxrwx+ 41 Administ None32768 Oct 30 05:35 win/ And yes, it really is Windows NT4 Workstation and is completely missing all the vulnerable crap like MSIE that MS has forced down users throats during the last 10 years. None the less, it still runs most application software reliably (both ms-windows and unix). I have considered attempting similar mad hackery with newer microsoft operating systems like XP and Win2003 but it's simply not worth the time and effort. It's not like Microsoft is willing to pay me to fix their crap and even if they were, the would not like the way I fix it (i.e. removing all of thier supposed technological enhancements like MSIE). As you might notice from the mkbt.idb I even audited the mkbt program with the IDA Pro disassembler by Ilfak Gulifanov (http://www.hexblog.com and http://www.datarescue.com/idabase and http://www.datarescue.com/cgi-local/ultimatebb.cgi) before replacing the NT4 boot sector with the boot sector from Win2K to get past the boot disk limitations. It seems Ilfak is getting some (very well deserved) fame these days for his hotfix to the new WMF vunerability. http://it.slashdot.org/it/06/01/02/1153244.shtml?tid=201tid=218 http://it.slashdot.org/it/06/01/03/1913252.shtml?tid=220tid=109tid=172tid=218 Just because people like Ilfak and I don't have access to the microsoft source code does not mean we are unable to do anything we want to the system. It's just a lot more work. The real problem is releasing patches for a proprietary product when we don't own the rights to it. jcr
Re: learning to code - suggestions needed
On Tuesday, January 3, Joe S wrote: Do you have any recommendations on how I should get started? Any help or recommendations would be appreciated. Just get started. Learn C. Look at code. Read code. Understand. --Toby.
Re: DadOS - sys shutdown with XDM
On Tue, 3 Jan 2006, Dave Feustel wrote: On Tuesday 03 January 2006 17:11, J.C. Roberts wrote: The rule of thumb for granting privileges is simple; avoid granting permissions whenever possible. Check the ownership/privileges on /tmp/.X11-unix/X0 after you start kde or Xorg. Come on, this is a unix domain socket, as has been pointed out before. You keep on repeating this nonsense. Having a world writable socket is not a problem in itself. X has it's own authentication/authorization scheme, which is used both for unix domain sockets and tcp sockets. Also check the ownership/privileges on the /dev/[pt]typ* pair allocated to any konsole session running under kde on openbsd. Now that is likely a problem. A workaround is to use xterm instead of konsole. -Otto
Re: learning to code - suggestions needed
At 02:35 PM 1/3/2006 -0800, you wrote: Hello list members. I'd like to direct this post to those that develop code for OpenBSD. I'd like a start developing software, and in turn, contribute to projects like OpenBSD and others. Right now, I'm working as a sysadmin/infosec person. I can write some simple perl and shell scripts, but that's about it. Do you have any recommendations on how I should get started? * Community college courses? * College courses? * Self-study books? Joe, Best suggestion - check the list archives. This has been discussed may times before. A few good books have been suggested. One thing you will *NOT* find in any college courses are system-level coding principles practices. OS code is written in C, which is FAR different than 'application level' coding taught in the vast majority of courses. Also: 1) Read code 2) Play with code 3) Read code 4) Play with code 5) Try to do something 6) Read code 7) Change code 8) Test, test test et seq. I think you get the idea. The only way to write OS code is to basically teach yourself. Lee
Re: DadOS - sys shutdown with XDM
On Tue, 3 Jan 2006 22:46:50 +0100, Hannah Schroeter [EMAIL PROTECTED] wrote: Hello! On Tue, Jan 03, 2006 at 11:15:46AM -0800, patrick ~ wrote: The first thing I did was add a flag file to my dad's home directory and made sure he cant modify or delete it. # touch /home/dad/.xshutdown # chown root:wheel /home/dad/.xshutdown # chmod 400 /home/dad/.xshutdown login: dad password: dadsbox $ ls -l .xshutdown -r1 root wheel 0 Jan 3 11:11 .xshutdown dadsbox $ mv .xshutdown /tmp dadsbox $ echo :-) :-) Assuming, of course, that /tmp and /home are one partition. If not, mv .xshutdown .xnoshutdown is enough too. But then, chflags schg .xshutdown may be enough. Yep, I totally forgot to use chflags to make the file immutable. Thanks, jcr
Re: DadOS - sys shutdown with XDM
On Tuesday 03 January 2006 17:50, Otto Moerbeek wrote: On Tue, 3 Jan 2006, Dave Feustel wrote: On Tuesday 03 January 2006 17:11, J.C. Roberts wrote: The rule of thumb for granting privileges is simple; avoid granting permissions whenever possible. Check the ownership/privileges on /tmp/.X11-unix/X0 after you start kde or Xorg. Come on, this is a unix domain socket, as has been pointed out before. You keep on repeating this nonsense. Having a world writable socket is not a problem in itself. X has it's own authentication/authorization scheme, which is used both for unix domain sockets and tcp sockets. I confess that I do not understand the ramifications of the world rw+suid permissions on this socket. I do wonder why this socket has world rw when it seems to work equally well after I do a chmod 4700 on it at the beginning of every kde session. Do not the permissions applied to this socket violate the principle of least privilege mentioned above? Also check the ownership/privileges on the /dev/[pt]typ* pair allocated to any konsole session running under kde on openbsd. Now that is likely a problem. A workaround is to use xterm instead of konsole. -Otto -- Lose, v., experience a loss, get rid of, lose the weight Loose, adj., not tight, let go, free, loose clothing
Re: DadOS - sys shutdown with XDM
Dave Feustel wrote: Check the ownership/privileges on /tmp/.X11-unix/X0 after you start kde or Xorg. You can stop repeating this now, you have already demonstrated your ignorance.
Re: Gallery on OpenBSD 3.8: resolv.conf needed for email registration through remote smtp
Joachim Schipper wrote: I'm afraid this'll result in lots of questions on [EMAIL PROTECTED] I, for one, would be stumped as to why I'd want OpenNIC. No particular reason. I just needed someone for the sake of example, and they're the ones who sprang to mind. My use of them was in no way an indication of support, just that their name was easy to remember.
Re: CGD
Travers Buda wrote: Ted Unangst, Yes, I've looked at the archives. You've made it very clear that CGD won't be imported into OpenBSD, yet you've never explained why, or why you ported it in the first place. Care to let us in on why? I expect your reply will be a short no just like a few of your replys to this subject. For what it is worth, I'm asking. You have this backwards, we do thing because there are *reasons to do so*, not because there are *no reasons not to*.
Re: DadOS - sys shutdown with XDM
On Tue, 03 Jan 2006 17:34:57 -0500, Dave Feustel [EMAIL PROTECTED] wrote: On Tuesday 03 January 2006 17:11, J.C. Roberts wrote: The rule of thumb for granting privileges is simple; avoid granting permissions whenever possible. Check the ownership/privileges on /tmp/.X11-unix/X0 after you start kde or Xorg. Whether or not the socket permissions and ownership are really a problem depends on your point of view. Most folks consider it to be just fine the way it is but as always, further investigation might prove otherwise. X11 has it's own permissions system and my understanding of it is negligible. Also check the ownership/privileges on the /dev/[pt]typ* pair allocated to any konsole session running under kde on openbsd. This is a problem, well, at least it is according to my personal point of view. ;-) Have you isolated the code causing this behavior? I'm not really a KDE user. Heck, I even resist installing X11 whenever possible. jcr
Re: learning to code - suggestions needed
We all have our favorite beginer, advanced and reference book(s) for C but I prefer: Begin: ISBN 0-393-96945-2 || C Programming: A Modern Aproach by K. N. King ( A real spoon feeder ) Middle: ISBN 0201433079 || Advanced Programming in the UNIX Environment ( get some interesting things done ) Advanced: Experience ( find an unsupported wireless card and build support for it ) Reference: ISBN 0131103628 || The C Programming Language (2nd Edition) Quoting Craig McCormick [EMAIL PROTECTED]: I asked a similar question on here recently and had some good books recommended to me. This relates to C programming. http://marc.theaimsgroup.com/?l=openbsd-miscm=113596339716980w=2 As a starting point, until my books arrive, I have been working from this online primer, which is getting me going: http://www.its.strath.ac.uk/courses/c/ Hope that helps in some way. Good luck. Craig On Tue, 2006-01-03 at 14:35 -0800, Joe S wrote: Hello list members. I'd like to direct this post to those that develop code for OpenBSD. I'd like a start developing software, and in turn, contribute to projects like OpenBSD and others. Right now, I'm working as a sysadmin/infosec person. I can write some simple perl and shell scripts, but that's about it. Do you have any recommendations on how I should get started? * Community college courses? * College courses? * Self-study books? I am aware that it will take a number of years before I can contribute quality code. I'm asking the OpenBSD folks for recommendations because I think the project goals are conducive to writing good software. I also think the quality of code in this project is superior to the alternatives. Any help or recommendations would be appreciated. -joe
Re: DadOS - sys shutdown with XDM
On Tuesday 03 January 2006 18:20, J.C. Roberts wrote: I'm not really a KDE user. Heck, I even resist installing X11 whenever possible. I am getting ever closer to adopting your point of view re X11 and KDE. -- Lose, v., experience a loss, get rid of, lose the weight Loose, adj., not tight, let go, free, loose clothing
Re: Blowfish still good enough?
On 1/3/06, Sebastian Rother [EMAIL PROTECTED] wrote: Blowfish is secure but Twofish is faster and as secure as Blowfish. wrong. apples are as fast as tables. bluefish encrypts faster than twofish. don't know about rekeying etc. At least if there some quant. computers 128Bit will not save ya day anymore. quantum computers are the real big buzzword to scare people into irrational behaviour. nobody knows whether or when quantum computer will be able to brute force 128 bit keys. and whether twofish will save you. Blowfish is a good compromise but Twofish would be indeed also neat too because it's faster (importent for data-encryption) in software then AES (Rijandel). twofish encrypts faster than aes-256 and slower than aes-128. but I don't give a shit, whether it is faster, as long it is fast enough. Or just a way to encrypt the disks where I could choose some parameters of the algorithm (Bits, Rounds..)... yeah, that is relly stupid. how to put your foot before your gun. Bruce Schneier wouldn't develop an algorithm if he would still think that Blowfish (an algorithm from 1993 and puplished 1994) would still be the best choice for the next 10-30 years. because he is bruce schneier? blowfish and twofish have partly different applications, different considerations how to implement in hardware. twofish was designed for aes, blowfish not. btw. bruce schneier never said blowfish would be the best choice. as far as anybody knows, blowfish is a strong cipher with nobody having an idea how to break it. --knitti
Re: Blowfish still good enough?
http://www.onlamp.com/lpt/a/6384 Inside NetBSD's CGD by Federico Biancuzzi 12/21/2005 OpenBSD didn't import CGD even if Ted Unangst wrote a port some time ago. Do you think OpenBSD's svnd is already offering the same features? RD: In a sense, OpenBSD's svnd appears to offer some of the same features as CGD. Before I developed CGD, I examined svnd and determined that it has a number of deficiencies. The biggest drawback of svnd is its lack of security in the general use case. It is vulnerable to an offline dictionary attack. That is, you can generate a database mapping known ciphertext blocks on the disk back into pass phrases that can be accessed in O(1) without even being in possession of the disk. What's even worse is that the same database will work on any svnd disk. It is possible--and perhaps even likely--that large agencies such as the NSA have constructed such a database and can crack a majority of the svnds in the world in less than a second. The way that one prevents an offline dictionary attack is to use a salt in conjunction with the pass phrase, and this is what I did when I wrote CGD by using PKCS#5 PBKDF2. Offline dictionary attacks have been well-known since at least the '70s, and salting the pass phrase has been standard practice for over 30 years.
Re: VPN packets not passing remote gateway
--- Quoting Jason Dixon on 2006/01/03 at 17:08 -0500: I'm testing a new VPN tunnel using ipsecadm and manual keying. Everything looks ok, but packets aren't making it to enc0 and beyond on the remote side (either way). I can watch the packet count increment on the relevant pass rules (see below), so I know it's making it all the way up to remote enc0. Examples below taken while pinging from 10.100.0.113 to 10.50.0.99. Check the usual suspects? net.inet.ip.forwarding=1? Appropriate pass rules on the internal interface? Verify the return path doesn't have a problem? .joel
Re: VPN packets not passing remote gateway
On Tue, 3 Jan 2006, Joel Knight wrote: Check the usual suspects? net.inet.ip.forwarding=1? Appropriate pass rules on the internal interface? Verify the return path doesn't have a problem? Also, make sure you're not blocking the ipencap packets. Check various places with tcpdump - see what's on enc0 and pflog0. If you have any block rules in your PF ruleset, make sure they log too, so you can see what's going on via pflog0...
Re: VPN packets not passing remote gateway
On Jan 3, 2006, at 7:14 PM, Joel Knight wrote: --- Quoting Jason Dixon on 2006/01/03 at 17:08 -0500: I'm testing a new VPN tunnel using ipsecadm and manual keying. Everything looks ok, but packets aren't making it to enc0 and beyond on the remote side (either way). I can watch the packet count increment on the relevant pass rules (see below), so I know it's making it all the way up to remote enc0. Examples below taken while pinging from 10.100.0.113 to 10.50.0.99. Check the usual suspects? Yes. net.inet.ip.forwarding=1? Yes, both systems are firewalls that have been passing traffic for some time now. As demonstrated by my example, you can see that packets are making it as far as the $ext_if of the remote side as ESP. Appropriate pass rules on the internal interface? Yes, see pfctl output from original post. Verify the return path doesn't have a problem? Yes, although that's more of a part B problem when we're still discussing part A. The packets aren't even making it as far as enc0, so there certainly won't be anything to return yet. Thanks, -- Jason Dixon DixonGroup Consulting http://www.dixongroup.net
Re: VPN packets not passing remote gateway
On Jan 3, 2006, at 7:32 PM, Adrian Close wrote: On Tue, 3 Jan 2006, Joel Knight wrote: Check the usual suspects? net.inet.ip.forwarding=1? Appropriate pass rules on the internal interface? Verify the return path doesn't have a problem? Also, make sure you're not blocking the ipencap packets. I've got a pass quick enc0 all as per my original post. Check various places with tcpdump - see what's on enc0 and pflog0. I have, I can see the packets as expected on the local enc0. Nothing on the remote enc0. If you have any block rules in your PF ruleset, make sure they log too, so you can see what's going on via pflog0... Nothing is being blocked (relevant to this connection). -- Jason Dixon DixonGroup Consulting http://www.dixongroup.net
Re: Time on amd64
On Tue, 03 Jan 2006 14:16:17 -0600, Ted Unangst [EMAIL PROTECTED] wrote: are you running ntpd? are you running ntpd with the kernel adjtime patch i posted to tech a few days ago? On 1/1/06, Cyrus Lopez [EMAIL PROTECTED] wrote: I have a machine with a sempron64 and it seems that time is a tad bit too fast. Every minute it skips ahead about 15-20 seconds. After about 10 minutes it's several minutes ahead of the real time. For now I've set a cron job to rdate time.nist.gov every 5 minutes. This is on OpenBSD 3.8 with the generic kernel and no other special modifications. Is there anything I can possibly do to fix this little glitch (perhaps something via sysctl?) or is it a problem in the code somewhere? Any help would be greatly appreciated, thanks. - Cyrus Actually I just started running NTPD and now the time is in sync with the real time. Although I do notice that ntpd adjusts the time quite a bit via the logs. However, that matters not to me as long as the server has fairly accurate time which it does now. Thanks for all the prompt replies. - Cyrus
Re: learning to code - suggestions needed
One thing you will *NOT* find in any college courses are system-level coding principles practices. OS code is written in C, which is FAR different than 'application level' coding taught in the vast majority of courses. Im taking a university degree that teaches unix system programming in solaris in the second year. So you never know. Im only in the first year at the moment, so I dont know how good quality It will be. Unfortunatley they taught java in the 1st year, so I imagine they will spend most of the time teaching the basics of C, then barely scratch the surface of the UNIX api. Regards Edd
Re: CGD
knitti wrote: On 1/3/06, Ted Unangst [EMAIL PROTECTED] wrote: On 1/2/06, Travers Buda [EMAIL PROTECTED] wrote: You've made it very clear that CGD won't be imported into OpenBSD, yet you've never explained why, or why you ported it in the first place. Care to let us in on why? I expect your reply will be a short no just like a few of your replys to this subject. For what it is worth, I'm asking. Because, like everyone else, you've failed to pass the articulation test. http://marc.theaimsgroup.com/?l=openbsd-miscm=112534721521131w=2 OK, I'll try, because I'd be interested in using it on OpenBSD. Since I won't be able to do it myself, any or no answer will qualify ;) cgd gives users some choice over how to build their encrypted partition. you're able to use different ciphers. More stuff to test to make sure it works perfectly... Knobs are not a selling feature for OpenBSD developers (in fact, accusing someone of adding useless knobs is fighting words! :). Practically speaking, it is just something else to screw up, either in the code or in the operation. That's more likely to hurt you than a suddenly found fatal flaw in a particular encryption system. you're able to use passphrases or keyfiles (with some tricks one could also do this in OpenBSD, but it'd be a hack and far easier to screw up) ok, why not improve OpenBSD's solution, then? you're able to change your passphrase without reencrypting your container. that could be nice. If there is a design reason this feature couldn't be added to OpenBSD's solution, you win a point. :) (I'll admit my crypto knowledge is very lame.). in the unlikely case of a cipher getting broken, you have the possibility to switch instantly, using a tool you know with stable code an the same way you configured it. from: http://www.onlamp.com/pub/a/bsd/2005/12/21/netbsd_cgd.html?page=2 Once I have an encrypted slice, can I switch cipher or disable cgd? RD: There is currently no way to change the encryption type of an existing partition in place. Doesn't quite sound instant... Which also means if you turn some of those knobs wrong, you have a lot of work to do to repair the problem... this is the way it appears. if there are any reasons, why cgd shouldn't be used at all I'd be more than interested to hear them. if there are any reasons not to port this to OpenBSD, nobody will die not knowing them. That's not the way they work... OpenBSD does not have multiple mail clients, multiple network filtering solutions, multiple web servers, five different versions of 'vi', etc. The preference is for one well maintained, highly tested solution than several poorly maintained solutions, even if some of those poorly maintained solutions have small theoretical advantages... CGD would probably need to have a knock-out killer reason to import it, something to justify the effort and possible forced replacement of the existing svnd amoung users who use it, not just a few minor features that are arguably better and a number of features that are just different. If the features are better, port the FEATURES. If the design is just a little better, why not work on it a lot and come up with a CLEARLY better design? The point is to make the best possible OS, not a few good features on some poorly implemented and under-tested tools slapped together carelessly. And yes, avoiding slapping things in because they are not horrible is a difficult challenge. :) Nick.
Re: Blowfish still good enough?
Hi, knitti wrote: ... At least if there some quant. computers 128Bit will not save ya day anymore. quantum computers are the real big buzzword to scare people into irrational behaviour. nobody knows whether or when quantum computer will be able to brute force 128 bit keys. and whether twofish will save you. Bruce Schneier recommends using 256 bit keys in order to achieve 128 bit overall strength for a symmetric cipher. You can read it in 'applied cryptography'. The reason for this recommendation is related to collision attacks. In my personal opinion, I think, the weakest link is entering the password when opening a svnd device. Are there already solutions known which combine passwords (knowledge) with hardware devices (i.e. smartcards) or biometrics in order to access some secure storage? I don't own one, but don't at least a couple of newer IBM notebook models have a fingerprint reader and a TPM built in? Do you think a combination of these measures would improve overall security? regards, Andreas
Re: Gallery on OpenBSD 3.8: resolv.conf needed for email registration through remote smtp
On Tue, Jan 03, 2006 at 06:18:47PM -0500, Chris Zakelj wrote: Joachim Schipper wrote: I'm afraid this'll result in lots of questions on [EMAIL PROTECTED] I, for one, would be stumped as to why I'd want OpenNIC. No particular reason. I just needed someone for the sake of example, and they're the ones who sprang to mind. My use of them was in no way an indication of support, just that their name was easy to remember. Oh, I'd understand *that* (or, rather, Google would make me understand that). The problem is more along the lines of 'why doesn't /etc/resolv.conf work?'. Is there a general policy on this sort of thing somewhere? It's not like this is the only thing ever to need resolv.conf in a chroot, and it would make sense to follow existing packages and provide an extra README or note in the description if the standard is not to do anything about resolv.conf (as seems to be the case). This discussion is perhaps best re-started on [EMAIL PROTECTED] Joachim
Re: Blowfish still good enough?
On Tue, Jan 03, 2006 at 11:40:26PM +0100, Sebastian Rother wrote: Yes OpenBSD uses Blowfish and yes it si secure and YES it could be blf with 448Bit. But OpenBSD uses (as far as I know) just 128Bit. This is not true, vnconfig does read a maximum of 128 bytes (1024bit) and the key can not be larger than that. You can easily follow the function calls until it gets into blf_key(). blowfish(3) says that The block size is 64 bits and the maximum key size is 448 bits. Blowfish is secure but Twofish is faster and as secure as Blowfish. At least if there some quant. computers 128Bit will not save ya day anymore. The question is not Is blowfish still secure enought. It is more: Why can't the user choose how strong the data will get encrypted? menpower? An ideal algorithm for user-accounts would be secure and slow as hell. But then such an algorithm would just be usefull to protect the user-passwords Blowfish is a good compromise but Twofish would be indeed also neat too because it's faster (importent for data-encryption) in software then AES (Rijandel). I have Truecrypt on a windows box. The benchmarks of this app show the blowfish ist faster than all the others on my computer. As far as i can remember, it supports blowfish, twofish, aes and some others. Have a look into it :) And if I'm allowed to wish me something for next x-mas: A better solution to encrypt whole disks would be nice. Maybe also using the AES-Engine from the VIA CPUs for this job. Or just a way to encrypt the disks where I could choose some parameters of the algorithm (Bits, Rounds..)... FreeBSD has a nice way (geom) to encrypt whole disks (just from the point of the usebility). Kind regards, Sebastian p.s. Bruce Schneier wouldn't develop an algorithm if he would still think that Blowfish (an algorithm from 1993 and puplished 1994) would still be the best choice for the next 10-30 years. As far as i know here were certain design criterias (for example 128 bit blocksize, hardware implementation and such stuff). And twofish does not sound very much like a completly new thing to me? Maybe someone should ask him why he did not say anything on his website that blowfish is insecure? I mean, he also said that md5 und sha-1 are insecure, so why does he not do the same thing for blowfish? Something else I would like to add. The real winner (in security) of the NIST contest was serpent. Serpent can be implemented very well in hardware, but does not perform good in software. The Linux kernel has support for it and i used it some time, but it is really slow. So if you are paranoid, don't cry for AES, go for serpent. There are maybe reasons why the NSA didn't like it ;)) Another (ot) thing, it is easy to add keyfile(s) to vnconfig. What you need is gpg and a small patch [1] that makes vnconfig read from stdin. Encrypt your keyfile with gpg und put it on an usb stick. Write some small shell scripts that pipe the output of gpg into vnconfig and add some nice dialogs.. Now you can change your passphrase as often as you wish and have your disk encrypted with a keyfile that is guarenteed not in an lookup table at some supercomputers of some mysterious three letter agency ;) Tobias [1] http://www.tmux.org/tmp/vnconfig.c.diff (That's my crappy version of it, but there are other...)
Re: learning to code - suggestions needed
On Tue, Jan 03, 2006 at 05:06:02PM -0600, L. V. Lammert wrote: One thing you will *NOT* find in any college courses are system-level coding principles practices. OS code is written in C, which is FAR different than 'application level' coding taught in the vast majority of courses. L.V. - the school I went to did have a small handful of courses that did include labs/assignments/projects that included this type of programming. Most of the curriculum was based on more abstract notions, but there are some systems-oriented courses. The undergraduate OS class I took, for example, invovled writing a memory manager and a shell. The graduate OS class I took included a write your own OS project. We also had a compiler course that involved writing your own compiler, etc, etc. Also: 1) Read code 2) Play with code [snip] et seq. I think you get the idea. The only way to write OS code is to basically teach yourself. While your higher-ed experience may have been different than mine, I totally agree that writing and reading code is the best thing you can do to learn. I might add that one thing that has helped me to figure out what code to read and what to write is to identify something *I* would like to see implemented, and try to implement it myself. bc -- Benjamin Collins [EMAIL PROTECTED] 'Broadly speaking, the short words are the best, and the old words best of all.' --- Sir Winston Churchill [demime 1.01d removed an attachment of type application/pgp-signature]
Re: VPN packets not passing remote gateway
--- Quoting Jason Dixon on 2006/01/03 at 19:39 -0500: Yes, although that's more of a part B problem when we're still discussing part A. The packets aren't even making it as far as enc0, so there certainly won't be anything to return yet. In your original email you say that [packets are] making it all the way up to remote enc0. Time to break out tcpdump. Are you getting packets at the remote side? .joel
Re: Blowfish still good enough?
Andreas Bartelt wrote: ... Bruce Schneier recommends using 256 bit keys in order to achieve 128 bit overall strength for a symmetric cipher. You can read it in 'applied cryptography'. The reason for this recommendation is related to collision attacks. oops, typo. It's in the newer book 'practical cryptography'. regards, Andreas
Re: VPN packets not passing remote gateway
On Jan 3, 2006, at 8:51 PM, Joel Knight wrote: --- Quoting Jason Dixon on 2006/01/03 at 19:39 -0500: Yes, although that's more of a part B problem when we're still discussing part A. The packets aren't even making it as far as enc0, so there certainly won't be anything to return yet. In your original email you say that [packets are] making it all the way up to remote enc0. The original post says that packets aren't making it to enc0 and beyond on the remote side. Yes, I admit that I was a bit contradictory in the next sentence that says it's making it all the way up to remote enc0, but I was trying to explain that ESP packets are making it to the remote side, but nothing is appearing on enc0 (as I've already explained). Just to avoid any further confusion for you... packets are NOT traversing enc0 on the remote side. Thanks, -- Jason Dixon DixonGroup Consulting http://www.dixongroup.net
Re: VPN packets not passing remote gateway
--- Quoting Jason Dixon on 2006/01/03 at 21:11 -0500: The original post says that packets aren't making it to enc0 and beyond on the remote side. Yes, I admit that I was a bit contradictory in the next sentence that says it's making it all the way up to remote enc0, but I was trying to explain that ESP packets are making it to the remote side, but nothing is appearing on enc0 (as I've already explained). Just to avoid any further confusion for you... packets are NOT traversing enc0 on the remote side. You haven't clarified if they're making it to the external interface on that box though.
Re: CGD
On 1/4/06, Nick Holland [EMAIL PROTECTED] wrote: knitti wrote: cgd gives users some choice over how to build their encrypted partition. you're able to use different ciphers. More stuff to test to make sure it works perfectly... Knobs are not a selling feature for OpenBSD developers (in fact, accusing someone of adding useless knobs is fighting words! :). Practically speaking, it is just something else to screw up, either in the code or in the operation. That's more likely to hurt you than a suddenly found fatal flaw in a particular encryption system. if choosing ciphers would be like turning knobs, we should abandon that choice for SSL/TLS, IPSec, different SSH keys or signatures. I don't agree with your statement in this context. I fully support sane defaults, and making it not easy to change them. but in this case not easy==impossible. at least without implementing it myself, which I'm not able to. chosing ciphers is no tuning. and algorithms can be broken, no one was really surprised when md5 got broken, since there was always sha. and as sha was broken, too (in terms of proper implementation fo alternatives naerly at the same time), a lot of projects had no real alternative. (which was in this case not as bad as it sound, most things do function still with md5 or sha, but md5s provides nothing more than a bit protection against random collisions. you're able to use passphrases or keyfiles (with some tricks one could also do this in OpenBSD, but it'd be a hack and far easier to screw up) ok, why not improve OpenBSD's solution, then? because OpenBSD's solution is not good enough. I'm not a c coder, and implementing crypto correctly is not trivial, so I can't improve the code. wrapping everything in shell scripts to achieve something similiar in terms of key handling would be OK, but the implementation itself is the bare minimun which can be called encrypted. and it's not _very_ secure. I'm not complaining, I simply don't use OpenBSD for encrypted storage. Thats ok for me. you're able to change your passphrase without reencrypting your container. that could be nice. If there is a design reason this feature couldn't be added to OpenBSD's solution, you win a point. :) (I'll admit my crypto knowledge is very lame.). I can't read the implementation very well, but as it seems, it would be easier to rewrite it (thats not an statement about code quality). (don't know about how hard a port of cgd is/ would be) in the unlikely case of a cipher getting broken, you have the possibility to switch instantly, using a tool you know with stable code an the same way you configured it. from: http://www.onlamp.com/pub/a/bsd/2005/12/21/netbsd_cgd.html?page=2 Once I have an encrypted slice, can I switch cipher or disable cgd? RD: There is currently no way to change the encryption type of an existing partition in place. Doesn't quite sound instant... Which also means if you turn some of those knobs wrong, you have a lot of work to do to repair the problem... sorry for that with instantly. I meant without having to wait for a patch to arrive to implement another cipher, which would in the current case mean either having really new code probably rather fast or well tested, stable code after a couple of weeks/months. No existing implementation supports in place reencryption. which is probably better. this is the way it appears. if there are any reasons, why cgd shouldn't be used at all I'd be more than interested to hear them. if there are any reasons not to port this to OpenBSD, nobody will die not knowing them. That's not the way they work... OpenBSD does not have multiple mail clients, multiple network filtering solutions, multiple web servers, five different versions of 'vi', etc. The preference is for one well maintained, highly tested solution than several poorly maintained solutions, even if some of those poorly maintained solutions have small theoretical advantages... I fully agree with you for user applications. however, not having a backup solution for something which can be declared broken anytime is neither reliable nor secure. and whether or not it breaks doesn't depend on how well maintained this existing solution is. CGD would probably need to have a knock-out killer reason to import it, something to justify the effort and possible forced replacement of the existing svnd amoung users who use it, not just a few minor features that are arguably better and a number of features that are just different. If the features are better, port the FEATURES. If the design is just a little better, why not work on it a lot and come up with a CLEARLY better design? svnd is fine and has its applications, and it shines _despite_ the crypto add-on. cgd _is_ a clearly better design. it is designed for secure storage, which is svnd apparently not, it has a minimal crypto feature _tacked on_. and if the posting in the other thread (the cite of the cgd
Re: VPN packets not passing remote gateway
On Jan 3, 2006, at 9:34 PM, Joel Knight wrote: --- Quoting Jason Dixon on 2006/01/03 at 21:11 -0500: The original post says that packets aren't making it to enc0 and beyond on the remote side. Yes, I admit that I was a bit contradictory in the next sentence that says it's making it all the way up to remote enc0, but I was trying to explain that ESP packets are making it to the remote side, but nothing is appearing on enc0 (as I've already explained). Just to avoid any further confusion for you... packets are NOT traversing enc0 on the remote side. You haven't clarified if they're making it to the external interface on that box though. I don't wish to be rude, but please read my replies to you. Here are quotes from two prior emails. Replying to you, 7:39pm EST As demonstrated by my example, you can see that packets are making it as far as the $ext_if of the remote side as ESP. Replying to you, 9:11pm EST ESP packets are making it to the remote side, but nothing is appearing on enc0 Thanks, -- Jason Dixon DixonGroup Consulting http://www.dixongroup.net
Re: CGD
On 1/3/06, knitti [EMAIL PROTECTED] wrote: cgd gives users some choice over how to build their encrypted partition. you're able to use different ciphers. in the unlikely case of a cipher getting broken, you have the possibility to switch instantly, using a tool you know with stable code an the same way you configured it. this is really not that useful. why would you pick anything other than the best when setting it up? and after it's setup, you can't change. the idea that once a cipher is broken you could migrate is nice, but think about it. are you equipping all your servers with double storage so that you can copy and reencrypt everything? i doubt anyone has thougt more than 10 seconds about what the migration procedure would really be. anyway, it's not that hard to switch ciphers in svnd. how critical is your timeframe? can you wait 24 hours to upgrade? do you have a beeper set to wake you up everytime somebody posts to sci.crypt? you're able to use passphrases or keyfiles (with some tricks one could also do this in OpenBSD, but it'd be a hack and far easier to screw up) this is a change that's fairly easy to bring about. you're able to change your passphrase without reencrypting your container. not really, or at least not any more so than with svnd.
Re: CGD
On 1/3/06, kami petersen [EMAIL PROTECTED] wrote: on a related subject: what's keeping that diff you did to add salting to vnconfig from hitting the tree? (or something like it) nobody commented on it. the lifecycle of this entire conversation has gone something like: whiners demand cgd without explanation. after a bit, we identify something that could be improved. i post a patch. silence. whiners demand cgd without explanation. i don't believe that the people asking for cgd really even intend to use it. they are certainly not capable of actually evaluating their needs. it doesn't matter what the solution is; if it's not spelled cgd they won't be happy. the absurdity of it all amazes me. like maybe if you post an interview with roland
Re: CGD
On 1/3/06, veins [EMAIL PROTECTED] wrote: --- Ted Unangst [EMAIL PROTECTED] wrote: On 1/3/06, kami petersen [EMAIL PROTECTED] wrote: on a related subject: what's keeping that diff you did to add salting to vnconfig from hitting the tree? (or something like it) nobody commented on it. [...] I didn't see that diff :( Still need comments on it ? If so I can patch tomorrow a box @ work and do some testing on it. it's only proof of concept; i wouldn't trust it too far. http://marc.theaimsgroup.com/?l=openbsd-miscm=110474799109884w=2
Re: CGD
--- Ted Unangst [EMAIL PROTECTED] wrote: On 1/3/06, kami petersen [EMAIL PROTECTED] wrote: on a related subject: what's keeping that diff you did to add salting to vnconfig from hitting the tree? (or something like it) nobody commented on it. [...] I didn't see that diff :( Still need comments on it ? If so I can patch tomorrow a box @ work and do some testing on it.
Re: CGD
--- Ted Unangst [EMAIL PROTECTED] wrote: On 1/3/06, knitti [EMAIL PROTECTED] wrote: cgd gives users some choice over how to build their encrypted partition. you're able to use different ciphers. in the unlikely case of a cipher getting broken, you have the possibility to switch instantly, using a tool you know with stable code an the same way you configured it. this is really not that useful. why would you pick anything other than the best when setting it up? and after it's setup, you can't change. the idea that once a cipher is broken you could migrate is nice, but think about it. are you equipping all your servers with double storage so that you can copy and reencrypt everything? i doubt anyone has thougt more than 10 seconds about what the migration procedure would really be. anyway, it's not that hard to switch ciphers in svnd. how critical is your timeframe? can you wait 24 hours to upgrade? do you have a beeper set to wake you up everytime somebody posts to sci.crypt? Not to mention that even in the case blowfish is broken at some point, it is unlikely that the attack reduces complexity of a decryption to a timeframe that would allow someone to decrypt data ciphered with a strong key in svnd before OpenBSD has the opportunity to switch cipher.
Re: VPN packets not passing remote gateway [RESOLVED... sorta]
After some gentle persuading by Adrian Close, I dropped ipsecadm and went back to automatic key exchange with isakmpd. A quick configuration based on the east/west and all is good. Same PF configuration, no changes there except for the addition of ISAKMP traffic. Don't know what the problem was, although I'm sure it was user related. -- Jason Dixon DixonGroup Consulting http://www.dixongroup.net
Re: CGD
On 01/03/2006 09:45:02 PM, Ted Unangst wrote: On 1/3/06, kami petersen [EMAIL PROTECTED] wrote: on a related subject: what's keeping that diff you did to add salting to vnconfig from hitting the tree? (or something like it) i don't believe that the people asking for cgd really even intend to use it. I don't intend to use svnd (and so have not been paying attention but am venturing to comment anyway), but I do _like_ the idea of having it there to use should the need arise. Salting sounds like something I want because, again, in my uninformed opinion, otherwise you wouldn't see it all over the place in password hashes. Apparently the implementation complexity v.s. increase in security trade-off comes out in favor of salting in at least that problem domain. It would be a question I'd investigate should I ever want an encrypted file system. I'm interested enough to pay a little attention now should somebody either decide to implement salting in svnd or explain why I don't want it. I suspect others are in the same frame of mind. Hence the not-necessarily-informed hand waving surrounding all sorts of encrypted filesystem issues (even though, IMHO, salting is the only issue of significance in svnd that was brought up in the CGD article.) Why did I write this? I guess because I'm lazy like everybody else and am hoping for an expert answer vis. svnd and salting. Perhaps I'm thinking you'd appreciate the data point regards my interest in the subject. Feel free to ignore me. Regardless you should know I do appreciate the work done. Karl [EMAIL PROTECTED] Free Software: You don't pay back, you pay forward. -- Robert A. Heinlein
Re: CGD
Karl O. Pinc wrote: On 01/03/2006 09:45:02 PM, Ted Unangst wrote: On 1/3/06, kami petersen [EMAIL PROTECTED] wrote: on a related subject: what's keeping that diff you did to add salting to vnconfig from hitting the tree? (or something like it) i don't believe that the people asking for cgd really even intend to use it. I don't intend to use svnd (and so have not been paying attention but am venturing to comment anyway), but I do _like_ the idea of having it there to use should the need arise. Salting sounds like something I want because, again, in my uninformed opinion, otherwise you wouldn't see it all over the place in password hashes. Apparently the implementation complexity v.s. increase in security trade-off comes out in favor of salting in at least that problem domain. It would be a question I'd investigate should I ever want an encrypted file system. I'm interested enough to pay a little attention now should somebody either decide to implement salting in svnd or explain why I don't want it. I think you are missing the point, cgd and salting are two different and unrelated things. It's not because cgd isn't making it into OpenBSD, that salting won't make it into svnd. I'd explain, but frankly after a night at work i'd rather go and sleep while you google :-) ps. tedu just said that he got no comments about his diff, if you really think the idea is valuable, you should be testing the diff.
Re: DadOS - sys shutdown with XDM
On Tue, 3 Jan 2006, Dave Feustel wrote: On Tuesday 03 January 2006 17:50, Otto Moerbeek wrote: On Tue, 3 Jan 2006, Dave Feustel wrote: On Tuesday 03 January 2006 17:11, J.C. Roberts wrote: The rule of thumb for granting privileges is simple; avoid granting permissions whenever possible. Check the ownership/privileges on /tmp/.X11-unix/X0 after you start kde or Xorg. Come on, this is a unix domain socket, as has been pointed out before. You keep on repeating this nonsense. Having a world writable socket is not a problem in itself. X has it's own authentication/authorization scheme, which is used both for unix domain sockets and tcp sockets. I confess that I do not understand the ramifications of the world rw+suid permissions on this socket. I do wonder why this socket has world rw when it seems to work equally well after I do a chmod 4700 on it at the beginning of every kde session. Do not the permissions applied to this socket violate the principle of least privilege mentioned above? It does not have suid permissions. This clearly shows you understand little about permissions. Hint: it's a socket, starting with an 's'. The princpiple is not violated, because having the socket writable for others has it's uses, maybe? -Otto
