From: Bryan Steele Subject: Re: Investigating adding functionality to doas To: tech@openbsd.org Date: Fri, 29 Nov 2024 12:52:49 -0500 On Fri, Nov 29, 2024 at 11:44:30AM -0600, Aaron Rainbolt wrote: > On Fri, 29 Nov 2024 17:39:13 +0000 > Stuart Henderson wrote: > > > On 2024/11/29 09:44, Theo de Raadt wrote: > > > Stuart Henderson wrote: > > > > > > > An alternative would be to put the configuration sections for > > > > these various programs into a default doas.conf distributed with > > > > the system. Or use a special binary based on doas which is _just_ > > > > used for these "internal" elevations and permits only them. > > > > > > But the ship has sailed. > > > > I meant in a fork, that's clearly not possible in doas itself. > > > > > We are not going to make this more complicated, and affect the > > > existing users who rely upon the simplicity. > > > > > > It is simple for a reason. There are always people showing up and > > > saying "but I want it to be more complicated, and here are my > > > complicated reasons, and the people who rely upon simplicity will > > > just adapt". > > ... > > > Anyone is free to fork doas codebase, add all the features they > > > want, CALL IT BY A NEW NAME WITH NEW COMMANDNAME, and in a couple > > > years collect all the features of sudo and start collecting bug > > > dangerous reports in those features. Anyone who thinks this isn't > > > how it will play out is being dishonest. > > > > yep. > > > > > > On 2024/11/29 11:30, Aaron Rainbolt wrote: > > > I am well aware that forking doas is an option. It's also one I'm > > > trying to avoid like the plague because as much as I trust I can > > > write good code, I don't trust myself to write good enough code on > > > my own. The fact that the only two CVEs ever reported against doas > > > were both in a fork of it and only affected the fork does not > > > escape me, and that's another big reason why I want to work with > > > upstream rather than forging my own path alone. Especially since > > > this is an SUID-root utility. > > > > But doas relies on TIOCCHKVERAUTH (in the kernel) for persist, so you > > need some kind of fork anyway... > > I mean, sure, but obviously the further one diverges from upstream, the > worse. Besides, I don't intend on using persist at all, partially > because Kicksecure doesn't need it, and partially because it's part of > what a fork would need to modify and that's scary. The ship had sailed when the PAM code was added. OpenBSD doas doesn't have that either, which is already a pretty big divergence. -Bryan.