openssl.cnf req defaults -> default_md sha256

[Brent Cook]

U

On Tue, Oct 20, 2015 at 12:12 AM, Jonathan Gray > wrote:
> On Wed, Oct 01, 2014 at 10:53:34AM +0100, Stuart Henderson wrote:
>> On 2014/10/01 19:05, Joel Sing wrote:
>> > > I should also add that the other obvious/easy "fix" is to initialise
digest
>> > > in openssl/req.c to the SHA-256 EVP. That only changes 'openssl req'
>> > > though.
>> > >
>> > > > (and yes, clearly I've spent too much time in this code base
recently...
>> > > > :)
>> > > >
>> > > > > Index: openssl.cnf
>> > > > >
===
>> > > > > RCS file: /cvs/src/lib/libcrypto/openssl.cnf,v
>> > > > > retrieving revision 1.1
>> > > > > diff -u -p -r1.1 openssl.cnf
>> > > > > --- openssl.cnf   11 Apr 2014 22:51:53 -  1.1
>> > > > > +++ openssl.cnf   30 Sep 2014 22:42:53 -
>> > > > > @@ -7,7 +7,8 @@
>> > > > >
>> > > > >

>> > > > >  [ req ]
>> > > > > -default_bits = 1024
>> > > > > +default_bits = 2048
>> > > > > +default_md   = sha256
>> > > > >  default_keyfile  = privkey.pem
>> > > > >  distinguished_name   = req_distinguished_name
>> > > > >  attributes   = req_attributes
>> >
>> > The following does this, however note that the default_bits of 1024
from
>> > openssl.cnf trumps the 2048 in the define... we probably should also
stop
>> > making EVP_des_ede3_cbc() the default cipher...
>>
>> I think I prefer it this way (changing usr.bin/openssl rather than
>> the library) as there's less risk of impact in unpredictable areas.
>> How about this one?
>
> Any reason to not change the default for crl/ocsp/fingerprints as well?
>
> It looks like openssl(1) could use updating:
> "The digest of choice for all new applications is SHA1."

I like this idea, of course with a man page update as well.

> Index: crl.c
> ===
> RCS file: /cvs/src/usr.bin/openssl/crl.c,v
> retrieving revision 1.9
> diff -u -p -r1.9 crl.c
> --- crl.c   17 Oct 2015 15:00:11 -  1.9
> +++ crl.c   20 Oct 2015 04:48:26 -
> @@ -243,7 +243,7 @@ crl_main(int argc, char **argv)
> }
> }
>
> -   digest = EVP_sha1();
> +   digest = EVP_sha256();
>
> memset(_config, 0, sizeof(crl_config));
> crl_config.informat = FORMAT_PEM;
> Index: ocsp.c
> ===
> RCS file: /cvs/src/usr.bin/openssl/ocsp.c,v
> retrieving revision 1.7
> diff -u -p -r1.7 ocsp.c
> --- ocsp.c  17 Oct 2015 15:00:11 -  1.7
> +++ ocsp.c  20 Oct 2015 04:47:42 -
> @@ -355,7 +355,7 @@ ocsp_main(int argc, char **argv)
> if (!cert)
> goto end;
> if (!cert_id_md)
> -   cert_id_md = EVP_sha1();
> +   cert_id_md = EVP_sha256();
> if (!add_ocsp_cert(, cert,
cert_id_md, issuer, ids))
> goto end;
> if (!sk_OPENSSL_STRING_push(reqnames,
*args))
> @@ -366,7 +366,7 @@ ocsp_main(int argc, char **argv)
> if (args[1]) {
> args++;
> if (!cert_id_md)
> -   cert_id_md = EVP_sha1();
> +   cert_id_md = EVP_sha256();
> if (!add_ocsp_serial(, *args,
cert_id_md, issuer, ids))
> goto end;
> if (!sk_OPENSSL_STRING_push(reqnames,
*args))
> Index: x509.c
> ===
> RCS file: /cvs/src/usr.bin/openssl/x509.c,v
> retrieving revision 1.12
> diff -u -p -r1.12 x509.c
> --- x509.c  17 Oct 2015 15:00:11 -  1.12
> +++ x509.c  20 Oct 2015 04:50:25 -
> @@ -788,7 +788,7 @@ bad:
> const EVP_MD *fdig = digest;
>
> if (!fdig)
> -   fdig = EVP_sha1();
> +   fdig = EVP_sha256();
>
> if (!X509_digest(x, fdig, md, )) {
> BIO_printf(bio_err, "out of
memory\n");
>

fcntl F_SETOWN pipe

[Alexander Bluhm]

Hi,

Setting fcntl(F_SETOWN) for a pipe does not work.
fcntl F_SETOWN: Inappropriate ioctl for device

In sys_fcntl() the ioctl(TIOCSPGRP) is called, but the pipe expects
SIOCSPGRP.  Sockets have a specal case for the same reason.  I would
prefer that socketpair and pipe behave identical, so I have adapted
the special code for pipes.

ok?

bluhm

Index: kern/kern_descrip.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/kern/kern_descrip.c,v
retrieving revision 1.121
diff -u -p -r1.121 kern_descrip.c
--- kern/kern_descrip.c 16 Oct 2015 13:37:43 -  1.121
+++ kern/kern_descrip.c 20 Oct 2015 13:02:50 -
@@ -429,6 +429,10 @@ restart:
*retval = ((struct socket *)fp->f_data)->so_pgid;
break;
}
+   if (fp->f_type == DTYPE_PIPE) {
+   *retval = ((struct pipe *)fp->f_data)->pipe_pgid;
+   break;
+   }
error = (*fp->f_ops->fo_ioctl)
(fp, TIOCGPGRP, (caddr_t), p);
*retval = -tmp;
@@ -441,6 +445,12 @@ restart:
so->so_pgid = (long)SCARG(uap, arg);
so->so_siguid = p->p_ucred->cr_ruid;
so->so_sigeuid = p->p_ucred->cr_uid;
+   break;
+   }
+   if (fp->f_type == DTYPE_PIPE) {
+   struct pipe *mpipe = (struct pipe *)fp->f_data;
+
+   mpipe->pipe_pgid = (long)SCARG(uap, arg);
break;
}
if ((long)SCARG(uap, arg) <= 0) {

Re: pledge(2) in script(1)

[Sebastien Marie]

On Tue, Oct 20, 2015 at 12:18:07PM +0200, Theo Buehler wrote:
> On Tue, Oct 20, 2015 at 11:45:59AM +0200, Jan Stary wrote:
> > My script(1) just got killed with
> > 
> > script(15938): syscall 37
> 
> Can you provide a reproducible test case?  What did you do?
>

syscall 37 is SYS_kill:

$ grep 37 /usr/include/sys/syscall.h
   
#define SYS_kill37
[...]

the script(1) source has two calls for kill(2):
$ grep -R kill /usr/src/usr.bin/script  
   
/usr/src/usr.bin/script/script.c:   killpg(pgrp, SIGWINCH);
/usr/src/usr.bin/script/script.c:   (void)kill(0, SIGTERM);

The second one should be permitted with "stdio": it is a kill to self.
But the first one will be forbidden with the current peldge requests.

This one is in handlesigwinch() function, which is an handler for
SIGWINCH signal, in order to "forward" a received signal to
subprocesses.

So script(1) needs "proc" request to be able to do that.

It could be reproduced easily with tmux(1): inside a tmux session, start
script, and create a new-window (Ctrl+B "): tmux will send SIGWINCH
signal to the script process for telling it "beware, your window size
has changed". And the script process will (try to) send forward this
signal to subprocess.

Here a diff with add "proc" to script(1).

OK ?
-- 
Sebastien Marie

Index: script.c
===
RCS file: /cvs/src/usr.bin/script/script.c,v
retrieving revision 1.31
diff -u -p -r1.31 script.c
--- script.c9 Oct 2015 01:37:08 -   1.31
+++ script.c20 Oct 2015 11:36:55 -
@@ -165,7 +165,7 @@ main(int argc, char *argv[])
sa.sa_handler = finish;
(void)sigaction(SIGCHLD, , NULL);
 
-   if (pledge("stdio tty", NULL) == -1)
+   if (pledge("stdio proc tty", NULL) == -1)
err(1, "pledge");
 
(void)fclose(fscript);
@@ -251,7 +251,7 @@ dooutput(void)
sa.sa_handler = SIG_IGN;
(void)sigaction(SIGCHLD, , NULL);
 
-   if (pledge("stdio", NULL) == -1)
+   if (pledge("stdio proc", NULL) == -1)
err(1, "pledge");
 
value.it_interval.tv_sec = 30;

pledge(2) hangman(6)

[Ricardo Mestre]

Hi tech@!

Let's give some pledge(2) love to hangman(6)!

It seems to work fine for me with the patch mentioned below, 
nevertheless please be aware that I don't consider myself a developer, 
just a mere OpenBSD user with 'security uncle syndrome' :D


Index: src/games/hangman/main.c
===
RCS file: /cvs/src/games/hangman/main.c,v
retrieving revision 1.12
diff -u -p -u -r1.12 main.c
--- src/games/hangman/main.c7 Feb 2015 01:37:30 -   1.12
+++ src/games/hangman/main.c20 Oct 2015 19:54:01 -
@@ -43,6 +43,9 @@ main(int argc, char *argv[])
 {
int ch;

+   if (pledge("malloc tty rpath", NULL) == -1)
+   err(1, "pledge");
+
while ((ch = getopt(argc, argv, "d:hk")) != -1) {
switch (ch) {
case 'd':

Best regards,
Ricardo Mestre

Re: make iked not static

[Sebastian Benoit]

Christian Weisgerber(na...@mips.inka.de) on 2015.10.20 20:46:12 +:
> On 2015-10-20, Reyk Floeter  wrote:
> 
> > For historical reasons, isakmpd and iked are compiled static:
> > people used NFS over ipsec.
> >
> > Is anyone still using this?  Is it more than one person?
> >
> > Otherwise I'd suggest to make iked dynamic.
> 
> Already, iked is started after /usr has been mounted, so why the
> static requirement?
> 
> > --- etc/rc  18 Oct 2015 21:33:18 -  1.467
> > +++ etc/rc  20 Oct 2015 18:03:58 -
> > @@ -353,7 +353,7 @@ make_keys
> >  
> >  echo -n 'starting early daemons:'
> >  start_daemon syslogd ldattach pflogd nsd unbound ntpd
> > -start_daemon iscsid isakmpd iked sasyncd ldapd npppd
> > +start_daemon iscsid isakmpd sasyncd ldapd npppd
> >  echo '.'
> 
> Most of these are dynamically linked.
> 
> You can make iked dynamic without moving it in the startup sequence.

In a lot of cases it will need the routing daemons to work anyway, so why
start it so much earlier?

Re: make iked not static

[Stuart Henderson]

On 2015/10/20 23:00, Sebastian Benoit wrote:
> Christian Weisgerber(na...@mips.inka.de) on 2015.10.20 20:46:12 +:
> > On 2015-10-20, Reyk Floeter  wrote:
> > 
> > > For historical reasons, isakmpd and iked are compiled static:
> > > people used NFS over ipsec.

isakmpd is an odd one. Reading cvs log, it started as a static
binary but used dlopen to load the libs. Anyone know the history
of that?

> > > Is anyone still using this?  Is it more than one person?
> > >
> > > Otherwise I'd suggest to make iked dynamic.
> > 
> > Already, iked is started after /usr has been mounted, so why the
> > static requirement?
> > 
> > > --- etc/rc18 Oct 2015 21:33:18 -  1.467
> > > +++ etc/rc20 Oct 2015 18:03:58 -
> > > @@ -353,7 +353,7 @@ make_keys
> > >  
> > >  echo -n 'starting early daemons:'
> > >  start_daemon syslogd ldattach pflogd nsd unbound ntpd
> > > -start_daemon iscsid isakmpd iked sasyncd ldapd npppd
> > > +start_daemon iscsid isakmpd sasyncd ldapd npppd
> > >  echo '.'
> > 
> > Most of these are dynamically linked.
> > 
> > You can make iked dynamic without moving it in the startup sequence.
> 
> In a lot of cases it will need the routing daemons to work anyway, so why
> start it so much earlier?

But in other cases (yay OSPFv3 - also bgpd with 'ipsec esp ike',
and pfsync setups without dedicated nic, if that still works)
you want IPsec up and running before the routing daemons.

pledge(2) hangman(6)

[Ricardo Mestre]

Hi tech@!

Let's give some pledge(2) love to hangman(6)!

It seems to work fine for me with the patch mentioned below, 
nevertheless please be aware that I don't consider myself a developer, 
just a mere OpenBSD user with 'security uncle syndrome' :D


That being said please don't beat me to death for trying to turn this 
lovely OS a little bit more secure :)


Index: src/games/hangman/main.c
===
RCS file: /cvs/src/games/hangman/main.c,v
retrieving revision 1.12
diff -u -p -u -r1.12 main.c
--- src/games/hangman/main.c7 Feb 2015 01:37:30 -   1.12
+++ src/games/hangman/main.c20 Oct 2015 19:54:01 -
@@ -43,6 +43,9 @@ main(int argc, char *argv[])
 {
int ch;

+   if (pledge("malloc tty rpath", NULL) == -1)
+   err(1, "pledge");
+
while ((ch = getopt(argc, argv, "d:hk")) != -1) {
switch (ch) {
case 'd':

Best regards,
Ricardo Mestre

accept 39B9-1135-C247

[Ricardo Mestre]

accept 39B9-1135-C247

A couple of style(9) tweaks

[Ilya Kaliman]

===
RCS file: /cvs/src/bin/ed/main.c,v
retrieving revision 1.53
diff -u -p -r1.53 main.c
--- bin/ed/main.c   9 Oct 2015 21:24:05 -   1.53
+++ bin/ed/main.c   20 Oct 2015 22:49:53 -
@@ -174,7 +174,7 @@ top:
signal(SIGHUP, signal_hup);
signal(SIGQUIT, SIG_IGN);
signal(SIGINT, signal_int);
-   if (status = sigsetjmp(env, 1)) {
+   if ((status = sigsetjmp(env, 1))) {
fputs("\n?\n", stderr);
seterrmsg("interrupt");
} else {
Index: usr.bin/rcs/co.c
===

===
RCS file: /cvs/src/usr.bin/rcs/co.c,v
retrieving revision 1.121
diff -u -p -r1.121 co.c
--- usr.bin/rcs/co.c13 Jun 2015 20:15:21 -  1.121
+++ usr.bin/rcs/co.c20 Oct 2015 22:52:04 -
@@ -515,7 +515,7 @@ checkout_err_nobranch(RCSFILE *file, con
file->rf_path,
date ? " a date before " : "",
date ? date : "",
-   author ? " and author " + (date ? 0:4 ) : "",
+   author ? " and author " + (date ? 0:4) : "",
author ? author : "",
state  ? " and state " + (date || author ? 0:4) : "",
state  ? state : "");
Index: usr.bin/who/who.c
===

===
RCS file: /cvs/src/usr.bin/who/who.c,v
retrieving revision 1.26
diff -u -p -r1.26 who.c
--- usr.bin/who/who.c   12 Oct 2015 19:56:47 -  1.26
+++ usr.bin/who/who.c   20 Oct 2015 22:52:04 -
@@ -77,7 +77,7 @@ main(int argc, char *argv[])
if (pledge("stdio rpath getpw", NULL) == -1)
err(1, "pledge");

-   if (mytty = ttyname(0)) {
+   if ((mytty = ttyname(0))) {
/* strip any directory component */
if ((t = strrchr(mytty, '/')))
mytty = t + 1;

Re: Unlocking ix(4) a bit further

[Hrvoje Popovski]

On 16.10.2015. 20:30, Mark Kettenis wrote:
>> Date: Fri, 16 Oct 2015 14:13:52 +0200
>> From: Martin Pieuchot 
>>
>> On 08/10/15(Thu) 20:49, Mark Kettenis wrote:
 Date: Wed, 30 Sep 2015 14:30:11 +0200 (CEST)
 From: Mark Kettenis 

 Since people seemed to like my diff for em(4), here is one for ix(4).
 In addition to unlocking the rx completion path, this one also uses
 intr_barrier() and removes the rx mutex that claudio@ put in recently.

 I don't have any ix(4) hardware.  So the only guarantee is that this
 compiles ;).
>>>
>>> Based on the experience with em(4), here is an updated diff.
>>
>> What's happening to this?  Mark did you get any test report?
> 
> Got a report from Hrvoje Popovski that this triggers OACTIVE a lot and
> sometimes even gets stuck completely.

Hi all,

i'm confirming what Mark said. I must admit that this traffic is
synthetic and maybe too aggressive for normal scenario.

With if_ix.c rev 1.125 i can't trigger OACTIVE flag, box is stable but i
can trigger
ix1: unable to fill any rx descriptors
ix1: Could not setup receive structures
I'm sorry that i haven't seen this with revision 1.125.


I will try to describe what I'm seeing with Marks patch.

traffic is routed between ix interfaces
sender is connected to ix1 (82599)
receiver is connected to ix0 (82599)

pf=NO
ddb.console=1
kern.pool_debug=1
net.inet.ip.forwarding=1
net.inet.ip.ifq.maxlen=1024

box is freshly rebooted and i'm generating cca 10Mpps
box is unstable and on receiver pps vary from 180kpps to 1.1Mpps (i
never seen 2Mpps on receiver)

# netstat -i 1
  em0 inem0 out  total in  total out
 packets  errs  packets  errs colls   packets  errs  packets  errs colls
 833 0  649 0 0  259125144 0 146427665 0 0
   2 02 0 0   1035261 0   341645 0 0
   1 01 0 0979946 0   177223 0 0
   1 02 0 0   1451247 0  1287839 0 0
   2 01 0 0   1095354 0   847450 0 0
   3 01 0 0985081 0   180134 0 0
   1 01 0 0   1034061 0   370778 0 0
   2 02 0 0   2182566 0  1420698 0 0
   1 01 0 0   1137561 0  1115412 0 0
   2 01 0 0   1012692 0   257518 0 0
   3 01 0 0965894 0   180484 0 0
   3 02 0 0988832 0   179729 0 0
   2 01 0 0959809 0   178349 0 0
   2 01 0 0   1003070 0   179792 0 0
   1 01 0 0989400 0   179187 0 0
   1 01 0 0   1007894 0   182429 0 0
   1 01 0 0   2211264 0  1455209 0 0
   1 01 0 0   2161230 0  2122498 0 0
   2 01 0 0   1136320 0  1078249 0 0
   1 01 0 0   1046122 0   486958 0 0
   2 02 0 0994789 0   177598 0 0


doing ifconfig ix0 down while generating traffic makes box really
unstable and sometimes breaks ssh session.  
after ifconfig ix0 down/up while generating traffic i'm getting stable
1Mpps, box is responsive and everything is fine ...

# netstat -i 1
  em0 inem0 out  total in  total out
 packets  errs  packets  errs colls   packets  errs  packets  errs colls
2348 0 1714 0 0  1102233921 0 58906 0 0
   2 03 0 0   1145492 0  1135339 0 0
   1 01 0 0   1526533 0  1492768 0 0
   3 03 0 0   1109545 0  1056238 0 0
   2 02 0 0   1255325 0  1250910 0 0
   2 02 0 0   1557626 0  1527923 0 0
   2 02 0 0   1136320 0  1113975 0 0
   2 02 0 0   1476924 0  1442136 0 0
   2 02 0 0   2248410 0  2203062 0 0
   2 02 0 0   2189965 0  2145617 0 0
   2 02 0 0   1786688 0  1740730 0 0
   2 02 0 0   2090607 0  2045849 0 0
   2 02 0 0   2151949 0  2110065 0 0
   3 04 0 0   1613589 0  1576791 0 0
   2 02 0 0   1958826 0  1915090 0 0
   2 02 0 0   1843465 0  1800886 0 0
   2 02 0 0   1107742 0  1054389 0 0
   3 02 0 0   1227703 0