Onderzoeker ontdekt remotecode-executionbug in CUPS-printsysteem van Linux

Een onderzoeker heeft een kwetsbaarheid in het afdruksysteem OpenPrinting CUPS van Unix-besturingssystemen als Linux ontdekt. Het lek zou remote code execution mogelijk maken. De kwetsbaarheid is vooralsnog niet gedicht.

Gebruikers die gebruikmaken van het OpenPrinting CUPS-afdruksysteem en waarbij het cups-browsed-proces is geactiveerd, zijn mogelijk kwetsbaar voor een remotecode-executionaanval, schrijft onderzoeker Simone Margaritelli in een blogpost. Hij ontdekte dat kwaadwillenden via CUPS de URL's van de Internet Printing Protocols van printers kunnen vervangen door schadelijke URL's, of zelf een nieuwe printer met een schadelijke IPP-URL aan de dienst kunnen toevoegen. Als een gebruiker vervolgens iets print via een geïnfecteerde printer, wordt de code van die URL op de computer geactiveerd.

Hoewel CUPS in verschillende Linux-distro's wordt meegeleverd, is de cups-browsed-daemon op de meeste systemen standaard uitgeschakeld, stelt Margaritelli. Met dit proces zoekt CUPS automatisch naar nieuwe printers in de buurt en voegt het systeem ze automatisch toe aan de printerlijst. Volgens de onderzoeker laat deze daemon vrijwel iedereen verbinding maken met het printsysteem, zonder ze eerst te autoriseren.

De onderzoeker raadt gebruikers aan om de cups-browsed-daemon te verwijderen, mits deze is geactiveerd. Indien dat niet mogelijk zou zijn, kunnen gebruikers er ook voor kiezen om al het verkeer naar UDP-poort 631 te blokkeren, aangezien aanvallers de CUPS-dienst via die serverpoort moeten bereiken. Ook treedt de aanval pas in werking als gebruikers een printopdracht starten.

Red Hat bevestigt in een reactie op de bevindingen dat alle versies van RHEL kwetsbaar zijn voor het lek, maar schrijft dat cups-browsed in de distro niet standaard geactiveerd is. Het bedrijf beoordeelt de kwetsbaarheid dan ook als 'Belangrijk', een niveau lager dan ernstigheid 'Kritiek'. De distro laat weten dat gebruikers met het commando $ sudo systemctl status cups-browsed erachter kunnen komen of het proces is geactiveerd. Indien dat het geval is, kunnen ze het met $ sudo systemctl stop cups-browsed uitschakelen.

De ontwikkelaars van CUPS hebben nog niet gereageerd op de bevindingen. Het is onduidelijk of en wanneer de kwetsbaarheden worden gedicht.

Reacties (75)

[wica]

Wat een soap was deze bug. Begin van de week, werd deze bug door Simone Margaritelli ( evilsocket op X) nog al groot aangekondigd.

* Unauthenticated RCE vs all GNU/Linux systems (plus others) disclosed 3 weeks ago.

Het bracht nog al wat onnodige onrust, onder beheerder. Want dit klonk niet best.
Gisteren bleek het om Cups te gaan en dat de gebruiker, de aangemaakte printer moet selecteren en er naar toe printen. Wat het risico al een heel stuk lager maakt voor alle Linux systemen. Daar het niet meer standaard installeert wordt op servers.

Volgens shodan: There are at least 75,000 exposed CUPS daemons on the Internet

Neemt niet weg dat dit een ernstige bug is. Maar de impact is een stuk lager, dan werd aangekondigd.

[GrooV]

Ja echt heel weinig impact op een service die op 300.000 via het internet benaderbare computers als ROOT draait. Waarbij wildvreemden printers kunnen wijzigen en toevoegen, requests naar externe servers kunnen maken en dus ook de default printer met hun eigen driver kunnen vervangen.

Ik snap niet dat je zoiets kan bagatelliseren, Ubuntu desktop installeert notabene standaard CUPS op 0.0.0.0. Lekker dan op je bedrijfsnetwerk of (gast) netwerk thuis.

Een PDF export gaat ook vaak via een virtuele printer en is dus ook vulnerable

Verder geeft Simone zelf niet de score.

[Reactie gewijzigd door GrooV op 27 september 2024 12:16]

[Loen]

Mja, als je op shodan verder kijkt zie je vaak dat de port zelf een 403 terug geeft. Daarnaast, als het al echt een exposed cups service zou zijn, moet je eerst de gebruiker nog laten printen naar de malicious printer. Zeker, het is niet niks, maar de aankondiging eerder deze week liet veel erger vermoeden.

Overigens, 1214x cups in NL met open port 631 volgens shodan. Ik weet overigens niet precies wat shodan doet om die 403 terug te krijgen. Kan natuurlijk zijn dat dat default behaviour is. Groot deel lijkt in serverfarms te staan. Misschien misconfigured, misschien honeypots, maar dat zijn geen bakjes waar je over het algemeen een gebruiker een print zal kunnen laten starten

[Reactie gewijzigd door Loen op 27 september 2024 12:27]

[Lizard]

De 403 krijg je op port 631 op tcp niveau. Het lek gaat via port 631 udp.

[Loen]

Ah, natuurlijk. Geen response is logischer voor udp

Als je op shodan zoekt op udp:631 udp dan krijg je maar 678 resultaten wereldwijd, waarvan 3 in NL. Lijkt me nog steeds eerder dan dat honeypots zijn

[MacGyverNL]

Het probleem met die analyse is dat je op UDP niet naïef, i.e. protocol-agnostisch, kunt scannen, omdat er geen handshake is om een verbinding op te bouwen. Voor deze kwetsbaarheid vatbare systemen ga je niet op die manier in Shodan vinden, want het is geen simpele "stuur een pakket en krijg een pakket terug". Je moet een correct geformat IPP-bericht erheen sturen, dat door de Avahi daemon aan de kwetsbare software wordt gegeven, en dan verbindt de kwetsbare software met jouw machine terug.

Simone's eigen probes laten -- naar zijn zeggen, maar er is echt geen reden waarom hij dít zou overdrijven -- tien- tot honderdduizenden systemen zien die reageren. En dat zijn dus alleen maar de systemen die die poort bereikbaar hebben vanaf het internet -- dat telt de systemen die kwetsbaar zijn als ze bij de Starbucks op WiFi zitten niet mee.

Simone is ook de auteur van bettercap en gaat deze scanvorm in de volgende versie inbouwen.

Edit: ik meende me te herinneren dat Avahi actief moest zijn op je systeem maar na even snel checken lijkt het erop dat cups-browsed zelf direct luistert.

[Reactie gewijzigd door MacGyverNL op 27 september 2024 18:59]

[Loen]

Ik zou alleen verwachten dat ze wel protocol specifieke packets kunnen sturen (kan nmap volgens mij ook) als ze wel die open udp port 631 vinden.

Die potentiële cups printers bij een Starbucks (overigens, die rechtstreeks aan internet hangen misschien nog meer) verdienen het overigens om gehacked te worden.

Dan alsnog, als je alleen een printer kunt spoofen en eerst nog een print moet sturen past dat eerder een halve definitie van een RCE. Het is zeker een issue, maar het nieuws eerder deze week leek een heel stuk erger. Ik weet niet of dat door communicatie issues komt, maar de lezing was RCE en all Linux distros. Dat is simpelweg niet waar natuurlijk

[MacGyverNL]

Ik zou alleen verwachten dat ze wel protocol specifieke packets kunnen sturen (kan nmap volgens mij ook) als ze wel die open udp port 631 vinden.

Dat kan zeker, maar dan moet toch echt eerst iemand die scan schrijven, en dat is gewoon nog niet gedaan. Het zou me ook zeer verbazen als we níet binnenkort wél die systemen op Shodan zien verschijnen.

Die potentiële cups printers bij een Starbucks (overigens, die rechtstreeks aan internet hangen misschien nog meer) verdienen het overigens om gehacked te worden.

Het zijn niet de printers die kwetsbaar zijn. Het zijn de laptops (en desktops) die cups-browsed draaien om automatisch printers op het (lokale) netwerk te detecteren en toe te voegen. En blijkbaar (wist ik ook niet) staat dit standaard aan in meerdere Linux-distributies. Wat kunnen de mensen die gewoon een distro geïnstalleerd hebben eraan doen dat dit spul standaard aan staat?

Dan alsnog, als je alleen een printer kunt spoofen en eerst nog een print moet sturen past dat eerder een halve definitie van een RCE.

Ik ben het met je eens (en Simone zelf overigens ook) dat de initiële CVSS vreemd was en in hindsight incorrect, want de Red Hat-mensen hadden hem zónder gebruikersinteractie ingeschaald. Dat gezegd hebbend, je kunt met deze vulnerability ook bestaande printers overriden. En hoe hard half ex-twitter ook beweert dat niemand ooit meer print, de praktijk wijst toch echt uit dat voldoende mensen nog steeds gewoon dode bomen voor legio dingen gebruiken.

Ja het initiële lek leek zorgwekkender dan het blijkt te zijn, en ik heb zeker persoonlijke meningen over hoe dit gegaan is, maar ga alsjeblieft niet de daadwerkelijke impact daarom óók bagatelliseren.

[Nahata]

moet je eerst de gebruiker nog laten printen naar de malicious printer.

Zou een test page printen vanuit cups niet werken dan?

[Alfa1970]

Ik kan me zo voorstellen dat dat kan.
En je moet jezelf bedenken dat als er eenmaal een gat is gevonden, het héél goed mogelijk is als je het koppelt met andere zaken dat de gebruiker inderdaad helemaal niks zelf hoeft te doen.
Uiteindelijk werkt de POC ook samen met meerdere kwetsbaarheden, niemand die zegt dat het daar moet stoppen.

[Reactie gewijzigd door Alfa1970 op 27 september 2024 18:43]

[wica]

Hoe kom je aan 300.000? Volgens Shodan zijn het er ongeveer 75.000. Mee eens, dat elke er 1 te veel is.
Maar om eerlijk te zijn, met zijn aankondigen. Hadden we eerder iets in de netwerk stack verwacht.
Wat dus nog ergens zou zijn, daar hij nog zei "still no working fix."

Ik erken, dat de bug ernstig is, maar niet zo rampzalig als hij deed voorkomen.
Het verwijderen van cups-browsed of je FW er voor dicht gooien is voldoende.

[Mellow Jack]

Op Linux desktop zal de impact idd redelijk groot zijn. In de media wordt de term Linux gebruikt voor OS'en met Linux kernel die op desktops en servers draaien. Dan is de impact nihil. Als je kijkt naar devices met Linux kernel dan is di impact 0

[Lucb1e]

De score klopt echter niet. Je moet in de standaardconfiguratie op LAN zitten om het kwetsbare component te bereiken en de gebruikers computer moet online zijn (passieve interactie). Als je dat in de CVSS 4-calculator gooit en verder alles op maximaal erg zet kom je op een lagere score uit dan de geclaimde 9.9

Edit: ah, iets verderop in de reacties zei iemand dit ook al

[Reactie gewijzigd door Lucb1e op 27 september 2024 13:17]

[Expresso]

Een stuk minder dan dat oorspronkelijk gezegd werd. Een crit rating van 9.9/10 op ALLE Linux computers is toch echt gigantisch zwaar. De aanvankelijke aankondiging liet vermoeden dat het om een beveiligingsgat in de kernel zelf ging die op zo'n plaats zit dat iedereen het wel moet hebben, die tot een root console leidt door er simpelweg de exploit te activeren vanaf het internet.

Dat het hier over CUPS gaat, waar de gebruiker ook nog wat moet doen, maakt het allemaal een stuk minder erg. Niettemin is elke exploit een probleem, maar dit zou ik absoluut geen 9.9/10 geven.

[Anoniem: 1028301]

Gisteren twee updates gekregen die verband hielden met cups,
ze hebben het opepakt.

[goarilla]

Is dit de RCE 9.9/10 undisclosed linux vuln nu ? En ik heb het altijd gewantrouwd die proliferatie van ongebruikte maar altijd draaiende "automagische configuratiediensten" (avahi/zeroconf, mDNS, nmbd, ...)

[ray0755]

Even benieuwd: zette je die services dan ook uit?

[goarilla]

Nee want ik draaide Slackware en die services zaten er niet in buiten de Samba netbios master browsing (nmbd) maar dat (Samba) firewall je zowiezo tot je eigen LAN. Ik denk ook niet dat het nog gaat om bv. avahi/zeroconf af te zetten op RHEL systemen. Op mijn test debian VM's laat ik ze staan want ze zitten toch achter localhost en een VM laag en ik wil geen tijd besteden aan wellicht vele vruchteloze rondjes whack-a-mole.

PS: mijn debian test VM's bevatten blijkbaar alleen 3 libavahi pakketjes met schijnbaar alleen docs

[Reactie gewijzigd door goarilla op 27 september 2024 20:48]

[ray0755]

Met nieuwe installs heb ik ondertussen zo'n grote lijst met services om te masken, dat ik er een script voor heb gemaakt die ik eenmalig draai. Geen ervaring met RHEL, maar de avahi-daemon service én socket zijn prima te disablen/masken (o.a. op Fedora).

[goarilla]

Super, goed om te horen dat het gaat.

[De Vliegmieren]

Ik kreeg al de indruk dat deze security onderzoeker een beetje een dramaqueen is.

Op google ook al een heel verhaal over een sollicitatie bij DarkMatter en hoe dat niet spoort. Had 'ie dat niet kunnen opzoeken voordat hij naar de VAE afreiste? Lol..

[pven]

Mooi verwoord! Iets met storm en een glas water.

[pimlie]

Ubuntu heeft het al gedicht: https://ubuntu.com/blog/c...lnerability-fix-available

[Regn0]

Is er bekend welke versie van de daemon de fix bevat? Ik neem aan dat ik dan kan checken op m’n installatie of die gefixte versie geïnstalleerd is.

[IStealYourGun]

Het blijft een security incident, maar heeft het wel opgeblazen en een 9.9 score geven die eigenlijk lager zou moeten zijn.

Zo geeft hij attack vector network mee, waar die eerder adjacent network is. Doorgaans gaat je client of print server wel achter een fw zitten of natten.

Ook beweert de onderzoeker dat er geen interactie nodig is, maar je moet wel degelijk een print opdracht versturen naar een onbekende printer.

Vooral dat laatste maakt het onwaarschijnlijk dat het echt bruikbaar is imo. Meeste mensen hebben geen printer of printen weinig en al zeker naar printers die ze niet kennen.

[Reactie gewijzigd door IStealYourGun op 27 september 2024 18:01]

[Magic Power]

Ook beweert de onderzoeker dat er geen interactie nodig is, maar je moet wel degelijk een print opdracht versturen naar een onbekende printer.

Voor zover ik lees kunnen bestaande printers ook kwetsbaar zijn en misbruikt worden. Zoals in deze blogpost staat:

A remote unauthenticated attacker can silently replace existing printers’ (or install new ones) IPP urls with a malicious one, resulting in arbitrary command execution (on the computer) when a print job is started (from that computer).

[dgompie]

Mocht het aanstaan, als je UFW (firewall) geactiveerd hebt, wordt het dan niet alsnog tegengehouden?

[fastedje]

Er is een WAN attack en een LAN attack gevonden. Het beste is om alle cups services uit te zetten en je firewall voor cups.poorten te blokkeren.

Wat ik niet snap: we weten al jaren dat UDP een groot lek is, dus waarom niet gewoon afschaffen en de extra.overhead van TCP dan maar voor lief nemen?

[downtime]

What would be the point? Er zijn wel meer lekke protocollen (het hele emailsysteem is 1 groot lek protocol) maar we blijven het gebruiken omdat het nu eenmaal bestaat en we nooit iedereen zover krijgen om naar alternatieven over te stappen. Ik geloof dat we nu ook al 30 jaar proberen om IPv4 uit te faseren en daar blijven we nog wel de komende 30 jaar mee bezig.

[CH4OS]

Het 'emailsysteem' (applicatielaag) is dan weer wel een andere laag dan waar UDP/TCP (transportlaag) op opereren volgens het OSI model. Strict gezien vergelijk je nu dus appels met peren. Waarom SMTP/IMAP en eventueel POP3 nog uitgefaseerd zou moeten en wat dan het alternatief erop zou moeten zijn ontgaat mij daarnaast ook volledig.

[Reactie gewijzigd door CH4OS op 27 september 2024 12:09]

[c-nan]

Nou nou, IPv6 bestaat nog niet eens 30 jaar, om dan te stellen dat we IPv4 al 30 jaar lang proberen uit te faseren gaat wel erg ver. Ook geloof ik niet dat we daar de komende 30 jaren nog mee bezig zullen zijn

Maar ik snap ook de reactie van @fastedje niet, hoezo weten we al jaren dat het een groot lek is?

[CH4OS]

Als bekend is dat UDP 'al jaren' lek is, waarom zou Google dan UDP gebruiken om HTTP/3 erop te baseren? Ik ben dus zeer benieuwd waarom je concludeert dat UDP 'al jaren' lek zou zijn.

Juist die overhead is namelijk niet per se nodig voor (voornamelijk) eenrichtingsverkeer (zoals HTTP) verkeer. Naar mijn weten is het verschil tussen de twee ook niet heel groot, TCP heeft als extra foutafhandeling er in zitten, met o.a. de mogelijkheid om bepaalde packages/data opnieuw te requesten. Maar is dus in genoeg gevallen totaal niet interessant, zoals eenrichtingsverkeer.

[Reactie gewijzigd door CH4OS op 27 september 2024 12:06]

[Anoniem: 334725]

Sterker nog je kan tcp implementeren met udp.

[Lucb1e]

ben dus zeer benieuwd waarom je concludeert dat UDP 'al jaren' lek zou zijn.

Dit moet eigenlijk wel refereren aan amplification attacks, want iets anders is niet echt van toepassing op de omschreven manier

Die aanvallen zijn overigens te voorkomen door goed protocolontwerp of, voor oude protocollen zoals DNS, met rate limiting en/of extensies (bijvoorbeeld "DNS cookies", een nogal ongelukkig gekozen naam )

[Reactie gewijzigd door Lucb1e op 27 september 2024 13:21]

[latka]

UDP is niet inherent onveilig ofzo. Sterker nog: HTTP3/QUIC gaat juist naar UDP toe ivm. performance. Het is wel zo dat UDP verkeer 1 richting kan zijn, dus het faken/spoofen van de afzender is minder belangrijk als er geen retourbericht nodig is.

[Anoniem: 334725]

Udo en tcp zijn protocollen en hebben niks te maken met veiligheid dus ik snap niet zo wat je zegt.

[vide]

Zorgt je firewall ook dat lokaal verkeer, binnen lokaal netwerk of van toestel zelf, ook tegengehouden wordt. Vanaf de lokale machine zou het nog steeds gebruikt kunnen worden om code uit te kunnen voeren in een security context die je anders niet zou hebben.

[Soldaatje]

Dat hangt af van de configuratie, de firewall kan ook de port naar localhost blokkeren, dit zal standaard niet zo zijn neem ik aan.

[Lucb1e]

UFW (in de standaardconfiguratie) voorkomt inkomende verbindingen die je niet zelf hebt aangezet (geallowlist of hoe heet dat). Als je echter packets uitzendt om een printer te zoeken of te printen via het netwerk, houdt het dat niet tegen

[Reactie gewijzigd door Lucb1e op 27 september 2024 13:18]

[goarilla]

Jep zelf geinitieerde (TCP) pakketjes zijn ge-connection tracked en behoren tot een toegelaten datastroom.

Chain ufw-before-input (1 references)
pkts bytes target prot opt in out source destination
18 1512 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
9694 1722K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
120 6240 ufw-logging-deny all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate INVALID
120 6240 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate INVALID

Dit is op Debian 11/Bullseye.

[Lucb1e]

output van iptables -v -L of zoiets denk ik? Misschien goed om erbij te vermelden voor als mensen hun eigen setup willen vergelijken of nakijken

[goarilla]

Ik heb denk ik

ufw show raw

gedaan en dan het relevante deel eruit geknipt - is ook nieuw voor mij (ufw). Maar dit is inderdaad equivalent aan het vertrouwde

iptables -v -n -L

edit: wijzigen quote haakjes en ufw show ipv ufw report

[Reactie gewijzigd door goarilla op 27 september 2024 20:30]

[Lucb1e]

ah, ik wist niet dat ufw dat kon tonen! Cool, weer wat geleerd

[dmantione]

De "ontwikkelaar van CUPS" is dat bedrijfje met een appel als logo en ik zou verwachten dat dit dan ook voor MacOS geldt.

[JeroenED]

Nee klopt niet. Cups werd oorspronkelijk onafhankelijk ontwikkeld door een bedrijf dat werd overgenomen door apple. En in 2020 heeft de linux foundation onder openprinting een fork uitgebracht met de oorspronkelijke developer aan het roer. Hier word specifiek de linux versie bedoeld. Geen idee of de mac os versie ook kwetsbaar is.

Wikipedia: CUPS

[Reactie gewijzigd door JeroenED op 27 september 2024 11:31]

[33Fraise33]

In de blogpost hint de schrijver naar een 2e blogpost ivm apple vulnerabilities die nog niet disclosed mogen worden.

[tisvonkje]

Dat is wel kort door de bocht. Apple CUPS is niet hetzelfde als openprinting CUPS.

[kodak]

Sinds een afsplitsing enkele jaren geleden is Apple CUPS in ontwikkeling voor Apple en OpenPrinting CUPS voor veel andere OS-distributies. Wie er last van heeft hangt er maar net vanaf wanneer het probleem is ontstaan en wie het overgenomen heeft. Maar dat hangt daarbij dan ook nog af of het wel in gebruikt is. Meestal wil je dit soort services niet standaard aan hebben staan.

[joyrider3774]

sudo systemctl stop cups-browsed

stop dat niet gewoon tijdelijk de service / deamon ? bedoel als je het wilt uitschakelen moet je dan (nadien ook) niet hetvolgende gebruiken om de service volledig te disablen of werkt dat anders op redhat ?

sudo systemctl disable cups-browsed

anders staat het na een reboot of zo toch gewoon weer aan ?

[Reactie gewijzigd door joyrider3774 op 27 september 2024 11:22]

[Anonymoussaurus]

Je kan het ook in 1 command stoppen:

`sudo systemctl disable --now cups-browsed`

En ja, als je het niet disabled staat het weer aan na een reboot.

[Reactie gewijzigd door Anonymoussaurus op 27 september 2024 11:28]

[joyrider3774]

ah handig, maar het artikel vermeld het stop commando als uitschakel commando en dat klopt niet volledig volgens mij

[Anonymoussaurus]

Sowieso vind ik het altijd vaag als websites het dollarteken in een one-liner meenemen, want dat hoort helemaal niet bij het commando. Het toont dat je het in de CLI moet draaien. I mean, waar anders? Een bash-script?

[Reactie gewijzigd door Anonymoussaurus op 27 september 2024 11:28]

[rubenvb]

Dollarteken vs # geeft wel aan normale user vs root shell natuurlijk.
Hoewel zshell liever een percentje toont.

[Hardfreak]

Ik vind het wel handig dat ze het doen, maar `sudo` is over het algemeen niet nodig om systemctl status aan te roepen, dus dat mochten ze er voor de correctheid ook aflaten.
Het is pas als je `systemctl disable` doet dat sudo nodig is.

[Z80]

Unix en Linux op een grote hoop gooien ook niet.

Klinkt als klok, en de schrijver van het stukje weet niet waar de klepel hangt.

[markjanssen]

Nou draait cups ook op *BSD en Unix systemen, dus ze hier groeperen is acceptabel

[sfranken]

Voor de mensen die een snelle oneliner willen om te kijken of cups-browsed actief is (met systemd):

$ systemctl is-enabled cups-browsed

Komt dat terug met iets anders dan "disabled" kun/moet je 'm dus uitschakelen. De oneliner hierboven is wat makkelijker "parsen" dan de volledige info van $ systemctl status cups-browsed

[goarilla]

Mja dan ga je er indirect vanuit dat de unit/service whatever abstractie systemd het noemt "cups-browsed" noemt. Wat dan enkel op debian of RHEL of ... zo zal kunnen zijn. Ik zou eerder een systemctl status doen en dan zoeken "/cups" en n/N als less de pager is.

[sfranken]

Het is een gegeven dat dit ding op zo'n beetje elke distro dus gewoon cups-browsed heet, aangezien dat zo uit de broncode ervoor komt en ik geen enkele (professionele) distro ken die dat aanpast in de broncode van CUPS

[goarilla]

AAh juist ja, goed om te weten. CUPS brengt de unit files en naam dan zelf waarschijnlijk aan vermoed ik.
Als oud Slackware gebruiker moest je vroeger de bijgevoegde init.d scripts altijd nakijken en daar waar nodig aanpassen.
Maar dat is geen (professionele) distro. Alhoewel dat niets wil zeggen over de kwaliteit ervan. Ik heb een hekel aan SuSE, opgelopen tijdens de 7.x -> 9.x tijd, maar ook openSUSE 10.1 kon die afkeur niet ontmijnen.

[Reactie gewijzigd door goarilla op 27 september 2024 20:36]

[sfranken]

Als oud Slackware gebruiker moest je vroeger de bijgevoegde init.d scripts altijd nakijken en aanpassen

Dat is dus iets wat al 20 jaar niet meer hoeft (in de rest van de Linux wereld dan, geen ervaring met Slackware)

[goarilla]

20 jaar is misschien wat lang niet ? Wanneer heeft ubuntu upstart eruit geknikkert maar je hebt wellicht wel gelijk. Er werd vermoedelijk wel gezorgd dat upstart init scripts werktte. Slackware had als standaard alle init scripts in /etc/rc.d/ met een /etc/init.d/ wrapper directory die min of meer het gedrag van SXXservice en KXXservice symlinks naar die scripts emuleerde.

[sfranken]

20 jaar is inderdaad wat lang, het is 10. Maar Ubuntu is in deze niet een goede maatstaaf, want die zijn soms érg traag met het overnemen van zaken. Iets met kat uit de boom kijken. Ubuntu heeft Upstart vervangen voor systemd in 2011, en defintief gemaakt in 2015 zo te zien.

[Videopac]

Kreeg vanmorgen een update in Mint.

[Defspace]

Weet niet wie je op 0 zet, maar je reactie is wel relevant, net mijn Mint gecontroleerd en staat kennelijk standaard enabled.

[marktweakt]

Wat hield die update in? Staat die service dan standaard op disabled of hebben ze echt het probleem in de service gefixt?

[UPPERKEES]

In hoeverre helpt SELinux bij dit soort dingen?

[sfranken]

Niet veel, aangezien dit een SELinux label/context heeft die het uitvoeren van cups-browsed gewoon toelaat.

[The Zep Man]

De distro laat weten dat gebruikers met het commando $ sudo systemctl status cups-browsed erachter kunnen komen of het proces is geactiveerd. Indien dat het geval is, kunnen ze het met $ sudo systemctl stop cups-browsed uitschakelen.

Hetzelfde onder Arch Linux-achtige distributies. Onder Arch Linux wordt cups-browsed standaard niet eens geïnstalleerd omdat het een apart package betreft. Je kan dus ook kijken of package cups-browsed geïnstalleerd is. Zo niet, dan zit je goed. Dat kan met:

$ pacman -Q cups-browsed

[Reactie gewijzigd door The Zep Man op 27 september 2024 11:34]