From: Fabien Romano Subject: Re: kern_pledge, allow sysctl hw.model & hw.cpuspeed To: Theo de Raadt Cc: Tobias Heider , tech@openbsd.org Date: Fri, 21 Jun 2024 07:47:22 +0100 On 20/06/2024 23:29, Theo de Raadt wrote: >> I would like so much. I can't do that without a lot of effort. I don't know a >> lot about electron internals yet but, depending on how the software is designed, >> it start directly into the chromium sandbox then load its nodejs app & modules. > > But instead you propose that everyone else put in a lot of effort. > > When anything new is allowed by pledge, we must audit *all software* that > uses pledge, to see if there is a downside. It wasn't obvious it need such effort, that's why I asked. This is exactly the kind of answer I was looking for. So it could be an issue. Then, for sure, I will look for an other solution instead of making a full audit (furthermore I'm not skilled enough to do so, I think). There are differents ways to solve this in ports. I guess I'm going to patch os.cpus() in electron, then I will see if model & cpuspeed informations are of any use. > Yes, for two sysctl nodes that seems a bit melodramatic. But the current > sysctl exposure was selected because a lot of software does it. Not just > 1 piece of software. I had this feeling, adding this for just two softwares looks overkill but it was the best answer regarding os.cpus() promise to provide this information. > And you aren't even done making it work. Will you return a couple more > times with further requests? At some point, big software cannot be > pledged, because it is big and belives it can do everything. It depends. As example, for me its obvious we can't allow mlock(2) call without huge audit. Furthermore the feature looks optionnal to me but I may be wrong as I don't understand exactly why it is used in the first place. For this one I just disable it at compilation time and it looks like I understood it right as it still work. I also have an issue with nodejs path.resolve() regarding unveil(2) and I had to unveil "/usr r" at least. I have to make my homework first, for now I guess it does not use realpath(3) but implement its own recursive resolver. Then the next one I may ask for, if it's not allowed under pledge(), is __realpath() ... If at the end I'm not able to sandbox electron's apps based on chromium rules then I may keep some of them with --no-sandbox but at least I have to try and do my best to overcome any issue I find. I needed to know in which direction to go regarding those two sysctl. Thanks.