Journal – Een nieuwe logging daemon

 
15 december 2011

Deze blogpost is eens niet direct gericht op programmeer technieken, maar juist op een ontwikkeling op het gebied waar we onze producten vaak op toepassen: een Linux server. Ondanks het belang van dit onderwerp, weten we vaak relatief weinig van de ins en outs op dit gebied. In deze blogpost wil ik dan ook wat vertellen over de ontwikkelingen op het gebied van logging die momenteel spelen.

Het bekende Redhat heeft, naast de commercieel georiënteerde Redhat Enterprise Linux, nog een Linuxdistributie waar ze aan werken. Deze heet Fedora, en wordt veelal gezien als ‘de speeltuin’, de distributie waar nieuwe technieken in worden getest voordat ze worden opgenomen in Redhat. Een van de onderwerpen die in de huidige Fedora releases centraal staat, is het upgraden van de init daemon. Redhat probeert hier een moderne, nieuwe implementatie van te maken.

Een van de gerelateerde zaken die ze ook willen vervangen is het logging framework, traditioneel aangeboden door Syslog en consorten. Dit willen ze vervangen door een nieuw product genaamd Journal, onderdeel van systemd. De belangrijkste veranderingen tussen de traditionele Syslogs en Journal komen neer op vier belangrijke onderwerpen:
– Logging is opt in in plaats van opt out.
– Messages kunnen veel meer informatie bevatten.
– Snellere en eenvoudigere logparsing.
– Verifieerbare logchains.

De eerste grote wijziging is dat daemons niet meer expliciet hoeven te loggen. Alles wat op de stdin en stdout wordt weggeschreven wordt al in de log geplaatst. Dit betekent dat eenvoudige daemons erg simpel kunnen loggen: gewoon net als in userspace data wegschrijven naar één van de standaard streams. Logging is hiermee een integraal onderdeel van het systeem geworden. De init daemon zorgt dat bij het spawnen van een service de streams aan elkaar worden gekoppeld. Er is ook nog een specifieke Journal interface, en zelfs ‘the good old’ syslog() blijft bestaan.

Log messages kunnen bij Journal ook veel meer informatie bevatten. Dit wordt gerealiseerd door enerzijds het toevoegen van binaire data toe te staan. Een crashende daemon zou bijvoorbeeld een coredump kunnen loggen. Daarnaast wordt informatie gelogd als individuele metadatavelden. Deze zijn er voor uid, gid, /proc/self/cmdline of eventuele zelfgedefinieerde velden.
Dit soort input heeft tot gevolg dat de log niet meer standaard als tekst te parsen is, iets wat tot de nodige kritiek heeft geleid. Journals primaire consumer van de logs is echter geen mens, maar juist de machine. Door middel van een meegeleverde library is de log te parsen naar iets wat voor mensen een zinvolle betekenis heeft.

De journal is ook sneller in het benaderen van individuele log entries. In tegenstelling tot de traditionele, plain text interface is de journal een database van messages. Dankzij indexes kan de toegangstijd tot specifieke content in veel gevallen worden versneld. Een gewone tekstlog moet immers helemaal worden doorgelopen op zoek naar een specifieke message.

De laatste – en in mijn ogen belangrijkste – verandering is de mogelijkheid tot het verifiëren van logchains. Bij de traditionele tekstuele logs kunnen, mits er geen gebruik wordt gemaakt van een logging host, bij een inbraak eenvoudig wijzigingen worden uitgevoerd aan deze log. Er kan bijvoorbeeld worden verwijderd dat er een login is geweest van user x, die vervolgens root rechten heeft gekregen. Wanneer dit discreet word aangepakt, is het mogelijk bijna helemaal onder de radar te blijven, en zo het systeem te compromitteren.

Bij Journal word iedere log message vergezeld met een hash van zichzelf, en de hash van de voorganger. Op deze manier ontstaat er dus een verifieerbare log chain. Mits er geen collisions worden gecreëerd kan er dus een hash worden onthouden, welke gebruikt kan worden om de chain met alle voorgaande log messages te verifieren. Git-gebruikers zullen dit herkennen, hier gebeurt hetzelfde met commits.

Een kwaadwillende gebruiker kan, mits de messages opgeslagen zijn vóór het moment van de laatste geverifieerde hash, nu niet zomaar meer log messages modificeren. Dit betekent immers dat de gebruikte hash en message niet meer valide zijn. De chain is hiermee gebroken.

De ‘top’ hash van de chain zal dus regelmatig op een veilige locatie moeten worden weggeschreven. Dit is gelijk één van de twee zwakke plekken van het mechanisme. Er kan niet worden gegarandeerd dat een intruder met root acces de chain opnieuw kan hashen, eventueel met het wegschrijven naar deze locatie. Linux ondersteunt geen echte secure mode, een gegarandeerde append- only file die zelfs niet kan worden overridden door root.

In het ontwerpdocument van Journal wordt het probleem van de tophash als volgt geaddresseerd: If the top-most hash is regularly saved to a secure write-only location, the full chain is authenticated by it. Manipulations by the attacker can hence easily be detected.

Modifications in de chain kunnen dus perfect worden geverifieerd, mits deze wijziging plaatsvindt vóór het moment dat de laatste hash is opgeslagen. Stel dat wij iedere maandag de hash verifiëren en extern noteren. Een aanvaller die dinsdag inlogt, root acces verkrijgt en de logs aanpast zal dan op de maandag daarna onopgemerkt blijven.

Ondanks deze beperkingen is het systeem in mijn mening behoorlijk waardevol. Veel intrusions vinden namelijk niet in één keer plaats, maar worden langzaamaan opgebouwd. Vaak worden deze al ruim van te voren in logs aangekondigd. Denk aan het analyseren van draaiende services, of het uitvoeren van mislukte exploits. Als deze adequaat worden gelogd, en daarna ook worden onderzocht, is er een grote kans dat eventuele inbraken aan het licht komen.

Naast het veiligheidsissue is de rest van het systeem zelf ook veelbelovend. Het opslaan van (meer en duidelijkere) data, en het impliciet koppelen van daemons aan logging zijn twee belangrijke vooruitgangen. Daarnaast kan, doordat iedere log en zijn entries allemaal zijn voorzien van metadata, er aanzienlijk makkelijker geparsed worden. Iedereen die weleens een Unix log heeft moeten parsen weet dat het gebruik van gecompliceerde reguliere expressies dan vereist is. Dit is iets wat het onderhoud vaak niet ten goede komt…


Werken met ?
Kijk dan bij onze mogelijkheden voor starters en/of ervaren IT'ers.


Categorieën: Linux, Open Source, Operating systems