---

Hej..

...jeg er temmelig newb indenfor linux verdenen, men har alligevel kastet
mig ud i et webmin modul. Modulet jeg har lavet skal køre "mount --bind
/et/eller/andet /et/eller/andet", men det virker ikke.

Jeg tror at det skyldes at man skal være root for at kunne køre "mount" og
det ved jeg ikke om man er når man kører webmin. Jeg har prøvet at chmod'e
/bin/mount, men den bliver ved med at brokke sig over at man skal køre
mount som root :( (brugte chmod 777 /bin/mount)

Er der nogle der ved hvordan man ellers kan få lov til at mounte når man
ikke er logget på som root??

På forhånd tak
mvh.
Allan

---

Allan Eriksen wrote:

> ..jeg er temmelig newb indenfor linux verdenen, men har alligevel
> kastet mig ud i et webmin modul.

Kan være lidt farligt når man ikke har tilstrækkeligt viden, men pyt.

> Modulet jeg har lavet skal køre "mount --bind /et/eller/andet
> /et/eller/andet", men det virker ikke.
>
> Jeg tror at det skyldes at man skal være root for at kunne køre
> "mount"

Det skal man.

> og det ved jeg ikke om man er når man kører webmin.

Antageligvist ikke, siden du får det problem ...

> Jeg har prøvet at chmod'e /bin/mount, men den bliver ved med at brokke
> sig over at man skal køre mount som root :( (brugte chmod 777
> /bin/mount)

Er du *helt* klar over hvad den kommando har gjort? Du har lavet
'mount' programmet skrivbart for *alle* med adgang til computeren.
Siden root normalt kører 'mount', så har du åbnet et *kæmpe*
sikkerhedshul! Kan du med det samme køre 'chmod 4711 /bin/mount'!

Du må huske at chmod kun fortæller om en bruger må køre programmet. Det
ændrer ikke umiddelbart ved hvilke tilladelser programmet har. Og så
alligevel. Hvis du sætter SUID bit, så kan du godt give tilladelse til
at alle brugere kan køre 'mount', men det er en *dårlig* idé, så lad
hellere være!

> Er der nogle der ved hvordan man ellers kan få lov til at mounte når
> man ikke er logget på som root??

Tre måder.

Med den første metode skal du lave en gruppe der indeholder de brugere
der må køre 'mount', hvorefter du kører 'chown :<gruppe der må mounte>
/bin/mount' og 'chmod 4711 /bin/mount'. Denne metode er dog ikke at
foretrække, da den ikke er specifik nok.

Den anden metode gør brug af 'sudo'. Du redigerer '/etc/sudoers' med
programmet 'visudo' (bruger EDITOR variablen). Læs 'man sudoers'
(grundigt!) for mere information om hvordan det sættes op. Det er lidt
mere besværligt, men det kan give en meget nøjagtig kontrol over hvad
der må gøres.

Til sidst kan du overveje om det er værd at skrive mount kommandoerne
ind i /etc/fstab, og bruge 'user' option. Hvis der er mange
kombinationer af biblioteker, så er det nok for besværligt ...

--
PeKaJe

Standards are crucial. And the best thing about standards is: there are
so many to choose from!

---

---

Michael Knudsen wrote:

>> Er du *helt* klar over hvad den kommando har gjort? Du har lavet
>> 'mount' programmet skrivbart for *alle* med adgang til computeren.
>> Siden root normalt kører 'mount', så har du åbnet et *kæmpe*
>> sikkerhedshul! Kan du med det samme køre 'chmod 4711 /bin/mount'!
>
> [1]
>
>> Du må huske at chmod kun fortæller om en bruger må køre programmet.
>> Det ændrer ikke umiddelbart ved hvilke tilladelser programmet har.
>> Og så alligevel. Hvis du sætter SUID bit, så kan du godt give
>> tilladelse til at alle brugere kan køre 'mount', men det er en
>> *dårlig* idé, så lad hellere være!
>
> Hvorfor siger du saa, at han skal goere det i afsnittet foer [1]?

Doh! Det er selvfølgeligt korrekt, men min fejl ligger ikke helt dér.
Den 'mount' jeg bruger (antageligvist den samme som de fleste andre)
lader sig ikke helt overbevise af SUID bit. For at 'user' og 'users'
virker i /etc/fstab, så skal selve programmet være SUID, men en
almindelig bruger kan stadig ikke køre 'mount' på noget kritisk, da
programmet selv tester for de nødvendige tilladelser. Dette betyder så
også at den metode med gruppen af 'mount' brugere ikke virker. Dér lå
min fejl.

Jeg vil vove at påstå at der ikke er noget større sikkerhedshul i SUID
på 'mount', idet 'mount' tilsyneladende selv har en test på den rigtige
UID. Det er dog ikke alle programmer der har den slags test, så vær
altid forsigtig med SUID bit!

> sudo er den korrekte loesning,

Enig.

> men jeg er meget modstander at bruge web-interfaces til
> systemadministration, hvori der indgaar root-adgang.

*Meget* enig! Der er for mange steder et password kan slippe igennem.
Brug derfor altid CLI til fjernadministration, og forbyd root at logge
direkte ind.

--
PeKaJe

If this fortune didn't exist, somebody would have invented it.

---

Peter Jensen <usenet@pekajemaps.homeip.net> writes:

>Doh! Det er selvfølgeligt korrekt, men min fejl ligger ikke helt dér.
>Den 'mount' jeg bruger (antageligvist den samme som de fleste andre)
>lader sig ikke helt overbevise af SUID bit.

Det er omvendt. SUID- og SGID-bittene gør intet som helst ved
programmet. Det kører præcis, som det ellers ville have gjort,
og kun dem, der med de normale rettigheder kan køre programmet,
kan køre det.

Hvis programmet specifikt er skrevet til det, kan det anmode
operativsystemet om at ændre sin kontekst til at være en anden
bruger. Men det kræver, at programmet er skrevet til det.

Hvis du f.eks. sætter SUID-bitten på /bin/ls, sker der intet
som helst andet, end det, der normalt vil ske. Ingen bruger får
noget ud af det - og slet ikke nogen ekstra muligheder.

Mvh.
   Klaus.

---

Klaus Ellegaard wrote:

> Hvis du f.eks. sætter SUID-bitten på /bin/ls, sker der intet
> som helst andet, end det, der normalt vil ske. Ingen bruger får
> noget ud af det - og slet ikke nogen ekstra muligheder.

Hvad mener du præcist? Hvis SUID-bitten bliver sat på /bin/ls, så kan alle
brugere se alle filer.

[chrivers@zephyr]~ #dir /root
ls: /root: Permission denied

<suid sættes på /bin/ls>

[chrivers@zephyr]~ #dir /root
total 1047
[cut]
drwx------ 2 root root 512 Nov 8 22:16 Foo
drwx------ 2 root root 48 Nov 8 20:14 Mail
[cut]

<suid fjernes på /bin/ls>

[chrivers@zephyr]~ #dir /root
ls: /root: Permission denied

--
M.V.H
Christian Iversen

---

Christian Iversen <chrivers@iversen-net.dk> writes:

>> Hvis du f.eks. sætter SUID-bitten på /bin/ls, sker der intet
>> som helst andet, end det, der normalt vil ske. Ingen bruger får
>> noget ud af det - og slet ikke nogen ekstra muligheder.

>Hvad mener du præcist? Hvis SUID-bitten bliver sat på /bin/ls, så kan alle
>brugere se alle filer.

Ja, men eksemplet gik ud på at lave en gruppe med brugere i og
sætte mode 4711 på mount. Det får de brugere ikke noget ud af i
forhold til at sætte mode 4711 på mount og IKKE lave en gruppe.

Hvis der skal ske noget specielt, er det programmet, der har
ansvaret for, at det sker.

Mvh.
   Klaus.

---

Klaus Ellegaard wrote:

> Christian Iversen <chrivers@iversen-net.dk> writes:
>
>>> Hvis du f.eks. sætter SUID-bitten på /bin/ls, sker der intet
>>> som helst andet, end det, der normalt vil ske. Ingen bruger får
>>> noget ud af det - og slet ikke nogen ekstra muligheder.
>
>>Hvad mener du præcist? Hvis SUID-bitten bliver sat på /bin/ls, så kan alle
>>brugere se alle filer.
>
> Ja, men eksemplet gik ud på at lave en gruppe med brugere i og
> sætte mode 4711 på mount. Det får de brugere ikke noget ud af i
> forhold til at sætte mode 4711 på mount og IKKE lave en gruppe.
>
> Hvis der skal ske noget specielt, er det programmet, der har
> ansvaret for, at det sker.

Ok, ja. Det var bare svært at læse ud fra det du skrev :)

--
M.V.H
Christian Iversen

---

Christian Iversen <chrivers@iversen-net.dk> writes:

>Ok, ja. Det var bare svært at læse ud fra det du skrev :)

Det må man sige.

Jeg har lige læst min artikel igen, og jeg tror, jeg tabte
tråden halvvejs igennem min argumentation. På den måde, det
står i den, er det noget sludder.

Hvis jeg skal prøve igen:

Der kommer ikke nogen ekstra funktionalitet ud af at sætte
et program SUID. Jo, folk får mulighed for at opføre sig
som en anden bruger (typisk root), men det er næppe dét,
man er interesseret i særligt ofte.

Hvis der skal ske noget snedigt, er det altså programmets
ansvar at sørge for det. Der kommer ikke nogen ekstra
features ud af, at man sætter ls mode 4711. Heller ikke at
man sætter mount til det samme.

Programmet skal selv indeholde den logik, der skal til,
for at give f.eks. nogen brugere adgang til noget og ikke
til andre.

I mount's tilfælde vil man kun opnå at give alle adgang
til at gøre alt med alle filsystemer, hvilket næppe er en
god plan. Og da mount også kan bruges af almindelige brugere
(til at se mountede filsystemer), nytter det ikke noget at
fjerne "other"s 1-tal på den. Eller jo, det kan man da godt,
men så går ens Unix-system lidt "i stykker".

Så håber jeg, jeg gav mere mening end før. Sorry.

Mvh.
   Klaus.

---

>>Ok, ja. Det var bare svært at læse ud fra det du skrev :)
>
> Det må man sige.
>
> Jeg har lige læst min artikel igen, og jeg tror, jeg tabte
> tråden halvvejs igennem min argumentation. På den måde, det
> står i den, er det noget sludder.

Bare vi er enige

> Hvis jeg skal prøve igen:

[helt enig]

> I mount's tilfælde vil man kun opnå at give alle adgang
> til at gøre alt med alle filsystemer, hvilket næppe er en
> god plan. Og da mount også kan bruges af almindelige brugere
> (til at se mountede filsystemer), nytter det ikke noget at
> fjerne "other"s 1-tal på den. Eller jo, det kan man da godt,
> men så går ens Unix-system lidt "i stykker".

Jeps. Men hvis det skulle være, kunne man lave et lille wrapper-program der
er suid-root og 4750 - så kunne det kalde mount med de rigtige parametre,
mens "mount" alene giver listen over mountede filsystemer.

> Så håber jeg, jeg gav mere mening end før. Sorry.

Kein problem :)

--
M.V.H
Christian Iversen

---

On 2003-11-15, Klaus Ellegaard <klausellegaard@msn.com> wrote:
>
> Hvis du f.eks. sætter SUID-bitten på /bin/ls, sker der intet
> som helst andet, end det, der normalt vil ske. Ingen bruger får
> noget ud af det - og slet ikke nogen ekstra muligheder.

Hvad med de directories brugeren ikke havde adgang til at liste før du
satte SUID-bitten?

--
Andreas Plesner Jacobsen | Did I SELL OUT yet??

---

---

Michael Knudsen wrote:

>> Den 'mount' jeg bruger (antageligvist den samme som de fleste andre)
>> lader sig ikke helt overbevise af SUID bit. For at 'user' og 'users'
>> virker i /etc/fstab, så skal selve programmet være SUID, men en
>> almindelig bruger kan stadig ikke køre 'mount' på noget kritisk, da
>> programmet selv tester for de nødvendige tilladelser. Dette betyder
>> så også at den metode med gruppen af 'mount' brugere ikke virker.
>> Dér lå min fejl.
>
> Det anede mig. Jeg mindes, at der var noget funktionalitet i den stil,
> dengang jeg koerte Linux.

Det er nødvendigt for at få almindeligt desktop arbejde til at flyde
nogenlunde fornuftigt. Hvis KDE kunne overtales til at kalde 'sudo' når
den mounter, så var det måske en anden sag, men den indstilling har jeg
ikke kunnet finde.

>> Jeg vil vove at påstå at der ikke er noget større sikkerhedshul i
>> SUID på 'mount', idet 'mount' tilsyneladende selv har en test på den
>> rigtige UID. Det er dog ikke alle programmer der har den slags test,
>> så vær altid forsigtig med SUID bit!
>
> Dette er _meget_ afhaengigt af din platform.

Platformen er Linux, og det var OP's også. Jeg vil selvfølgeligt ikke
anbefale at ændre noget ved default indstillingen, men det havde OP jo
allerede. Jeg havde umiddelbart kun min egen indstilling at gå ud fra,
og det kan umuligt blive *mindre* sikkert end hvad der allerede var
gjort.

> Jeg tvivler staerkt paa, at BSDerne laver disse checks,

Hvis OP ikke havde nævnt sit OS, så havde jeg nok også været mere
forsigtig med hvad jeg skrev.

> men jeg har ikke checket koden.

Det har jeg lige gjort for den kode jeg har brugt. Hvis rigtig og
effektiv UID ikke stemmer overens, så betyder det at en almindelig
bruger prøver at mounte. Dette aktiverer et ekstra check i
suid_check(), så 'user(s)' parameteren i /etc/fstab kan bruges. Hvis
ikke de er sat, så dør processen med "only root can mount...". Jeg vil
sige at det er acceptabel sikkerhed for et typisk system, så længe
/etc/fstab ikke kan redigeres af andre end root.

> Lad vaere med at stole paa saadanne hacks.

I high-security systemer skal man rigtigt nok ikke stole på den slags.
De fleste burde nok vælge at stole på deres distribution, hvis de ikke
ved hvad de foretager sig. Derfor er mit råd til OP at køre 'chmod u-s
/bin/mount', hvis han ikke er sikker på hvordan hans system oprindeligt
var sat op. 'user(s)' i /etc/fstab vil dog ikke virke derefter, hvilket
kan gøre desktop brug mere besværligt. Det burde dog ikke gøre noget
for en server.

--
PeKaJe

BOFH Excuse #122: because Bill Gates is a Jehovah's witness and so
nothing can work on St. Swithin's day.

---

---

Michael Knudsen wrote:

> On Sat, 15 Nov 2003, Christian Iversen wrote:
>> Jeps. Men hvis det skulle være, kunne man lave et lille wrapper-program
>> der er suid-root og 4750 - så kunne det kalde mount med de rigtige
>> parametre, mens "mount" alene giver listen over mountede filsystemer.
>
> Eller ogsaa bruger man bare sudo -- saa slipper du ogsaa for at lave 60
> wrappers. Man vil jo ogsaa gerne reducere antallet af programmer med SUID
> bit.

Meget gerne,ja - det var bare et eksempel på hvad man kan. Man kunne fx lave
en sudo-klon sådan :)

--
M.V.H
Christian Iversen