[linux] extra root user?

[Arioch]

Is het mogelijk om een extra user te maken met dezelfde rechten als root?
En zoja: hoe?

[Verwijderd]

Simpel : Nieuwe user aanmaken en volgende uitvoeren :

root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin

Getalletje 1 en 1 aanpassen in 0 en 0.

Succes ..

PS Bin is wel geen geldige login maar dat even terzijde.

[CyeZ]

Op woensdag 17 juli 2002 23:22 schreef Winegummetje het volgende:
Simpel : Nieuwe user aanmaken en volgende uitvoeren :

root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin

Getalletje 1 en 1 aanpassen in 0 en 0.

Succes ..

PS Bin is wel geen geldige login maar dat even terzijde.

Niet helemaal. Voor de meeste programma's werkt dat ja.
De meeste programma's controleren of iemand root is door te kijken of user en group id beide 0 zijn. Sommige kijken echter (ook) naar de username, en daarvoor zal dus alleen de user met als naam 'root' werken.

[deadinspace]

Op woensdag 17 juli 2002 23:27 schreef CyeZ het volgende:

[..]

Niet helemaal. Voor de meeste programma's werkt dat ja.
De meeste programma's controleren of iemand root is door te kijken of user en group id beide 0 zijn. Sommige kijken echter (ook) naar de username, en daarvoor zal dus alleen de user met als naam 'root' werken.

Programma's kijken doorgaans helemaal niet naar het uid, gid of username, dat doet de kernel. En die controleert alleen op uid of gid (welke van toepassing is).
Er zijn wel apps die zelf op uid of gid controleren, maar dat is redelijk zeldzaam. Apps die op username controleren om te zien of je root bent heb ik iirc nog nooit gezien.

[Verwijderd]

Ehh, blackhat.. waar wil je dat voor gebruiken? Gewoon die gebruiker sudo rechten zonder restrictie geven. Nieuwe user aanmaken en de uids, gids groups en paths handmatig aanpassen: vergelijkbaar met die van root. Is wel zo dat als je dan een wachtwoord veranderd deze bij de /etc/shadow van de 2de entry niet meeveranderd.

Op donderdag 18 juli 2002 01:59 schreef deadinspace het volgende:

Apps die op username controleren om te zien of je root bent heb ik iirc nog nooit gezien.

Slechtgeschreven scriptjes is iig wel de verkeerde manier..

[Polichism]

Er is nog een manier.... je kan toch ook rechten geven in: /etc/group

code:

wheel:*:0:root,user1,user2

user1 en user2 zal je dan zelf moeten weten wat er staat.
daar moeten gewoon de users in die jij root permissions wilt geven.

[Arioch]

Op donderdag 18 juli 2002 05:32 schreef dystopia het volgende:
Ehh, blackhat.. waar wil je dat voor gebruiken?
[..]

wil je niet weten >:):p

[ACM]

Op donderdag 18 juli 2002 05:32 schreef dystopia het volgende:
Ehh, blackhat.. waar wil je dat voor gebruiken?

Zo'n slecht idee is een backup root-user sowieso niet hoor

[Verwijderd]

Op donderdag 18 juli 2002 08:17 schreef SuperKoej het volgende:

code:

wheel:*:0:root,user1,user2

Met Linux is het meestal root ipv. wheel.

Sudo heeft een aantal voordelen tov. su. Zo kun je loggen. Zo kun je makkelijker af en toe een commando als root uitvoeren (bijv. configure en make hoor je als user te draaien) terwijl je daarna heel simpel sudo make install kunt doen. Als je sudo recent al hebt uitgevoerd hoef je niet weer je wachtwoord in te typen; dat voordeel heeft su niet. Enzo zijn er nog wel meer.

Op donderdag 18 juli 2002 09:51 schreef ACM het volgende:

Zo'n slecht idee is een backup root-user sowieso niet hoor

Leg uit? Heb het zelf ooit gebruikt omdat ik een bak had genaamd hell, die ook echt een hell was om op te werken qua brakke hardware. Vond ik bofh@hell wel grappig. Maar verder..

[Arioch]

Op donderdag 18 juli 2002 09:51 schreef ACM het volgende:

[..]

Zo'n slecht idee is een backup root-user sowieso niet hoor

dan kan ik overal de root login blocken
local, ssh, ftp, ...
dat was eigelijk de bedoeling...

[Bint]

joa, je kan de root login blokken...

maar 1x su en je bent weer root... of werkt dat niet? eigenlijk nooit geprobeerd

[Arioch]

dat werkt perfect

[Bint]

maar waarom wil je dan een extra root user??

gewoon dus ssh login van root blokken, inloggen als user en dan su uitvoeren, dan ben je toch evenver?!

[im_ik]

maar waarom wil je dan een extra root user??

Kijk voor thuis gebruik is het niet heel intresant ..
Maar als jij remote beheer moeten doen x aantal klanten.
Dan wil je gewoon op alle server's met hetzelfde (root)user inloggen.
Zo hebben wij hier staandaart altijd op elke server 2 standaard login's (exa=root,in=user) waardoor je altijd kan inloggen.

[Verwijderd]

Op donderdag 18 juli 2002 10:55 schreef Bl4cKH4T het volgende:

[..]

dan kan ik overal de root login blocken
local, ssh, ftp, ...
dat was eigelijk de bedoeling...

Unencrypted remote inloggen als root is al helemaal dom. Services die dat toestaan.. .. in SSH kun je al instellen dat root niet mag inloggen. In FTPd (Pure/Pro) ook.

OpenSSH: PermitRootLogin no
PureFTPd: MinUID 1
ProFTPd: DenyUser root

etc. etc.

[Arioch]

wat is nu het veiligste? proftp of pureftp

[2P]

Op donderdag 18 juli 2002 13:55 schreef Bl4cKH4T het volgende:
wat is nu het veiligste? proftp of pureftp

sftp

[Verwijderd]

Op donderdag 18 juli 2002 13:55 schreef Bl4cKH4T het volgende:
wat is nu het veiligste? proftp of pureftp

Hangt er vanaf wat je wilt. Beide hebben MySQL en LDAP support bijv. Alledrie chroot in homedir mogelijkheden. OpenBSD-FTPd is de code van geaudit. Wanneer je geen gebruik maakt van een database zou ik voor OpenBSD-FTPd gaan. Hij heet ietsje anders btw en is ook geport naar andere Unices.

Persoonlijk ga ik voor Pure aangezien ik deze fijn te configureren vind en ik gebruik maak van LDAP.. maar die voorkeur is niet echt genuanceerd

[hbokh]

Is de FreeBSD-manier al langs gekomen?


$ cat /etc/passwd
# $FreeBSD: src/etc/master.passwd,v 1.25 1999/09/13 17:09:07 peter Exp $
#
root:*:0:0:Charlie &:/root:/bin/csh
toor:*:0:0:Bourne-again Superuser:/root:

toor krijgt als shell /bin/sh

[deadinspace]

Op donderdag 18 juli 2002 05:32 schreef dystopia het volgende:
Slechtgeschreven scriptjes is iig wel de verkeerde manier..

Veel programma's verkrijgen UID en/of username ook via getpwnam(). Dat is op zich goed, maar dit is wel een library call, en dus makkelijk te overriden via een LD_PRELOAD.
Voorbeeld:

code:

[marcelm@nothing marcelm]$ id
uid=1000(marcelm) gid=1000(marcelm) groups=1000(marcelm),4(adm),7(lp),20(dialout),24(cdrom),25(floppy),29(audio),33(www-data),102(ftp),1005(samba)
[marcelm@nothing marcelm]$ fakeroot id
uid=0(root) gid=0(root) groups=1000(marcelm),4(adm),7(lp),20(dialout),24(cdrom),25(floppy),29(audio),33(www-data),102(ftp),1005(samba)
[marcelm@nothing marcelm]$

Dat deze calls te overriden zijn is op zich prima: het levert extra flexibiliteit op, maar (vooral setuid!) programma's moeten de output van getpwnam() dus niet het al dan niet toestaan van een actie hierop baseren.
Dat een programma deze calls gebruikt om netjes een error te geven 'You are not root' in plaats van te segv-en omdat een call een EPERM krijgt is ok, maar er mag niks belangrijks vanaf hangen.

Als je wilt controleren of iemand echt root is gebruik je getuid() of geteuid(). Dit zijn kernel calls en daardoor -afaik- niet te overriden.
Maar in gewone programma's is het meestal good practice om permissie checking door de kernel te laten doen: open die file nou maar, je krijgt wel een EACCESS van de kernel als het niet mag.

Setuid (met name setuid root) files zijn een ander verhaal, maar bij die files moet je sowieso altijd goed op de veiligheid letten.

[Verwijderd]

Op donderdag 18 juli 2002 10:55 schreef Bl4cKH4T het volgende:

[..]

dan kan ik overal de root login blocken
local, ssh, ftp, ...
dat was eigelijk de bedoeling...

Moet je altijd doen

ftp ssh alles root niet accepteren alleen een user naam met een pleuris goed lang password kan je goed dicht zitten.

zowieso snap ik niet dat default ssh root binnen laat
sudo of su - als user is beter.

moeten hackers ook nog de naam uitzoeken (of bugs)

dus moelijker

[Verwijderd]

ik snap het niet helemaal, waarom zal je een tweede 'root' user aanmaken en dan de originele dichtgooien.
Dan heb je dus weer hetzelfde effect, toch ??

Of is het idee dan dat je dan een ander login hebt, die ze ook nog eens moeten zien te verkrijgen, waardoor het eventueel kraken lastiger wordt??

[Arioch]

goed geraden!

[deadinspace]

Dat is nutteloos.
Een tweede root-account aanmaken is nuttig voor als je bijvoorbeeld als root een shell als zsh hebt ingesteld, die in /usr/bin staat. Als /usr/bin dan onbereikbaar is (/usr op ander filesystem of zelfs network mounted), dan kun je met dat tweede account (die gewoon /bin/sh oid heeft) nog wel inloggen.
Ook is een tweede root account handig als je met meerdere mensen op één bak root bent en het echt niet eens kunt worden over een shell configuratie (al zijn daar ook andere methoden voor).

Maar root 'renamen' om veiliger te proberen te zijn is nutteloos. Het gaat namelijk niet om de naam, maar het UID, en het UID van root is 0, hoevaak je de naam ook veranderd. Een service die als root draait wordt dus niet minder vulnerable als root anders heet.

Verder kan iemand die een user op je systeem heeft heel eenvoudig achterhalen waar je root naar hebt gerenamed, want dat staat gewoon in /etc/passwd.