Alpine Linux wil sudo-commando door doas van OpenBSD vervangen

De op beveiliging gerichte lichtgewicht Linux-distributie Alpine Linux gaat bij de komende versie waarschijnlijk overstappen van sudo naar doas. De ontwikkelaars beschouwen de OpenBSD-tool als een simpeler implementatie van de sudo-functionaliteit.

Sudo maakt bij het verschijnen van Alpine Linux 3.16 de overstap naar de community-repository. Het voorstel is om deze functionaliteit te vervangen door doas in de main-repository. Dat meldt het ontwikkelteam van Alpine Linux bij de releasenotes van het pas verschenen Alpine Linux 3.15.

Het voorstel werd in eerste instantie een jaar geleden ingediend omdat doas een eenvoudigere implementatie van de sudo-functionaliteit zou bieden, en vier maanden geleden werd dit uitgewerkt door het beveiligingsteam van Alpine Linux. Dat team wijst er onder andere op dat het nu nog twee jaar lang beveiligingsupdates voor sudo moet garanderen. Bij een overstap op doas zou dat niet meer hoeven. Doas heeft minder functies dan sudo, maar is ook minder complex en heeft een kleinere codebase, met voordelen wat betreft beheer en beveiliging.

Doas is oorspronkelijk ontwikkeld voor OpenBSD als sudo-vervanger en verscheen in 2015 in versie 5.8 van dat OS. Alpine Linux is een compacte Linux-distro, gericht op beveiliging en efficiëntie. Het is opgetrokken rond de BusyBox-verzameling van Unix-tools.

Reacties (89)

[afterburn]

Ik vind de discussie sudo <> doas een beetje vreemd. Het zal best zo zijn dat de code van sudo na al die jaren groot en uit de complex geworden is. Vind ik eerlijk gezegd niet zo interessant. Dat er zo nu en dan een bug gevonden wordt ook niet. Maar die discussies gaan compleet voor bij aan een paar olifanten in de kamer:

1) Waarom mag Jan en Alleman inloggen op systemen en scripts runnen. Stap 1 bij beveiliging is het limiteren van toegang. Als niemand toegang heeft, is er ook geen probleem met sudo
2) Waarom lopen we op Linux en Unix nog steeds to kloten met een archaisch systeem dat maar 2 niveaus kent: alles (root) of niks (de rest). In plaats van de zeuren over de merits van sudo en doas of vv, zou er geinvesteerd moeten worden in een fatsoenlijk systeem rond het beheer van rechten.

Dit is alleen pappen en nathouden. Er zullen hele felle discussies gehouden worden over dit onderwerp, met heel veel passie aan beide zijden. Maar het gaat compleet voorbij aan het feit dat het permissies systeem van Linux en Unix 50 jaar oud is en niet meer van deze tijd. Dat kan beter en intelligenter. Heck, Novell had dit 35 jaar geleden al door.

[Reactie gewijzigd door afterburn op 23 juli 2024 05:42]

[GertMenkel]

2) Waarom lopen we op Linux en Unix nog steeds to kloten met een archaisch systeem dat maar 2 niveaus kent: alles (root) of niks (de rest). In plaats van de zeuren over de merits van sudo en doas of vv, zou er geinvesteerd moeten worden in een fatsoenlijk systeem rond het beheer van rechten.

Dat is toch ook de standaardopzet bij ieder ander OS? Met admin op Windows kun je kernelmodules inladen en ben je praktisch NTAUTHORITY\SYSTEM als je dat zou willen. Met Linux hetzelfde, wordt je root, dan kun je alles.

In Linux kun je alsnog een hele hoop africhten met PolicyKit en SELinux/AppArmor zelfs als je programma root bereikt, maar niemand gebruikt het bijna. Mensen zijn ook heel dom en de eerste stap die je op internet vaak leest als een programma niet werkt is "zet selinux uit" in plaats van een echte oplossing voor het probleem.

Android heeft een hele hoop niveaus en permissies die keihard via selinux worden afgedwongen. Alle apps draaien in een losse security namespace doordat ze andere gebruikers en groepen zijn en alle gegevens worden daarmee op FS-niveau afgedwongen. In de praktijk is dat natuurlijk niet heel anders dan wat de gemiddelde Linuxserver al jaren doet, maar het bewijst dat zelfs voor eindgebruikers de "duizend permissieniveaus"-aanpak al bestaat en gebruikt wordt.

In Linux is de trend niet om dit systeem complexer te maken, maar juist om naar andere dingen te kijken. Er wordt steeds meer met containers gewerkt (docker, snap, etc.) of het directe management wordt vervangen door iets groters (kubernetes, plesk, cpanel). Wat ik in de praktijk geleerd heb is dat ieder slimmigheidje achteraf alleen maar in de weg zit, want in een project waarin je met anderen moet samenwerken is het lastig om iedereen op de hoogte te houden van hoe je slimmigheidje in elkaar zit.

Ik zie systemd hier in de toekomst nog wel eens wat mee doen, zorgen dat gebruikers die onderdeel van bepaalde groepen zijn bepaalde services mogen beheren maar andere niet. Momenteel kan dat natuurlijk ook al door een gebruiker "system" te maken en al je applicaties daarin als user service te draaien, waardoor je in je sudoers file je beheerders alleen "system" hoeft te geven maar geen "wheel". Of het voordeel heeft, weet ik niet.

Je kunt zes niveaus tussen gebruiker en root toevoegen (zoals Windows doet met "low integrity" etc.) maar dat maakt je applicatiestack alleen maar complexer. Hoe simpeler je architectuur, hoe beter je kunt voorkomen dat iemand een EoP op je systeem dumpt.

Apple gaat hier helemaal ver in, wil je echt root zijn, dan moet je belangrijke systeemveiligheidsfunctionaliteit uitzetten. Ik vind die aanpak persoonlijk maar niets, maar ik zie waarom ze het zo gedaan hebben.

[HashIT]

Windows kent al heel lang het mechanisme van User Privileges of User Privileges. Daarmee kan je bijvoorbeeld inregelen of een gebruiker:

• Gebruikers en groepen mag beheren
• File system permissions mag omzeilen (bijvoorbeeld voor backups)
• In mag loggen op de desktop en/of over het netwerk

De tools zijn er dus om een maatwerk user aan te maken, die bijvoorbeeld alleen maar andere users mag managen of een backup user ACL mag omzeilen. Voor dit soort dingen heb je in traditionele Unix omgevingen toch echt root rechten nodig.

Ter referentie: https://docs.microsoft.co...gs/user-rights-assignment

[Reactie gewijzigd door HashIT op 23 juli 2024 05:42]

[GertMenkel]

Linux heeft iets soortgelijks met ACL's. Zo kun je via factl bestandssysteempermissies aan bepaalde gebruikers toekennen en met PolKit bepaalde "root"-operaties zoals het uitvoeren van gebruikersmanagement aan bepaalde gebruikers of groepen toekennen. Je kunt op Linux hele specifieke operaties aan hele specifieke gebruikers(groepen) toekennen als je dat zo instelt.

Zo heb je voor het afsluiten van het systeem op Linux (in elk geval bij mijn distributies) normaal root-access nodig omdat je systeemservices moet stoppen etc., maar wordt via PolKit gezorgd dat je dit zonder root-wachtwoord kunt doen. PolKit gaat nog veel verder dan de Windows ACL's omdat het beheer van rechten via je eigen code gaat, en niet door middel van simpele lijstjes.

Ik ben het met je eens dat de ACL's van Windows veel specifieker zijn, maar dit heeft in het heden en verleden ook voor hele grote fouten gezorgd vanwege de complexiteit hiervan.

Op Linux zit de beperking niet in de mogelijkheden die het systeem heeft, maar met de defaults die ingesteld worden. Je kunt een heel Linuxnetwerk opzetten waar niemand ooit root hoeft te worden met de nodige ACL's, SELinux/AppArmor- en PolKit-regels, maar dan moet je dat wel zelf opzetten. Dat laatste doen alleen hele specialistische organisaties. De NSA is hier bijvoorbeeld heel goed in.

Het nadeel is dat veel Linuxgebruikers juist die absolute vrijheid willen hebben, waardoor regels en standaarden voor een "bedrijfs-Linux" nooit van de grond zullen komen buiten omgevingen als Red Hat Linux. Voor iedere serverbeheerder die roept om standaard meer regels in te stellen, roepen er tien dat het ze "alleen maar in de weg zit" met vaak als onderbouwing dat ze "heus wel weten hoe het hoort" en niet als kind behandeld willen worden. Microsoft kan makkelijk zeggen "dikke pech, volgende release staat VBS standaard aan", maar als Linux dat zegt dan stappen er mensen op die een gedeelte van de distro onderhouden.

[dmantione]

Ik kan mij er wel wat bij voorstellen: Linux maakt geen onderscheid tussen root en operator. Veel operator-kwesties, zoals het rebooten van het systeem worden nu met root-privileges uitgevoerd. Om te zorgen dat japie ook zijn computer kan rebooten zonder het root-wachtwoord te kennen is er een mechanisme nodig waarmee normale gebruikers soms zaken die beperkt zijn tot root uit kunnen voeren. Sudo is één van die mechanismen.

Zou je dieper in het systeem meerdere lagen kennen, dan zou je minder afhankelijk zijn van dit soort userspace-infrastructuur, die de neiging heeft om erg complex te worden.

Maar... als ik dit schrijf dan doe ik Linux te kort, want de Linuxkernel heeft door middel van capabilities wel degelijkheid de mogelijkheid om gebruikers te definiëren die bepaalde privileges hebben. Dus de functionaliteit is er, er wordt alleen niet afdoende gebruik van gemaakt en dat komt een beetje door de Unix-erfenis: Linux is al veel verder dan Unix, maar is nog steeds ingericht als Unix en teven verwachten de gebruikers ook precies die traditionele Unix.

[DigitalExorcist]

Japie kan ook gewoon de stekker eruit trekken. Geen Root rechten voor nodig…

[Magic V]

Mensen zijn ook heel dom en de eerste stap die je op internet vaak leest als een programma niet werkt is "zet selinux uit" in plaats van een echte oplossing voor het probleem.

Laten we eerlijk zijn, SELinux is ook niet iets dat je even in 5 minuten uitlegt of gaat tweaken (zeker niet in een reactie aan een gemiddelde Linux gebruiker op een forum). Het is leuk dat het bestaat, maar door de complexiteit heb je er vaak meer problemen mee dan dat het wat oplevert (als je er als gemiddelde gebruiker mee gaat werken).

Ik ben in het geheel niet overtuigd dat een grotere rol voor systemd met betrekking tot access control server systemen veiliger gaat maken. Uiteindelijk is systemd zelf natuurlijk ook gewoon een attack surface. De filosofie van Alpine linux is veel meer dat je het systeem juist compacter en overzichtelijker maakt (incl. onder de motorkap). Systemd lijkt me in de toekomst toch vooral relevant voor Linux op de desktop. Alpine linux is absoluut geen desktop OS (als iemand het daar voor gebruikt, gefeliciteerd, maar je weet dat je er relatief veel moeite voor hebt moeten doen).

[Reactie gewijzigd door Magic V op 23 juli 2024 05:42]

[GertMenkel]

SELinux is inderdaad niet iets dat je in vijf minuten opzet, maar hetzelfde geldt ook voor het complexere Windows-authorizatiesysteem. In de praktijk wordt eerder gewoon een account in de nodige admingroep gegooid dan dat er gebruik wordt gemaakt van de fijnmazige ACL-structuur, met alle nadelen van dien.

Systemd heeft, ondanks dat weinig applicaties het tot nu toe helaas gebruiken, een enorme hoeveelheid veiligheidsfeatures. Zo kunnen delen van het bestandssysteem onschrijfbaar en onleesbaar worden gemaakt, kunnen on the fly gebruikers-ID's worden aangemaakt zodat je niet iedere keer een service user hoeft aan te maken en kunnen hele klasses systeemfuncties zoals netwerkverkeer of standaard-IPC worden uitgeschakeld. Met systemd-analyze worden dit soort dingen heel simpel gemaakt om te configureren.

Gooi hier nog eens iets als AppArmor overheen, wat voor systeemsercives vaak makkelijk te configureren is omdat ze bijvoorbeeld geen arbitraire bestandslocaties nodig hebben, en een overgenomen systeemservice is kansloos, zelfs als die met verhoogde permissies draait.

Al deze dingen zijn natuurlijk niets dat andere systemen niet kunnen doen, maar dan zit je al snel wrappers en shims te schrijven die de nodige kernel-API's voor je aanroepen en die SELinux voor je configureren. Je zou bijvoorbeeld LXC, snap, docker of containerd kunnen gebruiken, die systemen gebruiken veel van dezelfde API's om sandboxing mogelijk te maken. Die systemen zijn echter al snel heel complex, dus dat gaat juist weer tegen het Alpine-principe in. Juist doordat systemd met de meeste distros meekomt is het een kansrijke methode om je security net wat op te krikken.

Alpine gebruikt OpenRC dus daarin zul je dingen als namespaces en andere beveiligingssegregratie zelf moeten regelen. Dat houdt al snel in dat je zelf je SELinux mag gaan inrichten, en dat is natuurlijk complex en foutgevoelig. Ik ken zelf echter niemand die Alpine direct op hardware of in een VM draait buiten specialistische distros (alternatieve routerfirmware, een minimale Linux-omgeving voor smartphones, etc.), het is meestal toch een basis voor bijvoorbeeld een container in mijn ervaring. Het kan natuurlijk, maar in de praktijk zie ik meestal Ubuntu Server, CentOS en andere fully-featured serverdistro's voorbij komen aan de serverkant.

[jurroen]

1) Waarom mag Jan en Alleman inloggen op systemen en scripts runnen. Stap 1 bij beveiliging is het limiteren van toegang. Als niemand toegang heeft, is er ook geen probleem met sudo

En hoe exact denk je dat (web)hosting werkt en terminal services?

2) Waarom lopen we op Linux en Unix nog steeds to kloten met een archaisch systeem dat maar 2 niveaus kent: alles (root) of niks (de rest). In plaats van de zeuren over de merits van sudo en doas of vv, zou er geinvesteerd moeten worden in een fatsoenlijk systeem rond het beheer van rechten.

Misschien wil je jezelf even inlezen op de materie voordat je zo'n post doet. Je kunt met doas heel fijnmazig rechten toekennen. Bijvoorbeeld:

permit nopass jurroen as www cmd npm install

Daarmee kan de user jurroen het commando npm install uitvoeren als de www gebruiker. Zie ook de manpage van doas(5), de blogpost van Ted Unangst en eventueel dit artikel van Vultr.

[Reactie gewijzigd door jurroen op 23 juli 2024 05:42]

[niqck]

2) Waarom lopen we op Linux en Unix nog steeds to kloten met een archaisch systeem dat maar 2 niveaus kent: alles (root) of niks (de rest). In plaats van de zeuren over de merits van sudo en doas of vv, zou er geinvesteerd moeten worden in een fatsoenlijk systeem rond het beheer van rechten.

Ik vrees dat vooral jij zelf achterloopt

Solaris (een Unix) kent bv. al meer dan 10 jaar Roles en Privileges, RBAC etc... Zo kan je bv. zonder problemen een webserver draaien op een privileged poort (80, 443) zonder ook maar iets van root-rechten via de net_privaddr privilege enz... Ooit was er Trusted Solaris, vervangen door Trusted Extensions voor Solaris, waar je security labels had. Maar geen idee of Oracle er al in geslaagd is ook dat dood te kloppen...

Zelfde geldt voor AIX (heeft ook RBAC). Andere (commerciele) Unices hebben misschien iets soortgelijk (in de mate dat ze nog bestaan...)

Voor Linux heb je SELinux, AppArmor en misschien zelfs nog andere implementaties; bij Linux weet je nooit... altijd wel iemand die denkt dat hij het beter kan

[GekkePrutser]

En FreeBSD heeft MAC (Mandatory Access Control).

Maar inderdaad wel jammer dat er een hoop verloren is gegaan met de traditionele unixen.

[niqck]

Die was ik idd nog vergeten. Maar bij veel van die oplossingen is het te vaak

• onbekend is onbemind
• complex waardoor een simpele maar minder veilige oplossing gezocht wordt

Genoeg meegemaakt dat bv een ontwikkelaar root-rechten op zijn station wou want hij moest de webserver kunnen herstarten. Als je dan gewoon rechten gaf (via sudo, ik praat over pre-RBAC) dan kloeg die nog want ja, hij was nog steeds niet de baas over zijn station

En wat ik spijtig genoeg ook te vaak merk is dat iemand die thuis een Linux draaien heeft denkt dat hij een sysadmin is... Een thuisomgeving is iets compleet anders dan een bedrijfsomgeving...

[GekkePrutser]

Ja dat laatste ben ik het ook helemaal eens mee. Uiteraard werk ik thuis met admin rechten op mijn werkstation. Op mijn werk laptop echter niet, hoewel ik juist een van de admins ben van het hele beheerplatform.

Waarom? Nou, anders kan er heel makkelijk privilege escalation gebeuren en ik heb juist veel privileges. Dat is enorm gevaarlijk. Vooral omdat we vast zitten aan AD wat nogal ouderwets is qua security. Via een admin-rechten trucje kan je de credentials pakken (gehasht) en die kan je zonder te brute forcen doorgeven (pass the hash aanval) en overal op inloggen. In sommige gevallen zelfs bij een gelockt account! Dus hebben admin rechten ingetrokken bij iedereen en wij met admin rechten werken op speciale hardened werkstations. Het probleem dat je met een thuissituatie niet hebt is dat een hacker zo door je hele organisatie kan springen, daar zit juist een groot gevaar.

Toen we bij iedereen de admin rechten introkken was er ook veel geklaag maar uiteindelijk viel de impact op de produktie wel mee. Het was veel werk voor ons om de kleinere onbekende apps officieel te packagen, en sommige gebruikers waren geirriteerd omdat de regel dat alleen door ons gecertificeerde apps te gebruiken zijn voor werk, niet meer zomaar te omzeilen is. Maar ook daar zijn goede redenen voor.

Bij ons krijg je op AWS idd ook alleen de rechten om te doen wat je moet kunnen doen en verder helemaal niets

[Reactie gewijzigd door GekkePrutser op 23 juli 2024 05:42]

[Ronnie N]

Je punt 2: we hebben nu polkit, en dat werkt prima. Maar het voelt nog wel een beetje als kruk om mee te lopen in plaats van een nieuwe heup.

[bzzzt]

1) Waarom mag Jan en Alleman inloggen op systemen en scripts runnen. Stap 1 bij beveiliging is het limiteren van toegang. Als niemand toegang heeft, is er ook geen probleem met sudo

Als echt niemand toegang heeft kan je een systeem ook gewoon uitzetten

2) Waarom lopen we op Linux en Unix nog steeds to kloten met een archaisch systeem dat maar 2 niveaus kent: alles (root) of niks (de rest). In plaats van de zeuren over de merits van sudo en doas of vv, zou er geinvesteerd moeten worden in een fatsoenlijk systeem rond het beheer van rechten.

Unix heeft een user / groep / others permissiemodel wat betekent dat er ook nog wat stapjes tussen root en nobody gemaakt kunnen worden. Eenvoudig in te stellen en relatief overzichtelijk. Daarnaast kan je met bv. SELinux nog een hele kerstboom van policies optuigen waarmee je gegarandeerd bakken tijd kwijt bent en met discutabele opbrengst.
Het Windows NT model (afgeleid van VMS) is ook niet zaligmakend aangezien Windows z'n portie aan exploits ook wel heeft (de printer spooler issue laatst bijvoorbeeld).

Belangrijkste bestaansreden van de Alpine distributie is juist het feit dat een volledig OS draaien in een container niet echt nuttig is. In een ideale microservice wereld bevat iedere container 1 service die niet eens als root hoeft te draaien. Vermoedelijk is deze actie meer gericht op het verminderen aan onderhoud op ingewikkelde componenten die toch niet gebruikt worden.

[StCreed]

Inderdaad. In 1993 zag ik al een operating systeem van (ik meen) de VU waarbij capabilities centraal stonden, in plaats van rechten.

Een beetje zoals op je telefoon: wat vind je dat een applicatie mag? Die capabilities kan je uitdelen, of niet. En dan op redelijk hoog niveau, dus: lezen/schrijven naar eigen folder, eigen settings aanpassen, alle settings aanpassen, alle folders lezen/schrijven, zaken naar de printer sturen, verbinden met internet als server of als gebruiker, etc.

Die capabilities kan je bundelen tot bepaalde standaard setjes. Games, Office apps, Browsers, Social Media, etc. en zo kan de gebruiker aangeven wat hij voor gedrag verwacht en toestaat.

Maar ja, dat is echt lastig. Dus gebeurt het niet, want lastige dingen doen mensen niet zo graag.

[Exirion]

Je bedoelt waarschijnlijk MINIX, de basis van het vroege Linux. Leeft nog altijd en er worden nog nieuwe ports gemaakt.

[GekkePrutser]

1) Waarom mag Jan en Alleman inloggen op systemen en scripts runnen. Stap 1 bij beveiliging is het limiteren van toegang. Als niemand toegang heeft, is er ook geen probleem met sudo

Dit is zeer afhankelijk van de situatie. In sommige gevallen is een infrastructure as code oplossing (denk ansible, puppet) een prima idee waardoor je nooit meer hoeft in te loggen. In andere gevallen minder. Het is geen techniek die geen nadelen kent.

Bovendien zal je dit op werkstations nooit kunnen bereiken omdat je daar wel op moet inloggen om ze te gebruiken

[beerse]

Omdat ik mijn gedachten niet terug vind in de andere reacties, wil ik ze toch neerzetten.

1) Waarom mag Jan en Alleman inloggen op systemen en scripts runnen. Stap 1 bij beveiliging is het limiteren van toegang. Als niemand toegang heeft, is er ook geen probleem met sudo

Jan en alleman kan en mag inloggen op het systeem om zaken en taken uit te voeren. Dat is de essentie van een computer systeem. Als je toegang nodig hebt voor andere zaken en andere taken dan zijn daar andere protocollen voor om toegang te krijgen. Elk met een passende beveiliging. Voor informatie op halen: http en omstreken. Om bestanden op te halen: ftp/nfs/samba. En zo voorts en zo voorts.

2) Waarom lopen we op Linux en Unix nog steeds to kloten met een archaisch systeem dat maar 2 niveaus kent: alles (root) of niks (de rest). In plaats van de zeuren over de merits van sudo en doas of vv, zou er geinvesteerd moeten worden in een fatsoenlijk systeem rond het beheer van rechten.

Er zijn voor de meeste systemen, functies en protocollen maar 2 niveaus van toegang: Gebruiker en beheerder. Voor een website is er de gebruiker en de beheerder. Voor een operating systeem is er de gebruiker en de beheerder.

Bij het unix rechten systeem zijn overigens 3 niveaus aan te geven: De gebruiker, de groep en de wereld. Met daarbij de mogelijkheid om gecontroleerd tussen de groepen te bewegen. Dit kan/mag een basis zijn om role-based access of hoe dat ook genoemd word, in te richten, al stelt dat eisen aan hoe de basis daar word ingericht. Helaas is dan een matrix rechten structuur lastig in te richten.

Aan de andere kant zie ik met het gebruik van compartimentering zoals bij docker en ook bij systeem-virtualsiatie ook een scheiding van rechten ontstaan op basis van de functionaliteit: Je kan en mag in de ene docker container wel alles maar daar buiten niet.

Het nadeel van de implementaties zoals Novel die ooit heeft opgezet is dat daar best veel administatie bij komt kijken. Net zoals bij het gebruik van acl-s en dergelijke toegevoegde rechten systemen. Als je role-based-access gaat toepassen moet je beginnen met het definieren van de rollen en de bijgaande rechten en plichten. Daarbij moet je er vooral voor zorgen welke andere rol de binnen een rol geblokkeerde taken wel kan uitvoeren. Zolang niet elke taak in een rol is opgenomen of niet duidelijk is welke rol een geblokkeerde taak wel kan uitvoeren, zal er een 'do-all' root/administrator account nodig zijn. Daarbij als het rechten/plichten systeem ergens hapert, zal de rest vooral welk moeten kunnen blijven doorgaan om een kip-ei probleem te voorkomen.

Al met al heeft het rechten en plichten systeem zoals ik dat ooit bij unix en minix heb leren kennen mij nog nooit in de steek gelaten. OOk heeft het andere systemen op 1 of andere manier overleefd omdat het praktisch inzetbaar is. Misschien ook wel omdat het de beheerder in haar/zijn waarde laat zonder het onnodig te beperken.

Overigens, de keuze tussen 'inloggen als root', het gebruik van 'su', 'sudo' of 'doas' is naar mijn idee niet alleen aan het os maar ook aan de beheerder. Het account 'root' hoeft al jaren niet meer in te loggen. Het gebruik van 'su' en 'sudo' stel ik gelijk. Waarbij voor mij de betekenis "Set User" prefereert boven "SuperUser". Met beide commando's kan je namelijk ook wisselen naar een ander account, het gebruik van 'root' is slechts de default.
Toegegeven, 'doas' kende ik niet tot dit artikel. Op basis van de naam stel ik het gelijk met 'sudo' waarbij de naam netjes aangeeft dat het is om naar een andere (beperkte) gebruiker te wisselen. Als het gebruik (en vooral de configuratie) eenvoudiger is dan die van sudo dan kunnen ze wat mij betreft naast elkaar bestaan, liefst naast elkaar kunnen draaien en hoop ik dat er vertaal-scripts worden ontwikkeld om de instellingen (binnen de mogelijkheden) om te zetten.

[davekok]

1) Jan en Alleman mogen niet inloggen. Alleen netwerk/systeem beheerders mogen inloggen. Tenminste voor Alpine/Linux toepassingen.
2) Beveiliging via het bestandsysteem is een administratieve beveiligingstechniek. Hoe complexer die wordt hoe waarschijnlijk het is dat je fouten maakt en die dus niet werkt en wordt uitgezet. Beter is het te investeren in crypto beveiligingstechnieken zoals secure boot en daar een chain voor opzetten. De BIOS controleert de bootloader. De bootloader de kernel en de kernel de systeemonderdelen. De systeemonderdelen de containers die uit container registries komen. Met daarnaast een dedicate resource model eventueel gevitualiseerd. Dus elke container zijn eigen (virtuele) harde schijf. In plaats van software dezelfde resources laten delen.

Voor wat overblijft is dan root en rest prima.

[delphium]

2) Waarom lopen we op Linux en Unix nog steeds to kloten met een archaisch systeem dat maar 2 niveaus kent: alles (root) of niks (de rest). In plaats van de zeuren over de merits van sudo en doas of vv, zou er geinvesteerd moeten worden in een fatsoenlijk systeem rond het beheer van rechten.

Omdat dit systeem superieur is juist door zijn eenvoudigheid. Zo eenvoudig als jij het schets is het echter ook weer niet. Er zijn wel degelijk meer gradaties in rechten te bereiken d.m.v. groepen, shells en dus sudo/doas. Zeker als je ook nog apparmour of SElinux inzet.

Wat je ziet bij complexere systemen zoals dat van Windows, is dat zelfs MS door de bomen het bos niet meer ziet. Om de haverklap privilege escalation bugs (printergate, Exchange, Windows Installer) wat de boel er niet veiliger op maakt. Nog even los van het feit dat het systeem voor de meeste gebruikers volstrekt onbegrijpelijk is, wat weer zorgt voor nieuwe beveiligingsproblemen.

Dat 50 jaar oude, super eenvoudige systeem, voldoet echter nog prima en is by design, vele malen veiliger dan de rechtenhel van Windows.

Doas heeft minder functies dan sudo, maar is ook minder complex en heeft een kleinere codebase, met voordelen wat betreft beheer en beveiliging.

Keep it stupid simple. Dat is waar Linux altijd al goed in is geweest (op wat uitspattingen daar gelaten). Daar zou Microsoft eens een voorbeeld aan moeten nemen.

[zvbhvb]

2) Waarom lopen we op Linux en Unix nog steeds to kloten met een archaisch systeem dat maar 2 niveaus kent: alles (root) of niks (de rest). In plaats van de zeuren over de merits van sudo en doas of vv, zou er geinvesteerd moeten worden in een fatsoenlijk systeem rond het beheer van rechten.

Net niet. Windows kent inderdaad alleen alles (root) of gewone gebruiker. Daarbij wordt om het admin wachtwoord gevraagt bij bepaalde acties zoals sofware en of drivers installeren.

Linux maakt het mogelijk om een extra gebruiker aan te maken onder de sudo gebruiker die je zowat van alle groepen het lidmaatschap afpakt (printer setup,wheel,etc)

Om vervolgens iets te installeren (alleen mogelijk via de cli) moet je met: "su - <sudo-gebruiker>
overgaan op de user die in de wheel group zit (sudo-gebruiker) om vervolgens root taken met sudo te kunnen uitvoeren (bijvoorbeeld: sudo apt install <vul maar in>.

[bigoldie]

En ik maar denken dat DOAS een afkorting voor iets complex, blijkt het gewoon "do as" te zijn.

[84hannes]

blijkt het gewoon "do as" te zijn.

Niet helemaal waar, het kan blijkbaar ook staan voor:
dedicated openbsd application subexecutor

https://flak.tedunangst.com/post/doas

[batjes]

sudo = su do, su = super user.

Het is vaak simpeler dan je denkt

[Xorifelse]

Of "substitute user" do, standaard root user, en anders gebruikt je de -u flag.

[beerse]

Zo ook met 'su'. Daarbij kan je ook naar een ander account wisselen. Root is slechts de default: https://man7.org/linux/man-pages/man1/su.1.html
https://man7.org/linux/man-pages/man8/sudo.8.html

Helaas heeft die man-pages-website 'doas' nog niet opgenomen.

[Xorifelse]

Zelf gebruik ik alleen nog maar man als er geen internet beschikbaar is of als ik mezelf wil pijnigen.
Voor alle andere zaken is er tldr: https://tldr.sh, demo: https://tldr.ostera.io/doas

Daarbij is doas van OpenBSD en niet zo zeer Linux, https://man.openbsd.org/doas dus dat is wel logisch dat het nog niet is opgenomen en als je het kan installeren zijn de man pages lokaal wel beschikbaar.

[tweazer]

Tja en ik lees daar doass, ass as in de trend van BHA, de butthead astronomer Carl Sagan, men heeft kritiek, meerdere keren kritiek, wordt niet opgelost, dan doen we het zelf wel ...

[CasEbb]

Hier gaan heel wat Dockerfiles sneuvelen.

[GekkePrutser]

Niet echt denk ik. Je zal nog steeds gewoon sudo kunnen installeren. Alleen doas wordt de default.

[closefuture]

Op werk zijn wij ook over gestapt naar doas. Sudo heeft toch iedere paar jaar wel een serieus incident en voor zo'n security sensitive tool is dat eigenlijk teveel.

[HollowGamer]

Sudo is wel al jarenlang in gebruik, werkt met huidige tools die het nodig hebben en zal best wel een audit ergens hebben gehad.

Wat is precies het voordeel om over te stappen naar dit alternatief? Als ik mij niet vergist zijn er nog meer sudo alternatieven.

[Reactie gewijzigd door HollowGamer op 23 juli 2024 05:42]

[closefuture]

en zal best wel een audit ergens hebben gehad.

Dat is een gevaarlijke aanname maar sowieso wat doet een audit er toe als er iedere paar jaar wel een serieus security incident is? In de "Lees meer" sectie van dit artikel staan er al 2. Een van januari 2021 en een van 15 oktober 2019.

Wat is precies het voordeel om over te stappen naar dit alternatief?

Primair dat het OpenBSD project een goede reputatie heeft mede door hun focus op security. Daarbij is het een veel kleinere implementatie wat het aanvalsoppervlak verkleind.

[HollowGamer]

Dat is een gevaarlijke aanname maar sowieso wat doet een audit er toe als er iedere paar jaar wel een serieus security incident is? In de "Lees meer" sectie van dit artikel staan er al 2. Een van januari 2021 en een van 15 oktober 2019.

Wat is daar precies erg aan? Het is juist goed dat er lekken worden gevonden, iets zonder lekken bestaat simpelweg niet.

Primair dat het OpenBSD project een goede reputatie heeft mede door hun focus op security. Daarbij is het een veel kleinere implementatie wat het aanvalsoppervlak verkleind.

Dat is ook maar een aannamen, een kleinere implementatie maakt dingen niet altijd veiliger en dit soort software is complex.

[closefuture]

Dat is ook maar een aannamen, een kleinere implementatie maakt dingen niet altijd veiliger en dit soort software is complex.

Jij vind de focus en reputatie op het gebied van veiligheid van het OpenBSD project een aanname?

[HollowGamer]

Dat zeg ik niet, maar dat maakt OpenBSD (stuff) niet 'heilig'/kwetsbaar, al geven zij inderdaad meer om veiligheid en stabiliteit.

Het is en blijft software geschreven door mensen, dat bevat altijd fouten of kan om zeep worden geholpen door iets anders (zoals per ongeluk root toegang).

Ik vind het interessant om de ontwikkeling van een sudo-alternatief te volgen, de uiteindelijke ontwikkelaar maakt mij niet zoveel uit, het gaat om de adoptie ervan.

[Reactie gewijzigd door HollowGamer op 23 juli 2024 05:42]

[ro8in]

Denk je niet dat er bij sudo ook gewoon veel meer incidenten bekend zijn omdat het gewoon veel meer wordt gebruikt dan bijvoorbeeld doas?

Gewoon maar aannemen dat doas veiliger is is ook gevaarlijk

[Reactie gewijzigd door ro8in op 23 juli 2024 05:42]

[markjanssen]

Deels ook, maar vooral dat sudo iedere versie ook allerlei nieuwe features toevoegd, en ondertussen een vrij complex beest is geworden. Doas heeft als policy om vrij minimaal te zijn,

Sudo zie ik iedere release nog aardig wat nieuwe features bij komen, naast natuurlijk de bugfixes en patches.

[nopcode]

sudo is toch ook een openbsd project?

[nopcode]

tedu heeft goede blogs rond doas geschreven op zijn flak blog.

Een leuk weetje: zowel sudo als doas worden primair gemaakt op OpenBSD en door dezelfde personen (millert).

[Eonfge]

Dat is een beetje paniekvoetbal. Simpelweg omdat beveiligingsexperts een tool regenmatig tegen het licht houden, en soms iets vinden, is dat geen rede om die tool niet meer te gebruiken.

Wat gaat er dan nog meer de deur uit? Microsoft Office en Google Chrome? In die programma's worden meer kwetsbaarheden gevonden dan in sudo. Vergeet ook niet OpenSSL, NGINX en OpenJDK. Maandelijks zijn daarin patches voor de beveiliging.

[Reactie gewijzigd door Eonfge op 23 juli 2024 05:42]

[closefuture]

Dat is een beetje paniekvoetbal. Simpelweg omdat beveiligingsexperts een tool regenmatig tegen het licht houden, en soms iets vinden, is dat geen rede om die tool niet meer te gebruiken.

En soms iets vinden? Sudo is de tool die een muur moet zijn tussen normale gebruikers om root rechten te verkrijgen. Het zou een project van een paar duizend, goed geauditen, regels code moeten zijn. In plaats daarvan is het een project met iedere paar jaar een fors security incident. Lees: normale users die opeens root rechten kunnen verkrijgen door een fout in sudo. En dat bagataliseer je als paniekvoetbal?

Vergeet ook niet OpenSSL, NGINX en OpenJDK. Maandelijks zijn daarin patches voor de beveiliging.

Je vergelijkt het aanvals oppervlak van projecten met een code base van miljoenen regels met een project (sudo) wat eigenlijk een paar duizend regels max zou moeten zijn? Serieus?

[Blokker_1999]

De vraag is dan vooral:hoe kan jij zo zeker zijn dat doas zo geen fouten bevat?

Het vinden van bugs is nooit leuk, maar dat zijn fouten die er niet meer inzitten en opgelost zijn. Het zijn de bugs die niet ontdekt zijn die een probleem vormen, en daar kan je bij geen enkele tool uitspraken over doen.

[Tjidde]

Zodra er meer gebruikers van doas of andere alternatieve komen zal de hack wereld echt niet stil zitten.

Volgens mij blijf je dan elke x tijd verplaatsen voor eigenlijk niets.

Niet dat er fouten in iets van super user geen groot probleem zijn.

[closefuture]

De vraag is dan vooral:hoe kan jij zo zeker zijn dat doas zo geen fouten bevat?

Waar zeg ik dan dat doas geen fouten bevat?

Het gaat erom welk project vertrouw je. En als jij zegt: "Goh de reputatie van het OpenBSD project met hun focus en track record op het gebied van veiligheid is mij niks waard" dan kan je sudo en doas inderdaad evenveel vertrouwen...

Daarnaast komt er dus ook bij dat doas een overzichtlijke en kleine codebase is waarbij de sudo codebase een melog is die ook zaken als LDAP, Kerberos en what not ondersteund. En dan kan je zeggen: "Ja maar die heb ik niet enabled". Er zijn wel allerlij abstractie lagen in de sudo code base om uberhaupt die functionaliteit mogelijk te maken. Allemaal complexiteit waar bugs in kunnen zitten.

De vraag is eerder: Waarom zou je uberhaupt sudo willen gebruiken?

[Reactie gewijzigd door closefuture op 23 juli 2024 05:42]

[Jerie]

Zeker weet je het nooit maar de code is door OpenBSD geaudit en heeft veel minder LOC dan sudo (welke ook nog eens een slechte track record heeft). Het is net zoiets als BIND vs djbns.

[markjanssen]

De OpenBSD/OpenSSH developers hebben echter wel een reputatie van secure code schrijven, en ze proberen ook de features/codebase te minimaliseren.
Hoe minder code, hoe minder bugs

[84hannes]

De vraag is dan vooral:hoe kan jij zo zeker zijn dat doas zo geen fouten bevat?

Nee, de vraag is: waarom kun je aannemen dat doas minder fouten bevat? En die vraag is in het artikel beantwoord:

Doas heeft minder functies dan sudo, maar is ook minder complex en heeft een kleinere codebase, met voordelen wat betreft beheer en beveiliging.

Diezelfde aanpak zie je bij OpenSSL (aangehaald door @Eonfge ), die vervangen kan worden door LibreSLL.

OpenBSD developers "removed half of the OpenSSL source tree in a week."

De overeenkomsten tussen OpenSSL en sudo zijn dat ze beide veiligheid zouden moeten bieden, maar daar regelmatig in falen. Het bieden van veiligheid is niet de reden om bijvoorbeeld Chrome of Office te gebruiken; die producten zijn complexer en veiligheid is slechts 1 van de vele eisen waar ze aan willen voldoen.

[Reactie gewijzigd door 84hannes op 23 juli 2024 05:42]

[Oon]

Maar wie zegt dat tegen de tijd dat doas zo populair is als sudo daar niet hetzelfde over gezegd gaat worden?

[closefuture]

Ben je uberhaupt bekend met het OpenBSD project en hun insteek?

[Blokker_1999]

Hoe verschillend zijn deze in dagelijks gebruik? Is het mogelijk om scripts te laten werken door sudo gewoon als alias van doas toe te voegen, of gaat dat niet werken?

[Jerie]

Ik draai het al tijden op macOS.

Op zich werkt het prima, je kunt dan sudo in je shell profile aliasen naar doas.

Je kunt je environment bewaren (zie doas.conf.sample).

Zelfs Yubico PIV werkt (inmiddels) prima (remote niet IIRC).

Maar je moet iedere keer als je een commando uitvoert authen. Hij onthoudt dus niet dat je X min geleden hebt geauth en dat-ie niet nog eens hoeft te vragen. Op zich is dat ook een stukje veiliger, helpt ook deels tegen een social engineering aanval, maar bij sudo kun je dat aan- of uitzetten. Je kunt wel in config permit nopass gebruiken maar dat is meteen het andere uiterste.

Hoe los je het op? Door met doas een root shell te starten en je environment vars te behouden en dan de commando's uitvoeren. Niet echt hoe het moet maar het scheelt veel tijd tov vele keren authen.

Voorheen werkte Yubico PIV niet en moest ik steeds m'n wachtwoord invoeren. En die is op die machine nogal lang...

[Reactie gewijzigd door Jerie op 23 juli 2024 05:42]

[novasurp]

Bij de OpenBSD en Linux-versies van doas heb je een optie “persist” waardoor hij wel onthoud dat je je wachtwoord al kort geleden ingevoerd had. De port voor Mac, FreeBSD, en illumos ondersteunt dit niet.

[Jerie]

Bedankt, dat was het probleem inderdaad.

edit:
Net getest, op Linux werkt persist ook niet

edit:
Het verschilt per port/fork. Er is een port waar PAM niet werkt (die gebruikt /etc/shadow) maar heeft een eigen persist implementatie, en er is eentje waar persist niet werkt en PAM wel. Ik weet niet welke port er zoal in welke distributie zit, ik weet wel dat ik allebei de features wil op macOS en Linux.

[Reactie gewijzigd door Jerie op 23 juli 2024 05:42]

[novasurp]

Het moet blijkbaar gecompileerd worden met de optie aangezet https://github.com/Duncaen/OpenDoas#persisttimestamptimeout

[Jerie]

Nice, die port werkt voor beiden. Dat is ook de port die ik gebruik op macOS. Hij gebruikt dan een eigen implementatie van persist, die is file-based in /var/lib/doas. Maar die feature werkt op macOS niet. Vandaar dat ik op macOS doas gebruik om een root shell te verkrijgen. En dan kun je eigenlijk net zo goed su gebruiken.

[markjanssen]

Ja, dat zou redelijk een drop-in replacement moeten zijn voor de gebruikers... de config is natuurlijk wel anders, maar als je sudo config nu ook gewoon 'username ALL=ALL' is... is dat niet echt anders.

Sudo heeft echter ook de mogelijkheden om o.a. zijn config uit LDAP te halen, dat heeft doas allemaal niet, en daarom is 't ook een stuk simpelere codebase. Wat er niet in zit, kan ook niet geexploit worden.

[Kees]

Dat laatste is wel een vervelende tekortkoming; wellicht is het in containers wat makkelijker, maar voor mijn normale servers heb ik dat het liefst allemaal centraal (in freeipa)

[HollowGamer]

Volgens mij staan er in het artikel dingen door elkaar: gaan ze nu van sudo naar doas of van doas naar sudo?

[Vihaio]

Ze gebruiken nu sudo en gaan doas gebruiken

[maevian]

als eindgebruiker zal je hier wel niet veel van merken, ze zullen wel een alias naar sudo zetten om script compatibility te garanderen

[Thunder1984]

En dat deprecaten zodat jij tijd hebt om je scripts te updaten.
(Tenzij je die alias daarna zelf blijft aanmaken)

[Xantios]

er zijn legio scripts die er "blind" vanuit gaan dat je sudo beschikbaar hebt. of dat iets is wat je moet willen is een andere discussie maar feit is dat het nu eenmaal dekfacto standaard is.

er zal dan toch echt significant werk verricht moeten worden om een tussenoplossing te bieden. en tegen welke toegevoegde waarde zou dat zijn?

Dat men fouten vind in sudo is niet zo gek, immers gebruikt nagenoeg elke linux distro het. inclusief de mensen die toch echt wel op hun Security zitten. met zo'n grote gebruiksgroep ga je gegarandeerd elke typefout er wel een keer uitlichten.

dit komt sterk over als een alternatief om het alternatief, iets wat de BSD wereld niet vreemd is.

[eamelink]

alias sudo='doas'

[Magic V]

Alpine is sowieso al een van de meest BSD-achtige Linux distro's die je kunt vinden. Kijk ook naar de licenties van de core software die ze gebruiken, je komt een heel eind zonder GPL-3 te hoeven gebruiken met Alpine.

De gemiddelde Alpine gebruiker zal hier niet echt last van hebben denk ik, het is nogal een distro voor specialistische toepassingen (daar reken ik het zelf samenstellen van een docker image ook wel onder).

Bovendien trekt het Alpine team gewoon altijd hun eigen plan op basis van de doelstelling om de distributie compacter, veiliger en in zekere zin meer UNIX-like te maken. Denk alleen al aan de keuze voor open-rc, busybox & musl, ash.

Voor mij is het (naast Gentoo) een van de beste manieren om in de buurt te komen van een BSD OS, maar met de meer mainstream software opties en hardware compatibility van Linux. ZoL werkt op Alpine overigens ook geweldig.

[GekkePrutser]

KLopt, daarom gebruik ik het ook op al mijn servers. Geen systemd, geen snaps, heel erg licht in de basis install.

Overigens is het lang niet alleen voor docker images. Het is ook een prima server distro op bare metal. Juist omdat het niet teveel probeert te doen en niet te veel desktop paradigma's binnensleept in wat een server moet zijn. Voor desktops is het gewoon uitgesproken niet bedoeld (al zitten er wel dingen als Gnome en KDE in de repo).

En inderdaad ZFS on Linux werkt ook super. Ik gebruik zelf ook heel veel FreeBSD maar op sommige servers heb ik dockers nodig en dan is Alpine echt een uitkomst.

Ze zijn trouwens ook bezig aan een lichtgewicht alternatief voor systemd op basis van s6.

[Reactie gewijzigd door GekkePrutser op 23 juli 2024 05:42]

[Magic V]

Nice, Alpine op de server heeft mij tot nu toe nog nooit teleurgesteld, en natuurlijk makkelijk in het onderhoud

Wat ook erg tof is, is om Alpine volledig vanuit het geheugen te draaien. Met de Local Backup Utility (LBU) commit en track je dan steeds alleen de changes aan je file system naar persistent storage. Ideaal als je een server OS vanaf een USB stick wilt laden, zonder slijtage aan de USB stick. Op deze manier heb ik Alpine ook al ingezet als (Qemu / KVM) hypervisor OS.

Natuurlijk is Alpine bekend als docker image base, maar het leent zich ook uitstekend als een soort minimaal Virtual Machine Guest OS waarop je dan weer docker draait. Zegmaar de security sandbox voordelen van een VM, maar dan met de extra flexibiliteit van docker images. Een volledig functionele Alpine VM Guest + docker images is zelden groter dan een paar GB.

[GekkePrutser]

Ja dat laatste doe ik momenteel, ik gebruik het als host voor docker (en ook volledige virtualisatie met KVM / libvirt).

Bedankt voor de tip met het in geheugen draaien, dat ga ik eens uitproberen.

[beuki]

Ik denk een typo in de tekst. Titel en tekst sreken elkaar nu tegen : "gaat bij de komende versie waarschijnlijk overstappen van doas naar sudo" .