From: "Theo de Raadt" To: ig0r@b3zdna.net cc: tech@openbsd.org Subject: Re: [PATCH] xenocara: change xterm ProcGetCWD to get cwd via sysctl instead of procfs Comments: In-reply-to ig0r@b3zdna.net message dated "Sun, 15 May 2022 22:30:46 -0400." Date: Sun, 15 May 2022 20:46:00 -0600 Sender: owner-tech@openbsd.org ig0r@b3zdna.net wrote: > > Eventually there will protocol or text side bug in xterm, and someone > > will figure out ways to escalate beyond our other mitigations. Rather > > than forcing them to operate inside an uncomfortable less-than-POSIX > > pledge+unveil environment, they can reuse a simple 1996-era shell-egg to > > execve straight to a fresh shell for their pleasure. Because pledge > > "proc exec" lets them do so. > > But should it not be up to us to make sure that these exploits are > mitigated? Is it not our responsibility to properly go through all of > the changes made to applications in the source tree to make sure they're > secure? You'll turn into a smurf before you finish auditing xterm perfectly. And in the meantime, a new version from upstream will arrive. My point of view is for critical pieces of code, the best way to curtail risk isn't just to review against bugs, but to minimize what the software can do if such bugs are triggered. So I argue we should try to force xterm into a somewhat privsep/privdrop mindset -- using pledge and unveil to constrain action when it goes off the rails, and hopefully collect crashes that alert us ahead of time about problems. And then, I think we can disable features that aren't being used, when we shrink the unveil and pledge. I wonder how "localeFilter" / "luit" is supposed to work, because we don't allow "exec", or is that started earlier, and if so has someone reviewed that code, and added pledge/unveil to restrict the failure modes? xterm is already full of #ifdef, why not add a few more? If people don't like the xterm variation we ship, there are 20+ xterm variations with all sorts of fluff they will use instead (and most of them probably have these features ... and far worse perhaps) That's how I see it. Others might not agree, probably because they are using features I don't.