Re: sudo -u & environment help

[Craig R. Skinner]

To clarify, there are no ~/. shell dot files.

$PATH & umask are set in /etc/login.conf
$MAIL is the default set by login(1)

/etc/profile sources /etc/ksh.kshrc, which just sets $PS1,
window decor & some aliases, nothing major.

This arrangement works fine when logging in directly,
or via "sudo su -l user"

>From my reading of sudo(8), I thought the same environment could be
gained with something like "sudo -H -i -u username".

Am I missing sudo flags or settings in /etc/sudoers?


On 2014-04-04 Fri 11:30 AM |, Craig R. Skinner wrote:
> Hi,
> 
> When sudo'ing to another user, how can I obtain all of their environment
> settings as they receive when logging in themselves?
> 
> When I use sudo in this manner, settings such as $PATH, $MAIL & umask
> aren't being honoured:
> 
> 
> $ echo $LOGNAME; echo $PATH; echo $MAIL; umask
> craig
> /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/sbin:/usr/site/bin:/usr/site/sbin:/home/craig/bin
> /var/mail/craig
> 027
> 
> 
> 
> Here, $PATH, $MAIL & umask are unchanged:
> 
> $ sudo -H -i -u david
> $ echo $LOGNAME; echo $PATH; echo $MAIL; umask
> david
> /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/sbin:/usr/site/bin:/usr/site/sbin:/home/craig/bin
> /var/mail/craig
> 027
> 
> 
> Compare the difference when logging in as that user:
> 
> $ login david
> ...
> $ echo $LOGNAME; echo $PATH; echo $MAIL; umask
> david
> /usr/bin:/bin:/usr/local/bin:/usr/site/bin:/home/david/bin
> /var/mail/david
> 022
> 
> 
> 
> 
> /etc/login.conf:
> default:\
>   :passwordcheck=/usr/local/bin/pwqcheck -1:\
>   :passwordtries=0:\
>   :path=/usr/bin /bin /usr/local/bin /usr/site/bin ~/bin:\
>   :umask=022:\
>   :datasize-cur=
> 
> staff:\
>   :path=/usr/bin /bin /usr/sbin /sbin /usr/local/bin /usr/local/sbin 
> /usr/site/bin /usr/site/sbin ~/bin:\
>   :umask=027:\
>   :datasize-cur=
> 
> 
> $ egrep 'env_|Defaults' /etc/sudoers | grep -v ^#
> Defaults env_keep +="DESTDIR DISTDIR EDITOR FETCH_CMD FLAVOR FTPMODE GROUP 
> MAKE"
> Defaults env_keep +="MAKECONF MULTI_PACKAGES NOMAN OKAY_FILES OWNER PKG_CACHE"
> Defaults env_keep +="PKG_DBDIR PKG_DESTDIR PKG_PATH PKG_TMPDIR PORTSDIR"
> Defaults env_keep +="RELEASEDIR SHARED_ONLY SSH_AUTH_SOCK SUBPACKAGE VISUAL"
> Defaults env_keep +="WRKOBJDIR"
> Defaults always_set_home, ignore_dot, use_loginclass
> 
> 
> 
> login(1):
> 
>  login enters information into the environment (see environ(7)) specifying
>  the user's home directory (HOME), command interpreter (SHELL), search
>  path (PATH), terminal type (TERM), and user name (both LOGNAME and USER).
> 
> ENVIRONMENT
>  login sets the following environment variables:
> 
>  HOME
>  MAIL
> 
> sudo(8):
> 
>   Command Environment
>  ..  On BSD systems, if the use_loginclass option is
>  enabled, the environment is initialized based on the path and setenv
>  settings in /etc/login.conf.  The new environment contains the TERM,
>  PATH, HOME, MAIL, SHELL, LOGNAME, USER, USERNAME and SUDO_* variables in
>  addition to variables from the invoking process permitted by the
>  env_check and env_keep options.  This is effectively a whitelist for
>  environment variables.
> 
> 
> 
> How can I become another user - without knowing their password,
> and gain their 'natural' environment?
> 
> e.g. from wheel group to a users group member.
> 
> 'su -l username' & 'login username' require their password.
> 
> I thought 'sudo -H -i -u username' would do it.
> 
> Any suggestions on what else I need to configure?

Re: PF rule for transparent siproxd ?

[Stuart Henderson]

On 2014-04-07, Christophe  wrote:
> The goal is to accept every SIP device from inside the LAN to register
> to SIP provider without any "outbound proxy" configuration, and let
> siproxd acting as a masquerading server.

Do you really need it? Most user-facing SIP providers run SBCs to work
around NAT problems (amongst other things) and either don't need, or
work better without, SIP NAT helpers.

Re: Only two holes in a heck of a long time, but why?

[Stuart Henderson]

On 2014-04-07, Kevin Chadwick  wrote:
> previously on this list Stuart Henderson contributed:
>
>> > If a port is considered dangerous like wireshark was it
>> > is removed to avoid encouraging it but users can still build it of
>> > course.  
>> 
>> There's a problem with *not* having it in ports too, if people do compile
>> it for themselves, considering how long the damn thing takes to build it's
>> highly likely that they won't update it as often as if there were packages...
>> 
>> And it's less bad now than it used to be - they don't do proper privilege
>> separation like OpenBSD's tcpdump does, but at least it's now just the
>> network capture part that runs as root, the packet dissectors now run as
>> a normal uid.
>
> I thought it was the sheer number of parsing bugs, wouldn't dumpcap
> suid have sorted that or have they built it in more finely and did
> doing that just bring other insecurities?

It used to be that, in order to run live captures, you had to run the
whole thing as root. Totally unsafe.

Following the dumpcap split, the dissectors (which are still dangerous
and untrustworthy) are run as a normal user. This is better than it used
to be, though still not great; looking at the release notes for pretty
much every version of wireshark ever released will show a number of
security-related bugs in this area, this is difficult code to get right
and is obviously handling untrusted data, and I think many users would
run it as their normal user account. But then one could also say that
about your average web browser..

Compare with the model used by OpenBSD's tcpdump - the dissectors are
run in a child process, chrooted in an empty unwritable directory.
(tcpdump.org's version is not as strong; they can chroot/drop privs,
however this is done in a single process).

Re: PF rule for transparent siproxd ?

[Christophe]

Hi Simon,

Le 07/04/2014 20:20, Simon Perreault a écrit :
> I don't know the direct answer to your question, but taking a step back...
> 
> Any reason you want a transparent SIP proxy rather than an
> explicitly-configured SIP B2BUA? The latter is usually much easier to
> set up and maintain.
> 

SIP B2BUA can be interesting, thanks for the advice ;).

But in this case, there is already several devices configured.
(different types, and different SIP providers).

If we can avoid reconfiguring all the devices ... ;) .

Christophe.

Re: PF rule for transparent siproxd ?

[Christophe]

Hi Stuart,

Le 08/04/2014 10:41, Stuart Henderson a écrit :
> On 2014-04-07, Christophe  wrote:
>> The goal is to accept every SIP device from inside the LAN to register
>> to SIP provider without any "outbound proxy" configuration, and let
>> siproxd acting as a masquerading server.
> 
> Do you really need it? Most user-facing SIP providers run SBCs to work
> around NAT problems (amongst other things) and either don't need, or
> work better without, SIP NAT helpers.
> 

As you say : most , but not all ... and we have to deal with :( .

Cisco routers (2600 and 800 series) are able to handle this : only
public IP address are seen in SIP packets on external network interface,
without configuring anything in "internal SIP devices" (IPBX or phones).

That's why I try to get a similar behavior using a transparent SIP proxy.

Don't know if it's the best way to do, but from what I know of SIP
protocol and NAT issues, I found it was a nice solution to handle all
cases with minimum configuration (or reconfiguration) ;).


Christophe.

Re: sudo -u & environment help

[Andres Perera]

On Fri, Apr 4, 2014 at 6:00 AM, Craig R. Skinner
 wrote:
> Hi,
>
> When sudo'ing to another user, how can I obtain all of their environment
> settings as they receive when logging in themselves?
>
> When I use sudo in this manner, settings such as $PATH, $MAIL & umask
> aren't being honoured:

[...]

You do that with `sudo -c - -l`:

$ { ulimit -a; env; } > ea
$ sudo -c - -i 'ulimit -a; env' > eb
$ diff -u ea e
--- ea Tue Apr  8 07:13:11 2014
+++ eb Tue Apr  8 07:14:22 2014
@@ -1,29 +1,24 @@
 time(cpu-seconds)unlimited
 file(blocks) unlimited
 coredump(blocks) unlimited
-data(kbytes) 524288
-stack(kbytes)4096
+data(kbytes) 33554432
+stack(kbytes)8192
 lockedmem(kbytes)2667916
 memory(kbytes)   7984356
-nofiles(descriptors) 512
-processes128
+nofiles(descriptors) 128
+processes1310
 _=/usr/bin/env
+USERNAME=root
 XAUTHORITY=/home/a/.Xauthority
-LOGNAME=a
-WINDOWID=10485773
-WINDOWPATH=5
-XTERM_SHELL=/usr/bin/tmux
-HOME=/home/a
-PWD=/home/a
-XTERM_VERSION=XTerm/OpenBSD(301)
+LOGNAME=root
+HOME=/root
+SUDO_GID=1000
 DISPLAY=:0
+SUDO_COMMAND=/bin/ksh -c ulimit -a; env
+SUDO_USER=a
+SUDO_UID=1000
 MAIL=/var/mail/a
-PATH=/home/a/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin:/usr/games:.
-TMUX=/tmp/tmux-1000/default,3104,0
-PAGER=less
-TMUX_PANE=%2
-TERM=screen
+PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/sbin:/usr/local/bin
 SHELL=/bin/ksh
-DBUS_SESSION_BUS_ADDRESS=unix:path=/tmp/dbus-8X6HB7BfTU,guid=b24ea188864417630554661f5343d7bf
-USER=a
-XTERM_LOCALE=C
+TERM=screen
+USER=root

Also see `use_loginclass` in sudoers(5).

Re: Only two holes in a heck of a long time, but why?

[Mihai Popescu]

So, Martin, what is your point ?

Re: sudo -u & environment help

[Andres Perera]

On Tue, Apr 8, 2014 at 7:17 AM, Andres Perera  wrote:
> On Fri, Apr 4, 2014 at 6:00 AM, Craig R. Skinner
>  wrote:
>> Hi,
>>
>> When sudo'ing to another user, how can I obtain all of their environment
>> settings as they receive when logging in themselves?
>>
>> When I use sudo in this manner, settings such as $PATH, $MAIL & umask
>> aren't being honoured:
>
> [...]
>
> You do that with `sudo -c - -l`:
>
> $ { ulimit -a; env; } > ea
> $ sudo -c - -i 'ulimit -a; env' > eb
> $ diff -u ea e
> --- ea Tue Apr  8 07:13:11 2014
> +++ eb Tue Apr  8 07:14:22 2014
> @@ -1,29 +1,24 @@
>  time(cpu-seconds)unlimited
>  file(blocks) unlimited
>  coredump(blocks) unlimited
> -data(kbytes) 524288
> -stack(kbytes)4096
> +data(kbytes) 33554432
> +stack(kbytes)8192
>  lockedmem(kbytes)2667916
>  memory(kbytes)   7984356
> -nofiles(descriptors) 512
> -processes128
> +nofiles(descriptors) 128
> +processes1310
>  _=/usr/bin/env
> +USERNAME=root
>  XAUTHORITY=/home/a/.Xauthority
> -LOGNAME=a
> -WINDOWID=10485773
> -WINDOWPATH=5
> -XTERM_SHELL=/usr/bin/tmux
> -HOME=/home/a
> -PWD=/home/a
> -XTERM_VERSION=XTerm/OpenBSD(301)
> +LOGNAME=root
> +HOME=/root
> +SUDO_GID=1000
>  DISPLAY=:0
> +SUDO_COMMAND=/bin/ksh -c ulimit -a; env
> +SUDO_USER=a
> +SUDO_UID=1000
>  MAIL=/var/mail/a

^ the fact that $MAIL is preserved is a bug according to sudo(8),
section ``Command Environment'':

  As a special case, if sudo's -i option (initial login) is specified, sudo
  will initialize the environment regardless of the value of env_reset.
  The DISPLAY, PATH and TERM variables remain unchanged; HOME, MAIL, SHELL,
  USER, and LOGNAME are set based on the target user.

As shown, $MAIL doesn't correspond to the target user, which in this
invocation would be root.

> -PATH=/home/a/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin:/usr/games:.
> -TMUX=/tmp/tmux-1000/default,3104,0
> -PAGER=less
> -TMUX_PANE=%2
> -TERM=screen
> +PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/sbin:/usr/local/bin
>  SHELL=/bin/ksh
> -DBUS_SESSION_BUS_ADDRESS=unix:path=/tmp/dbus-8X6HB7BfTU,guid=b24ea188864417630554661f5343d7bf
> -USER=a
> -XTERM_LOCALE=C
> +TERM=screen
> +USER=root
>
> Also see `use_loginclass` in sudoers(5).

Re: sudo -u & environment help

[Craig R. Skinner]

On 2014-04-08 Tue 07:17 AM |, Andres Perera wrote:
> 
> You do that with `sudo -c - -l`:
> 
> $ sudo -c - -i 'ulimit -a; env' > eb
> $ diff -u ea e
> --- ea Tue Apr  8 07:13:11 2014
> +++ eb Tue Apr  8 07:14:22 2014
> @@ -1,29 +1,24 @@
> -LOGNAME=a
> +LOGNAME=root
> 
> Also see `use_loginclass` in sudoers(5).
> 

Unfortunately Andres, that doesn't work here for non-root:

$ userinfo $LOGNAME | fgrep class
class   staff
^
$ echo $LOGNAME; echo $PATH; echo $MAIL; umask
craig
/usr/bin:/bin:/usr/sbin:.../usr/site/bin:/usr/site/sbin:/home/craig/bin
/var/mail/craig
027

$ userinfo david | fgrep class
class
$ sudo -c - -i -u david
$ userinfo $LOGNAME | fgrep class
class
^
$ echo $LOGNAME; echo $PATH; echo $MAIL; umask
david
/usr/bin:/bin:/usr/sbin:.../usr/site/bin:/usr/site/sbin:/home/craig/bin
  ^
/var/mail/craig
  ^
027
  ^

$ exit
$ fgrep use_loginclass /etc/sudoers
Defaults always_set_home, ignore_dot, use_loginclass

$ login david
Password:
$ echo $LOGNAME; echo $PATH; echo $MAIL; umask
david
/usr/bin:/bin:/usr/local/bin:/usr/site/bin:/home/david/bin
 ^
/var/mail/david
  ^
022
  ^
$ /usr/sbin/userinfo $LOGNAME | fgrep class
class
^




/etc/login.conf:
...
...
default:\
:path=/usr/bin /bin /usr/local/bin /usr/site/bin ~/bin:\
:umask=022:\
:datasize
 
staff:\
:path=/usr/bin /bin /usr/sbin /sbin /usr/local/bin /usr/local/sbin 
/usr/site/bin /usr/site/sbin ~/bin:\
:umask=027:\
:ignorenologin:\
:datasize...


$ sudo -c default -i -u david
sudo: only root can use -c default


>From what I'm seeing, "sudo -iu username" isn't setting
$PATH, $MAIL & umask, as set by login/su -l, rather than shell dotfiles.

Re: No USB devices recognized (HP box, 5.4-stable)

[Neil Hughes]

On 02/02/14 07:39, howard eisenberger wrote:


I just got back to this and, to be fair, with Debian Linux USB pen
drive is detected, but not USB/IDE external laptop drive with APIC
enabled or disabled in BIOS. The same external drive with the same
USB/IDE adapter is detected and works with 5.4 on a couple of other
machines with different USB chips.

So, it looks like both Linux and OpenBSD have a problem with the
ATI SB400 USB.


I ended up disabling the onboard USB and adding a NEC USB PCI
card, which seems to work fine with OpenBSD 5.4


SorryI missed both your replies and to be honest haven't spent much 
more time looking into this. Thanks for confirming the problem with this 
particular USB hardware. FreeBSD 10 appears to have the same issue.

Re: PF rule for transparent siproxd ?

[Stuart Henderson]

On 2014-04-08, Christophe  wrote:
> Hi Stuart,
>
> Le 08/04/2014 10:41, Stuart Henderson a écrit :
>> On 2014-04-07, Christophe  wrote:
>>> The goal is to accept every SIP device from inside the LAN to register
>>> to SIP provider without any "outbound proxy" configuration, and let
>>> siproxd acting as a masquerading server.
>> 
>> Do you really need it? Most user-facing SIP providers run SBCs to work
>> around NAT problems (amongst other things) and either don't need, or
>> work better without, SIP NAT helpers.
>> 
>
> As you say : most , but not all ... and we have to deal with :( .
>
> Cisco routers (2600 and 800 series) are able to handle this : only
> public IP address are seen in SIP packets on external network interface,
> without configuring anything in "internal SIP devices" (IPBX or phones).
>
> That's why I try to get a similar behavior using a transparent SIP proxy.
>
> Don't know if it's the best way to do, but from what I know of SIP
> protocol and NAT issues, I found it was a nice solution to handle all
> cases with minimum configuration (or reconfiguration) ;).

First diagnosis step with many ITSPs is to disable any such proxies...

Re: PF rule for transparent siproxd ?

[Stuart Henderson]

On 2014-04-07, Christophe  wrote:
[..]

Let's ignore the siproxd side of things and just look at the ruleset.

>> set skip on lo
>> set loginterface pflog0
>> 
>> block in on ! lo0 proto tcp to port 6000:6010
>> 
>> match out log on em0 inet from 172.18.160.0/24 to any nat-to em0
>> 
>> pass in on em1 inet proto tcp from 172.18.160/24 to any port { 80, 443 } 
>> keep state
>> pass in on em1 inet proto icmp from 172.18.160.0/24 to any keep state
>> 
>> pass in on em0 inet proto tcp from any to em0 port 22 keep state 
>> pass in on em0 inet proto icmp from any to em0 keep state 
>> 
>> # Here is the rule I try to use .
>> pass in log on em1 inet proto udp from 172.18.160.0/24 to any port 5060 
>> divert-to 172.18.160.252 port 5060 
>> 
>> pass in on em0 inet proto udp from any to em0 port 5060 keep state
>> pass in on em0 inet proto udp from any to em0 port 17030:17080 keep state

You have no "pass" or "block" rules for any outbound traffic so the implicit
default is used for outbound traffic - this is "pass all no state" - I would
start the ruleset with an explicit "block" and then perhaps "pass out" if
that's what you want.

OpenSSL heartbleed ?

[Jack Woehr]

http://www.itnews.com.au/News/382068,serious-openssl-bug-renders-websites-wide-open.aspx

accurate w/r/t 5.3?

--
Jack Woehr   # "We commonly say we have no time when,
Box 51, Golden CO 80402  #  of course, we have all that there is."
http://www.softwoehr.com # - James Mason, _The Art of Chess_, 1905

Re: PF rule for transparent siproxd ?

[Christophe]

Hi Stuart,

Le 08/04/2014 18:31, Stuart Henderson a écrit :
> On 2014-04-07, Christophe  wrote:
> [..]
> 
> Let's ignore the siproxd side of things and just look at the ruleset.
> 
> You have no "pass" or "block" rules for any outbound traffic so the implicit
> default is used for outbound traffic - this is "pass all no state" - I would
> start the ruleset with an explicit "block" and then perhaps "pass out" if
> that's what you want.
> 

Oops, true ! I made a `grep -v` mistake ... Sorry :( .

Here is the real ruleset, that effectively contains block and pass
"default" rules.

> set skip on lo
> set loginterface pflog0
> 
> block in log 
> pass out   
> 
> block in on ! lo0 proto tcp to port 6000:6010
>
> match out log on em0 inet from 172.18.160.0/24 to any nat-to em0
> 
> pass in on em1 inet proto tcp from 172.18.160/24 to any port { 80, 443 } keep 
> state
> pass in on em1 inet proto icmp from 172.18.160.0/24 to any keep state
> 
> pass in on em0 inet proto tcp from any to em0 port 22 keep state 
> pass in on em0 inet proto icmp from any to em0 keep state 
> 
> pass in log on em1 inet proto udp from 172.18.160.0/24 to any port 5060 
> divert-to 172.18.160.253 port 5060  
> 
> pass in on em0 inet proto udp from any to em0 port 5060 keep state
> pass in on em0 inet proto udp from any to em0 port 17030:17080 keep state



Regards,
Christophe.

heartbleed ssl bug and ports or packages question

[Didier Wiroth]

Hello,
I'm not a developer but more of an openbsd hobbyist.
I'm using current with current packages that are a few days old.

I patched my openbsd servers and revoked all my ssl keys, generated
new ones and changed every possible password.
Even though, as far as I understood, you can't be sure credentials
have not been read out of memory and your system has not been
compromised at some point in the past.
Anyway, I had a look at the following patch and was reading the comments:

and came across this line:
"Also recompile any statically-linked binaries depending on it"

F.ex. I use dovecot:
# ldd `which dovecot`
/usr/local/sbin/dovecot:
StartEnd  Type Open Ref GrpRef Name
04f81c50 04f81c913000 exe  10   0  /usr/local/sbin/dovecot
04fa2152c000 04fa219f4000 rlib 01   0
/usr/local/lib/dovecot/libdovecot.so.2.0
04fa1d89 04fa1dd7d000 rlib 01   0  /usr/lib/libc.so.74.0
04fa275a7000 04fa27aa4000 rlib 01   0
/usr/local/lib/libiconv.so.6.0
04fa2bb0 04fa2bb0 rtld 01   0  /usr/libexec/ld.so

The following library is not listed: /usr/lib/libssl.so.20.0
So I guess ssl was statically compiled in the dovecot package/port, as
dovecot supports ssl and I currently use it.

Is it possible to track which ports or packages have statically
compiled in ssl support?

Do I need to recompile/rebuild the port with the patched libssl library?
or better ... but slower:
Do I need to recompile every ports to be sure the bug can't be
exploited on my openbsd systems?

Thank you very much!
Kind regards,
Didier

Re: OpenSSL heartbleed ?

[Josh Grosse]

On 2014-04-08 13:19, Jack Woehr wrote:

http://www.itnews.com.au/News/382068,serious-openssl-bug-renders-websites-wide-open.aspx

accurate w/r/t 5.3?


Jack,

Please read: http://www.openbsd.org/errata53.html and note item #14.  
You may download

the patch from there or for your convenience:

http://ftp.openbsd.org/pub/OpenBSD/patches/5.3/common/014_openssl.patch

You may also want to read the article published by the OpenBSD Journal:

http://undeadly.org/cgi?action=article&sid=20140408063423

Re: OpenSSL heartbleed ?

[Ted Unangst]

On Tue, Apr 08, 2014 at 11:19, Jack Woehr wrote:
> http://www.itnews.com.au/News/382068,serious-openssl-bug-renders-websites-wide-open.aspx
> 
> 
> accurate w/r/t 5.3?
> 

5.3, 5.4, and 5.5 are all affected. only 5.2 and earlier are not.

FYA: http://heartbleed.com/

[nobody]

OpenBSD 5.3 (OpenSSL 1.0.1c 10 May 2012) and 5.4 (OpenSSL 1.0.1c 10 May
2012)

how surprising..

but doesn't ASLR suppose to protect from this?

http://undeadly.org/cgi?action=article&sid=20140408063423

Re: OpenSSL heartbleed ?

[LCD 47]

On 8 April 2014, Jack Woehr  wrote:
> http://www.itnews.com.au/News/382068,serious-openssl-bug-renders-websites-wide-open.aspx
> 
> accurate w/r/t 5.3?

A few popular testers:

https://github.com/titanous/heartbleeder
https://github.com/FiloSottile/Heartbleed
http://filippo.io/Heartbleed/
https://www.ssllabs.com/ssltest/index.html
http://possible.lv/tools/hb/

/lcd

"not configured" components on Dell C5220 / C6220

[Donovan Watteau]

Hello,

We'd like to deploy OpenBSD on some Dell C5220 and Dell C6220 servers,
for a high-traffic website.

However, the C5220 has some unconfigured components in dmesg [1], and
the C6220 has even more of them [2].

Are they crucial for the machines to operate accurately?  By 'accurately',
I mean we need them to compute and send stuff on the wire, while remaining
stable, with a high load of work and traffic.

Thanks for your help,
Donovan.

[1]:
OpenBSD 5.5 (GENERIC.MP) #315: Wed Mar  5 09:37:46 MST 2014
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 33506557952 (31954MB)
avail mem = 32606011392 (31095MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xebe40 (46 entries)
bios0: vendor Dell Inc. version "2.1.0" date 07/30/2013
bios0: Dell Inc. PowerEdge C5220
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S5
acpi0: tables DSDT FACP APIC MCFG HPET SSDT PRAD SPMI SSDT SSDT SSDT SSDT SPCR 
BGRT
acpi0: wakeup devices PCIB(S3) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) 
USB6(S3) USB7(S3) PEGP(S3) PEG0(S3) PEG1(S3) PEG2(S3) PEG3(S3) GLAN(S3) 
EHC1(S3) EHC2(S3) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) CPU E3-1220 V2 @ 3.10GHz, 3093.41 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1.0, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Xeon(R) CPU E3-1220 V2 @ 3.10GHz, 3092.98 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Xeon(R) CPU E3-1220 V2 @ 3.10GHz, 3092.98 MHz
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Xeon(R) CPU E3-1220 V2 @ 3.10GHz, 3092.98 MHz
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 3 (PCIB)
acpiprt2 at acpi0: bus 1 (PEG0)
acpiprt3 at acpi0: bus 2 (PEG1)
acpiprt4 at acpi0: bus -1 (PEG2)
acpiprt5 at acpi0: bus -1 (PEG3)
acpiec0 at acpi0: Failed to read resource settings
acpicpu0 at acpi0: PSS
acpicpu1 at acpi0: PSS
acpicpu2 at acpi0: PSS
acpicpu3 at acpi0: PSS
acpipwrres0 at acpi0: FN00, resource for FAN0
acpipwrres1 at acpi0: FN01, resource for FAN1
acpipwrres2 at acpi0: FN02, resource for FAN2
acpipwrres3 at acpi0: FN03, resource for FAN3
acpipwrres4 at acpi0: FN04, resource for FAN4
acpitz0 at acpi0: critical temperature is 106 degC
acpitz1 at acpi0: critical temperature is 106 degC
acpibat0 at acpi0: BAT0 not present
acpibat1 at acpi0: BAT1 not present
acpibat2 at acpi0: BAT2 not present
acpibtn0 at acpi0: PWRB
acpibtn1 at acpi0: LID0
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD02
ipmi at mainbus0 not configured
cpu0: Enhanced SpeedStep 3093 MHz: speeds: 3101, 3100 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Xeon E3-1200 v2 Host" rev 0x09
ppb0 at pci0 dev 1 function 0 "Intel Core 3G PCIE" rev 0x09: msi
pci1 at ppb0 bus 1
ppb1 at pci0 dev 1 function 1 "Intel Core 3G PCIE" rev 0x09: msi
pci2 at ppb1 bus 2
em0 at pci2 dev 0 function 0 "Intel 82580" rev 0x01: msi, address XXX
em1 at pci2 dev 0 function 1 "Intel 82580" rev 0x01: msi, address XXX
"Intel 6 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured
vendor "Intel", unknown product 0x1c3b (class communications subclass 
miscellaneous, rev 0x04) at pci0 dev 22 function 1 not

Re: FYA: http://heartbleed.com/

[nobody]

"read overrun, so ASLR won't save you"

-> any pro-active thoughts to prevent this in the future? (I'm not a
programmer, so.. pardon if my question is idiotic)

Thanks!


On Tue, Apr 8, 2014 at 7:34 PM, nobody wrote:

> OpenBSD 5.3 (OpenSSL 1.0.1c 10 May 2012) and 5.4 (OpenSSL 1.0.1c 10 May
> 2012)
>
> how surprising..
>
> but doesn't ASLR suppose to protect from this?
>
> http://undeadly.org/cgi?action=article&sid=20140408063423

Re: heartbleed ssl bug and ports or packages question

[Stefan Sperling]

On Tue, Apr 08, 2014 at 07:26:06PM +0200, Didier Wiroth wrote:
> F.ex. I use dovecot:
> # ldd `which dovecot`
> /usr/local/sbin/dovecot:
> StartEnd  Type Open Ref GrpRef Name
> 04f81c50 04f81c913000 exe  10   0  /usr/local/sbin/dovecot
> 04fa2152c000 04fa219f4000 rlib 01   0
> /usr/local/lib/dovecot/libdovecot.so.2.0
> 04fa1d89 04fa1dd7d000 rlib 01   0  /usr/lib/libc.so.74.0
> 04fa275a7000 04fa27aa4000 rlib 01   0
> /usr/local/lib/libiconv.so.6.0
> 04fa2bb0 04fa2bb0 rtld 01   0  /usr/libexec/ld.so
> 
> The following library is not listed: /usr/lib/libssl.so.20.0
> So I guess ssl was statically compiled in the dovecot package/port, as
> dovecot supports ssl and I currently use it.

Dovecot is composed of several programs.
The program which uses SSL is the imap-login program:

$ ldd /usr/local/libexec/dovecot/imap-login 
   
/usr/local/libexec/dovecot/imap-login:
StartEnd  Type Open Ref GrpRef Name
02f7ecf0 02f7ed307000 exe  10   0  
/usr/local/libexec/dovecot/imap-login
02f9f4a02000 02f9f4e1d000 rlib 01   0  
/usr/local/lib/dovecot/libdovecot-login.so.2.0
02f9ee22b000 02f9ee6fc000 rlib 02   0  
/usr/local/lib/dovecot/libdovecot.so.2.0
02f9f5789000 02f9f5c72000 rlib 01   0  
/usr/lib/libc.so.73.1
02f9f6bae000 02f9f700c000 rlib 01   0  
/usr/lib/libssl.so.20.0
02f9f8e8b000 02f9f9445000 rlib 01   0  
/usr/lib/libcrypto.so.23.0
02f9ed10 02f9ed5fe000 rlib 01   0  
/usr/local/lib/libiconv.so.6.0
02f9f250 02f9f250 rtld 01   0  
/usr/libexec/ld.so

> Do I need to recompile/rebuild the port with the patched libssl library?

No. You only need to restart your dovecot server after the upgrade.

Re: heartbleed ssl bug and ports or packages question

[Jérémie Courrèges-Anglas]

Didier Wiroth  writes:

> Hello,
> I'm not a developer but more of an openbsd hobbyist.
> I'm using current with current packages that are a few days old.
>
> I patched my openbsd servers and revoked all my ssl keys, generated
> new ones and changed every possible password.
> Even though, as far as I understood, you can't be sure credentials
> have not been read out of memory and your system has not been
> compromised at some point in the past.
> Anyway, I had a look at the following patch and was reading the comments:
> 
> and came across this line:
> "Also recompile any statically-linked binaries depending on it"
>
> F.ex. I use dovecot:
> # ldd `which dovecot`
> /usr/local/sbin/dovecot:
> StartEnd  Type Open Ref GrpRef Name
> 04f81c50 04f81c913000 exe  10   0  /usr/local/sbin/dovecot
> 04fa2152c000 04fa219f4000 rlib 01   0
> /usr/local/lib/dovecot/libdovecot.so.2.0
> 04fa1d89 04fa1dd7d000 rlib 01   0  /usr/lib/libc.so.74.0
> 04fa275a7000 04fa27aa4000 rlib 01   0
> /usr/local/lib/libiconv.so.6.0
> 04fa2bb0 04fa2bb0 rtld 01   0  /usr/libexec/ld.so
>
> The following library is not listed: /usr/lib/libssl.so.20.0
> So I guess ssl was statically compiled in the dovecot package/port, as
> dovecot supports ssl and I currently use it.

/usr/local/sbin/dovecot is not the listener facing the network.

ldd /usr/local/libexec/dovecot/imap-login

> Is it possible to track which ports or packages have statically
> compiled in ssl support?

I can't think of a reliable way to do this.  I doubt there are many of
such ports.

> Do I need to recompile/rebuild the port with the patched libssl library?
> or better ... but slower:
> Do I need to recompile every ports to be sure the bug can't be
> exploited on my openbsd systems?

Your call.  Note that dpb makes it easy.

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Re: heartbleed ssl bug and ports or packages question

[Didier Wiroth]

Ok, thank you very much!
Didier

On 8 April 2014 19:44, Stefan Sperling  wrote:
> On Tue, Apr 08, 2014 at 07:26:06PM +0200, Didier Wiroth wrote:
>> F.ex. I use dovecot:
>> # ldd `which dovecot`
>> /usr/local/sbin/dovecot:
>> StartEnd  Type Open Ref GrpRef Name
>> 04f81c50 04f81c913000 exe  10   0  
>> /usr/local/sbin/dovecot
>> 04fa2152c000 04fa219f4000 rlib 01   0
>> /usr/local/lib/dovecot/libdovecot.so.2.0
>> 04fa1d89 04fa1dd7d000 rlib 01   0  /usr/lib/libc.so.74.0
>> 04fa275a7000 04fa27aa4000 rlib 01   0
>> /usr/local/lib/libiconv.so.6.0
>> 04fa2bb0 04fa2bb0 rtld 01   0  /usr/libexec/ld.so
>>
>> The following library is not listed: /usr/lib/libssl.so.20.0
>> So I guess ssl was statically compiled in the dovecot package/port, as
>> dovecot supports ssl and I currently use it.
>
> Dovecot is composed of several programs.
> The program which uses SSL is the imap-login program:
>
> $ ldd /usr/local/libexec/dovecot/imap-login
> /usr/local/libexec/dovecot/imap-login:
> StartEnd  Type Open Ref GrpRef Name
> 02f7ecf0 02f7ed307000 exe  10   0  
> /usr/local/libexec/dovecot/imap-login
> 02f9f4a02000 02f9f4e1d000 rlib 01   0  
> /usr/local/lib/dovecot/libdovecot-login.so.2.0
> 02f9ee22b000 02f9ee6fc000 rlib 02   0  
> /usr/local/lib/dovecot/libdovecot.so.2.0
> 02f9f5789000 02f9f5c72000 rlib 01   0  
> /usr/lib/libc.so.73.1
> 02f9f6bae000 02f9f700c000 rlib 01   0  
> /usr/lib/libssl.so.20.0
> 02f9f8e8b000 02f9f9445000 rlib 01   0  
> /usr/lib/libcrypto.so.23.0
> 02f9ed10 02f9ed5fe000 rlib 01   0  
> /usr/local/lib/libiconv.so.6.0
> 02f9f250 02f9f250 rtld 01   0  
> /usr/libexec/ld.so
>
>> Do I need to recompile/rebuild the port with the patched libssl library?
>
> No. You only need to restart your dovecot server after the upgrade.



-- 
Didier Wiroth

Re: OpenSSL heartbleed ?

[Jack Woehr]

Josh Grosse wrote:


Please read: http://www.openbsd.org/errata53.html and note item #14.  You may 
download
the patch from there or for your convenience:

http://ftp.openbsd.org/pub/OpenBSD/patches/5.3/common/014_openssl.patch

You may also want to read the article published by the OpenBSD Journal:

http://undeadly.org/cgi?action=article&sid=20140408063423


Thanks for the update. Should have read the errata list first. I'm getting old 
and slow.


--
Jack Woehr   # "We commonly say we have no time when,
Box 51, Golden CO 80402  #  of course, we have all that there is."
http://www.softwoehr.com # - James Mason, _The Art of Chess_, 1905

Re: heartbleed ssl bug and ports or packages question

[Matthew Weigel]

You should at least be able to know which of your packages have access to an 
SSL private key, and speak SSL.

You also need to recursively check each library dovecot links to... That 
libdovecot looks like a likely candidate for linking ssl.so.

That said, For dovecot, I THINK it uses dlopen at runtime to load ssl.so. You 
might try fstat on a running dovecot process that talks SSL.
-- 
 Matthew Weigel


> On Apr 8, 2014, at 12:26 PM, Didier Wiroth  wrote:
> 
> Hello,
> I'm not a developer but more of an openbsd hobbyist.
> I'm using current with current packages that are a few days old.
> 
> I patched my openbsd servers and revoked all my ssl keys, generated
> new ones and changed every possible password.
> Even though, as far as I understood, you can't be sure credentials
> have not been read out of memory and your system has not been
> compromised at some point in the past.
> Anyway, I had a look at the following patch and was reading the comments:
> 
> and came across this line:
> "Also recompile any statically-linked binaries depending on it"
> 
> F.ex. I use dovecot:
> # ldd `which dovecot`
> /usr/local/sbin/dovecot:
> StartEnd  Type Open Ref GrpRef Name
> 04f81c50 04f81c913000 exe  10   0  /usr/local/sbin/dovecot
> 04fa2152c000 04fa219f4000 rlib 01   0
> /usr/local/lib/dovecot/libdovecot.so.2.0
> 04fa1d89 04fa1dd7d000 rlib 01   0  /usr/lib/libc.so.74.0
> 04fa275a7000 04fa27aa4000 rlib 01   0
> /usr/local/lib/libiconv.so.6.0
> 04fa2bb0 04fa2bb0 rtld 01   0  /usr/libexec/ld.so
> 
> The following library is not listed: /usr/lib/libssl.so.20.0
> So I guess ssl was statically compiled in the dovecot package/port, as
> dovecot supports ssl and I currently use it.
> 
> Is it possible to track which ports or packages have statically
> compiled in ssl support?
> 
> Do I need to recompile/rebuild the port with the patched libssl library?
> or better ... but slower:
> Do I need to recompile every ports to be sure the bug can't be
> exploited on my openbsd systems?
> 
> Thank you very much!
> Kind regards,
> Didier

Re: FYA: http://heartbleed.com/

[Mike Small]

nobody  writes:

> "read overrun, so ASLR won't save you"

What if malloc's "G" option were turned on? You know, assuming the
subset of the worlds' programs you use is good enough to run with that.

Re: FYA: http://heartbleed.com/

[Ted Unangst]

On Tue, Apr 08, 2014 at 15:09, Mike Small wrote:
> nobody  writes:
> 
>> "read overrun, so ASLR won't save you"
> 
> What if malloc's "G" option were turned on? You know, assuming the
> subset of the worlds' programs you use is good enough to run with that.

No. OpenSSL has exploit mitigation countermeasures to make sure it's
exploitable.

Re: FYA: http://heartbleed.com/

[Theo de Raadt]

> On Tue, Apr 08, 2014 at 15:09, Mike Small wrote:
> > nobody  writes:
> > 
> >> "read overrun, so ASLR won't save you"
> > 
> > What if malloc's "G" option were turned on? You know, assuming the
> > subset of the worlds' programs you use is good enough to run with that.
> 
> No. OpenSSL has exploit mitigation countermeasures to make sure it's
> exploitable.

What Ted is saying may sound like a joke...

So years ago we added exploit mitigations counter measures to libc
malloc and mmap, so that a variety of bugs can be exposed.  Such
memory accesses will cause an immediate crash, or even a core dump,
then the bug can be analyed, and fixed forever.

Some other debugging toolkits get them too.  To a large extent these
come with almost no performance cost.

But around that time OpenSSL adds a wrapper around malloc & free so
that the library will cache memory on it's own, and not free it to the
protective malloc.

You can find the comment in their sources ...

#ifndef OPENSSL_NO_BUF_FREELISTS
 /* On some platforms, malloc() performance is bad enough that you can't just


OH, because SOME platforms have slow performance, it means even if you
build protective technology into malloc() and free(), it will be
ineffective.  On ALL PLATFORMS, because that option is the default,
and Ted's tests show you can't turn it off because they haven't tested
without it in ages.

So then a bug shows up which leaks the content of memory mishandled by
that layer.  If the memoory had been properly returned via free, it
would likely have been handed to munmap, and triggered a daemon crash
instead of leaking your keys.

OpenSSL is not developed by a responsible team.

Re: rss2email feed header field missing

[Peter Kane]

Seems to be fixed in the 7 April snapshot.

Thanks, Peter

Virtual firewalls with OpenBSD and PF

[Wiesław Kielas]

Hi misc@,

I'm trying to achieve something similar to Cisco's firewall contexts or
Juniper's virtual systems with PF and OpenBSD.

Currently I run an OpenBSD box as a firewalling device for multiple
environments, most of them independent of each other. My main problem
with this arrangement is that when I make a mistake modifying the
ruleset, all of the environments are affected.

Mistakes I've made include:
- Fatfingering and disabling PF completely on a machine
- Fatfingering and loading an empty ruleset
- Creating block rules that catch legitimate traffic
- Putting rules in wrong order completely changing their behavior

I'd love to be in a situation when I (or any of my colleagues for that
matter) make any of the mistakes mentioned above the impact for other
environments (those which rules weren't modified) is minimal.

The best I've came up with so far is using anchors with matching,
keeping all rules for environments separate, for example:
> anchor ENV_APP1 on $app1_if from $app1_net
> anchor ENV_APP2 on $app2_if from $app2_net
and modifying the rules per anchor at a time.

This brings the problem of restricting access to things like "pfctl -d".
First I've thought about using securelevel=2, hoping that you can
manipulate anchors when it's active, but unfortunately it doesn't work
that way.

Another idea is to forfeit using the root account and work entirely
though sudo, giving my account access to "pfctl -a" and "pfctl -sr" only.

The obvious thing to do, meaning splitting the firewall into separate
physical/virtual machines isn't something I'd want to consider for
multiple reasons, including the actual cost of buying new hardware.

Do you have any ideas on how to approach the problem of logical
separation of rules? I'd greatly appreciate any help and tips ;-)

--
regards,

Wiesław Kielas

[demime 1.01d removed an attachment of type application/pgp-signature which had 
a name of signature.asc]

feature patch -> replace /etc/crontab by /etc/cron.d/

[Remy]

Hi guys,

here is a simple patch to replace /etc/crontab by /etc/cron.d/.
You need to manually mkdir /etc/cron.d.


--- pathnames_original.hMon Apr  7 22:31:53 2014
+++ pathnames.h Tue Apr  8 16:12:30 2014
@@ -92,8 +92,8 @@
 #define PIDFILE"cron.pid"
 #define _PATH_CRON_PID PIDDIR PIDFILE

-   /* 4.3BSD-style crontab */
-#define SYSCRONTAB "/etc/crontab"
+   /* system crontab dir */
+#define SYSCRON_DIR"/etc/cron.d"

/* what editor to use if no EDITOR or VISUAL
 * environment variable specified.
@@ -42,30 +42,31 @@

Debug(DLOAD, ("[%ld] load_database()\n", (long)getpid()))

-   /* before we start loading any data, do a stat on SPOOL_DIR
-* so that if anything changes as of this moment (i.e., before 
we've

-* cached any of the database), we'll see the changes next time.
+   /* before we start loading any data, do a stat on SPOOL_DIR and
+* SYSCRON_DIR so that if anything changes as of this moment
+* (i.e., before we've cached any of the database), we'll see
+* the changes next time.
 */
if (stat(SPOOL_DIR, &statbuf) < OK) {
log_it("CRON", getpid(), "STAT FAILED", SPOOL_DIR);
return;
}

-   /* track system crontab file
-*/
-   if (stat(SYSCRONTAB, &syscron_stat) < OK)
-   syscron_stat.st_mtime = 0;
+   if (stat(SYSCRON_DIR, &syscron_stat) < OK) {
+   log_it("CRON", getpid(), "STAT FAILED", SYSCRON_DIR);
+   return;
+   }

-   /* if spooldir's mtime has not changed, we don't need to fiddle 
with

-* the database.
+   /* if spooldir's and syscrondir's mtime has not changed, we 
don't

+* need to fiddle with the database.
 *
 * Note that old_db->mtime is initialized to 0 in main(), and
 * so is guaranteed to be different than the stat() mtime the 
first

 * time this function is called.
 */
if (old_db->mtime == HASH(statbuf.st_mtime, 
syscron_stat.st_mtime)) {
-   Debug(DLOAD, ("[%ld] spool dir mtime unch, no load 
needed.\n",

- (long)getpid()))
+   Debug(DLOAD, ("[%ld] spool dirs mtime unch, no load 
needed.\n",

+   (long)getpid()))
return;
}

@@ -77,28 +78,45 @@
new_db.mtime = HASH(statbuf.st_mtime, syscron_stat.st_mtime);
new_db.head = new_db.tail = NULL;

-   if (syscron_stat.st_mtime) {
-   process_crontab(ROOT_USER, NULL, SYSCRONTAB, 
&syscron_stat,

-   &new_db, old_db);
-   }
-
/* we used to keep this dir open all the time, for the sake of
 * efficiency.  however, we need to close it in every fork, and
 * we fork a lot more often than the mtime of the dir changes.
 */
-   if (!(dir = opendir(SPOOL_DIR))) {
-   log_it("CRON", getpid(), "OPENDIR FAILED", SPOOL_DIR);
+   if (!(dir = opendir(SYSCRON_DIR))) {
+   log_it("CRON", getpid(), "OPENDIR FAILED", SYSCRON_DIR);
return;
}

-   while (NULL != (dp = readdir(dir))) {
-   char fname[MAXNAMLEN+1], tabname[MAXNAMLEN];
+   char fname[MAXNAMLEN+1], tabname[MAXNAMLEN];

+   while (NULL != (dp = readdir(dir))) {
/* avoid file names beginning with ".".  this is good
 * because we would otherwise waste two guaranteed calls
 * to getpwnam() for . and .., and also because user 
names
 * starting with a period are just too nasty to 
consider.

 */
+   if (dp->d_name[0] == '.')
+   continue;
+
+   if (strlcpy(fname, dp->d_name, sizeof fname) >= sizeof 
fname)

+   continue;   /* XXX log? */
+
+   if (snprintf(tabname, sizeof tabname, "%s/%s", 
SYSCRON_DIR,

+   fname) >= sizeof(tabname))
+   continue;   /* XXX log? */
+
+   process_crontab(ROOT_USER, NULL, tabname, &syscron_stat,
+   &new_db, old_db);
+   }
+
+   closedir(dir);
+
+   if (!(dir = opendir(SPOOL_DIR))) {
+   log_it("CRON", getpid(), "OPENDIR FAILED", SPOOL_DIR);
+   return;
+   }
+
+   while (NULL != (dp = readdir(dir))) {
if (dp->d_name[0] == '.')
continue;


--- cron_original.8 Mon Apr  7 22:31:53 2014
+++ cron.8  Tue Apr  8 16:12:30 2014
@@ -71,9 +71,8 @@
 commands.
 Additionally,
 .Nm
-checks the modification time on the system crontab file
-.Pq Pa /etc/crontab ,
-the crontab spool
+checks the modification time on the crontab spool dirs
+.Pq Pa /etc/cron.d,
 .Pq Pa /var/cron/tabs ,
 and the at spool
 .Pq Pa /var/cron/atjobs
@@ -187,8 +186,8 @@
 .El
 

Re: feature patch -> replace /etc/crontab by /etc/cron.d/

[Theo de Raadt]

In your dreams.


> here is a simple patch to replace /etc/crontab by /etc/cron.d/.
> You need to manually mkdir /etc/cron.d.
> 
> 
> --- pathnames_original.hMon Apr  7 22:31:53 2014
> +++ pathnames.h Tue Apr  8 16:12:30 2014
> @@ -92,8 +92,8 @@
>   #define PIDFILE"cron.pid"
>   #define _PATH_CRON_PID PIDDIR PIDFILE
> 
> -   /* 4.3BSD-style crontab */
> -#define SYSCRONTAB "/etc/crontab"
> +   /* system crontab dir */
> +#define SYSCRON_DIR"/etc/cron.d"
> 
>  /* what editor to use if no EDITOR or VISUAL
>   * environment variable specified.
> @@ -42,30 +42,31 @@
> 
>  Debug(DLOAD, ("[%ld] load_database()\n", (long)getpid()))
> 
> -   /* before we start loading any data, do a stat on SPOOL_DIR
> -* so that if anything changes as of this moment (i.e., before 
> we've
> -* cached any of the database), we'll see the changes next time.
> +   /* before we start loading any data, do a stat on SPOOL_DIR and
> +* SYSCRON_DIR so that if anything changes as of this moment
> +* (i.e., before we've cached any of the database), we'll see
> +* the changes next time.
>   */
>  if (stat(SPOOL_DIR, &statbuf) < OK) {
>  log_it("CRON", getpid(), "STAT FAILED", SPOOL_DIR);
>  return;
>  }
> 
> -   /* track system crontab file
> -*/
> -   if (stat(SYSCRONTAB, &syscron_stat) < OK)
> -   syscron_stat.st_mtime = 0;
> +   if (stat(SYSCRON_DIR, &syscron_stat) < OK) {
> +   log_it("CRON", getpid(), "STAT FAILED", SYSCRON_DIR);
> +   return;
> +   }
> 
> -   /* if spooldir's mtime has not changed, we don't need to fiddle 
> with
> -* the database.
> +   /* if spooldir's and syscrondir's mtime has not changed, we 
> don't
> +* need to fiddle with the database.
>   *
>   * Note that old_db->mtime is initialized to 0 in main(), and
>   * so is guaranteed to be different than the stat() mtime the 
> first
>   * time this function is called.
>   */
>  if (old_db->mtime == HASH(statbuf.st_mtime, 
> syscron_stat.st_mtime)) {
> -   Debug(DLOAD, ("[%ld] spool dir mtime unch, no load 
> needed.\n",
> - (long)getpid()))
> +   Debug(DLOAD, ("[%ld] spool dirs mtime unch, no load 
> needed.\n",
> +   (long)getpid()))
>  return;
>  }
> 
> @@ -77,28 +78,45 @@
>  new_db.mtime = HASH(statbuf.st_mtime, syscron_stat.st_mtime);
>  new_db.head = new_db.tail = NULL;
> 
> -   if (syscron_stat.st_mtime) {
> -   process_crontab(ROOT_USER, NULL, SYSCRONTAB, 
> &syscron_stat,
> -   &new_db, old_db);
> -   }
> -
>  /* we used to keep this dir open all the time, for the sake of
>   * efficiency.  however, we need to close it in every fork, and
>   * we fork a lot more often than the mtime of the dir changes.
>   */
> -   if (!(dir = opendir(SPOOL_DIR))) {
> -   log_it("CRON", getpid(), "OPENDIR FAILED", SPOOL_DIR);
> +   if (!(dir = opendir(SYSCRON_DIR))) {
> +   log_it("CRON", getpid(), "OPENDIR FAILED", SYSCRON_DIR);
>  return;
>  }
> 
> -   while (NULL != (dp = readdir(dir))) {
> -   char fname[MAXNAMLEN+1], tabname[MAXNAMLEN];
> +   char fname[MAXNAMLEN+1], tabname[MAXNAMLEN];
> 
> +   while (NULL != (dp = readdir(dir))) {
>  /* avoid file names beginning with ".".  this is good
>   * because we would otherwise waste two guaranteed calls
>   * to getpwnam() for . and .., and also because user 
> names
>   * starting with a period are just too nasty to 
> consider.
>   */
> +   if (dp->d_name[0] == '.')
> +   continue;
> +
> +   if (strlcpy(fname, dp->d_name, sizeof fname) >= sizeof 
> fname)
> +   continue;   /* XXX log? */
> +
> +   if (snprintf(tabname, sizeof tabname, "%s/%s", 
> SYSCRON_DIR,
> +   fname) >= sizeof(tabname))
> +   continue;   /* XXX log? */
> +
> +   process_crontab(ROOT_USER, NULL, tabname, &syscron_stat,
> +   &new_db, old_db);
> +   }
> +
> +   closedir(dir);
> +
> +   if (!(dir = opendir(SPOOL_DIR))) {
> +   log_it("CRON", getpid(), "OPENDIR FAILED", SPOOL_DIR);
> +   return;
> +   }
> +
> +   while (NULL != (dp = readdir(dir))) {
>  if (dp->d_name[0] == '.')
>  continue;
> 
> 
> --- cron_original.8 Mon Apr  7 22:31:53 2014
> +++ cron.8  Tue Apr  8 16:12:30 2014
> @@ -71,9 +71,8 @@
>   comma

Android 4.4 and L2TP/IPSEC VPN

[Kaya Saman]

Hi,

I'm wondering if anyone has had any experience with VPN and Android 4.4??

I used to use OpenVPN with versions 4.1 through 4.3 however, 4.4 
apparently broke the tun interface so the app doesn't work now.

As I need vpn access I configured ipsec and npppd however, I keep 
getting these errors when trying to establish connection:

responder_recv_HASH_SA_NONCE: peer proposed invalid phase 2 IDs: 
initiator id 2.2.2.2, responder id 1.1.1.1

dropped message from 2.2.2.2 port 500 due to notification type 
INVALID_ID_INFORMATION




On the Droid I setup L2TP/IPsec PSK

with server address and IPSec PSK; and my npppd credentials.


The config I have is standard:

ipsec.conf:

ike passive esp transport \
 proto udp from any to any port 1701  \
 main auth "hmac-sha1" enc "aes" group modp1024 \
 quick auth "hmac-sha1" enc "aes" \
 psk "some_key"


npppd.conf:

# $OpenBSD: npppd.conf,v 1.2 2014/03/22 04:32:39 yasuoka Exp $
# sample npppd configuration file.  see npppd.conf(5)

authentication LOCAL type local {
 users-file "/etc/npppd/npppd-users"
}
#authentication RADIUS type radius {
#   authentication-server {
#   address 192.168.0.1 secret "hogehoge"
#   }
#   accounting-server {
#   address 192.168.0.1 secret "hogehoge"
#   }
#}

tunnel L2TP protocol l2tp {
 listen on 0.0.0.0
 listen on ::
}

ipcp IPCP {
 pool-address 
 dns-servers 
}

# I elected to go with Tun interface over Pipex

# use tun(4) interface.  multiple ppp sessions concentrate one interface.
interface tun1  address  ipcp IPCP
bind tunnel from L2TP authenticated by LOCAL to tun1

/etc/hostname.tun1
up


Looking through the @Misc archive I found a similar issue:

http://permalink.gmane.org/gmane.os.openbsd.misc/202338

which also incorporates (I assume) working config; very similar to my own.


My version of OpenBSD is: 5.5 GENERIC.MP#50 amd64 (Current as of a few 
days ago)


The Phase 2 ID issues usually happen when the devices remote and local 
IP addresses aren't what the system is expecting however, I have 
configured this to "any".

I do recall a separate issue I had when configuring IPSEC/GRE 
site-to-site tunnel with Cisco's where I had to specifically set:

ike esp from 0.0.0.0/0 to 0.0.0.0/0 peer 

and then configure hostname.greX accordingly.


Even using the Pipex interface:

#interface pppx0 address  ipcp IPCP
#bind tunnel from L2TP authenticated by LOCAL to pppx0


as a test I still get the same error of Invalid Phase 2 ID's.

I have analyzed /var/log/messages which gives above output, and in 
addition done a tcpdump -eni (IF) -vvv host (IP) to see what was going 
on but found nothing substantial


npppd output:

npppd[10593]: l2tpd ctrl=9 logtype=Started RecvSCCRQ 
from=2.2.2.2:46783/udp tunnel_id=9/30318 protocol=1.0 winsize=1 
hostname=anonymous vendor=(no vendorname) firm=

npppd[10593]: l2tpd ctrl=9 timeout waiting ack for ctrl packets.

npppd[10593]: l2tpd ctrl=9 logtype=Finished


Could this be a bug with Android 4.4 or is it simply something 
misconfigured on my behalf?

...oh and my handset is rooted so I don't know if that makes a difference?


Thanks.


Kaya

Re: smokeping errors on OpenBSD 5.4

[Thorleif Wiik [BCIX]]

Hi there,

here the requested output. The machine was just installed a few days ago
with 5.4  and smokeping was added with pkg_add.

>ldconfig -r | head -2

/var/run/ld.so.hints:

search directories: /usr/lib:/usr/local/lib

>env LD_DEBUG=1 smokeping --help

rtld loading: '/usr/bin/perl'

exe load offset:  0x129a7070

 flags /usr/bin/perl = 0x0

head /usr/bin/perl

obj /usr/bin/perl has /usr/bin/perl as head

examining: '/usr/bin/perl'

loading: libperl.so.13.0 required by /usr/bin/perl

 flags /usr/lib/libperl.so.13.0 = 0x0

obj /usr/lib/libperl.so.13.0 has /usr/bin/perl as head

loading: libc.so.69.0 required by /usr/bin/perl

 flags /usr/lib/libc.so.69.0 = 0x0

obj /usr/lib/libc.so.69.0 has /usr/bin/perl as head

loading: libpthread.so.17.3 required by /usr/bin/perl

 flags /usr/lib/libpthread.so.17.3 = 0x68

obj /usr/lib/libpthread.so.17.3 has /usr/bin/perl as head

loading: libutil.so.11.5 required by /usr/bin/perl

 flags /usr/lib/libutil.so.11.5 = 0x0

obj /usr/lib/libutil.so.11.5 has /usr/bin/perl as head

loading: libm.so.8.0 required by /usr/bin/perl

 flags /usr/lib/libm.so.8.0 = 0x0

obj /usr/lib/libm.so.8.0 has /usr/bin/perl as head

objname /usr/lib/libpthread.so.17.3 is nodelete

linking dep /usr/lib/libpthread.so.17.3 as child of /usr/bin/perl

linking dep /usr/lib/libperl.so.13.0 as child of /usr/bin/perl

linking dep /usr/lib/libm.so.8.0 as child of /usr/bin/perl

linking dep /usr/lib/libutil.so.11.5 as child of /usr/bin/perl

linking dep /usr/lib/libc.so.69.0 as child of /usr/bin/perl

examining: '/usr/lib/libpthread.so.17.3'

examining: '/usr/lib/libperl.so.13.0'

examining: '/usr/lib/libm.so.8.0'

examining: '/usr/lib/libutil.so.11.5'

examining: '/usr/lib/libc.so.69.0'

 flags /usr/libexec/ld.so = 0x0

obj /usr/libexec/ld.so has /usr/bin/perl as head

relocation took 0.001106

StartEnd  Type Open Ref GrpRef Name

129a7070 129a70b02000 exe  10   0  /usr/bin/perl

129c722aa000 129c726bb000 rlib 02   0
/usr/lib/libpthread.so.17.3

129c7e253000 129c7e7bf000 rlib 01   0
/usr/lib/libperl.so.13.0

129c7278f000 129c72bb7000 rlib 01   0
/usr/lib/libm.so.8.0

129c7c84b000 129c7cc56000 rlib 01   0
/usr/lib/libutil.so.11.5

129c79211000 129c796fa000 rlib 01   0
/usr/lib/libc.so.69.0

129c78e0 129c78e0 rtld 01   0
/usr/libexec/ld.so

symcache lookups 1231 hits 0 ratio 0% hits

dynamic loading done, success.

doing ctors obj 0x129c77829080 @0x129c722aeb50:
[/usr/lib/libpthread.so.17.3]

doing ctors obj 0x129c71695080 @0x129c7e284230: [/usr/lib/libperl.so.13.0]

doing ctors obj 0x129c76c3e080 @0x129c72793700: [/usr/lib/libm.so.8.0]

doing ctors obj 0x129c74e98080 @0x129c7c84e750: [/usr/lib/libutil.so.11.5]

doing ctors obj 0x129c736af080 @0x129c79230dd0: [/usr/lib/libc.so.69.0]

entry point: 0x129a70701140

dlctl: _dl_thread_fnc set to 0x129c722b0d30

dlctl: _dl_bind_lock_f set to 0x129c722b0630

dlopen: loading: /usr/libdata/perl5/amd64-openbsd/5.16.3/auto/Cwd/Cwd.so

 flags /usr/libdata/perl5/amd64-openbsd/5.16.3/auto/Cwd/Cwd.so = 0x0

head /usr/libdata/perl5/amd64-openbsd/5.16.3/auto/Cwd/Cwd.so

obj /usr/libdata/perl5/amd64-openbsd/5.16.3/auto/Cwd/Cwd.so has
/usr/libdata/perl5/amd64-openbsd/5.16.3/auto/Cwd/Cwd.so as head

linking /usr/libdata/perl5/amd64-openbsd/5.16.3/auto/Cwd/Cwd.so as
dlopen()ed

head [/usr/libdata/perl5/amd64-openbsd/5.16.3/auto/Cwd/Cwd.so]

examining: '/usr/libdata/perl5/amd64-openbsd/5.16.3/auto/Cwd/Cwd.so'

tail /usr/libdata/perl5/amd64-openbsd/5.16.3/auto/Cwd/Cwd.so

doing ctors obj 0x129c72cb6048 @0x129c74ea1160:
[/usr/libdata/perl5/amd64-openbsd/5.16.3/auto/Cwd/Cwd.so]

dlopen: /usr/libdata/perl5/amd64-openbsd/5.16.3/auto/Cwd/Cwd.so: done
(success).

dlsym: boot_Cwd in /usr/libdata/perl5/amd64-openbsd/5.16.3/auto/Cwd/Cwd.so:
0x129c74ea1450

dlopen: loading:
/usr/libdata/perl5/amd64-openbsd/5.16.3/auto/Encode/Encode.so

 flags /usr/libdata/perl5/amd64-openbsd/5.16.3/auto/Encode/Encode.so = 0x0

head /usr/libdata/perl5/amd64-openbsd/5.16.3/auto/Encode/Encode.so

obj /usr/libdata/perl5/amd64-openbsd/5.16.3/auto/Encode/Encode.so has
/usr/libdata/perl5/amd64-openbsd/5.16.3/auto/Encode/Encode.so as head

linking /usr/libdata/perl5/amd64-openbsd/5.16.3/auto/Encode/Encode.so as
dlopen()ed

head [/usr/libdata/perl5/amd64-openbsd/5.16.3/auto/Encode/Encode.so]

examining: '/usr/libdata/perl5/amd64-openbsd/5.16.3/auto/Encode/Encode.so'

tail /usr/libdata/perl5/amd64-openbsd/5.16.3/auto/Encode/Encode.so

doing ctors obj 0x129c7e80d048 @0x129c808f2250:
[/usr/libdata/perl5/amd64-openbsd/5.16.3/auto/Encode/Encode.so]

dlopen: /usr/libdata/perl5/amd64-openbsd/5.16.3/auto/Encode/Encode.so: done
(success).

dlsym: boot_Encode in
/usr/libdata/perl5/amd64-openbsd/5.16.3/auto/Encode/Encode.so:
0x129c808f6300

dlopen: loading:
/usr/libdata/perl5/amd64-openbsd/5.16.3/auto/Digest/MD5/MD5.so

 flags

ypldap

[Friedrich Locke]

Dear list members,

i have just configured my system (yp) to retrive information on groups and
users. It's working 100% ok.

Now, i would like to set some netgroups. How does netgroup works with
ypldap ?

Thanks.

fried.

Re: Virtual firewalls with OpenBSD and PF

[Daniel Melameth]

On Tue, Apr 8, 2014 at 12:47 PM, Wiesław Kielas
 wrote:
> I'm trying to achieve something similar to Cisco's firewall contexts or
> Juniper's virtual systems with PF and OpenBSD.
>
> Currently I run an OpenBSD box as a firewalling device for multiple
> environments, most of them independent of each other. My main problem
> with this arrangement is that when I make a mistake modifying the
> ruleset, all of the environments are affected.
>
> Mistakes I've made include:
> - Fatfingering and disabling PF completely on a machine
> - Fatfingering and loading an empty ruleset
> - Creating block rules that catch legitimate traffic
> - Putting rules in wrong order completely changing their behavior
>
> I'd love to be in a situation when I (or any of my colleagues for that
> matter) make any of the mistakes mentioned above the impact for other
> environments (those which rules weren't modified) is minimal.
>
> The best I've came up with so far is using anchors with matching,
> keeping all rules for environments separate, for example:
>> anchor ENV_APP1 on $app1_if from $app1_net
>> anchor ENV_APP2 on $app2_if from $app2_net
> and modifying the rules per anchor at a time.
>
> This brings the problem of restricting access to things like "pfctl -d".
> First I've thought about using securelevel=2, hoping that you can
> manipulate anchors when it's active, but unfortunately it doesn't work
> that way.
>
> Another idea is to forfeit using the root account and work entirely
> though sudo, giving my account access to "pfctl -a" and "pfctl -sr" only.
>
> The obvious thing to do, meaning splitting the firewall into separate
> physical/virtual machines isn't something I'd want to consider for
> multiple reasons, including the actual cost of buying new hardware.
>
> Do you have any ideas on how to approach the problem of logical
> separation of rules? I'd greatly appreciate any help and tips ;-)

While I don't have this requirement now, I might have in the future so
I'm interested in hearing what others are doing here.  That said, the
only thing I have to add is you might want investigate the use of
rdomains and/or rtlabels.

Re: feature patch -> replace /etc/crontab by /etc/cron.d/

[Dag Richards]

No Theo I don't think understand, if you accept the patch then you will 
be more like Ubuntu and other MODERN operating systems.


Why put everything in a single easily readable file, when you can split 
it up in to multiple directories.


Which reminds me when are you going to ditch /etc for a nice registry 
data base.




Theo de Raadt wrote:

In your dreams.



here is a simple patch to replace /etc/crontab by /etc/cron.d/.
You need to manually mkdir /etc/cron.d.


--- pathnames_original.hMon Apr  7 22:31:53 2014
+++ pathnames.h Tue Apr  8 16:12:30 2014
@@ -92,8 +92,8 @@
  #define PIDFILE"cron.pid"
  #define _PATH_CRON_PID PIDDIR PIDFILE

-   /* 4.3BSD-style crontab */
-#define SYSCRONTAB "/etc/crontab"
+   /* system crontab dir */
+#define SYSCRON_DIR"/etc/cron.d"

 /* what editor to use if no EDITOR or VISUAL
  * environment variable specified.
@@ -42,30 +42,31 @@

 Debug(DLOAD, ("[%ld] load_database()\n", (long)getpid()))

-   /* before we start loading any data, do a stat on SPOOL_DIR
-* so that if anything changes as of this moment (i.e., before 
we've

-* cached any of the database), we'll see the changes next time.
+   /* before we start loading any data, do a stat on SPOOL_DIR and
+* SYSCRON_DIR so that if anything changes as of this moment
+* (i.e., before we've cached any of the database), we'll see
+* the changes next time.
  */
 if (stat(SPOOL_DIR, &statbuf) < OK) {
 log_it("CRON", getpid(), "STAT FAILED", SPOOL_DIR);
 return;
 }

-   /* track system crontab file
-*/
-   if (stat(SYSCRONTAB, &syscron_stat) < OK)
-   syscron_stat.st_mtime = 0;
+   if (stat(SYSCRON_DIR, &syscron_stat) < OK) {
+   log_it("CRON", getpid(), "STAT FAILED", SYSCRON_DIR);
+   return;
+   }

-   /* if spooldir's mtime has not changed, we don't need to fiddle 
with

-* the database.
+   /* if spooldir's and syscrondir's mtime has not changed, we 
don't

+* need to fiddle with the database.
  *
  * Note that old_db->mtime is initialized to 0 in main(), and
  * so is guaranteed to be different than the stat() mtime the 
first

  * time this function is called.
  */
 if (old_db->mtime == HASH(statbuf.st_mtime, 
syscron_stat.st_mtime)) {
-   Debug(DLOAD, ("[%ld] spool dir mtime unch, no load 
needed.\n",

- (long)getpid()))
+   Debug(DLOAD, ("[%ld] spool dirs mtime unch, no load 
needed.\n",

+   (long)getpid()))
 return;
 }

@@ -77,28 +78,45 @@
 new_db.mtime = HASH(statbuf.st_mtime, syscron_stat.st_mtime);
 new_db.head = new_db.tail = NULL;

-   if (syscron_stat.st_mtime) {
-   process_crontab(ROOT_USER, NULL, SYSCRONTAB, 
&syscron_stat,

-   &new_db, old_db);
-   }
-
 /* we used to keep this dir open all the time, for the sake of
  * efficiency.  however, we need to close it in every fork, and
  * we fork a lot more often than the mtime of the dir changes.
  */
-   if (!(dir = opendir(SPOOL_DIR))) {
-   log_it("CRON", getpid(), "OPENDIR FAILED", SPOOL_DIR);
+   if (!(dir = opendir(SYSCRON_DIR))) {
+   log_it("CRON", getpid(), "OPENDIR FAILED", SYSCRON_DIR);
 return;
 }

-   while (NULL != (dp = readdir(dir))) {
-   char fname[MAXNAMLEN+1], tabname[MAXNAMLEN];
+   char fname[MAXNAMLEN+1], tabname[MAXNAMLEN];

+   while (NULL != (dp = readdir(dir))) {
 /* avoid file names beginning with ".".  this is good
  * because we would otherwise waste two guaranteed calls
  * to getpwnam() for . and .., and also because user 
names
  * starting with a period are just too nasty to 
consider.

  */
+   if (dp->d_name[0] == '.')
+   continue;
+
+   if (strlcpy(fname, dp->d_name, sizeof fname) >= sizeof 
fname)

+   continue;   /* XXX log? */
+
+   if (snprintf(tabname, sizeof tabname, "%s/%s", 
SYSCRON_DIR,

+   fname) >= sizeof(tabname))
+   continue;   /* XXX log? */
+
+   process_crontab(ROOT_USER, NULL, tabname, &syscron_stat,
+   &new_db, old_db);
+   }
+
+   closedir(dir);
+
+   if (!(dir = opendir(SPOOL_DIR))) {
+   log_it("CRON", getpid(), "OPENDIR FAILED", SPOOL_DIR);
+   return;
+   }
+
+   while (NULL != (dp = readdir(dir))) {
 if (dp->d_name[0] == '.')
 continue;


--- cron_original.8 

Re: smokeping errors on OpenBSD 5.4

[Philip Guenther]

On Tue, Apr 8, 2014 at 2:35 PM, Thorleif Wiik [BCIX]
 wrote:
> here the requested output. The machine was just installed a few days ago
> with 5.4  and smokeping was added with pkg_add.
...
> examining: '/usr/local/lib/librrd.so.3.0'
> loading: libfreetype.so.20.0 required by /usr/local/lib/librrd.so.3.0
> dlopen: failed to open libfreetype.so.20.0

You didn't install the xbase set when you installed 5.4, but smokeping
depends on rrdtool which does graphics processing using libfreetype,
which is in xbase.

So install xbase.

In the mean time, how did you manage to install rrdtool when you
system is missing libfreetype?  pkg_add should have complained about
that and refused to install it.  Which -D option did you use?


Philip Guenther

Re: smokeping errors on OpenBSD 5.4

[Stuart Henderson]

On 2014-04-08, Thorleif Wiik [BCIX]  wrote:
> Hi there,
>
> here the requested output. The machine was just installed a few days ago
> with 5.4  and smokeping was added with pkg_add.

OK - this matches my guess. You must have untarred xbase on
the system after installing the OS (perhaps after trying to
install smokeping and it failing due to missing X libraries?) and
haven't rebooted since then. Please follow the instructions in
http://www.openbsd.org/faq/faq4.html#AddFileSet.

Re: Virtual firewalls with OpenBSD and PF

[Andy Lemin]

Hi Wiesław,

Definitely support your desire to try to add more structure to your PF writing! 
:)

We use git to version control PF and many other files (over 60 files across an 
OBSD system now come to think of it).

For PF, I wouldn't recommend using anchors as I *think* their slower and 
restricted in terms of options. You also want to be using tables if you want 
performance.

Anyway, we wanted to create some structure too but opted for, instead of being 
too clever just using care and attention, always using 2 firewalls (running 
carp), and following PF's own 'skip steps' to define how we break our rules 
into different well defined groups within the PF file.
Of course within the skip step group ordering you can also add whatever other 
rules you like. E.g. We always say rules with the higher QoS go above other 
rules within the same rule group.

Doesn't make a difference in terms of actual QoS performance, it's just makes 
it easier for someone to come along and see where their new rule needs to be 
inserted, if their is a clear guideline to follow (which we leave commented in 
the pf file for reminders).

If anyone has a clever way of managing it I'd be interested but simple 
guidelines seem to work well enough.

PS; cannot encourage enough the benefits of two firewalls, honestly (esp if 
your sharing the management). It makes it so much easier to make a change to a 
backup firewall, switch to it gracefully, and check all is ok. then git pull 
your new PF on the previous firewall once your happy you don't have to roll 
back quickly.

You won't loose any states or break any connections created by a previous a 
ruleset as pfsync will keep you happy. If new connections are failing on the 
new ruleset just switch back. Barely anyone will notice a thing if your quick 
about spotting a fatfinger issue.

Cheers, Andy


Sent from my iPhone

> On 8 Apr 2014, at 19:47, Wiesław Kielas  wrote:
> 
> Wiesław

Re: Virtual firewalls with OpenBSD and PF

[Claudio Jeker]

On Tue, Apr 08, 2014 at 03:39:54PM -0600, Daniel Melameth wrote:
> On Tue, Apr 8, 2014 at 12:47 PM, Wies??aw Kielas
>  wrote:
> > I'm trying to achieve something similar to Cisco's firewall contexts or
> > Juniper's virtual systems with PF and OpenBSD.
> >
> > Currently I run an OpenBSD box as a firewalling device for multiple
> > environments, most of them independent of each other. My main problem
> > with this arrangement is that when I make a mistake modifying the
> > ruleset, all of the environments are affected.
> >
> > Mistakes I've made include:
> > - Fatfingering and disabling PF completely on a machine
> > - Fatfingering and loading an empty ruleset
> > - Creating block rules that catch legitimate traffic
> > - Putting rules in wrong order completely changing their behavior
> >
> > I'd love to be in a situation when I (or any of my colleagues for that
> > matter) make any of the mistakes mentioned above the impact for other
> > environments (those which rules weren't modified) is minimal.
> >
> > The best I've came up with so far is using anchors with matching,
> > keeping all rules for environments separate, for example:
> >> anchor ENV_APP1 on $app1_if from $app1_net
> >> anchor ENV_APP2 on $app2_if from $app2_net
> > and modifying the rules per anchor at a time.
> >
> > This brings the problem of restricting access to things like "pfctl -d".
> > First I've thought about using securelevel=2, hoping that you can
> > manipulate anchors when it's active, but unfortunately it doesn't work
> > that way.
> >
> > Another idea is to forfeit using the root account and work entirely
> > though sudo, giving my account access to "pfctl -a" and "pfctl -sr" only.
> >
> > The obvious thing to do, meaning splitting the firewall into separate
> > physical/virtual machines isn't something I'd want to consider for
> > multiple reasons, including the actual cost of buying new hardware.
> >
> > Do you have any ideas on how to approach the problem of logical
> > separation of rules? I'd greatly appreciate any help and tips ;-)
> 
> While I don't have this requirement now, I might have in the future so
> I'm interested in hearing what others are doing here.  That said, the
> only thing I have to add is you might want investigate the use of
> rdomains and/or rtlabels.
> 

I think you may want to use anchors with rdomain. Then you can map one
rdomain to one anchor and doing so the rule files in the anchors are no
longer influencing each other. Using rdomains will have other
side-effects (you may need to set rtable in a match or pass rule).
I think there are still ways how one anchor could cause issues in another
one. You may need to limit the available commands per anchor but this is
outside of the scope of pf.

-- 
:wq Claudio

Re: feature patch -> replace /etc/crontab by /etc/cron.d/

[Nick Holland]

On 04/08/14 16:35, Remy wrote:
> Hi guys,
> 
> here is a simple patch to replace /etc/crontab by /etc/cron.d/.
> You need to manually mkdir /etc/cron.d.
> 

um. eight days late.  I look forward to your contribution next year, but
try to hit the right date next time.

Nick.

Re: Virtual firewalls with OpenBSD and PF

[Giancarlo Razzolini]

Em 08-04-2014 19:13, Andy Lemin escreveu:
> Hi Wiesław,
>
> Definitely support your desire to try to add more structure to your PF 
> writing! :)
>
> We use git to version control PF and many other files (over 60 files across 
> an OBSD system now come to think of it).
>
> For PF, I wouldn't recommend using anchors as I *think* their slower and 
> restricted in terms of options. You also want to be using tables if you want 
> performance.
>
> Anyway, we wanted to create some structure too but opted for, instead of 
> being too clever just using care and attention, always using 2 firewalls 
> (running carp), and following PF's own 'skip steps' to define how we break 
> our rules into different well defined groups within the PF file.
> Of course within the skip step group ordering you can also add whatever other 
> rules you like. E.g. We always say rules with the higher QoS go above other 
> rules within the same rule group.
>
> Doesn't make a difference in terms of actual QoS performance, it's just makes 
> it easier for someone to come along and see where their new rule needs to be 
> inserted, if their is a clear guideline to follow (which we leave commented 
> in the pf file for reminders).
>
> If anyone has a clever way of managing it I'd be interested but simple 
> guidelines seem to work well enough.
>
> PS; cannot encourage enough the benefits of two firewalls, honestly (esp if 
> your sharing the management). It makes it so much easier to make a change to 
> a backup firewall, switch to it gracefully, and check all is ok. then git 
> pull your new PF on the previous firewall once your happy you don't have to 
> roll back quickly.
>
> You won't loose any states or break any connections created by a previous a 
> ruleset as pfsync will keep you happy. If new connections are failing on the 
> new ruleset just switch back. Barely anyone will notice a thing if your quick 
> about spotting a fatfinger issue.
>
> Cheers, Andy
>
>
> Sent from my iPhone
>
>> On 8 Apr 2014, at 19:47, Wiesław Kielas  wrote:
>>
>> Wiesław
Hi,

I find it very useful using a very simple script I created that:
1) Opens up /etc/pf.conf using whatever editor is in $EDITOR
2) After you save it, it uses pfctl -nf to check pf.conf syntax
3) If you made a mistake, it warns you and re-opens the file for
editing. If everything is ok it exits cleanly.

Of course the script above won't help with rules that are right in
its syntax, but are passing or blocking traffic they were not meant to.
I found empirically that the majority of the mistakes are in pf's
syntax. When you make a wrong rule you'll either detect it right away,
for instance, a block rule that blocks the wrong traffic or you will not
detect it for a long time. Also, even when detecting an unexpected
behavior, it might be hard to pinpoint where it is in you pf
configuration. I had to use tags many times to discover that the
combination of 3 or more rules was causing the unexpected behavior.

Now, I believe that as many others pointed the combination of
rdomains with pf is the way to go. Not perfect but close to what you
want to accomplish.

Cheers,

-- 
Giancarlo Razzolini
GPG: 4096R/77B981BC

Re: feature patch -> replace /etc/crontab by /etc/cron.d/

[czarkoff]

Remy said:
> here is a simple patch to replace /etc/crontab by /etc/cron.d/.

FWIW why?

-- 
Dmitrij D. Czarkoff

Re: OpenSSL heartbleed ?

[consultor]

On 04/08/2014 10:31 AM, Ted Unangst wrote:

On Tue, Apr 08, 2014 at 11:19, Jack Woehr wrote:

http://www.itnews.com.au/News/382068,serious-openssl-bug-renders-websites-wide-open.aspx


accurate w/r/t 5.3?


5.3, 5.4, and 5.5 are all affected. only 5.2 and earlier are not.



Hello Ted, are you saying that 5.5 is going to go out affected on May?

thanks.

Re: OpenSSL heartbleed ?

[Brad Smith]

On 08/04/14 6:53 PM, consultor wrote:

On 04/08/2014 10:31 AM, Ted Unangst wrote:

On Tue, Apr 08, 2014 at 11:19, Jack Woehr wrote:

http://www.itnews.com.au/News/382068,serious-openssl-bug-renders-websites-wide-open.aspx



accurate w/r/t 5.3?


5.3, 5.4, and 5.5 are all affected. only 5.2 and earlier are not.



Hello Ted, are you saying that 5.5 is going to go out affected on May?


Yes, it is way too late to do anything about it now.


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: OpenSSL heartbleed ?

[John D. Verne]

On Tue, Apr 08, 2014 at 03:53:06PM -0700, consultor wrote:
> On 04/08/2014 10:31 AM, Ted Unangst wrote:
> >On Tue, Apr 08, 2014 at 11:19, Jack Woehr wrote:
> >>http://www.itnews.com.au/News/382068,serious-openssl-bug-renders-websites-wide-open.aspx
> >>
> >>
> >>accurate w/r/t 5.3?
> >>
> >5.3, 5.4, and 5.5 are all affected. only 5.2 and earlier are not.
> >
> 
> Hello Ted, are you saying that 5.5 is going to go out affected on May?
> 
http://www.openbsd.org/errata55.html shows a 5.5 patch.

Re: feature patch -> replace /etc/crontab by /etc/cron.d/

[sven falempin]

Look what linux are accepting now : stuff like systemd, how modern ! and so
nicely done !

Maybe having a .d looks .damned cool but does it really solve something ?

New is not better, modern surely isn't.

If there is a way for OpenBSD to move to a cron.d  it probably needs a nice
explanation :
 - problems to be solved
 - why is it the best way to solved it
 - what other solution has been discarded and why.
 - (and does the gain of the change worth the work of the change)

PS:
If you install a software that require recurrent task it should be done
with a user with specific priviledge , so set up a crontab for this user.


Geez don't you have a TLS server to patch !

On Tue, Apr 8, 2014 at 4:59 PM, Dag Richards wrote:

> No Theo I don't think understand, if you accept the patch then you will be
> more like Ubuntu and other MODERN operating systems.
>
> Why put everything in a single easily readable file, when you can split it
> up in to multiple directories.
>
> Which reminds me when are you going to ditch /etc for a nice registry data
> base.
>
>
>
>
> Theo de Raadt wrote:
>
>> In your dreams.
>>
>>
>>  here is a simple patch to replace /etc/crontab by /etc/cron.d/.
>>> You need to manually mkdir /etc/cron.d.
>>>
>>>
>>> --- pathnames_original.hMon Apr  7 22:31:53 2014
>>> +++ pathnames.h Tue Apr  8 16:12:30 2014
>>> @@ -92,8 +92,8 @@
>>>   #define PIDFILE"cron.pid"
>>>   #define _PATH_CRON_PID PIDDIR PIDFILE
>>>
>>> -   /* 4.3BSD-style crontab */
>>> -#define SYSCRONTAB "/etc/crontab"
>>> +   /* system crontab dir */
>>> +#define SYSCRON_DIR"/etc/cron.d"
>>>
>>>  /* what editor to use if no EDITOR or VISUAL
>>>   * environment variable specified.
>>> @@ -42,30 +42,31 @@
>>>
>>>  Debug(DLOAD, ("[%ld] load_database()\n", (long)getpid()))
>>>
>>> -   /* before we start loading any data, do a stat on SPOOL_DIR
>>> -* so that if anything changes as of this moment (i.e., before
>>> we've
>>> -* cached any of the database), we'll see the changes next time.
>>> +   /* before we start loading any data, do a stat on SPOOL_DIR and
>>> +* SYSCRON_DIR so that if anything changes as of this moment
>>> +* (i.e., before we've cached any of the database), we'll see
>>> +* the changes next time.
>>>   */
>>>  if (stat(SPOOL_DIR, &statbuf) < OK) {
>>>  log_it("CRON", getpid(), "STAT FAILED", SPOOL_DIR);
>>>  return;
>>>  }
>>>
>>> -   /* track system crontab file
>>> -*/
>>> -   if (stat(SYSCRONTAB, &syscron_stat) < OK)
>>> -   syscron_stat.st_mtime = 0;
>>> +   if (stat(SYSCRON_DIR, &syscron_stat) < OK) {
>>> +   log_it("CRON", getpid(), "STAT FAILED", SYSCRON_DIR);
>>> +   return;
>>> +   }
>>>
>>> -   /* if spooldir's mtime has not changed, we don't need to fiddle
>>> with
>>> -* the database.
>>> +   /* if spooldir's and syscrondir's mtime has not changed, we don't
>>> +* need to fiddle with the database.
>>>   *
>>>   * Note that old_db->mtime is initialized to 0 in main(), and
>>>   * so is guaranteed to be different than the stat() mtime the
>>> first
>>>   * time this function is called.
>>>   */
>>>  if (old_db->mtime == HASH(statbuf.st_mtime,
>>> syscron_stat.st_mtime)) {
>>> -   Debug(DLOAD, ("[%ld] spool dir mtime unch, no load
>>> needed.\n",
>>> - (long)getpid()))
>>> +   Debug(DLOAD, ("[%ld] spool dirs mtime unch, no load
>>> needed.\n",
>>> +   (long)getpid()))
>>>  return;
>>>  }
>>>
>>> @@ -77,28 +78,45 @@
>>>  new_db.mtime = HASH(statbuf.st_mtime, syscron_stat.st_mtime);
>>>  new_db.head = new_db.tail = NULL;
>>>
>>> -   if (syscron_stat.st_mtime) {
>>> -   process_crontab(ROOT_USER, NULL, SYSCRONTAB,
>>> &syscron_stat,
>>> -   &new_db, old_db);
>>> -   }
>>> -
>>>  /* we used to keep this dir open all the time, for the sake of
>>>   * efficiency.  however, we need to close it in every fork, and
>>>   * we fork a lot more often than the mtime of the dir changes.
>>>   */
>>> -   if (!(dir = opendir(SPOOL_DIR))) {
>>> -   log_it("CRON", getpid(), "OPENDIR FAILED", SPOOL_DIR);
>>> +   if (!(dir = opendir(SYSCRON_DIR))) {
>>> +   log_it("CRON", getpid(), "OPENDIR FAILED", SYSCRON_DIR);
>>>  return;
>>>  }
>>>
>>> -   while (NULL != (dp = readdir(dir))) {
>>> -   char fname[MAXNAMLEN+1], tabname[MAXNAMLEN];
>>> +   char fname[MAXNAMLEN+1], tabname[MAXNAMLEN];
>>>
>>> +   while (NULL != (dp = readdir(dir))) {
>>>  /* avoid file names beginning with ".".  this is good
>>

source address for outgoing traffic with carpdevs?

[Florenz Kley]

hello misc,

can anyone please help me with a pointer:

two hosts have one interface each configured on the same subnet (.1 and .2), 
and also have a carp interface (.3) using the interfaces as carpdev. No load 
balancing is configured.

Is there more than one way to make the traffic originating from the host's 
carpdev have the source IP of the carp interface (in addition to nat-to with 
pf)?

and which is the recommended way?

regards
Florenz

OT: Re: FYA: http://heartbleed.com/

[noah pugsley]

On Tue, Apr 8, 2014 at 12:40 PM, Theo de Raadt wrote:

> > On Tue, Apr 08, 2014 at 15:09, Mike Small wrote:
> > > nobody  writes:
> > >
> > >> "read overrun, so ASLR won't save you"
> > >
> > > What if malloc's "G" option were turned on? You know, assuming the
> > > subset of the worlds' programs you use is good enough to run with that.
> >
> > No. OpenSSL has exploit mitigation countermeasures to make sure it's
> > exploitable.
>
> What Ted is saying may sound like a joke...
>
> So years ago we added exploit mitigations counter measures to libc
> malloc and mmap, so that a variety of bugs can be exposed.  Such
> memory accesses will cause an immediate crash, or even a core dump,
> then the bug can be analyed, and fixed forever.
>
> Some other debugging toolkits get them too.  To a large extent these
> come with almost no performance cost.
>
> But around that time OpenSSL adds a wrapper around malloc & free so
> that the library will cache memory on it's own, and not free it to the
> protective malloc.
>
> You can find the comment in their sources ...
>
> #ifndef OPENSSL_NO_BUF_FREELISTS
>  /* On some platforms, malloc() performance is bad enough that you can't
> just
>
>
> OH, because SOME platforms have slow performance, it means even if you
> build protective technology into malloc() and free(), it will be
> ineffective.  On ALL PLATFORMS, because that option is the default,
> and Ted's tests show you can't turn it off because they haven't tested
> without it in ages.
>
> So then a bug shows up which leaks the content of memory mishandled by
> that layer.  If the memoory had been properly returned via free, it
> would likely have been handed to munmap, and triggered a daemon crash
> instead of leaking your keys.
>
> OpenSSL is not developed by a responsible team.
>
>
>
Perhaps it's a great time to kickstart an OpenOpenSSL replacement, a la
bgpd, ospfd, smtpd et al? Now, I don't have the skills or the guts, but I
do have $5 on it. Anybody else?

Re: OT: Re: FYA: http://heartbleed.com/

[sven falempin]

On Tue, Apr 8, 2014 at 9:05 PM, noah pugsley  wrote:

> On Tue, Apr 8, 2014 at 12:40 PM, Theo de Raadt  >wrote:
>
> > > On Tue, Apr 08, 2014 at 15:09, Mike Small wrote:
> > > > nobody  writes:
> > > >
> > > >> "read overrun, so ASLR won't save you"
> > > >
> > > > What if malloc's "G" option were turned on? You know, assuming the
> > > > subset of the worlds' programs you use is good enough to run with
> that.
> > >
> > > No. OpenSSL has exploit mitigation countermeasures to make sure it's
> > > exploitable.
> >
> > What Ted is saying may sound like a joke...
> >
> > So years ago we added exploit mitigations counter measures to libc
> > malloc and mmap, so that a variety of bugs can be exposed.  Such
> > memory accesses will cause an immediate crash, or even a core dump,
> > then the bug can be analyed, and fixed forever.
> >
> > Some other debugging toolkits get them too.  To a large extent these
> > come with almost no performance cost.
> >
> > But around that time OpenSSL adds a wrapper around malloc & free so
> > that the library will cache memory on it's own, and not free it to the
> > protective malloc.
> >
> > You can find the comment in their sources ...
> >
> > #ifndef OPENSSL_NO_BUF_FREELISTS
> >  /* On some platforms, malloc() performance is bad enough that you can't
> > just
> >
> >
> > OH, because SOME platforms have slow performance, it means even if you
> > build protective technology into malloc() and free(), it will be
> > ineffective.  On ALL PLATFORMS, because that option is the default,
> > and Ted's tests show you can't turn it off because they haven't tested
> > without it in ages.
> >
> > So then a bug shows up which leaks the content of memory mishandled by
> > that layer.  If the memoory had been properly returned via free, it
> > would likely have been handed to munmap, and triggered a daemon crash
> > instead of leaking your keys.
> >
> > OpenSSL is not developed by a responsible team.
> >
> >
> >
> Perhaps it's a great time to kickstart an OpenOpenSSL replacement, a la
> bgpd, ospfd, smtpd et al? Now, I don't have the skills or the guts, but I
> do have $5 on it. Anybody else?
>
>
i which this : https://polarssl.org was open and inside the base

-- 
-
() ascii ribbon campaign - against html e-mail
/\

Re: feature patch -> replace /etc/crontab by /etc/cron.d/

[Dag Richards]

all sarcasm on my part.
hate the whole /etc/hourly /etc/daily /etc/whim-time cron crap

was happy to see Theo's reaction.  Was jerking the list's chain.


sven falempin wrote:

Look what linux are accepting now : stuff like systemd, how modern ! and so
nicely done !

Maybe having a .d looks .damned cool but does it really solve something ?

New is not better, modern surely isn't.

If there is a way for OpenBSD to move to a cron.d  it probably needs a nice
explanation :
 - problems to be solved
 - why is it the best way to solved it
 - what other solution has been discarded and why.
 - (and does the gain of the change worth the work of the change)

PS:
If you install a software that require recurrent task it should be done
with a user with specific priviledge , so set up a crontab for this user.


Geez don't you have a TLS server to patch !

On Tue, Apr 8, 2014 at 4:59 PM, Dag Richards wrote:


No Theo I don't think understand, if you accept the patch then you will be
more like Ubuntu and other MODERN operating systems.

Why put everything in a single easily readable file, when you can split it
up in to multiple directories.

Which reminds me when are you going to ditch /etc for a nice registry data
base.




Theo de Raadt wrote:


In your dreams.


 here is a simple patch to replace /etc/crontab by /etc/cron.d/.

You need to manually mkdir /etc/cron.d.


--- pathnames_original.hMon Apr  7 22:31:53 2014
+++ pathnames.h Tue Apr  8 16:12:30 2014
@@ -92,8 +92,8 @@
  #define PIDFILE"cron.pid"
  #define _PATH_CRON_PID PIDDIR PIDFILE

-   /* 4.3BSD-style crontab */
-#define SYSCRONTAB "/etc/crontab"
+   /* system crontab dir */
+#define SYSCRON_DIR"/etc/cron.d"

 /* what editor to use if no EDITOR or VISUAL
  * environment variable specified.
@@ -42,30 +42,31 @@

 Debug(DLOAD, ("[%ld] load_database()\n", (long)getpid()))

-   /* before we start loading any data, do a stat on SPOOL_DIR
-* so that if anything changes as of this moment (i.e., before
we've
-* cached any of the database), we'll see the changes next time.
+   /* before we start loading any data, do a stat on SPOOL_DIR and
+* SYSCRON_DIR so that if anything changes as of this moment
+* (i.e., before we've cached any of the database), we'll see
+* the changes next time.
  */
 if (stat(SPOOL_DIR, &statbuf) < OK) {
 log_it("CRON", getpid(), "STAT FAILED", SPOOL_DIR);
 return;
 }

-   /* track system crontab file
-*/
-   if (stat(SYSCRONTAB, &syscron_stat) < OK)
-   syscron_stat.st_mtime = 0;
+   if (stat(SYSCRON_DIR, &syscron_stat) < OK) {
+   log_it("CRON", getpid(), "STAT FAILED", SYSCRON_DIR);
+   return;
+   }

-   /* if spooldir's mtime has not changed, we don't need to fiddle
with
-* the database.
+   /* if spooldir's and syscrondir's mtime has not changed, we don't
+* need to fiddle with the database.
  *
  * Note that old_db->mtime is initialized to 0 in main(), and
  * so is guaranteed to be different than the stat() mtime the
first
  * time this function is called.
  */
 if (old_db->mtime == HASH(statbuf.st_mtime,
syscron_stat.st_mtime)) {
-   Debug(DLOAD, ("[%ld] spool dir mtime unch, no load
needed.\n",
- (long)getpid()))
+   Debug(DLOAD, ("[%ld] spool dirs mtime unch, no load
needed.\n",
+   (long)getpid()))
 return;
 }

@@ -77,28 +78,45 @@
 new_db.mtime = HASH(statbuf.st_mtime, syscron_stat.st_mtime);
 new_db.head = new_db.tail = NULL;

-   if (syscron_stat.st_mtime) {
-   process_crontab(ROOT_USER, NULL, SYSCRONTAB,
&syscron_stat,
-   &new_db, old_db);
-   }
-
 /* we used to keep this dir open all the time, for the sake of
  * efficiency.  however, we need to close it in every fork, and
  * we fork a lot more often than the mtime of the dir changes.
  */
-   if (!(dir = opendir(SPOOL_DIR))) {
-   log_it("CRON", getpid(), "OPENDIR FAILED", SPOOL_DIR);
+   if (!(dir = opendir(SYSCRON_DIR))) {
+   log_it("CRON", getpid(), "OPENDIR FAILED", SYSCRON_DIR);
 return;
 }

-   while (NULL != (dp = readdir(dir))) {
-   char fname[MAXNAMLEN+1], tabname[MAXNAMLEN];
+   char fname[MAXNAMLEN+1], tabname[MAXNAMLEN];

+   while (NULL != (dp = readdir(dir))) {
 /* avoid file names beginning with ".".  this is good
  * because we would otherwise waste two guaranteed calls
  * to getpwnam() for . and .., and also because user
names
  * starting with a period are just too na

Re: feature patch -> replace /etc/crontab by /etc/cron.d/

[System Administrator]

wasn't the "registry database" a dead giveaway???

On 8 Apr 2014 at 17:22, Dag Richards wrote:

> all sarcasm on my part.
> hate the whole /etc/hourly /etc/daily /etc/whim-time cron crap
> 
> was happy to see Theo's reaction.  Was jerking the list's chain.
> 
> 
> sven falempin wrote:
> > Look what linux are accepting now : stuff like systemd, how modern ! and so
> > nicely done !
> > 
> > Maybe having a .d looks .damned cool but does it really solve something ?
> > 
> > New is not better, modern surely isn't.
> > 
> > If there is a way for OpenBSD to move to a cron.d  it probably needs a nice
> > explanation :
> >  - problems to be solved
> >  - why is it the best way to solved it
> >  - what other solution has been discarded and why.
> >  - (and does the gain of the change worth the work of the change)
> > 
> > PS:
> > If you install a software that require recurrent task it should be done
> > with a user with specific priviledge , so set up a crontab for this user.
> > 
> > 
> > Geez don't you have a TLS server to patch !
> > 
> > On Tue, Apr 8, 2014 at 4:59 PM, Dag Richards 
> > wrote:
> > 
> >> No Theo I don't think understand, if you accept the patch then you will be
> >> more like Ubuntu and other MODERN operating systems.
> >>
> >> Why put everything in a single easily readable file, when you can split it
> >> up in to multiple directories.
> >>
> >> Which reminds me when are you going to ditch /etc for a nice registry data
> >> base.
> >>
> >>
> >>
> >>
> >> Theo de Raadt wrote:
> >>
> >>> In your dreams.
> >>>
> >>>
> >>>  here is a simple patch to replace /etc/crontab by /etc/cron.d/.
>  You need to manually mkdir /etc/cron.d.
> 
> 
>  --- pathnames_original.hMon Apr  7 22:31:53 2014
>  +++ pathnames.h Tue Apr  8 16:12:30 2014
>  @@ -92,8 +92,8 @@
>    #define PIDFILE"cron.pid"
>    #define _PATH_CRON_PID PIDDIR PIDFILE
> 
>  -   /* 4.3BSD-style crontab */
>  -#define SYSCRONTAB "/etc/crontab"
>  +   /* system crontab dir */
>  +#define SYSCRON_DIR"/etc/cron.d"
> 
>   /* what editor to use if no EDITOR or VISUAL
>    * environment variable specified.
>  @@ -42,30 +42,31 @@
> 
>   Debug(DLOAD, ("[%ld] load_database()\n", (long)getpid()))
> 
>  -   /* before we start loading any data, do a stat on SPOOL_DIR
>  -* so that if anything changes as of this moment (i.e., before
>  we've
>  -* cached any of the database), we'll see the changes next time.
>  +   /* before we start loading any data, do a stat on SPOOL_DIR and
>  +* SYSCRON_DIR so that if anything changes as of this moment
>  +* (i.e., before we've cached any of the database), we'll see
>  +* the changes next time.
>    */
>   if (stat(SPOOL_DIR, &statbuf) < OK) {
>   log_it("CRON", getpid(), "STAT FAILED", SPOOL_DIR);
>   return;
>   }
> 
>  -   /* track system crontab file
>  -*/
>  -   if (stat(SYSCRONTAB, &syscron_stat) < OK)
>  -   syscron_stat.st_mtime = 0;
>  +   if (stat(SYSCRON_DIR, &syscron_stat) < OK) {
>  +   log_it("CRON", getpid(), "STAT FAILED", SYSCRON_DIR);
>  +   return;
>  +   }
> 
>  -   /* if spooldir's mtime has not changed, we don't need to fiddle
>  with
>  -* the database.
>  +   /* if spooldir's and syscrondir's mtime has not changed, we don't
>  +* need to fiddle with the database.
>    *
>    * Note that old_db->mtime is initialized to 0 in main(), and
>    * so is guaranteed to be different than the stat() mtime the
>  first
>    * time this function is called.
>    */
>   if (old_db->mtime == HASH(statbuf.st_mtime,
>  syscron_stat.st_mtime)) {
>  -   Debug(DLOAD, ("[%ld] spool dir mtime unch, no load
>  needed.\n",
>  - (long)getpid()))
>  +   Debug(DLOAD, ("[%ld] spool dirs mtime unch, no load
>  needed.\n",
>  +   (long)getpid()))
>   return;
>   }
> 
>  @@ -77,28 +78,45 @@
>   new_db.mtime = HASH(statbuf.st_mtime, syscron_stat.st_mtime);
>   new_db.head = new_db.tail = NULL;
> 
>  -   if (syscron_stat.st_mtime) {
>  -   process_crontab(ROOT_USER, NULL, SYSCRONTAB,
>  &syscron_stat,
>  -   &new_db, old_db);
>  -   }
>  -
>   /* we used to keep this dir open all the time, for the sake of
>    * efficiency.  however, we need to close it in every fork, and
>    * we fo

Re: ypldap

[Matthew Weigel]

On 04/08/2014 04:31 PM, Friedrich Locke wrote:

Dear list members,

i have just configured my system (yp) to retrive information on groups and
users. It's working 100% ok.

Now, i would like to set some netgroups. How does netgroup works with
ypldap ?


Per ypldap.conf(5): "The currently implemented maps are: passwd.byname, 
passwd.byuid, group.byname, group.bygid."

--
 Matthew Weigel
 hacker
 unique & idempot . ent

RSA server certificate for nginx

[Erling Westenvik]

I'm used to generate RSA certificates for httpd(8) simply by following
the "GENERATING RSA SERVER CERTIFICATES FOR WEB SERVERS" section in the
manpage for ssl(8) and then setting httpd_flags="-DSSL" in
/etc/rc.conf.local. A few changes in /var/www/conf/httpd.conf and I'm
done. Up and go.

But how to do this with nginx(8)? After generating the certificates and
uncommenting the lines that deal with ssl in /etc/nginx/nginx.conf, I
get a SSL handshake error in my browsers:

"SSL received a record that exceeded the maximum permissible
length.  (Error code: ssl_error_rx_record_too_long)" (Firefox)

5.4 release. amd64.

Regards,

Erling

Re: RSA server certificate for nginx

[Raf Czlonka]

On Wed, Apr 09, 2014 at 03:25:25AM BST, Erling Westenvik wrote:

>   "SSL received a record that exceeded the maximum permissible
>   length.  (Error code: ssl_error_rx_record_too_long)" (Firefox)

That may have something to do with the way you have configured TLS (i.e.
version) either under 'nginx' or 'Firefox'[0].

[0] https://support.mozilla.org/en-US/questions/976504

Regards,

Raf

Re: "not configured" components on Dell C5220 / C6220

[Tomas Bodzar]

On Tue, Apr 8, 2014 at 7:35 PM, Donovan Watteau  wrote:

> Hello,
>
> We'd like to deploy OpenBSD on some Dell C5220 and Dell C6220 servers,
> for a high-traffic website.
>
> However, the C5220 has some unconfigured components in dmesg [1], and
> the C6220 has even more of them [2].
>
> Are they crucial for the machines to operate accurately?  By 'accurately',
> I mean we need them to compute and send stuff on the wire, while remaining
> stable, with a high load of work and traffic.
>
> Thanks for your help,
> Donovan.
>
> [1]:
> OpenBSD 5.5 (GENERIC.MP) #315: Wed Mar  5 09:37:46 MST 2014
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 33506557952 (31954MB)
> avail mem = 32606011392 (31095MB)
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xebe40 (46 entries)
> bios0: vendor Dell Inc. version "2.1.0" date 07/30/2013
> bios0: Dell Inc. PowerEdge C5220
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S1 S5
> acpi0: tables DSDT FACP APIC MCFG HPET SSDT PRAD SPMI SSDT SSDT SSDT SSDT
> SPCR BGRT
> acpi0: wakeup devices PCIB(S3) USB1(S3) USB2(S3) USB3(S3) USB4(S3)
> USB5(S3) USB6(S3) USB7(S3) PEGP(S3) PEG0(S3) PEG1(S3) PEG2(S3) PEG3(S3)
> GLAN(S3) EHC1(S3) EHC2(S3) [...]
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Xeon(R) CPU E3-1220 V2 @ 3.10GHz, 3093.41 MHz
> cpu0:
>
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,A
ES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
> cpu0: 256KB 64b/line 8-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
> cpu0: apic clock running at 99MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.1.0, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Xeon(R) CPU E3-1220 V2 @ 3.10GHz, 3092.98 MHz
> cpu1:
>
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,A
ES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu1: smt 0, core 1, package 0
> cpu2 at mainbus0: apid 4 (application processor)
> cpu2: Intel(R) Xeon(R) CPU E3-1220 V2 @ 3.10GHz, 3092.98 MHz
> cpu2:
>
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,A
ES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
> cpu2: 256KB 64b/line 8-way L2 cache
> cpu2: smt 0, core 2, package 0
> cpu3 at mainbus0: apid 6 (application processor)
> cpu3: Intel(R) Xeon(R) CPU E3-1220 V2 @ 3.10GHz, 3092.98 MHz
> cpu3:
>
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,A
ES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
> cpu3: 256KB 64b/line 8-way L2 cache
> cpu3: smt 0, core 3, package 0
> ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
> acpimcfg0 at acpi0 addr 0xe000, bus 0-255
> acpihpet0 at acpi0: 14318179 Hz
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 3 (PCIB)
> acpiprt2 at acpi0: bus 1 (PEG0)
> acpiprt3 at acpi0: bus 2 (PEG1)
> acpiprt4 at acpi0: bus -1 (PEG2)
> acpiprt5 at acpi0: bus -1 (PEG3)
> acpiec0 at acpi0: Failed to read resource settings
> acpicpu0 at acpi0: PSS
> acpicpu1 at acpi0: PSS
> acpicpu2 at acpi0: PSS
> acpicpu3 at acpi0: PSS
> acpipwrres0 at acpi0: FN00, resource for FAN0
> acpipwrres1 at acpi0: FN01, resource for FAN1
> acpipwrres2 at acpi0: FN02, resource for FAN2
> acpipwrres3 at acpi0: FN03, resource for FAN3
> acpipwrres4 at acpi0: FN04, resource for FAN4
> acpitz0 at acpi0: critical temperature is 106 degC
> acpitz1 at acpi0: critical temperature is 106 degC
> acpibat0 at acpi0: BAT0 not present
> acpibat1 at acpi0: BAT1 not present
> acpibat2 at acpi0: BAT2 not present
> acpibtn0 at acpi0: PWRB
> acpibtn1 at acpi0: LID0
> acpivideo0 at acpi0: GFX0
> acpivout0 at acpivideo0: DD02
> ipmi at mainbus0 not configured
> cpu0: Enhanced SpeedStep 3093 MHz: speeds: 3101, 3100 MHz
> pci0 at mainbus0 bus 0
> pchb0 at pci0 dev 0 function 0 "Intel Xeon E3-1200 v2 Host" rev 0x09
> ppb0 at pci0 dev 1 function 0 "Intel Core 3G PCIE" rev 0x09: msi
> pci1 at ppb0 bus 1
> ppb1 at pci0 dev 1 function 1 "Intel Core 3G PCIE" rev 0x09: msi
> pci2 at ppb1 bus 2
> em0 at pci2 dev 0 function 0 "Intel 82580" rev 0x01: msi, address XXX
> em1 at pci2 d

Re: source address for outgoing traffic with carpdevs?

[Janne Johansson]

If you want the slave machine (the one currently not winning the carp
elections) to be able to send traffic (logs, mail, respond to monitoring
and so on), you want local traffic to be originating from the interface IP
and not the carp ip.



2014-04-09 2:54 GMT+02:00 Florenz Kley :

> hello misc,
>
> can anyone please help me with a pointer:
>
> two hosts have one interface each configured on the same subnet (.1 and
> .2), and also have a carp interface (.3) using the interfaces as carpdev.
> No load balancing is configured.
>
> Is there more than one way to make the traffic originating from the host's
> carpdev have the source IP of the carp interface (in addition to nat-to
> with pf)?
>
> and which is the recommended way?
>
> regards
> Florenz
>
>


-- 
May the most significant bit of your life be positive.