Re: Preventing password reuse

2006-07-04 Thread Steffen Kluge
On Tue, 2006-07-04 at 07:15 +0200, Paul de Weerd wrote:
> | So, you are suggesting using something other than the hash stored  in
> | OpenBSD's master.passwd then?
> 
> Why exactly would we need another hash ?

Because the hashes in master.passwd are salted, as you come to realise
yourself further down in your post.

> | If not try this:
> | Add a user, nothing special.
> | Record the hash from master.passwd
> | Log in as the test user.
> | Change "your" password.
> | Change it back.
> | Compare the hashes.
> | Different eh?
> 
> How come these are different ? What happened ? It's still the same
> password, right ? How can one string hash to two different outputs ?

Because the hashes in master.passwd are salted, as you come to realise
yourself further down in your post.

> | So you need to change to a less secure password hash method.
> 
> Why ?

Because the hashes in master.passwd are salted, as you come to realise
yourself further down in your post.

> Your password is not hashed as-is. A salt is added (for extra flavour)
> before hashing.

Quite.

Cheers
Steffen.



lladdr in ipconfig - what's the story?

2005-06-06 Thread Steffen Kluge
Hi all,
I'd like some clarification on the support or non-support of the lladdr
option in ipconfig. I'm getting conflicting evidence from various
sources: on-line man page (+), man page of my brand new 3.7 install (-),
various forums (mix of + and -). It looks as if the ipconfig that comes
with 3.7 doesn't understand lladdr.

Is this a temporary issue? Will the option be added back in? Or does it
depend on the ethernet card driver in use (fxp in my case)?

Cheers
Steffen.



Re: lladdr in ipconfig - what's the story?

2005-06-06 Thread Steffen Kluge
On Tue, 2005-06-07 at 10:11 +1000, Steffen Kluge wrote:
> I'd like some clarification on the support or non-support of the lladdr
> option in ipconfig.

For crying out loud. Don't know where that came from, probably from
setting up a LAN party for my son last weekend...

Please bear with me.

Jeez!
Steffen.



Re: lladdr in ipconfig - what's the story?

2005-06-06 Thread Steffen Kluge
On Tue, 2005-06-07 at 02:17 +0200, Henning Brauer wrote:
> the manpages are (surprise, eh) right. no lladdr in 3.7, but it is in 
> -current.

Thanks.

Can I simply pick the ifconfig binary out of snapshots/i386/base37.tgz,
or must I upgrade the whole thing, including packages and ports? If I
upgrade, will the installer detect installed packages and attempt to
upgrade them, too?

Cheers
Steffen.



OS fingerprinting and netcraft

2005-06-15 Thread Steffen Kluge
Hi all,
I recently moved a web server in my domain to OpenBSD 3.7. Out of
curiosity I looked it up at netcraft. While they correctly identified
the web server software, the OS was listed as "unkown".

Not that I really care about this, but I'm curious as to what prevented
them from fingerprinting the OS. I notice that some sites are being
recognised as running OpenBSD, hence it can't be altogether impossible.

I wonder whether my firewall, which was also changed to OpenBSD/pf
recently, is interfering. I'm using "scrub in all" as well as "synproxy
state" on the inbound pass rules. Could that be defeating netcraft's
fingerprinting attempts?

Cheers
Steffen.



Re: Eric Raymond talks about GPL and BSD licenses on MyFreeBSD.com

2005-06-19 Thread Steffen Kluge

Johan M:son Lindman wrote:

http://www.catb.org/~esr/guns/


Thanks for pointing that out, Johan.

Of course, ESR being a gun nut makes his opinion about software 
licensing irrelevant at best, and wrong at worst. I mean, who would want 
the terms of a license as oppressive as the GPL written on their 
foreheads with an automatic gun?


(Jeez, what's wrong with you people...?)

Cheers
Steffen.



Re: Eric Raymond talks about GPL and BSD licenses on MyFreeBSD.com

2005-06-20 Thread Steffen Kluge
On Mon, 2005-06-20 at 22:20 -0500, Jeff Bachtel wrote:
> You know, I've often been accused of being unable to read, but to my
> eyes it appears Raymond was positing that the GPL was not needed, and
> that software should be released under a BSD license.

Actually, he said "GPL is based on the belief that open source software
is weak and needs to be protected. With it, we continue injuring
ourselves, cutting ourselves from the economic benefits of BSD license".

He didn't say whether the belief is wrong, or what the economic benefits
of licensing under BSD terms might be, and hence didn't conclude
anything.

However, regardless of what I think about this...

> So did you actually read the article, or just assumed you knew the
> position ESR had taken?

... I wasn't commenting on ESR's position at all, but on the previous
poster's assertion that ESR's stance on gun control has got anything to
do with anything.

Cheers
Steffen.



sudo vulnerability

2005-06-20 Thread Steffen Kluge
Hi all,
I was wondering whether sudo 1.6.8p8 as found in -current has the
pathname validation vulnerability reported recently (e.g. at
http://www.auscert.org.au/render.html?it=5193).

Its version number would suggest it does, however OBSD might contain
patches that are not included upstream, or other mitigating factors.

Is it recommendable to fetch and install 1.6.8p9 straight away?

Cheers
Steffen.



Re: OpenBSD 3.7 w/ Amavisd-New,SpamAssassin,Postfix

2005-06-21 Thread Steffen Kluge
On Tue, 2005-06-21 at 17:00 -0700, Timothy Horie wrote:
> I installed amavisd and I'm using Postfix but since I am using the 
> proxy_filter for amavisd, I can't use the REDIRECT keyword in 
> /etc/postfix/relay_recipients.

In relay_recipient_maps the RHS is ignored anyway. The files listed
under relay_recipient_maps are only checked for matches in the first
column (at least in all versions of postfix I've encountered so far).

> Is there a way to use both? I would like e-mails that go to, for 
> example, [EMAIL PROTECTED] to actualy be redirected to 
> [EMAIL PROTECTED] which actually does exist on the internal MS 
> exchange server.

Relay_recipient_maps aren't the right tool for this. Use alias_maps,
virtual_alias_maps or recipient_canonical_maps to achieve this. All of
these do will do the above, but behave somewhat differently in other
regards. Read up on them and pick the one you prefer. I suggest you
start with alias_maps.

Cheers
Steffen.



Re: nforce3 problem

2005-06-27 Thread Steffen Kluge
On Tue, 2005-06-28 at 00:52 +0200, Rogier Krieger wrote:
> I've given up hope on the ethernet chip ever
> getting supported as well as the S-ATA controller on board. In both
> cases, I blame nVidia.

/*
 * forcedeth: Ethernet driver for NVIDIA nForce media access controllers.
 *
 * Note: This driver is a cleanroom reimplementation based on reverse
 *  engineered documentation written by Carl-Daniel Hailfinger
 *  and Andrew de Quincey. It's neither supported nor endorsed
 *  by NVIDIA Corp. Use at your own risk.

Do you reckon this documentation could also be used to write a *BSD
driver?

> If you intend to only ever use Windows, I suppose nVidia's fine; if
> not, I heartily recommend other manufacturers. Why limit your options?

Well, it's about *not* limiting options. And this one is a particularly
attractive option (from the hardware price/performance point of view).

Cheers
Steffen.



Re: Semi-OT: Problems getting find to not recurse

2005-07-06 Thread Steffen Kluge
On Wed, 2005-07-06 at 22:19 +0200, Matthias Kilian wrote:
> find /home/kili -maxdepth 1 -type f -name \* -mtime +1 -exec echo {} \; |
> grep ssh

This test is irrelevant to the OP's problem.

> yields no output at all. [And of course, I *do* have a .ssh directory.]

But do you have *files* (-type f) that have "ssh" in their name and
don't start with a dot (-name \*)?

If you drop both the "type -f" and "-name \*" predicates your .ssh
directory will show up just fine.

However, "-maxdepth 1" will keep find from recursing into that
directory:

$ touch .ssh/file
$ find . -name file
./.ssh/file
$ find . -maxdepth 1 -name file
$

(OpenBSD 3.7 (GENERIC) #50: Sun Mar 20 00:01:57 MST 2005
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC)

Cheers
Steffen.



Re: buf_read & dhclient

2006-03-22 Thread Steffen Kluge
On Thu, 2006-03-16 at 18:43 +0100, Johan SANCHEZ wrote:
> And time to time this one:
> natbox dhclient[19726]: buf_read (connection closed): Undefined error: 0

That's what I'm seeing every time I run "sh /etc/netstart sis0". After
this a new dhclient gets started and the DHCP lease will be
obtained/renewed. However, no automatic renewals take place afterwards,
and I have to repeat the manual procedure.

> The external nic is an pcn0:

Mine is a "NS DP83815 10/100" (sis), on a WRAP.

> The box just run pf and nothing else.

Same here, just an Internet firewall. I was using 3.7 before yesterday
and this never happened. I have to say, though, that before yesterday
the firewall hardware was different, too, with an le interface on the
outside. For now I'm running a cron job to periodically renew my DHCP
lease...

My root fs is mounted noatime, and var and dev are mfs's:

/dev/wd0a on / type ffs (local, noatime)
mfs:15181 on /dev type mfs (asynchronous, local, noexec, nosuid, 
  size=1200 512-blocks)
mfs:28327 on /var type mfs (asynchronous, local, nodev, noexec, nosuid, 
  size=32768 512-blocks)

I suppose the WRAP dmesg is well known, but here it goes anyway:

OpenBSD 3.8 (GENERIC) #138: Sat Sep 10 15:41:37 MDT 2005
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Geode(TM) Integrated Processor by National Semi ("Geode by NSC" 
586-class) 267 MHz
cpu0: FPU,TSC,MSR,CX8,CMOV,MMX
cpu0: TSC disabled
real mem  = 133804032 (130668K)
avail mem = 115478528 (112772K)
using 1658 buffers containing 6791168 bytes (6632K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+(fa) BIOS, date 05/02/05, BIOS32 rev. 0 @ 0xfc5f2
pcibios0 at bios0: rev 2.1 @ 0xf/0x1
pcibios0: pcibios_get_intr_routing - function not supported
pcibios0: PCI IRQ Routing information unavailable.
pcibios0: PCI bus #0 is the last bus
bios0: ROM list: 0xe/0x8000
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Cyrix GXm PCI" rev 0x00
sis0 at pci0 dev 14 function 0 "NS DP83815 10/100" rev 0x00: DP83816A, irq 10, 
address 00:0d:b9:02:c7:c4
nsphyter0 at sis0 phy 0: DP83815 10/100 PHY, rev. 1
sis1 at pci0 dev 15 function 0 "NS DP83815 10/100" rev 0x00: DP83816A, irq 9, 
address 00:0d:b9:02:c7:c5
nsphyter1 at sis1 phy 0: DP83815 10/100 PHY, rev. 1
sis2 at pci0 dev 16 function 0 "NS DP83815 10/100" rev 0x00: DP83816A, irq 11, 
address 00:0d:b9:02:c7:c6
nsphyter2 at sis2 phy 0: DP83815 10/100 PHY, rev. 1
gscpcib0 at pci0 dev 18 function 0 "NS SC1100 ISA" rev 0x00
gpio0 at gscpcib0: 64 pins
"NS SC1100 SMI/ACPI" rev 0x00 at pci0 dev 18 function 1 not configured
pciide0 at pci0 dev 18 function 2 "NS SCx200 IDE" rev 0x01: DMA, channel 0 
wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0: 
wd0: 4-sector PIO, LBA, 246MB, 503808 sectors
wd0(pciide0:0:0): using PIO mode 4
"NS SCx200 AUDIO" rev 0x00 at pci0 dev 18 function 3 not configured
geodesc0 at pci0 dev 18 function 5 "NS SC1100 X-Bus" rev 0x00: iid 6 revision 3 
wdstatus 0
isa0 at gscpcib0
isadma0 at isa0
pcppi0 at isa0 port 0x61
midi0 at pcppi0: 
spkr0 at pcppi0
sysbeep0 at pcppi0
gscsio0 at isa0 port 0x2e/2: SC1100 SIO rev 1: ACB1 ACB2
iic0 at gscsio0
iic1 at gscsio0
lmtemp0 at iic1 addr 0x48: LM77
npx0 at isa0 port 0xf0/16: using exception 16
pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
pccom0: console
biomask f1ef netmask ffef ttymask ffef
pctr: no performance counters in CPU
nvram: invalid checksum
dkcsum: wd0 matches BIOS drive 0x80
root on wd0a
rootdev=0x0 rrootdev=0x300 rawdev=0x302
clock: unknown CMOS layout


Cheers
Steffen.



DST oddity in Australia/NSW timezone

2006-03-22 Thread Steffen Kluge
I just noticed that a fresh 3.8 install doesn't contain the DST
exception that has been declared for Australia (NSW and ACT) this year,
apparently to accommodate the Commonwealth Games.

This year, daylight savings won't be turned back on the last Sunday in
March, as usual, but a week later on the 1st of April.

Just thought somebody in Oz (NSW and ACT) might care.

I copied the /usr/share/zoneinfo/Australia/NSW file from a Linux box to
my OpenBSD machines, as well as a bunch of Solaris boxes, and all is
well.

Proper handling of DST can be checked by running "zdump -v -c 2007
Australia/NSW".

Cheers
Steffen.



Re: DST oddity in Australia/NSW timezone

2006-03-23 Thread Steffen Kluge
On Thu, 2006-03-23 at 19:23 +1100, Rod.. Whitworth wrote:
> >Proper handling of DST can be checked by running "zdump -v -c 2007
> >Australia/NSW".
> 
> or Sydney or Melbourne, Canberra, Hobart, Victoria, Tasmania, Adelaide,
> South or whatever you use that is affected

Sydney, NSW, Canberra and ACT are actually hardlinks to the same file on
most systems. I was falsely assuming that VIC and Melbourne were too. 

Are you sure SA and TAS are affected by the exception?

Cheers
Steffen.



Re: OpenBSD and the money

2006-04-02 Thread Steffen Kluge
On Fri, 2006-03-24 at 10:16 +0100, Toni Mueller wrote:
> Try
> to name at least one incentive for Alberta to fund a project where the
> financial benefits will largely be reaped outside of Alberta.

For a lot of people, OpenBSD has put Alberta on the map...

Cheers
Steffen.



Re: security bug in x86 hardware (thanks to X WIndows)

2006-05-15 Thread Steffen Kluge
On Sat, 2006-05-13 at 16:18 +0200, Ed White wrote:
> It seems XFree people disagree...
> [...]
> ...and some Linux developers too...
> 
> Alan Cox: What it essentially says is "if you can hack the machine enough to 
> get the ability to issue raw i/o accesses you can get any other power you
> want". Thats always been true. Using SMM to do this seems awfully hard
> work.

He said that in reply to you saying:

> The big problem is that the attack is possible thanks to the way X
> Windows is designed

He didn't comment on whether X is flawed or not, but rather that from a
Linux perspective this whole issue is a storm in a tea cup. In
(distribution default) Linux it is always possible for root to get ring
0 access. Simply because root can load kernel modules. That's what root
kits do. Fumbling registers through a hacked X server is a novel but
rather complicated way, in comparison.

Hence, securing a Linux server has always meant (besides removing X and
tons of other crud) to build a kernel that doesn't support loadable
modules. 

Cheers
Steffen.