Archief
- De topics van lang geleden
etc/passwd file
18-06-2007, 08:23 door Anoniem, 14 reacties
Hallo !
Wanneer je na de file /etc/passwd gaat. Staan hier een aantal
user names voor het uitvoeren van shells. Nu vraag ik me alleen af
waarvoor
bin,deamon,lip,mail,news,uucp,games,man,a,/wwwrun,ftp,postfix,sshd,
ntp,nobody zijn. En bv waarom bin:x:1:1 is gezet als je ingelogd ben met
root:x:0:0. Weet iemand misschien dit?
Wanneer je na de file /etc/passwd gaat. Staan hier een aantal
user names voor het uitvoeren van shells. Nu vraag ik me alleen af
waarvoor
bin,deamon,lip,mail,news,uucp,games,man,a,/wwwrun,ftp,postfix,sshd,
ntp,nobody zijn. En bv waarom bin:x:1:1 is gezet als je ingelogd ben met
root:x:0:0. Weet iemand misschien dit?
Reacties (14)
18-06-2007, 11:51 door
root
Dat zijn allemaal gebruikersnamen dit gebruikt worden door
programma's. sshd bijvoorbeeld is de user waaronder de
secure shell daemon draait. De meeste hebben geen wachtwoord
ingesteld en je kunt er dus niet mee inloggen. Niet
verwijderen, geen wachtwoord instellen, gewoon afblijven.
programma's. sshd bijvoorbeeld is de user waaronder de
secure shell daemon draait. De meeste hebben geen wachtwoord
ingesteld en je kunt er dus niet mee inloggen. Niet
verwijderen, geen wachtwoord instellen, gewoon afblijven.
18-06-2007, 12:20 door
SirDice
Vroeger draaide alles op root. Door schade en schande is men
wijzer geworden en hebben ze bepaalde services nu op een
eigen account met beperkte rechten draaien. Daar zijn deze
accounts voor.
wijzer geworden en hebben ze bepaalde services nu op een
eigen account met beperkte rechten draaien. Daar zijn deze
accounts voor.
18-06-2007, 16:10 door
SirDice
Door root
De meeste hebben geen wachtwoord ingesteld en je kunt er dus niet mee inloggen.
Omdat ze geen wachtwoord hebben kun je er niet mee inloggen?De meeste hebben geen wachtwoord ingesteld en je kunt er dus niet mee inloggen.
Nee, dat ligt eerder aan de login shell en de home directory. Op bsd is dat meestal /usr/sbin/nologin als shell en /nonexistent voor $HOME.
Niet verwijderen, geen wachtwoord instellen, gewoon afblijven.
Eens. Wel regelmatig controleren of ze niet spontaan veranderd zijn mbt login shell en home directory ;)Ok thanks ! Maar waarom hebben ze dan eigenlijk allemaal
verschillende rechten en niet allemaal 0:0 zoals bij root eigenlijk het
geval is ?
verschillende rechten en niet allemaal 0:0 zoals bij root eigenlijk het
geval is ?
18-06-2007, 16:33 door
root
Door SirDice
Omdat ze geen wachtwoord hebben kun je er niet mee inloggen?
Omdat ze geen wachtwoord hebben kun je er niet mee inloggen?
OK, om preciezer te zijn: er is wel een hash ingesteld (een * of een !), maar het is geen geldige MD5 hash, zodat je er nooit in komt.
Door Solid
Ok thanks ! Maar waarom hebben ze dan eigenlijk allemaal verschillende rechten en niet allemaal 0:0 zoals bij root eigenlijk het geval is ?
Ok thanks ! Maar waarom hebben ze dan eigenlijk allemaal verschillende rechten en niet allemaal 0:0 zoals bij root eigenlijk het geval is ?
Ze hebben allemaal de rechten die ze nodig hebben, niet meer en niet minder. Als ze allemaal root rechten zouden hebben, dan zouden ze niet hoeven te bestaan.
Waarom google je niet eens op /etc/passwd?
Waarom google je niet eens op /etc/passwd?
Daar ben ik ook al mee bezig maar dacht misschien vonden andere
lezers het ook wel intresant om er meer over te leren. Los hier van leerd het plezieriger via een forum dan een artikel. En gezien het eensecurity related is. Dacht het wel gepast was.
Ze hebben allemaal de rechten die ze nodig hebben, niet meer en niet minder. Als ze allemaal root rechten zouden hebben, dan zouden ze niet hoeven te bestaan.
Begin het te begrijpen van de guest en root wist ik het maar die andere niet.
19-06-2007, 08:42 door
SirDice
Onder (standaard) *nix is root oppermachtig, dat account kun je nergens uithouden. Om een voorbeeld te geven: Vroeger draaide de finger daemon ook op root. Vervolgens kwam er een exploit uit die via finger het systeem binnen kon komen. Presto, instant root access. Doordat finger nu niet meer als
root draait kan een eventueel probleem in de finger daemon niet meer zulke ver strekkende gevolgen hebben. Ditzelfde geldt voor apache en al die andere daemons.
root draait kan een eventueel probleem in de finger daemon niet meer zulke ver strekkende gevolgen hebben. Ditzelfde geldt voor apache en al die andere daemons.
19-06-2007, 18:00 door
SirDice
Door Solid
Dus apache heeft ook z'n eigen acount onder /etc/passwd?
Yep. Meestal www, zie de httpd.conf. Daar wordt het account opgegeven.Dus apache heeft ook z'n eigen acount onder /etc/passwd?
19-06-2007, 18:07 door
SirDice
/etc/passwd bestaat alleen nog voor backwards
compatibiliteit. Alles loopt tegenwoordig via /etc/shadow.
compatibiliteit. Alles loopt tegenwoordig via /etc/shadow.
20-06-2007, 00:53 door
[Account Verwijderd]
[Verwijderd]
Door SirDice
/etc/passwd bestaat alleen nog voor backwards
compatibiliteit. Alles loopt tegenwoordig via
/etc/shadow.
/etc/passwd bestaat alleen nog voor backwards
compatibiliteit. Alles loopt tegenwoordig via
/etc/shadow.
Dat is niet helemaal waar. Voor de MD5-hashes van de
passwords heb je gelijk, maar bijvoorbeeld de mapping van
UID met de username, zoals gebruikt bij bijvoorbeeld een ls
-l, wordt /etc/passwd wel degelijk gebruikt. En ook door
"mortal" users binnen unix (de niet-root-users). Dus zeker
geen "backwards compatibility only" functionaliteit.
20-06-2007, 11:02 door
SirDice
man shadow is erg summier.. Maar man master.passwd op BSD geeft wat meer info..
De reden dat programma's die op een 'gewoon' user account draaien gebruik maken van /etc/passwd is simpel:
En:
Om het verhaal wat completer te maken. Vroeger bestond er niet zoiets als shadow password files. De hashes stonden in /etc/passwd. Daarom vragen 'oude' exploits deze file op.
Later is men in gaan zien dat dit toch niet zo heel slim was en hebben ze dit shadow verhaal geimplementeerd. Maar omdat er dus ook programma's zijn die bijv. uid -> username conversies moeten doen met de rechten van een 'gewone' gebruiker is de huidige constructie bedacht. /etc/passwd is er dus wel degelijk als een soort 'backward compatibiliteit'. De andere optie was het SUID root maken van die programma's maar dat is, uiteraard, niet zo'n slimme zet.
De reden dat programma's die op een 'gewoon' user account draaien gebruik maken van /etc/passwd is simpel:
The master.passwd file is readable only by root, and consists of newline separated records, one per user, containing ten colon (``:'') separated fields. These fields are as follows
Dit is gedaan om het offline bruteforcen van de password hashes door 'gewone' gebruikers tegen te gaan. En:
The passwd file is generated from the master.passwd file by pwd_mkdb(8), has the class, change, and expire fields removed, and the password field replaced by a ``*''.
Om het verhaal wat completer te maken. Vroeger bestond er niet zoiets als shadow password files. De hashes stonden in /etc/passwd. Daarom vragen 'oude' exploits deze file op.
Later is men in gaan zien dat dit toch niet zo heel slim was en hebben ze dit shadow verhaal geimplementeerd. Maar omdat er dus ook programma's zijn die bijv. uid -> username conversies moeten doen met de rechten van een 'gewone' gebruiker is de huidige constructie bedacht. /etc/passwd is er dus wel degelijk als een soort 'backward compatibiliteit'. De andere optie was het SUID root maken van die programma's maar dat is, uiteraard, niet zo'n slimme zet.
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
