Re: pfctl -T show not permitted when kern.securelevel=2

[Theo de Raadt]

> On Sat, Feb 25, 2017 at 11:34:19PM -0500, Peter Colberg wrote:
> > >Synopsis:  pfctl -T show not permitted when kern.securelevel=2
> > >Category:  kernel
> > >Environment:
> > System  : OpenBSD 6.0
> > Details : OpenBSD 6.0 (GENERIC.MP) #2319: Tue Jul 26 13:00:43 
> > MDT 2016
> >  
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > 
> > Architecture: OpenBSD.amd64
> > Machine : amd64
> > >Description:
> > When attempting to list the contents of a pf table and the
> > kernel is set to securelevel 2, pfctl -T show fails with
> > `Operation not permitted'. pfctl -vT show works as expected.
> > >How-To-Repeat:
> > # sysctl kern.securelevel   
> > 
> > 
> > 
> > kern.securelevel=1
> > 
> > # pfctl -t test -T add 198.51.100.81
> > 1 table created.
> > 1/1 addresses added.
> > 
> > # pfctl -t test -T show
> >198.51.100.81
> > 
> > # pfctl -t test -vT show
> >198.51.100.81
> > Cleared: Sat Feb 25 22:57:50 2017
> > 
> > # sysctl kern.securelevel=2  
> > kern.securelevel: 1 -> 2
> > 
> > # pfctl -t test -T show
> > pfctl: Operation not permitted.
> > 
> > # pfctl -t test -vT show
> >198.51.100.81
> > Cleared: Sat Feb 25 22:57:50 2017
> 
> In addition to DIOCRGETASTATS, permit DIOCRGETADDRS if securelevel > 1.
> 
> Index: sys/net/pf_ioctl.c
> ===
> RCS file: /cvs/src/sys/net/pf_ioctl.c,v
> retrieving revision 1.307
> diff -u -p -r1.307 pf_ioctl.c
> --- sys/net/pf_ioctl.c30 Jan 2017 17:41:34 -  1.307
> +++ sys/net/pf_ioctl.c28 Feb 2017 05:21:15 -
> @@ -917,6 +917,7 @@ pfioctl(dev_t dev, u_long cmd, caddr_t a
>   case DIOCRADDADDRS:
>   case DIOCRDELADDRS:
>   case DIOCRSETADDRS:
> + case DIOCRGETADDRS:
>   case DIOCRGETASTATS:
>   case DIOCRCLRASTATS:
>   case DIOCRTSTADDRS:
> 


It was nearly 20 years ago that there were believers in securelevel 2.
I was never one of them.

However, the whole point was that securelevel 2 doesn't let you do a
whole ton of things.  That switch table was essentially complete two
decades ago, and we don't know who is relying upon the behaviour now.

I suggest you adapt.

Re: pfctl -T show not permitted when kern.securelevel=2

[Peter Colberg]

On Sat, Feb 25, 2017 at 11:34:19PM -0500, Peter Colberg wrote:
> >Synopsis:  pfctl -T show not permitted when kern.securelevel=2
> >Category:  kernel
> >Environment:
> System  : OpenBSD 6.0
> Details : OpenBSD 6.0 (GENERIC.MP) #2319: Tue Jul 26 13:00:43 MDT 
> 2016
>  
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
> Architecture: OpenBSD.amd64
> Machine : amd64
> >Description:
> When attempting to list the contents of a pf table and the
> kernel is set to securelevel 2, pfctl -T show fails with
> `Operation not permitted'. pfctl -vT show works as expected.
> >How-To-Repeat:
> # sysctl kern.securelevel 
>   
>   
>   
> kern.securelevel=1
> 
> # pfctl -t test -T add 198.51.100.81
> 1 table created.
> 1/1 addresses added.
> 
> # pfctl -t test -T show
>198.51.100.81
> 
> # pfctl -t test -vT show
>198.51.100.81
> Cleared: Sat Feb 25 22:57:50 2017
> 
> # sysctl kern.securelevel=2  
> kern.securelevel: 1 -> 2
> 
> # pfctl -t test -T show
> pfctl: Operation not permitted.
> 
> # pfctl -t test -vT show
>198.51.100.81
> Cleared: Sat Feb 25 22:57:50 2017

In addition to DIOCRGETASTATS, permit DIOCRGETADDRS if securelevel > 1.

Index: sys/net/pf_ioctl.c
===
RCS file: /cvs/src/sys/net/pf_ioctl.c,v
retrieving revision 1.307
diff -u -p -r1.307 pf_ioctl.c
--- sys/net/pf_ioctl.c  30 Jan 2017 17:41:34 -  1.307
+++ sys/net/pf_ioctl.c  28 Feb 2017 05:21:15 -
@@ -917,6 +917,7 @@ pfioctl(dev_t dev, u_long cmd, caddr_t a
case DIOCRADDADDRS:
case DIOCRDELADDRS:
case DIOCRSETADDRS:
+   case DIOCRGETADDRS:
case DIOCRGETASTATS:
case DIOCRCLRASTATS:
case DIOCRTSTADDRS:

Re: ldapd(8) hangs when receiving large data

[Robert Klein]

Hi Seiya,

On Sat, 18 Feb 2017 12:46:06 +
Seiya Kawashima  wrote:

> >Synopsis:  ldapd(8) hangs when receiving large data
> >Category:  system
> >Environment:  
> System  : OpenBSD 6.0
> Details   : OpenBSD 6.0-current (GENERIC.MP) #0: Thu Feb
> 16 19:58:50 CST 2017
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
> Architecture: OpenBSD.amd64
> Machine : amd64
> >Description:  
> Hi,
> 
> Thank you for your time to look at this bug report.
> 
> ldapd(8) hangs when it receives partial LDAPMessages due to
> the message sizes. conn_read() in /ldapd/conn.c is supposed to be
> called to read partial LDAPMessages by libevent until it receives
> complete LDAPMessages . In theory, conn_read() is called by libevent
> whenever data for reading is available. However, it doesn't work this
> way. What happens is that conn_read() is called once and nothing
> happens any further. As the result, ldapd(8) hangs. It seemed to me
> that ldapd(8) was waiting for more data from ldapadd as expected but
> ldapadd was also waiting for something to send the rest of the data
> to ldapd(8). So ldapadd was the one that didn't send the rest of the
> data to ldapd(8). To prove this point, once I killed ldapadd while
> they were hanging, ldapd(8) started receiving the rest of the data
> and stored the data without hanging at this time. ldapd(8) can't
> simply wait for more data to read but needs to do something to let
> ldapadd keep sending the rest of the data. I found a fix for this
> issue but I've not yet found any references about the fix on RFCs
> 4511, 4513 and 4514 and the source code at
> https://github.com/openldap/openldap so unfortunately I'm not quite
> sure if this one would be the right fix. The fix came from my
> experiments.
> 
> Thank you
> Seiya


I reproduced the issue with both OpenBSD 6.0 plus patches 1 through 17
applied and OpenBSD current (as of today).

The image I used show the issue for both versions.

When switching TLS off, however, the issue doesn't show up.  I didn't
try with non-self-signed certificates, however (will probably try
tomorrow).  Differences in the ldapd(8) output (self-signed TLS
certificate, no TLS) are below for both OpenBSD versions.

Anyway, the ldapadd operation completes, even when ldapadd hangs (you
can check with ldapsearch afterwards; ldapadd gives a lot more output if
you use the "-d 7" switch, where you can see the jpeg image is
transported to the ldapd(8) server.  It doesn't show the "add:..."
output though, because it's running in a loop.  With "-d 7" it repeats
the following output over and over:

--- snip ---
** ld 0x557e29a78770 Outstanding Requests:
 * msgid 2,  origid 2, status InProgress
   outstanding referrals 0, parent count 0
  ld 0x557e29a78770 request count 1 (abandoned 0)
** ld 0x557e29a78770 Response Queue:
   Empty
  ld 0x557e29a78770 response count 0
ldap_chkResponseList ld 0x557e29a78770 msgid 2 all 1
ldap_chkResponseList returns ld 0x557e29a78770 NULL
ldap_int_select
ldap_result ld 0x557e29a78770 msgid 2
wait4msg ld 0x557e29a78770 msgid 2 (timeout 10 usec)
wait4msg continue ld 0x557e29a78770 msgid 2 all 1
** ld 0x557e29a78770 Connections:
* host: r310  port: 636  (default)
  refcnt: 2  status: Connected
  last used: Mon Feb 27 20:14:07 2017


--- snip ---


I'm very hesitant about patching the file ber.c; BER is the encoding of
LDAP messages, and shouldn't concern itself about transport and getting
full or partial messages.  I'll dig a little more the next couple of
days.



--- Differences of ldapd(8) output tls / without tls
--- ldapd OpenBSD 6.0 w/ Patches 1 through 17 applied
--- (OpenBSD 6.0 (GENERIC) #2: Tue Feb 21 08:31:58 CET 2017)

--- without-tls.log Mon Feb 27 16:56:58 2017
+++ with-tls.logMon Feb 27 16:57:08 2017
@@ -2,16 +2,19 @@
  [] parsing schema file '/etc/ldap/core.schema'
  [] parsing schema file
'/etc/ldap/inetorgperson.schema' [] parsing schema
file '/etc/ldap/nis.schema'
+ [] loading certificate
file /etc/ldap/certs/vio0.crt
+ [] loading key file /etc/ldap/certs/vio0.key
  [] parsing namespace dc=example,dc=com
  [] deny 1F access to any scope 0 by any
  [] allow 10 access to ou=people,dc=example,dc=com
scope 1 by any [] allow 01 access to any scope 0 by
@ [] allow 02 access to any scope 0 by @
  [] startup
- [] listening on 192.168.131.146:389
+ [] listening on 192.168.131.146:636
  [] opening namespace dc=example,dc=com
  [] ldape: entering event loop
  [] accepted connection from 192.168.131.26 on fd 9
+ [] conn_tls_init: switching to TLS
  

Re: mount(2) man page missing Dv for MNT_WXALLOWED

[Jason McIntyre]

On Mon, Feb 27, 2017 at 05:07:13PM +0100, Bruno Flueckiger wrote:
> Hi,
> 
> I've read the man page mount(2) in Firefox today. The formating
> of MNT_WXALLOWED looks different than the formatting of the other
> flags. This is only visible in a graphical browswer, on my terminal I
> cannot see any difference.
> 
> The patch below adds Dv to .It, making it look the same as the other
> flags.
> 
> Cheers,
> Bruno
> 

fixed, thanks.
jmc

> 
> Index: lib/libc/sys/mount.2
> ===
> RCS file: /cvs/src/lib/libc/sys/mount.2,v
> retrieving revision 1.46
> diff -u -p -r1.46 mount.2
> --- lib/libc/sys/mount.2  27 May 2016 19:45:04 -  1.46
> +++ lib/libc/sys/mount.2  27 Feb 2017 15:48:09 -
> @@ -95,7 +95,7 @@ All I/O to the filesystem should be done
>  Use soft dependencies.
>  Applies to FFS filesystems only (see 'softdep' in
>  .Xr mount 8 ) .
> -.It MNT_WXALLOWED
> +.It Dv MNT_WXALLOWED
>  Processes that ask for memory to be made writeable plus executable
>  using the
>  .Xr mmap 2
> 

mount(2) man page missing Dv for MNT_WXALLOWED

[Bruno Flueckiger]

Hi,

I've read the man page mount(2) in Firefox today. The formating
of MNT_WXALLOWED looks different than the formatting of the other
flags. This is only visible in a graphical browswer, on my terminal I
cannot see any difference.

The patch below adds Dv to .It, making it look the same as the other
flags.

Cheers,
Bruno


Index: lib/libc/sys/mount.2
===
RCS file: /cvs/src/lib/libc/sys/mount.2,v
retrieving revision 1.46
diff -u -p -r1.46 mount.2
--- lib/libc/sys/mount.227 May 2016 19:45:04 -  1.46
+++ lib/libc/sys/mount.227 Feb 2017 15:48:09 -
@@ -95,7 +95,7 @@ All I/O to the filesystem should be done
 Use soft dependencies.
 Applies to FFS filesystems only (see 'softdep' in
 .Xr mount 8 ) .
-.It MNT_WXALLOWED
+.It Dv MNT_WXALLOWED
 Processes that ask for memory to be made writeable plus executable
 using the
 .Xr mmap 2