Re: new env defaults for doas

[Ted Unangst]

Martijn van Duren wrote:
> I'm not convinced that LOGIN_SETPATH is a good idea here. From what I
> gathered that sets PATH from login.conf(5), while most environments I
> know will use .profile to set it and could cause unexpected behaviour
> if the my and targ PATH are reset to unexpected values.
> 
> I would vote to safe PATH from the caller instead of getting a likely
> unexpected or incomplete PATH environment based on login.conf.

Short answer is this is what su - does. We can set a default safe path, but
there's no reason that's better than what's in .profile either. With
login.conf, we get a safe default and a way for the admin to fix it if it's
not what they want.

pppoe: use timeout_add_sec(9)

[Klemens Nanni]

This is straight forward:  All integer arguments are positive multiples
of `hz', hence it can be safely reduced and the now minimum sleep of one
tick is given already.

One call sleeps a constant amount of
(hz / 50) [ticks] = (hz / 50) / hz [s] = 1 / 50 [s] = 0.02 [s] = 20 [ms]

Runs fine on my APU2's PPPoE link to ISP.
Feedback? OK?

Index: if_pppoe.c
===
RCS file: /cvs/src/sys/net/if_pppoe.c,v
retrieving revision 1.67
diff -u -p -r1.67 if_pppoe.c
--- if_pppoe.c  19 Feb 2018 08:59:52 -  1.67
+++ if_pppoe.c  15 Jun 2019 19:42:37 -
@@ -109,8 +109,8 @@ struct pppoetag {
PPPOE_ADD_16(PTR, SESS);\
PPPOE_ADD_16(PTR, LEN)
 
-#definePPPOE_DISC_TIMEOUT  (hz*5)  /* base for quick timeout 
calculation */
-#definePPPOE_SLOW_RETRY(hz*60) /* persistent retry interval */
+#definePPPOE_DISC_TIMEOUT  5   /* base for quick timeout 
calculation (seconds) */
+#definePPPOE_SLOW_RETRY60  /* persistent retry interval 
(seconds) */
 #definePPPOE_DISC_MAXPADI  4   /* retry PADI four times 
(quickly) */
 #definePPPOE_DISC_MAXPADR  2   /* retry PADR twice */
 
@@ -579,7 +579,7 @@ breakbreak:
PPPOEDEBUG(("%s: failed to send PADR, error=%d\n",
sc->sc_sppp.pp_if.if_xname, err));
}
-   timeout_add(>sc_timeout,
+   timeout_add_sec(>sc_timeout,
PPPOE_DISC_TIMEOUT * (1 + sc->sc_padr_retried));
 
break;
@@ -1086,7 +1086,7 @@ pppoe_timeout(void *arg)
PPPOEDEBUG(("%s: failed to transmit PADI, error=%d\n",
sc->sc_sppp.pp_if.if_xname, err));
}
-   timeout_add(>sc_timeout, retry_wait);
+   timeout_add_sec(>sc_timeout, retry_wait);
splx(x);
 
break;
@@ -1102,7 +1102,7 @@ pppoe_timeout(void *arg)
PPPOEDEBUG(("%s: failed to send PADI, 
error=%d\n",
sc->sc_sppp.pp_if.if_xname, err));
}
-   timeout_add(>sc_timeout,
+   timeout_add_sec(>sc_timeout,
PPPOE_DISC_TIMEOUT * (1 + sc->sc_padi_retried));
splx(x);
break;
@@ -1112,7 +1112,7 @@ pppoe_timeout(void *arg)
PPPOEDEBUG(("%s: failed to send PADR, error=%d\n",
sc->sc_sppp.pp_if.if_xname, err));
}
-   timeout_add(>sc_timeout,
+   timeout_add_sec(>sc_timeout,
PPPOE_DISC_TIMEOUT * (1 + sc->sc_padr_retried));
splx(x);
 
@@ -1146,7 +1146,7 @@ pppoe_connect(struct pppoe_softc *sc)
PPPOEDEBUG(("%s: failed to send PADI, error=%d\n",
sc->sc_sppp.pp_if.if_xname, err));
 
-   timeout_add(>sc_timeout, PPPOE_DISC_TIMEOUT);
+   timeout_add_sec(>sc_timeout, PPPOE_DISC_TIMEOUT);
splx(x);
 
return (err);
@@ -1346,7 +1346,7 @@ pppoe_tlf(struct sppp *sp)
 * function and defer disconnecting to the timeout handler.
 */
sc->sc_state = PPPOE_STATE_CLOSING;
-   timeout_add(>sc_timeout, hz / 50);
+   timeout_add_msec(>sc_timeout, 20);
 }
 
 static void

Re: unveil(2) sysctl(8)

[Ricardo Mestre]

sure, it wasn't mine! it was just missing one unveil so it's ok mestre@
on this one

On 11:42 Sat 15 Jun , Theo de Raadt wrote:
> yeah that was my idea..
> 
> Ricardo Mestre  wrote:
> 
> > Hi,
> > 
> > Sorry to be late in the game, but as jca@ pointed out sysctl(8) tries to
> > open _PATH_DEVDB first and then /dev if it cannot open the former, so
> > both should be unveil(2)ed. Scramble the includes while at it.
> > 
> > Index: sysctl.c
> > ===
> > RCS file: /cvs/src/sbin/sysctl/sysctl.c,v
> > retrieving revision 1.242
> > diff -u -p -u -r1.242 sysctl.c
> > --- sysctl.c13 May 2019 20:47:19 -  1.242
> > +++ sysctl.c14 Jun 2019 19:04:01 -
> > @@ -94,13 +94,14 @@
> >  #include 
> >  #include 
> >  
> > +#include 
> >  #include 
> >  #include 
> > +#include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > -#include 
> > -#include 
> >  #include 
> >  
> >  #include 
> > @@ -162,6 +163,8 @@ struct list secondlevel[] = {
> >  
> >  intAflag, aflag, nflag, qflag;
> >  
> > +time_t boottime;
> > +
> >  /*
> >   * Variables requiring special processing.
> >   */
> > @@ -255,6 +258,15 @@ main(int argc, char *argv[])
> > argc -= optind;
> > argv += optind;
> >  
> > +   ctime(); /* satisfy potential $TZ expansion before unveil() */
> > +
> > +   if (unveil(_PATH_DEVDB, "r") == -1)
> > +   err(1,"unveil");
> > +   if (unveil("/dev", "r") == -1)
> > +   err(1, "unveil");
> > +   if (unveil(NULL, NULL) == -1)
> > +   err(1, "unveil");
> > +
> > if (argc == 0 || (Aflag || aflag)) {
> > debuginit();
> > vfsinit();
> > @@ -893,7 +905,6 @@ parse(char *string, int flags)
> > }
> > if (special & BOOTTIME) {
> > struct timeval *btp = (struct timeval *)buf;
> > -   time_t boottime;
> >  
> > if (!nflag) {
> > boottime = btp->tv_sec;
> > 
> > On 10:35 Sat 08 Jun , Theo de Raadt wrote:
> > > When userland was massaged for pledge(), I hesitated using the
> > > "manually call tzset()" approach for handling things.  It felt
> > > too low-level to call tzset(), an API almost noone knows the
> > > existance of.
> > > 
> > > Arriving in the same situation to satisfy unveil().  Again calling
> > > tzset() feels too unfamiliar and low level.
> > > 
> > > Regarding the comment in your diff, it says "localtime", but what is
> > > actually called is ctime(), which calls localtime() (which calls
> > > tzset(), which is where the unveil-files-missing or pledge-whatver
> > > issues would show up in some programs).  Probably should adjust
> > > the comment
> > > 
> > > Here's the later troublesome chunk:
> > > 
> > > if (special & BOOTTIME) {
> > > struct timeval *btp = (struct timeval *)buf;
> > > time_t boottime;
> > > 
> > > if (!nflag) {
> > > boottime = btp->tv_sec;
> > > (void)printf("%s%s%s", string, equ, 
> > > ctime());
> > > 
> > > That makes me wonder, can we be less obtuse up front, and
> > > prime the subsystem before unveil by calling the same function which
> > > will be called later?
> > > 
> > > Something like this.  It feels slightly better to me.
> > > 
> > > Index: sysctl.c
> > > ===
> > > RCS file: /cvs/src/sbin/sysctl/sysctl.c,v
> > > retrieving revision 1.242
> > > diff -u -p -u -r1.242 sysctl.c
> > > --- sysctl.c  13 May 2019 20:47:19 -  1.242
> > > +++ sysctl.c  8 Jun 2019 16:33:07 -
> > > @@ -162,6 +162,8 @@ struct list secondlevel[] = {
> > >  
> > >  int  Aflag, aflag, nflag, qflag;
> > >  
> > > +time_t boottime;
> > > +
> > >  /*
> > >   * Variables requiring special processing.
> > >   */
> > > @@ -255,6 +257,12 @@ main(int argc, char *argv[])
> > >   argc -= optind;
> > >   argv += optind;
> > >  
> > > + ctime(); /* satisfy potential $TZ expansion before unveil() */
> > > +
> > > + if (unveil("/dev", "r") == -1)
> > > + err(1, "unveil");
> > > + if (unveil(NULL, NULL) == -1)
> > > + err(1, "unveil");
> > >   if (argc == 0 || (Aflag || aflag)) {
> > >   debuginit();
> > >   vfsinit();
> > > @@ -893,7 +901,6 @@ parse(char *string, int flags)
> > >   }
> > >   if (special & BOOTTIME) {
> > >   struct timeval *btp = (struct timeval *)buf;
> > > - time_t boottime;
> > >  
> > >   if (!nflag) {
> > >   boottime = btp->tv_sec;
> > > 
> > > 
> > > 
> > > 
> > > 
> > > Florian Obser  wrote:
> > > 
> > > > On Fri, Jun 07, 2019 at 11:24:30PM +0100, Ricardo Mestre wrote:
> > > > > i did that and for some for reason i didn't get it! it tries to open
> > > > > timezone so it kinda looks like a red flag right there...
> > > > > 
> > > > > apart from /dev do we need to look into TZ on this one as well? if TZ
> > > > > var needs 

acme-client(1): elliptic curve account key

[Florian Obser]

OK?

diff --git acctproc.c acctproc.c
index 52309b765d5..09ac8c83372 100644
--- acctproc.c
+++ acctproc.c
@@ -24,6 +24,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -90,6 +91,42 @@ op_thumb_rsa(EVP_PKEY *pkey)
return json;
 }
 
+/*
+ * Extract the relevant EC components from the key and create the JSON
+ * thumbprint from them.
+ */
+static char *
+op_thumb_ec(EVP_PKEY *pkey)
+{
+   BIGNUM  *X = NULL, *Y = NULL;
+   EC_KEY  *ec = NULL;
+   char*x = NULL, *y = NULL;
+   char*json = NULL;
+
+   if ((ec = EVP_PKEY_get1_EC_KEY(pkey)) == NULL)
+   warnx("EVP_PKEY_get1_EC_KEY");
+   else if ((X = BN_new()) == NULL)
+   warnx("BN_new");
+   else if ((Y = BN_new()) == NULL)
+   warnx("BN_new");
+   else if (!EC_POINT_get_affine_coordinates_GFp(EC_KEY_get0_group(ec),
+   EC_KEY_get0_public_key(ec), X, Y, NULL))
+   warnx("EC_POINT_get_affine_coordinates_GFp");
+   else if ((x = bn2string(X)) == NULL)
+   warnx("bn2string");
+   else if ((y = bn2string(Y)) == NULL)
+   warnx("bn2string");
+   else if ((json = json_fmt_thumb_ec(x, y)) == NULL)
+   warnx("json_fmt_thumb_rsa");
+
+   EC_KEY_free(ec);
+   BN_free(X);
+   BN_free(Y);
+   free(x);
+   free(y);
+   return json;
+}
+
 /*
  * The thumbprint operation is used for the challenge sequence.
  */
@@ -109,6 +146,10 @@ op_thumbprint(int fd, EVP_PKEY *pkey)
if ((thumb = op_thumb_rsa(pkey)) != NULL)
break;
goto out;
+   case EVP_PKEY_EC:
+   if ((thumb = op_thumb_ec(pkey)) != NULL)
+   break;
+   goto out;
default:
warnx("EVP_PKEY_type: unknown key type");
goto out;
@@ -183,6 +224,42 @@ op_sign_rsa(char **prot, EVP_PKEY *pkey, const char 
*nonce, const char *url)
return rc;
 }
 
+static int
+op_sign_ec(char **prot, EVP_PKEY *pkey, const char *nonce, const char *url)
+{
+   BIGNUM  *X = NULL, *Y = NULL;
+   EC_KEY  *ec = NULL;
+   char*x = NULL, *y = NULL;
+   int rc = 0;
+
+   *prot = NULL;
+
+   if ((ec = EVP_PKEY_get1_EC_KEY(pkey)) == NULL)
+   warnx("EVP_PKEY_get1_EC_KEY");
+   else if ((X = BN_new()) == NULL)
+   warnx("BN_new");
+   else if ((Y = BN_new()) == NULL)
+   warnx("BN_new");
+   else if (!EC_POINT_get_affine_coordinates_GFp(EC_KEY_get0_group(ec),
+   EC_KEY_get0_public_key(ec), X, Y, NULL))
+   warnx("EC_POINT_get_affine_coordinates_GFp");
+   else if ((x = bn2string(X)) == NULL)
+   warnx("bn2string");
+   else if ((y = bn2string(Y)) == NULL)
+   warnx("bn2string");
+   else if ((*prot = json_fmt_protected_ec(x, y, nonce, url)) == NULL)
+   warnx("json_fmt_protected_ec");
+   else
+   rc = 1;
+
+   EC_KEY_free(ec);
+   BN_free(X);
+   BN_free(Y);
+   free(x);
+   free(y);
+   return rc;
+}
+
 /*
  * Operation to sign a message with the account key.
  * This requires the sender ("fd") to provide the payload and a nonce.
@@ -190,14 +267,19 @@ op_sign_rsa(char **prot, EVP_PKEY *pkey, const char 
*nonce, const char *url)
 static int
 op_sign(int fd, EVP_PKEY *pkey, enum acctop op)
 {
-   char*nonce = NULL, *pay = NULL, *pay64 = NULL;
-   char*prot = NULL, *prot64 = NULL;
-   char*sign = NULL, *dig64 = NULL, *fin = NULL;
-   char*url = NULL, *kid = NULL;
-   unsigned char   *dig = NULL;
-   EVP_MD_CTX  *ctx = NULL;
-   int  cc, rc = 0;
-   unsigned int digsz;
+   EVP_MD_CTX  *ctx = NULL;
+   const EVP_MD*evp_md = NULL;
+   EC_KEY  *ec;
+   ECDSA_SIG   *ec_sig = NULL;
+   const BIGNUM*ec_sig_r = NULL, *ec_sig_s = NULL;
+   int  cc, rc = 0;
+   unsigned int digsz, bufsz, degree, bn_len, r_len, s_len;
+   char*nonce = NULL, *pay = NULL, *pay64 = NULL;
+   char*prot = NULL, *prot64 = NULL;
+   char*sign = NULL, *dig64 = NULL, *fin = NULL;
+   char*url = NULL, *kid = NULL, *alg = NULL;
+   unsigned char   *dig = NULL, *buf = NULL;
+   const unsigned char *digp;
 
/* Read our payload and nonce from the requestor. */
 
@@ -219,8 +301,23 @@ op_sign(int fd, EVP_PKEY *pkey, enum acctop op)
goto out;
}
 
+   switch (EVP_PKEY_type(pkey->type)) {
+   case EVP_PKEY_RSA:
+   alg = "RS256";
+   evp_md = EVP_sha256();
+   break;
+   case EVP_PKEY_EC:
+   alg = "ES384";
+   evp_md = EVP_sha384();
+ 

Re: [patch] default promises for unprivileged processes

[Bryan Steele]

On Sat, Jun 15, 2019 at 04:05:14PM +0200, Srikant T wrote:
> + /* XXX cludge to let Xorg function */
> + if (35 == p->p_ucred->cr_uid)
> + return;

This is completely unacceptable.

Kludge is spelled with a K.

> ---
> END.
> 
> 

Re: new env defaults for doas

[Theo de Raadt]

Martijn van Duren  wrote:

> Sorry for the delay.
> 
> I like the general direction, but I'm not 100% convinced the semantics
> are fine-tuned enough.
> 
> On 6/13/19 4:16 AM, Ted Unangst wrote:
> > This has come up a few times before. For background, the default rule for 
> > doas
> > is to copy a few environment settings from the user and omit the rest. This 
> > is
> > to prevent confusion, and also supposedly for security. However, some of the
> > alleged safe variables like PATH probably aren't that safe. And things like
> > USER are confusing? And why even bother with MAIL? The list is kinda adhoc 
> > and
> > mostly copied from what I understood sudo to do at the time, but I believe
> > sudo has changed defaults as well.
> > 
> > So here's a new model which I think is safer and more consistent.
> > 
> > 1. Always add a DOAS_USER with the invoking user's name.
> 
> Why not add a DOAS_UID and DOAS_GID as well. From testing I found that
> sudo sets them from the passwd values, but since these values can easily
> be derived from DOAS_USER (unless there's overlap between passwd(5) and
> ypldap(8)); I propose that we save the original uid and egid. Egid,
> because that's the gid that's actually in effect and uid because we
> already lost euid to doas (0).
> suggested diff below.
> 
> I don't know if it's worth to store DOAS_COMMAND (similar to sudo), or
> maybe store some additional values that we overwrite by default, but it's
> easier to add to the DOAS_* set than remove them, so that can always be
> determined later.

Why do all this?  How many usage cases are there?  I can't think of any.
Will a sub-process ever be in a situation where it knows more than it
should?  That feels more likely.

Re: [patch] default promises for unprivileged processes

[Theo de Raadt]

Your diff isn't a change to pledge -- it is completely tearing up
the POSIX rulebook for all programs.

I am not interested in the way it goes.

[patch] default promises for unprivileged processes

[Srikant T]

Hi,

Sharing my patch in case someone finds it useful. Didn't have much to offer 
besides donations and CD purchases all these years. 

Tested on amd64 6.5-stable (Changes are not arch-dependent) : base + Xorg + vmd 
+ ntpd + sshd + chromium : work fine
Patch is against current src tree as on 2019-06-15.

The current thoroughly done pledge(2) mechanism goes deep in denying dangerous 
functionality to pledged processes. Depth is apparent in sysctl(2), ioctl(2) 
and namei(9) scrutiny. 

The only issue is that it is voluntary :
1. Attacker's code will not make a pledge.
2. Unpledged software is missing out on this extra security.
3. The model is that the program does all of it's prep-work early and then 
makes a pledge. But during the prep-work no restrictions are imposed. This is 
needed for processes which start as root and daemons, but for the rest of 
unprivileged processes, leaves a window of unrestricted behaviour.


This patch is a kernel change which enforces a default set of promises and a 
syscall whitelist in the form of promises on all unprivileged processes.


This is how it works :
+ The root processes are left untouched. This is to provide a way via doas(1) 
to gain restricted functionality. Also ensures that boot and init scripts are 
not interfered with. Of course, privsep'ed daemons will cotinue to work.

+ We have a default promises list which includes all the functionality needed 
for Xorg (_x11), chromium, vmd, ntpd and all /bin /sbin tools. This list looks 
big but reflects reality. Still, better to have additional checks and 
hard-coded enforcements such as ACCESSPERMS, than not.

+ All subsequent pledge(2) calls are enforced to be subsets of the default 
promises. This is enforced silently to let over-pledged programs go past 
pledge(2) calls into program flows where they may not exercise any restricted 
functionality, which is caught anyway. In short, allow more programs to work 
for more command line options or control flows without modification. pledge(2) 
itself is not the end, syscall is, hence.

+ execve(2), set.*uid(2) syscall handlers set the default promises when uid 
changes to or is non-zero.

+ A syscall whitelist (same as default promises) is enforced early in the chain 
for unprivileged porcesses. Independant of pledge(2) mechanism, this 
effectively ensures all unprivileged software is prevented from dangerous 
operations early. This was optional, but I wanted it this way.

+ Default promises are immutable right now since they are already very 
comprehensive. For more secure server/firmware requirements, sys admins may 
want to further tighten it. If folks are interested, this can be exposed as a 
sysctl setting which can be set early on boot before securelevel is raised to 1 
or 2.

+ Removed PLEDGE_ERROR or "error" promise to ensure malicious/compromised 
process doesn't get to live. Detailed error message gives enough information to 
know why it aborted. This whole patch is about enforcement rather than 
voluntary restrictions.


Advantages of using this patch :
+ Everything runs pledged whether explicitly or otherwise (root can be 
discounted since trying to contain root is futile). Hence, more security than 
the current default, especially for ports and software from non-OpenBSD sources.

+ Default promises set provides a single knob to control what you want to 
permit on your machine based on the intended functionality.

+ Slightly more informative pledge violation error messages


Disadvantages of using this patch :
+ Available syscalls list has shrunk a little and they have become more 
restrictive. The kernel contract with software changed since this is now 
default for all unprivileged processes.

+ Current assumptions of programmers are not exactly correct anymore. Those who 
use pledge(2) understand what they are getting into, but default promises 
changes that for those who didn't pledge(2) or don't care or can't pledge(2).

+ May induce people to open up their doas.conf too much or turn on setuid bit 
more.

+ Of course, compiling your own kernel may reduce chances of getting help on 
mailing lists.


Do let me know if modifications are needed or there are any questions.
Also have the same patch ready against 6.5-stable if needed.

Srikant T.
--


--- ./sys/arch/amd64/amd64/vmm.c.orig   Sat Jun 15 13:49:35 2019
+++ ./sys/arch/amd64/amd64/vmm.cSat Jun 15 15:26:42 2019
@@ -763,7 +763,7 @@ vm_find(uint32_t id, struct vm **res)
if (((p->p_p->ps_pledge &
(PLEDGE_VMM|PLEDGE_PROC)) == PLEDGE_VMM) &&
(vm->vm_creator_pid != p->p_p->ps_pid))
-   return (pledge_fail(p, EPERM, PLEDGE_VMM));
+   return (pledge_fail(p, EPERM, PLEDGE_VMM, 
"vm_find"));
*res = vm;
return (0);
}
--- ./sys/kern/kern_pledge.c.orig   Sat Jun 15 13:50:39 2019
+++ 

Re: net80211: more steady Tx rate with MiRa (please test)

[Matthias Schmidt]

Hi,

* Stefan Sperling wrote:
> 
> This diff has no effect on management frames; it only affects transmit
> rate of data frames while in assocated state; association state is
> kept alive by received frames, not by frames being sent.
> 
> I don't see how the diff could be causing either of your issues.
> They must have been present already.
> 
> Check 'ifconfig iwn0 debug' and see which messages correlate to disconnects.
> You're probably running into known issues with background scan (sends deauth
> to old AP but never switches to new AP; stays dead until down/up) and/or
> dead AP detection (sends probe request to AP, never gets a response, drops
> to SCAN state, takes some time to find the AP again, reconnects).

Seems you were quite right.  The first disconnect I had today was
related to a firmware error.

Cheers

Matthias

2019-06-15T10:57:42.422Z sigma /bsd: iwm0: fatal firmware error
2019-06-15T10:57:42.422Z sigma /bsd: iwm0: RUN -> INIT
2019-06-15T10:57:42.592Z sigma /bsd: iwm0: begin active scan
2019-06-15T10:57:42.593Z sigma /bsd: iwm0: INIT -> SCAN
2019-06-15T10:57:45.797Z sigma /bsd: iwm0: end active scan
2019-06-15T10:57:45.797Z sigma /bsd: iwm0: - 00:1e:2a:e1:18:906   +17 54M   
ess  privacy   rsn  "ChaosUnlimited"!
2019-06-15T10:57:45.798Z sigma /bsd: iwm0: - 12:62:e5:d1:fd:a96   +21 54M   
ess  privacy   rsn  "DIRECT-A9-HP OfficeJet 5200"!
2019-06-15T10:57:45.798Z sigma /bsd: iwm0: - 1c:3a:de:64:90:5b   13   +18 54M   
ess  privacy   rsn  "CelenoInitialAP64905B"!
2019-06-15T10:57:45.798Z sigma /bsd: iwm0: - 38:10:d5:79:a3:4a6   +21 54M   
ess  privacy   rsn  "FRITZ!BS"!
2019-06-15T10:57:45.799Z sigma /bsd: iwm0: - 44:4e:6d:98:c6:176   +21 54M   
ess  privacy   rsn  "FRITZ!Box 6490 Cable"!
2019-06-15T10:57:45.799Z sigma /bsd: iwm0: - 44:4e:6d:ec:3c:d31   +21 54M   
ess  privacy   rsn  "FRITZ!Box 6490 Cable"!
2019-06-15T10:57:45.799Z sigma /bsd: iwm0: - 44:fe:3b:10:c5:dc1   +17 54M   
ess   no!  rsn! "Telekom_FON"!
2019-06-15T10:57:45.800Z sigma /bsd: iwm0: - 46:4e:6d:ec:3c:d31   +21 54M   
ess  privacy   rsn  "FRITZ!"!
2019-06-15T10:57:45.800Z sigma /bsd: iwm0: - 54:67:51:3d:90:46   11   +49 54M   
ess  privacy   rsn  "melbourne2016"!
2019-06-15T10:57:45.800Z sigma /bsd: iwm0: - 54:67:51:3d:90:c8   36   +35 54M   
ess  privacy   rsn  "melbourne2016"!
2019-06-15T10:57:45.800Z sigma /bsd: iwm0: - 56:67:11:3d:90:46   11   +48 54M   
ess  privacy   rsn! "Unitymedia WifiSpot"!
2019-06-15T10:57:45.800Z sigma /bsd: iwm0: - 90:5c:44:24:40:fa  100   +21 54M   
ess  privacy   rsn  "UPC6ED3663"!
2019-06-15T10:57:45.801Z sigma /bsd: iwm0: - 90:5c:44:24:41:03   11   +17 54M   
ess  privacy   rsn  "UPC6ED3663"!
2019-06-15T10:57:45.801Z sigma /bsd: iwm0: - 90:5c:44:27:c6:1b6   +17 54M   
ess  privacy   rsn  "UPC89142D1"!
2019-06-15T10:57:45.801Z sigma /bsd: iwm0: - 90:5c:44:cf:2c:e66   +17 54M   
ess  privacy   rsn  "UPCE5AEF49"!
2019-06-15T10:57:45.802Z sigma /bsd: iwm0: - 90:5c:44:db:c8:e56   +19 54M   
ess  privacy   rsn  "UPC877738E"!
2019-06-15T10:57:45.802Z sigma /bsd: iwm0: - 90:5c:44:dd:72:486   +17 54M   
ess  privacy   rsn  "UPCA7A2229"!
2019-06-15T10:57:45.802Z sigma /bsd: iwm0: - 92:5c:14:24:41:03   11   +17 54M   
ess  privacy   rsn! "Unitymedia WifiSpot"!
2019-06-15T10:57:45.802Z sigma /bsd: iwm0: - ae:22:15:d0:db:bf   11   +17 54M   
ess  privacy   rsn! "Unitymedia WifiSpot"!
2019-06-15T10:57:45.803Z sigma /bsd: iwm0: - cc:ce:1e:8b:cf:d1   60   +31 54M   
ess  privacy   rsn  "hs.ka.v01d"!
2019-06-15T10:57:45.803Z sigma /bsd: iwm0: + cc:ce:1e:8b:cf:d23   +46 54M   
ess  privacy   rsn  "karlsruhe.v01d"
2019-06-15T10:57:45.803Z sigma /bsd: iwm0: - d4:21:22:53:3a:9b1   +17 54M   
ess  privacy   rsn  "WLAN-604342"!
2019-06-15T10:57:45.804Z sigma /bsd: iwm0: - e0:28:6d:16:2b:18   11   +21 54M   
ess  privacy   rsn  "FRITZ!Box 7490"!
2019-06-15T10:57:45.804Z sigma /bsd: iwm0: SCAN -> AUTH
2019-06-15T10:57:45.804Z sigma /bsd: iwm0: sending auth to cc:ce:1e:8b:cf:d2 on 
channel 3 mode 11g
2019-06-15T10:57:45.813Z sigma /bsd: iwm0: AUTH -> ASSOC
2019-06-15T10:57:45.813Z sigma /bsd: iwm0: sending assoc_req to 
cc:ce:1e:8b:cf:d2 on channel 3 mode 11g
2019-06-15T10:57:45.825Z sigma /bsd: iwm0: ASSOC -> AUTH
2019-06-15T10:57:50.549Z sigma /bsd: iwm0: AUTH -> SCAN
2019-06-15T10:57:53.682Z sigma /bsd: iwm0: end active scan
2019-06-15T10:57:53.682Z sigma /bsd: iwm0: - 00:1e:2a:e1:18:906   +18 54M   
ess  privacy   rsn  "ChaosUnlimited"!
2019-06-15T10:57:53.682Z sigma /bsd: iwm0: - 44:4e:6d:ee:7e:ae1   +21 54M   
ess  privacy   rsn  "FRITZ!Box 6490 Cable"!
2019-06-15T10:57:53.683Z sigma /bsd: iwm0: - 44:fe:3b:42:1d:22   11   +17 54M   
ess  privacy   rsn  "WLAN-331218"!
2019-06-15T10:57:53.683Z sigma /bsd: iwm0: - 44:fe:3b:42:1d:24   11   +17 54M   
ess   no!  rsn! "Telekom_FON"!
2019-06-15T10:57:53.683Z sigma /bsd: iwm0: - 54:67:51:3d:90:46   11   +56 54M   
ess  privacy   rsn  "melbourne2016"!
2019-06-15T10:57:53.683Z sigma /bsd: 

Re: new env defaults for doas

[Martijn van Duren]

Sorry for the delay.

I like the general direction, but I'm not 100% convinced the semantics
are fine-tuned enough.

On 6/13/19 4:16 AM, Ted Unangst wrote:
> This has come up a few times before. For background, the default rule for doas
> is to copy a few environment settings from the user and omit the rest. This is
> to prevent confusion, and also supposedly for security. However, some of the
> alleged safe variables like PATH probably aren't that safe. And things like
> USER are confusing? And why even bother with MAIL? The list is kinda adhoc and
> mostly copied from what I understood sudo to do at the time, but I believe
> sudo has changed defaults as well.
> 
> So here's a new model which I think is safer and more consistent.
> 
> 1. Always add a DOAS_USER with the invoking user's name.

Why not add a DOAS_UID and DOAS_GID as well. From testing I found that
sudo sets them from the passwd values, but since these values can easily
be derived from DOAS_USER (unless there's overlap between passwd(5) and
ypldap(8)); I propose that we save the original uid and egid. Egid,
because that's the gid that's actually in effect and uid because we
already lost euid to doas (0).
suggested diff below.

I don't know if it's worth to store DOAS_COMMAND (similar to sudo), or
maybe store some additional values that we overwrite by default, but it's
easier to add to the DOAS_* set than remove them, so that can always be
determined later.
> 
> 2. When doing keepenv, nothing changes, except addition of above.

It feels inconsistent to make keepenv behave different here.
- It may allow certain applications to behave unexpected compared to
  without keepenv (e.g. scripts that use $HOME/.cache).
- The values are hard to retrofit into doas.conf by the end-user, while
  it's easy to keep the original with setenv { HOME ... }.

I'm not convinced one way or the other, but for now it just feels weird.
> 
> 3. When starting with a new environment, fill in USER and HOME and such with
> the values of the target user, instead of copying from the invoking user. You
> run a command as a user, you should have that user's environment.

This I like.
> 
> 4. DISPLAY and TERM are still copied, since they represent a description of
> the actual environment in which we are running. (Not sure how useful display
> is without xauth cookies, but not my problem.)
> 
Sure.

> 5. As before, anything can be overridden with setenv in the config.

See point 2.
> 
> This is a kinda breaking change, but probably in a good way.
> For simple configurations, I expect nothing changes. For more complicated
> setups, this new handling is probably closer to what the admin expects or
> desires.
> 
> 
> Index: doas.c
> ===
> RCS file: /home/cvs/src/usr.bin/doas/doas.c,v
> retrieving revision 1.76
> diff -u -p -r1.76 doas.c
> --- doas.c12 Jun 2019 02:50:29 -  1.76
> +++ doas.c13 Jun 2019 02:11:07 -
> @@ -421,6 +421,7 @@ main(int argc, char **argv)
>   errx(1, "no passwd entry for target");
>  
>   if (setusercontext(NULL, targpw, target, LOGIN_SETGROUP |
> + LOGIN_SETPATH |
>   LOGIN_SETPRIORITY | LOGIN_SETRESOURCES | LOGIN_SETUMASK |
>   LOGIN_SETUSER) != 0)
>   errx(1, "failed to set user context for target");
> @@ -439,8 +440,13 @@ main(int argc, char **argv)
>   syslog(LOG_AUTHPRIV | LOG_INFO, "%s ran command %s as %s from %s",
>   mypw->pw_name, cmdline, targpw->pw_name, cwd);
>  
> - envp = prepenv(rule);
> + envp = prepenv(rule, mypw, targpw);
>  
> + if (rule->cmd) {
> + /* do this again after setusercontext reset it */
> + if (setenv("PATH", safepath, 1) == -1)
> + err(1, "failed to set PATH '%s'", safepath);
> + }
>   execvpe(cmd, argv, envp);
>  fail:
>   if (errno == ENOENT)

I'm not convinced that LOGIN_SETPATH is a good idea here. From what I
gathered that sets PATH from login.conf(5), while most environments I
know will use .profile to set it and could cause unexpected behaviour
if the my and targ PATH are reset to unexpected values.

I would vote to safe PATH from the caller instead of getting a likely
unexpected or incomplete PATH environment based on login.conf.

> Index: doas.conf.5
> ===
> RCS file: /home/cvs/src/usr.bin/doas/doas.conf.5,v
> retrieving revision 1.35
> diff -u -p -r1.35 doas.conf.5
> --- doas.conf.5   7 Feb 2018 05:13:57 -   1.35
> +++ doas.conf.5   13 Jun 2019 01:41:18 -
> @@ -51,15 +51,9 @@ again for some time.
>  .It Ic keepenv
>  The user's environment is maintained.
>  The default is to reset the environment, except for the variables
> -.Ev DISPLAY ,
> -.Ev HOME ,
> -.Ev LOGNAME ,
> -.Ev MAIL ,
> -.Ev PATH ,
> -.Ev TERM ,
> -.Ev USER
> +.Ev DISPLAY
>  and
> -.Ev USERNAME .
> +.Ev TERM .
>  .It Ic setenv { Oo Ar variable ... Oc Oo 

Re: net80211: more steady Tx rate with MiRa (please test)

[Stefan Sperling]

On Fri, Jun 14, 2019 at 05:33:41PM +0200, Matthias Schmidt wrote:
> Hi,
> 
> * Stefan Sperling wrote:
> > On Fri, Jun 14, 2019 at 01:01:58PM +0200, Matthias Schmidt wrote:
> > > Hi Stefan,
> > > 
> > > * Stefan Sperling wrote:
> > > > 
> > > > Since I am knee-deep in Tx aggregation right now, I would like to 
> > > > delegate
> > > > testing of the diff below against plain -current to the community.
> > > > If some of you could test the diff below and report back to me I would
> > > > appreciate it.
> > > > You don't need to get numbers from wireshark for this if you don't want 
> > > > to.
> > > > Letting me know if Tx is faster or not and whether there are any 
> > > > perceived
> > > > regressions is sufficient.
> > > 
> > > I tested your diff for the last two days and noticed a regression
> > > After some time one of the two things happens:
> > 
> > Are you sure these problem are introduced by this diff?
> > I am quite certain that these symptoms must be unrelated.
> 
> The first problem also shows up without your diff, however, the
> reconnect happens a lot faster.  I will spend some more time testing.

This diff has no effect on management frames; it only affects transmit
rate of data frames while in assocated state; association state is
kept alive by received frames, not by frames being sent.

I don't see how the diff could be causing either of your issues.
They must have been present already.

Check 'ifconfig iwn0 debug' and see which messages correlate to disconnects.
You're probably running into known issues with background scan (sends deauth
to old AP but never switches to new AP; stays dead until down/up) and/or
dead AP detection (sends probe request to AP, never gets a response, drops
to SCAN state, takes some time to find the AP again, reconnects).