Codex CLI 0.162.0 maakt de Linux-sandbox veiliger en lost Windows PowerShell-problemen op

Codex CLI 0.162.0 sluit twee kleine, maar belangrijke zwakke plekken in de manier waarop de Linux-sandbox van OpenAI is opgebouwd. In het eerste geval konden de eigen ripgrep-instellingen van een ontwikkelaar de uitsluitlijst van de sandbox verzwakken. In het tweede geval kon een schrijfbare bwrap-binary op PATH worden gekozen als starter van de sandbox. De release bevat daarnaast ook verbeteringen voor Windows, en die zijn relevant voor iedereen die Codex gebruikt in PowerShell of WSL2.

Wat er veranderde in het ripgrep-pad van de uitsluitlijst

Codex voert shellopdrachten uit binnen een sandbox, en de uitsluitlijst bepaalt welke bestanden buiten bereik blijven. Op Linux wordt die lijst omgezet in maskers door ripgrep te vragen welke bestanden overeenkomen met elke uitsluitglob. In de README van de Codex Linux-sandbox staat dit proces beschreven: Codex bouwt de maskers door ripgrep te laten zoeken naar bestanden die overeenkomen met elke uitsluitglob. Als ripgrep geen uitvoer geeft, blijft de lijst dus ook leeg. De aanbevolen scan in de README is rg --files --hidden --no-ignore --glob, met een interne globset-walker als terugvaloptie wanneer rg niet is geïnstalleerd.

Het zwakke punt is dat ripgrep gebruikersconfiguratie inleest. Volgens de eigen handleiding van ripgrep zoekt het niet in een vaste map naar een configuratiebestand. Je moet de omgevingsvariabele RIPGREP_CONFIG_PATH expliciet naar zo’n bestand laten verwijzen. Diezelfde handleiding zegt ook dat --no-config ervoor zorgt dat ripgrep nooit configuratie uit de omgeving leest.

Pull request #51527, samengevoegd op 7 oktober, beschrijft het probleem. Daar staat dat gebruikersconfiguratie van ripgrep de bestandslijst kan onderdrukken die wordt gebruikt om de uitsluitmaskers voor de Linux-sandbox op te bouwen, en dat --quiet in RIPGREP_CONFIG_PATH ervoor kan zorgen dat bestanden die eigenlijk door uitsluitglobs worden geraakt, niet worden gemaskeerd. De oplossing is om --no-config mee te geven aan de ripgrep-aanroep die de uitgesloten bestandsglobs uitbreidt.

De regressietest breidt de bestaande test met meerdere geweigerde bestanden uit. Daarin wordt een ripgrep-configuratie toegevoegd met --quiet, en vervolgens wordt gecontroleerd of geweigerde bestanden onleesbaar en onschrijfbaar blijven, terwijl toegestane bestanden toegankelijk blijven. De ripgrep-specifieke test wordt overgeslagen wanneer er geen beschermde rg-uitvoerbare beschikbaar is.

De oplossing voor bubblewrap-detectie

Bubblewrap (bwrap) is het hulpprogramma dat daadwerkelijk de Linux-sandbox opbouwt. In de README staat dat Codex de eerste bwrap op PATH kiest, zolang die zich buiten de huidige werkmap bevindt. Als er geen geschikte versie wordt gevonden, valt Codex terug op een meegeleverde kopie.

Pull request #51211, samengevoegd op 6 oktober, zegt dat het probleem is dat de detectie uitvoerbare bestanden controleert vóór de sandbox-isolatie. Als alleen de huidige map wordt uitgesloten, blijven kandidaten in andere schrijfbare paden geschikt om buiten de sandbox te worden uitgevoerd. De oplossing in de PR bestaat uit het volgende:

• Canonieke PATH-kandidaten worden gefilterd op basis van het bestandssysteembeleid en de effectieve gebruikersrechten. Daarmee worden schrijfbare bovenliggende mappen, symlink-constructies en volledige schijfschrijfbaarheid meegenomen.
• Beveiligde systeeminstallaties blijven toegestaan, terwijl vervangbare paden worden afgewezen.
• De starter wordt gekozen met de rechten van het commando zelf, nog vóór de preflight van de proc-mount, terwijl de meegeleverde bubblewrap-terugvaloptie behouden blijft.
• Voor opstartwaarschuwingen worden het effectieve permissieprofiel en de beleidsmatige werkmap gebruikt.

De tests voegen eenheidsdekking toe voor schrijfbare hoofdpaden, symlinks, read-only uitzonderingen, vervangbare bovenliggende mappen en schijfbrede schrijfbeleid. Linux-integratietests laten zien dat schrijfbare bwrap-kandidaten niet meer worden gecontroleerd of gestart. Dat geldt ook voor uitvoeringen vanuit een submap van een werkruimte en voor beheerde netwerken met volledige schrijfrechten op de schijf.

Hoe bezorgd moet je zijn?

Niet heel bezorgd, maar de verbeteringen zijn wel de moeite waard. Beide problemen hangen af van lokale omstandigheden:

• Het ripgrep-geval vereist een ripgrep-configuratie waarnaar iemand RIPGREP_CONFIG_PATH heeft verwezen, met opties die de uitvoer onderdrukken.
• Het bubblewrap-geval vereist een schrijfbare bwrap op PATH, vóór een beschermde versie.

In de release notes of pull requests wordt nergens melding gemaakt van misbruik in de praktijk, een aanval op afstand of een algemene omzeiling van elke installatie. Zie dit vooral als een versteviging van de manier waarop de sandbox zelf wordt opgebouwd. Veel ontwikkelaars gebruiken een ripgrep-configuratie voor onschuldige zaken, zoals kleuren, smart-case of --hidden. De les is dat elke beveiligingsgevoelige interne aanroep van een configureerbaar hulpprogramma de gebruikersconfiguratie moet negeren.

De release notes groeperen vier Linux-sandboxonderdelen samen: #50059, #51211, #51407 en #51527. Ze worden genoemd als gerelateerde bugfixes, niet als één enkele kwetsbaarheid.

Een gerelateerde operationele opmerking komt uit een melding van een derde partij. Daarin staat dat Codex 0.160.1 opgaf bij de eerste map die ripgrep niet kon tonen tijdens het uitbreiden van uitsluitglobs. In dat rapport blokkeerde het gegenereerde profiel vervolgens elk commando op Linux. Dat is een melding van een externe partij over een oudere versie, en niet iets wat de notities van 0.162.0 claimen op te lossen. Test je eigen uitsluitglob-profielen daarom opnieuw na de upgrade.

Windows-fixes in dezelfde release

De release notes van 0.162.0 noemen ook deze Windows-wijzigingen:

• Gewone bestandstoegang via stationsletters is hersteld in Windows 10 (#51511).
• De tijdelijke maprechten van de Windows-sandbox komen nu overeen met de omgeving van het kindproces (#51512).
• De controle van de archief-checksum werkt weer correct bij installatie via Windows PowerShell, ook wanneer PowerShell 7-modulepaden aanwezig zijn (#51257).
• Er wordt nu een ondertekend PowerShell-installatieprogramma meegeleverd met de Windows-releases (#51158).

Een handleiding van een derde partij vermeldt dat Codex in PowerShell een native sandbox gebruikt. In WSL2 gebruikt het de Linux-implementatie, waarvoor bubblewrap binnen de distributie geïnstalleerd moet zijn. De Linux-sandboxfixes zijn dus ook relevant voor Windows-ontwikkelaars die WSL2 gebruiken. Dat is een algemene uitleg over hoe Codex werkt, en niet iets wat letterlijk in de release notes staat.

Wat je het beste kunt doen

1. Controleer je versie met codex --version. Alles ouder dan 0.162.0 mist deze verbeteringen.
2. Werk bij via de methode waarmee je het hebt geïnstalleerd. Voor npm is het pakket @openai/codex, en 0.162.0 is de versie waar je op moet uitkomen.
3. Controleer op Linux of WSL2 met command -v bwrap of het verwijst naar een systeempad dat eigendom is van root en niet schrijfbaar is.
4. Als je een ripgrep-configuratie gebruikt, hoef je die niet te verwijderen. Door de fix negeert Codex die configuratie bij het uitbreiden van uitsluitglobs.
5. Controleer na de upgrade of een bestand dat door een uitsluitglob wordt geraakt, ook echt niet toegankelijk is binnen een Codex-sessie. Dat is een verstandige extra controle.

De upgrade is normaal gesproken routine, en de release notes noemen geen omweg voor oudere versies.