root su starten vanuit script

[Yarisken]

Mijn vraag
Ik krijg het niet voor elkaar om automatisch het wachtwoord voor de su user mee te geven in een script. Het operating system is busybox dus geen sudo bv is mogelijk. Aanmelden met root is niet mogelijk.
Ik zou automagish via ssh bv willen aanmelden met een gewone gebruiker en dan via een script su user aanmelden en een ander script starten.


Relevante software en hardware die ik gebruik
Busybox

Wat ik al gevonden of geprobeerd heb
Voorbeelden die werken gebruiken expect of sudo. Beide zijn niet mogelijk. Misschien is su gewoon te beveiligd. Stdin werkt ook niet op busybox.

Iets in de aard van echo password | su .

[efan]

echo pa$$w0rd | su -c whoami user_1

[ Voor 86% gewijzigd door efan op 09-06-2019 21:41 ]

[thunder7]

chmod u+s ook onmogelijk?

[Yarisken]

thunder7 schreef op zondag 9 juni 2019 @ 22:28:
chmod u+s ook onmogelijk?

Ja ik moet echt root kunnen worden. Dus su en dan het wachtwoord plakken erachter ....

[d1ng]

Bij bash kan je het wachtwoord gewoon pipen naar je su commando. Of dat ook werkt onder busybox kan ik niet testen.

[RobIII]

Ik zou toch nog eens héél goed overdenken of het niet anders kan wat je probeert te doen. Je wil toch niet het root wachtwoord in cleartext ergens hebben staan?

[BCC]

Heeft busybox geen /etc/crontab? Met een “@reboot”.. en anders een nette service schrijven

[ Voor 49% gewijzigd door BCC op 11-06-2019 19:40 ]

[DataGhost]

Wat probeer je eigenlijk te bereiken? Er is 99,99% zeker een betere oplossing voor te verzinnen. Zoiets kan ook zijn het installeren van een sudo-binary of simpelweg je programma als setuid root zetten, maar daarmee introduceer je waarschijnlijk behoorlijke beveiligingsgaten als je niet goed weet waar je mee bezig bent.

Edit: als het iets te maken heeft met je gedoe met ansible en je probeert een machine te provisionen, is het waarschijnlijk handiger/makkelijker als je het installatiemedium aanpast zodat je benodigde dingen er on-install al zijn, of in ieder geval een key in /root/.ssh/authorized_keys zet en sshd_config (of equivalent) zo dichtzet dat je dat alleen vanaf een lokaal ip/netwerk mag gebruiken.

[ Voor 38% gewijzigd door DataGhost op 11-06-2019 20:02 ]

[Yarisken]

DataGhost schreef op dinsdag 11 juni 2019 @ 19:52:
Wat probeer je eigenlijk te bereiken? Er is 99,99% zeker een betere oplossing voor te verzinnen. Zoiets kan ook zijn het installeren van een sudo-binary of simpelweg je programma als setuid root zetten, maar daarmee introduceer je waarschijnlijk behoorlijke beveiligingsgaten als je niet goed weet waar je mee bezig bent.

We moeten een config pushen , ander user en root wachtwoord, enable ssl etc... naar +1k access points. Na ons totale project komt het beheer terug in handen van de fabrikant. We willen dus niet klooien met installaties van softwares of andere zaken. Gewoon script uitvoeren, reboot en klaar.
Omdat het er zoveel zijn willen we vermijden om manueel aan te melden.
Setuid heb ik ook al bekeken maar dan moet je ook root zijn om dit in te stellen. Dus manueel inloggen.

Als wij op die access points "klooien" dan vergroten we idd het risico op problemen in de toekomst.

[Yarisken]

RobIII schreef op dinsdag 11 juni 2019 @ 19:22:
Ik zou toch nog eens héél goed overdenken of het niet anders kan wat je probeert te doen. Je wil toch niet het root wachtwoord in cleartext ergens hebben staan?

Script gaat worden verwijderd na het uitvoeren.

[Yarisken]

d1ng schreef op dinsdag 11 juni 2019 @ 19:19:
Bij bash kan je het wachtwoord gewoon pipen naar je su commando. Of dat ook werkt onder busybox kan ik niet testen.

Sudo kan je makkelijk pipen, Su niet helaas.
Op het werk heb ik een paar linux specialisten maar voorlopig is het nog niet gelukt.
Manieren om het te realiseren zijn expect of sudo installeren maar dat is geen optie.

[Will_M]

Yarisken schreef op dinsdag 11 juni 2019 @ 20:02:
[...]


Script gaat worden verwijderd na het uitvoeren.

Security through obscurity?

Je verwijderd het script dus pas van de machines nadat ze 't uitgevoerd hebben maar ondertussen was tijdens het uitvoeren van dat script alles gewoon 'plain text' uit te lezen.

[DataGhost]

Dus je hebt alleen bash? Geen andere scripttalen? En alleen voor een eenmalige provisioning? Je kan niks pre-install doen? Ik heb hier zelf geprobeerd en "echo wachtwoord | busybox su -c whoami" laat "root" zien bij mij, dus dat zou gewoon moeten werken. Als dat niet zo is zou ik een executable (in C ofzo) maken die "su -c /pad/naar/script" uitvoert en het wachtwoord op de een of andere manier "intypt" aangezien het kennelijk niet van stdin wordt gelezen bij jou.

Je kan eens busybox su doen, geen wachtwoord in typen en in een aparte sessie (als root) met lsof kijken welke FDs open staan voor input, daar moet je waarschijnlijk het wachtwoord in zien te stoppen.

wimmel_1 schreef op dinsdag 11 juni 2019 @ 20:09:
[...]


Security through obscurity?

Je verwijderd het script dus pas van de machines nadat ze 't uitgevoerd hebben maar ondertussen was tijdens het uitvoeren van dat script alles gewoon 'plain text' uit te lezen.

Als het daadwerkelijk alleen een one-off provisioning is van een accesspoint wat op dat moment niet in gebruik is, en het rootwachtwoord daarbij veranderd wordt, lijkt het me enigszins harmless. Het is niet iets wat op een productieserver draait en te allen tijde aangeroepen moet kunnen worden.

[ Voor 48% gewijzigd door DataGhost op 11-06-2019 20:14 ]

[Yarisken]

DataGhost schreef op dinsdag 11 juni 2019 @ 20:10:
Dus je hebt alleen bash? Geen andere scripttalen? En alleen voor een eenmalige provisioning? Je kan niks pre-install doen? Ik heb hier zelf geprobeerd en "echo wachtwoord | busybox su -c whoami" laat "root" zien bij mij, dus dat zou gewoon moeten werken. Als dat niet zo is zou ik een executable (in C ofzo) maken die "su -c /pad/naar/script" uitvoert en het wachtwoord op de een of andere manier "intypt" aangezien het kennelijk niet van stdin wordt gelezen bij jou.

Je kan eens busybox su doen, geen wachtwoord in typen en in een aparte sessie (als root) met lsof kijken welke FDs open staan voor input, daar moet je waarschijnlijk het wachtwoord in zien te stoppen.


[...]

Als het daadwerkelijk alleen een one-off provisioning is van een accesspoint wat op dat moment niet in gebruik is, en het rootwachtwoord daarbij veranderd wordt, lijkt het me enigszins harmless. Het is niet iets wat op een productieserver draait en te allen tijde aangeroepen moet kunnen worden.

Bedankt voor de tip. Ik ga het morgen eens testen.

[__fred__]

DataGhost schreef op dinsdag 11 juni 2019 @ 20:10:

Als het daadwerkelijk alleen een one-off provisioning is van een accesspoint wat op dat moment niet in gebruik is, en het rootwachtwoord daarbij veranderd wordt, lijkt het me enigszins harmless. Het is niet iets wat op een productieserver draait en te allen tijde aangeroepen moet kunnen worden.

Vergeet je bash history niet.

[DataGhost]

__fred__ schreef op dinsdag 11 juni 2019 @ 20:19:
[...]


Vergeet je bash history niet.

Je typt 'm niet in de console, script1 bevat het wachtwoord en roept su -c script2 aan. Lijkt me nogal logisch. Afhankelijk van hoe je alles doet komt er helemaal geen bash (shell) bij kijken, als het geautomatiseerd is (wat TS doet, je gaat dit alsnog niet copy/pasten op 1000+ machines) doe je iets als scp files user@host; ssh user@host ./script1 en dat komt ook niet in je .bash_history (op de target) te staan omdat de shell helemaal niet gestart wordt.

Yarisken schreef op zondag 9 juni 2019 @ 21:16:
Voorbeelden die werken gebruiken expect of sudo. Beide zijn niet mogelijk.

DataGhost schreef op dinsdag 11 juni 2019 @ 20:10:
...
Als dat niet zo is zou ik een executable (in C ofzo) maken die "su -c /pad/naar/script" uitvoert en het wachtwoord op de een of andere manier "intypt" aangezien het kennelijk niet van stdin wordt gelezen bij jou.

Je kan eens busybox su doen, geen wachtwoord in typen en in een aparte sessie (als root) met lsof kijken welke FDs open staan voor input, daar moet je waarschijnlijk het wachtwoord in zien te stoppen.

Nog even reageren op mezelf, basically is dit hetzelfde als wat expect doet en het zal /dev/tty zijn waar je busybox van probeert te lezen. Volgens mij is het niet triviaal om vanuit bash op de juiste manier daarin te schrijven maar ik moet toegeven dat ik het nog nooit heb geprobeerd. Ik had er even niet bij stilgestaan, maar volgens mij is expect zelf niet setuid (ik nam aan van wel omdat je zei dat het niet mogelijk was) dus als je een (static) versie van expect met je config-scripts mee-scp't zou je die moeten kunnen gebruiken om busybox su mee aan te roepen. Ik heb het net in ieder geval gebruikt om sudo whoami uit te voeren en dat werkt prima.

Dit gaat vanzelf:

$ ls -l /usr/bin/expect; expect script.exp
-rwxr-xr-x 1 root root 10232 apr 20  2018 /usr/bin/expect
spawn sudo whoami
[sudo] password for dataghost: 
root

En hier wacht 'ie op m'n wachtwoord:

$ echo wachtwoord | sudo whoami
[sudo] password for dataghost:

[ Voor 61% gewijzigd door DataGhost op 11-06-2019 20:43 ]

[Yarisken]

Dataghost. Het werkt hier perfect nu. Busybox Su -c path . Hartelijk bedankt. Ik was hier al heel lang op aan het zoeken.

Dus concreet echo password | busybox su -c /xxx/xxx/xxx.sh gets the job done.
Ik was de moed al verloren.

[ Voor 31% gewijzigd door Yarisken op 12-06-2019 17:46 ]