|
|
 | oprette bruger via web/PHP
Fra : Kim Emax |
Dato : 13-09-03 14:51 |
|
Hey
Jeg sidder med et perl script, der opretter en bruger med adduser, som jeg
gerne vil kunne fyre af fra et webinterface (sikkerheden er i top), men
render ind i problemet at apache jo ikke kører som root, hvorfor adduser
delen i scriptet ikke bliver udført. Kan jeg på nogen måde omgåes dette
problem? Andet end at hælde det brugernavn og password, der indtastes i en
fil eller DB, hente det derfra som root og derefter udføre scriptet som root
i cron.
--
Take Care
Kim Emax - master|minds: http://www.masterminds.dk
http://www.emax.dk - http://www.ayianapa.dk
Køb din vin online på http://www.gmvin.dk,
Danmarks måske mest avancerede VinWebShop
| |
 Peter Mogensen (13-09-2003)
| Kommentar
Fra : Peter Mogensen |
Dato : 13-09-03 15:02 |
|
Kim Emax wrote:
> Jeg sidder med et perl script, der opretter en bruger med adduser, som jeg
> gerne vil kunne fyre af fra et webinterface (sikkerheden er i top), men
> render ind i problemet at apache jo ikke kører som root, hvorfor adduser
> delen i scriptet ikke bliver udført. Kan jeg på nogen måde omgåes dette
> problem? Andet end at hælde det brugernavn og password, der indtastes i en
> fil eller DB, hente det derfra som root og derefter udføre scriptet som root
> i cron.
Du kan vælge at eksekvere dine scripts suid, eller sudo.
.... men uha uha uha... hvor skal du holde tungen lige i munden for ikke
at åbne en ladeport af et sikkerhedshul.
Hvem har adgang til maskinen? Sker det her over Internettet?
Hvordan er forbindelsen beskyttet?
Peter
| |
Kim Emax (13-09-2003)
| Kommentar
Fra : Kim Emax |
Dato : 13-09-03 15:14 |
|
Peter Mogensen wrote:
> Du kan vælge at eksekvere dine scripts suid, eller sudo.
> ... men uha uha uha... hvor skal du holde tungen lige i munden for
> ikke at åbne en ladeport af et sikkerhedshul.
Jeg tænkte på at gøre apache brugeren "medlem" i root gruppen, men det
bryder jeg mig sguette om...
> Hvem har adgang til maskinen?
min partner vil ha adgang til det script, ingen andre... input tjekkes i
hoved og r..
> Sker det her over Internettet?
Jeps,
> Hvordan er forbindelsen beskyttet?
planen er SSL, lige nu er det alm. webtrafik, men testes så kun lokalt, så
det aldrig kommer i til omverdenen.
--
Take Care
Kim Emax - master|minds: http://www.masterminds.dk
http://www.emax.dk - http://www.ayianapa.dk
Køb din vin online på http://www.gmvin.dk,
Danmarks måske mest avancerede VinWebShop
| |
 Peter Mogensen (13-09-2003)
| Kommentar
Fra : Peter Mogensen |
Dato : 13-09-03 15:54 |
|
Kim Emax wrote:
>>Du kan vælge at eksekvere dine scripts suid, eller sudo.
>>... men uha uha uha... hvor skal du holde tungen lige i munden for
>>ikke at åbne en ladeport af et sikkerhedshul.
>
>
> Jeg tænkte på at gøre apache brugeren "medlem" i root gruppen, men det
> bryder jeg mig sguette om...
Uha nej... det kan jeg rigtig godt forstå at du ikke bryder dig om.
Det er bedre at lave en speciel gruppe til at køre lige præcis det
scritp du snakker om. Lave scriptet ejet af root og med den gruppe. Give
gruppen x-rettigheder og lave det suid.
.... og gøre apache-brugeren medlem af den gruppe.
> min partner vil ha adgang til det script, ingen andre... input tjekkes i
> hoved og r..
>>Sker det her over Internettet?
> Jeps,
>
>>Hvordan er forbindelsen beskyttet?
>
> planen er SSL, lige nu er det alm. webtrafik, men testes så kun lokalt, så
> det aldrig kommer i til omverdenen.
Må jeg anbefale at det ikke bare er SSL, men også at verificerer
klientens certificat, så det kun er den maskine du har installeret det
på, der kan forbinde.
.... hvis hans browser kan den slags.
Peter
| |
Kim Emax (13-09-2003)
| Kommentar
Fra : Kim Emax |
Dato : 13-09-03 16:15 |
|
Peter Mogensen wrote:
> Uha nej... det kan jeg rigtig godt forstå at du ikke bryder dig om.
> Det er bedre at lave en speciel gruppe til at køre lige præcis det
> scritp du snakker om. Lave scriptet ejet af root og med den gruppe.
> Give gruppen x-rettigheder og lave det suid.
> ... og gøre apache-brugeren medlem af den gruppe.
Selve php filen, der kalder perl scriptet er ejet af root, det er bare ikke
nok lader det til. Hvor kan jeg læse om suid? man siderne har ikke noget.
> Må jeg anbefale at det ikke bare er SSL, men også at verificerer
> klientens certificat, så det kun er den maskine du har installeret det
> på, der kan forbinde.
> ... hvis hans browser kan den slags.
Der er naturligvis brugernavn/password beskyttelse på det område, hvor man
kalder perl scriptet. Jeg formoder at det du har i tankerne er at man ikke
skal kunne sniffe username og PW?
--
Take Care
Kim Emax - master|minds: http://www.masterminds.dk
http://www.emax.dk - http://www.ayianapa.dk
Køb din vin online på http://www.gmvin.dk,
Danmarks måske mest avancerede VinWebShop
| |
Peter Mogensen (13-09-2003)
| Kommentar
Fra : Peter Mogensen |
Dato : 13-09-03 16:25 |
|
Kim Emax wrote:
> Selve php filen, der kalder perl scriptet er ejet af root, det er bare ikke
> nok lader det til. Hvor kan jeg læse om suid? man siderne har ikke noget.
man siden for chmod(1) henviser til info-siden.
Infosiden har et afsnit om special-permissions.
(på nyere linux'er ihvertfald)
Ellers er linuxbog.dk din ven:
http://www.linuxbog.dk/sikkerhed/bog/suid-root.html
> Der er naturligvis brugernavn/password beskyttelse på det område, hvor man
> kalder perl scriptet. Jeg formoder at det du har i tankerne er at man ikke
> skal kunne sniffe username og PW?
Nej. Det klarer alm. SSL
Det jeg har i tankerne er at du også verificerer klienten med SSL.
SSL er kryptering af forbindelsen med mulig authentikering i begge
ender. Normalt authentikerer man kun serveren. F.eks. med Netbank. Du
skal vide at det faktisk er bankens server du snakker med.
Authentikeringen af dig foregår på et højere niveau. Det er for at du
kan tilgå netbanken fra alle mulige steder.
Men har du kun brug for at 1 maskine skulle tilgå din server, så kan du
bede serveren om at verificere den via SSL ligesom man normalt
verificerer serveren.
Peter
| |
Kim Hansen (13-09-2003)
| Kommentar
Fra : Kim Hansen |
Dato : 13-09-03 23:56 |
|
Peter Mogensen <apm-at-mutex-dot-dk@nospam.no> writes:
> Kim Emax wrote:
> > Jeg sidder med et perl script, der opretter en bruger med adduser, som jeg
> > gerne vil kunne fyre af fra et webinterface (sikkerheden er i top), men
> > render ind i problemet at apache jo ikke kører som root, hvorfor adduser
> > delen i scriptet ikke bliver udført. Kan jeg på nogen måde omgåes dette
> > problem? Andet end at hælde det brugernavn og password, der indtastes i en
> > fil eller DB, hente det derfra som root og derefter udføre scriptet som root
> > i cron.
>
> Du kan vælge at eksekvere dine scripts suid, eller sudo.
> ... men uha uha uha... hvor skal du holde tungen lige i munden for
> ikke at åbne en ladeport af et sikkerhedshul.
Jeg tror at sudo med en NOPASSWD: linje er det sikreste, især hvis du
er sikker på at man ved et hack/crack kun får åbnet op for at lave
bunker af nye brugere uden at slette nogen gamle. Evt. kan du begrænse
det totale antal brugere, så vil det ikke være det store problem hvis
noget går galt.
--
Kim Hansen | |\ _,,,---,,_ | Det er ikke
Dalslandsgade 8, A708 | /,`.-´` -. ;:-. | Jeopardy.
2300 København S | |,4- ) )-,_. ,\ ( `'-' | Svar _efter_
Tlf: 32 88 60 86 | '---''(_/--' `-'\_) | spørgsmålet.
| |
Peter Mogensen (13-09-2003)
| Kommentar
Fra : Peter Mogensen |
Dato : 13-09-03 16:05 |
|
Kim Emax wrote:
> problem? Andet end at hælde det brugernavn og password, der indtastes i en
> fil eller DB, hente det derfra som root og derefter udføre scriptet som root
> i cron.
Faktisk vil jeg anbefale dig at holde dig til den løsning. Så kører det
i det mindste ikke nogen processor som root, der kan tage input fra
anden end lige præcis den fil.
Hvis delay'et til cron starter den er et problem kan du lave et
kompromis, der kører en daemon som root, der læser fra en named pipe som
CGi-programmet skriver til.
(med passede læse-skrive-rettigheder)
Peter
| |
Kim Emax (13-09-2003)
| Kommentar
Fra : Kim Emax |
Dato : 13-09-03 16:12 |
|
Peter Mogensen wrote:
> Faktisk vil jeg anbefale dig at holde dig til den løsning. Så kører
> det i det mindste ikke nogen processor som root, der kan tage input
> fra anden end lige præcis den fil.
Ja, men grunden til at jeg ser mig om efter en anden løsning er at man gerne
skulle have en besked om at det gik godt med det samme...
> Hvis delay'et til cron starter den er et problem kan du lave et
> kompromis, der kører en daemon som root, der læser fra en named pipe
> som CGi-programmet skriver til.
> (med passede læse-skrive-rettigheder)
Der stod jeg lige af  gider du prøve en gang til?
--
Take Care
Kim Emax - master|minds: http://www.masterminds.dk
http://www.emax.dk - http://www.ayianapa.dk
Køb din vin online på http://www.gmvin.dk,
Danmarks måske mest avancerede VinWebShop
| |
Peter Mogensen (13-09-2003)
| Kommentar
Fra : Peter Mogensen |
Dato : 13-09-03 16:15 |
|
Kim Emax wrote:
> Peter Mogensen wrote:
>>Hvis delay'et til cron starter den er et problem kan du lave et
>>kompromis, der kører en daemon som root, der læser fra en named pipe
>> som CGi-programmet skriver til.
>>(med passede læse-skrive-rettigheder)
>
>
> Der stod jeg lige af gider du prøve en gang til?
Processor kan kommunikere gennem pipes (det tror jeg du ved :) )
Normalt er en pipe bare en anonym ting man skriver på kommando-linien
mellem to programmer.
Man man kan lave "named pipes", som en process kan åbne for skrivning og
en anden for læsning. Disse ligger i det normale fil-system.
De oprettes med mkfifo(1)
De kan åbnes som alm. filer.
Til to-vejs kommuniaktion skal du selvfølgelig bruge 2.
Peter
| |
Kim Emax (15-09-2003)
| Kommentar
Fra : Kim Emax |
Dato : 15-09-03 23:37 |
|
Peter Mogensen wrote:
> Processor kan kommunikere gennem pipes (det tror jeg du ved :) )
> Normalt er en pipe bare en anonym ting man skriver på kommando-linien
> mellem to programmer.
> Man man kan lave "named pipes", som en process kan åbne for skrivning
> og en anden for læsning. Disse ligger i det normale fil-system.
> De oprettes med mkfifo(1)
Takker, der er lidt læsestof, når jeg en dag har en time til overs
--
Take Care
Kim Emax - master|minds: http://www.masterminds.dk
http://www.emax.dk - http://www.ayianapa.dk
Køb din vin online på http://www.gmvin.dk,
Danmarks måske mest avancerede VinWebShop
| |
Mogens Kjaer (13-09-2003)
| Kommentar
Fra : Mogens Kjaer |
Dato : 13-09-03 16:27 |
|
Kim Emax wrote:
> Hey
>
> Jeg sidder med et perl script, der opretter en bruger med adduser, som jeg
> gerne vil kunne fyre af fra et webinterface (sikkerheden er i top), men
> render ind i problemet at apache jo ikke kører som root, hvorfor adduser
> delen i scriptet ikke bliver udført. Kan jeg på nogen måde omgåes dette
> problem?
Ja, med suidperl
Jeg har flikket et par perl cgi scripts sammen til
vores intraweb til brugeradministration (oprettelse
af brugere, samba shares, samba printere og vedlige-
holdelse af LDAP database til mozilla/outlook adresse-
bog) netop vha. suidperl.
- det er nok ikke noget, jeg ville have kørende på
en maskine, der var tilgængelig externt.
Mogens
--
Mogens Kjaer, Carlsberg A/S, Computer Department
Gamle Carlsberg Vej 10, DK-2500 Valby, Denmark
Phone: +45 33 27 53 25, Fax: +45 33 27 47 08
Email: mk@crc.dk Homepage: http://www.crc.dk
| |
Hans Joergensen (15-09-2003)
| Kommentar
Fra : Hans Joergensen |
Dato : 15-09-03 10:10 |
|
Kim Emax wrote:
> Jeg sidder med et perl script, der opretter en bruger med adduser, som jeg
> gerne vil kunne fyre af fra et webinterface (sikkerheden er i top), men
> render ind i problemet at apache jo ikke kører som root, hvorfor adduser
> delen i scriptet ikke bliver udført. Kan jeg på nogen måde omgåes dette
> problem? Andet end at hælde det brugernavn og password, der indtastes i en
> fil eller DB, hente det derfra som root og derefter udføre scriptet som root
> i cron.
Den sidste løsning med database og script der kører som root er en
meget brugt, og ret god løsning..
// Hans
--
UNIX Admin søger arbejde, http://nathue.dk/?page=cv
| |
Kim Emax (15-09-2003)
| Kommentar
Fra : Kim Emax |
Dato : 15-09-03 23:35 |
|
Hans Joergensen wrote:
> Den sidste løsning med database og script der kører som root er en
> meget brugt, og ret god løsning..
Det er også min umiddelbare tanke til løsningen, jeg har i forvejen andre
scripts kørende på denne måde. Jeg var bare interesseret i et output til min
partner, når han udførte scriptet, men efter en snak er vi blevet enige om
at det ikke er så vigtigt.
--
Take Care
Kim Emax - master|minds: http://www.masterminds.dk
http://www.emax.dk - http://www.ayianapa.dk
Køb din vin online på http://www.gmvin.dk,
Danmarks måske mest avancerede VinWebShop
| |
Morten Trab (16-09-2003)
| Kommentar
Fra : Morten Trab |
Dato : 16-09-03 14:14 |
|
"Kim Emax" <newsgroup@remove-emax.dk> skrev i en meddelelse
news:V8r9b.72189$Kb2.3405456@news010.worldonline.dk...
> Jeg var bare interesseret i et output til min
> partner, når han udførte scriptet
Hvis et output er ønsket, kunne du jo mail'e resultatet til ham, når cron
har udført sit job...
--
Mvh. Morten Trab
--
Svar venligst kun i NG, med mindre det er MEGET vigtigt.
Ved mail, slet REMOVE i min adresse.
Web: http://www.blackchart.dk
| |
Kim Emax (16-09-2003)
| Kommentar
Fra : Kim Emax |
Dato : 16-09-03 15:16 |
|
Morten Trab wrote:
> Hvis et output er ønsket, kunne du jo mail'e resultatet til ham, når
> cron har udført sit job...
Klart, det er en mulighed, jeg er bare minus vild med at sende passwords
over mail, men det er allerede tastet ind ved oprettelsen, så det går nok
--
Take Care
Kim Emax - master|minds: http://www.masterminds.dk
http://www.emax.dk - http://www.ayianapa.dk
Køb din vin online på http://www.gmvin.dk,
Danmarks måske mest avancerede VinWebShop
| |
|
|