/ Forside / Teknologi / Operativsystemer / Linux / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
Linux
#NavnPoint
o.v.n. 11177
peque 7911
dk 4814
e.c 2359
Uranus 1334
emesen 1334
stone47 1307
linuxrules 1214
Octon 1100
10  BjarneD 875
ssh sikkerhedsproblem.
Fra : Martin Jørgensen


Dato : 03-11-04 20:06

Hej NG/kloge hoveder.

En programmør vil gerne have lov at ssh´e sig ind på min mac og det har
jeg givet ham lov til. Men jeg kunne godt tænke mig at "overvåge" hvad
han laver. Det skal tilføjes at jeg kører os X, bygget på bsd unix,
SVJH. Dette indlæg blev allerede i går postet i mac-gruppen, men jeg
tror at denne gruppe er "klogere", mht. generel unix-viden

Han har ikke selv en macintosh, men er af hans firma blevet
fortalt at han skal programmere noget til macintosh og derudover
overvejer han at købe en mac. Så han vil lave noget i assemblere og
kompilere det + teste det på min computer.

Kan jeg læse i en .history fil hvad han har lavet i terminal-prompten
eller hvad? Hvor ligger denne? Kan han køre os x programmer fra ssh på
sin windows-computer?

Hvordan beskytter jeg mig i det hele taget bedst?

Jeg har kørt en repair disc permissions fordi jeg håber at den gør at
han ikke kan ændre noget i systemet. Jeg syntes det er svært at danne
sig et overblik over hvad han kan se/læse og helst ville jeg have det
sådan at han ikke kan bevæge sig længere ned (eller op) i systemet end
hans egen hjemmemappe. Hvordan gøres dette? (Sådan at han ikke engang
kan komme ind i /Users og se mine logins)... Dvs: Han skal *kun* kunne
bevæge sig inde i sit eget "home-directory"...

Med venlig hilsen / Best regards
Martin Jørgensen

--
---------------------------------------------------------------------------
Home of Martin Jørgensen - http://www.martinjoergensen.dk

 
 
Michael Knudsen (03-11-2004)
Kommentar
Fra : Michael Knudsen


Dato : 03-11-04 20:32



Martin Jørgensen (03-11-2004)
Kommentar
Fra : Martin Jørgensen


Dato : 03-11-04 22:13

Michael Knudsen wrote:

> On Wed, 3 Nov 2004, Martin Jørgensen wrote:
>
>> Kan jeg læse i en .history fil hvad han har lavet i terminal-prompten
>> eller hvad? Hvor ligger denne? Kan han køre os x programmer fra ssh på
>> sin windows-computer?
>
>
> Ja, men han kan blot slette den, inden han logger ud, eller han kan bede
> sin shell undlade at logge kommandoer.

Hvordan gør man egentligt det?

>> Hvordan beskytter jeg mig i det hele taget bedst?
>
>
> Hold dit system patchet og giv ham minimale privilegier. Gaa gerne dit

Hvordan giver jeg ham minimale privilegier? Jeg har gjort det i
opsætningen under "System Preferences" hvor jeg tilføjede ham som bruger
på pc´en (i den grafiske skal), men jeg tror kun det virker når han
logger ind grafisk på min computer... Hvilket jeg ikke engang ved
om/hvordan han kan med ssh... Jeg gætter på at han nu alligevel ikke kan.

> system igennem og fjern suid-bitten fra ting, du er sikker paa, du ikke
> bruger. Check permissions -- hold oeje med ting, hvor `other' kan skrive
> til (find / -perm -0002) etc. Standard hardening. Naar han skal have
> shelladgang, er der ikke meget mere at goere.

Shit... Den liste er ufatteligt lang... Mange ting under /Applications
ser vist ud på flg. måde:

drwxrwxrwx 3 standard admin 102 29 Jun 01:34 Firefox.app

Til dem som ikke kender mac os X-unix: Selvom "Firefox.app" ligner et
bibliotek er det egentligt et program, når man kører grafisk (det *er*
Firefox-browseren). Det er en "package" som man kan højreklikke på og
vælge "Show package contents" hvis man vil se underbibliotekerne, som
programmet indeholder...

-snip-

> Det bliver ret svaert at holde ham fanget i sit eget homedir; saerligt
> fordi han skal udfoere tonsvis af programmer, der ligger under /usr etc.
> Maaske findes der noget restricted shell-lignende, der kan opfylde
> dette, men jeg ville have meget fidus til det.

Øv...

> Hvis han ikke skal have adgang til /Users, kan du fjerne -r og -x paa
> dette for ham og hans gruppe, med mindre hans homedir ligger herunder.

Det gør det nemligt.

> Goer det dette, kan du _ikke_ fjerne -x, da han i saa fald ikke kan
> komme ind i sit homedir. Hvis det er nok, at han ikke kan se indholdet
> af /Users, kan du noejes med at fjerne -r for ham og hans gruppe.

Sådan ser det ud når man står i roden:

drwxrwxr-t 10 root admin 340 2 Nov 23:08 Users

Jeg er ikke helt med på hvordan jeg kan fjerne -r for ham og hans
gruppe. /Users er ejet af root som er i admin-gruppen, såvidt jeg
forstår. Ergo, har han r-t tilladelser. Hvis jeg fjerner read, så gælder
det for alle andre der ikke er i admin-gruppen, så det tror jeg jeg
lader være at pille med medmindre nogen har nogen gode ideer.

> Een ting undrer mig meget. Virkelig meget:
>
> Hvorfor giver du adgang til folk, du ikke stoler paa?

Jeg stoler da også på ham, men vil gerne være 110% sikker og gøre ham en
tjeneste samtidigt.

Det ene udelukker ikke at man tænker sig om ved at gøre sig de
fornuftige foranstaltninger der er nødvendige og sålænge systemet er
ordentligt sat op (tror jeg ikke det er nu), har jeg tiltro til at
systemet virker perfekt. Det er trods alt en Unix, ikke sandt? Jeg har
ikke før erfaringer med andre end mig selv på en unix/linux-maskine så
derfor spørger jeg. Systemet er jo beregnet til den slags, såvidt jeg ved.

Så enkelt er det. Det er der vel ikke spor underligt i?


Med venlig hilsen / Best regards
Martin Jørgensen

--
---------------------------------------------------------------------------
Home of Martin Jørgensen - http://www.martinjoergensen.dk

Christoffer Olsen (04-11-2004)
Kommentar
Fra : Christoffer Olsen


Dato : 04-11-04 09:34

Martin Jørgensen <unoder.spam@spam.jay.net> writes:

> > system igennem og fjern suid-bitten fra ting, du er sikker paa, du ikke
> > bruger. Check permissions -- hold oeje med ting, hvor `other' kan skrive
> > til (find / -perm -0002) etc. Standard hardening. Naar han skal have
> > shelladgang, er der ikke meget mere at goere.
>
> Shit... Den liste er ufatteligt lang... Mange ting under /Applications
> ser vist ud på flg. måde:

find / -perm -0002 -type f

Viser kun almindelige filer og -type d for biblioteker.

Hvis du ikke angiver nogen type så kommer symlinks f.eks. også med.

--
Mvh
Christoffer Olsen

Alex Holst (03-11-2004)
Kommentar
Fra : Alex Holst


Dato : 03-11-04 20:59

Martin Jørgensen wrote:
> Hej NG/kloge hoveder.

Du har ikke et ssh sikkerhedsproblem, men et unix administrationsproblem.

> En programmør vil gerne have lov at ssh´e sig ind på min mac og det har
> jeg givet ham lov til. Men jeg kunne godt tænke mig at "overvåge" hvad
> han laver.

Hvis han gaar med til det, kan du benytte programmet 'screen' til at
dele en session mellem flere brugere (det kan benyttes til meget andet
ogsaa). Han starter altsaa screen naar han er logget ind (eller du kan
tvinge hans userid til at starte screen) og du kan saa foelge med i
hvilke kommandoer han taster, etc.

> Jeg har kørt en repair disc permissions fordi jeg håber at den gør at
> han ikke kan ændre noget i systemet. Jeg syntes det er svært at danne
> sig et overblik over hvad han kan se/læse og helst ville jeg have det
> sådan at han ikke kan bevæge sig længere ned (eller op) i systemet end
> hans egen hjemmemappe. Hvordan gøres dette? (Sådan at han ikke engang
> kan komme ind i /Users og se mine logins)... Dvs: Han skal *kun* kunne
> bevæge sig inde i sit eget "home-directory"...

Du kan ikke laase ham inde i et chroot hvis han skal kunne arbejde med
vaerktoejer installeret paa maskinen - i hvert fald ikke uden at du kan
duplikere hele udviklingsmiljoe inde i brugerens chroot.

Han kan laese alle filer, med undtagelse af visse systemfiler med
foelsomme oplysninger i (f.eks. password filen). Hvis der er filer du
ikke oensker han skal tilgaa, skal du blot fjerne r bitten, og paa
directories fjerne xr bittene.

Du kan benytte shellens 'restricted' mode til noget af det du oensker,
men det er ikke en perfekt beskyttelse og det kraever en god forstaaelse
at saette forsvarligt op.

Jeg vil anbefale at du laeser mere om UNIX hvis du vil opnaa det du
beskriver - eller lade vaere med at give ham adgang.

--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.mongers.org

OSS/FAQ for dk.edb.sikkerhed: http://sikkerhed-faq.dk

Sune Vuorela (03-11-2004)
Kommentar
Fra : Sune Vuorela


Dato : 03-11-04 21:03

On 2004-11-03, Alex Holst <a@mongers.org> wrote:
> Du kan ikke laase ham inde i et chroot hvis han skal kunne arbejde med
> vaerktoejer installeret paa maskinen - i hvert fald ikke uden at du kan
> duplikere hele udviklingsmiljoe inde i brugerens chroot.

Er det ikke det man kan gøre på en sikker måde med vserver?
Det er der i hvert fald nogle kloge hoveder der har forsøgt at bilde mig
ind.

http://www.linux-verver.org

--
Sune

Sune Vuorela (03-11-2004)
Kommentar
Fra : Sune Vuorela


Dato : 03-11-04 21:07

On 2004-11-03, Sune Vuorela <nospam@vuorela.dk> wrote:
> Er det ikke det man kan gøre på en sikker måde med vserver?
> Det er der i hvert fald nogle kloge hoveder der har forsøgt at bilde mig
> ind.
>
> http://www.linux-verver.org

.... og så kom han til at tænke på at det var ævlepcer vi snakkede om -
de kører jo ævleos.

--
Sune

Martin Jørgensen (03-11-2004)
Kommentar
Fra : Martin Jørgensen


Dato : 03-11-04 22:24

Alex Holst wrote:

> Martin Jørgensen wrote:
>
>> Hej NG/kloge hoveder.
>
>
> Du har ikke et ssh sikkerhedsproblem, men et unix administrationsproblem.

Ja, ok. Så siger vi det

>> En programmør vil gerne have lov at ssh´e sig ind på min mac og det har
>> jeg givet ham lov til. Men jeg kunne godt tænke mig at "overvåge" hvad
>> han laver.
>
>
> Hvis han gaar med til det, kan du benytte programmet 'screen' til at
> dele en session mellem flere brugere (det kan benyttes til meget andet
> ogsaa). Han starter altsaa screen naar han er logget ind (eller du kan
> tvinge hans userid til at starte screen) og du kan saa foelge med i
> hvilke kommandoer han taster, etc.

Så får vi måske det samme skærmbillede/terminalvindue op? Jeg ville
helst have noget der kører helt usynligt for ham.

>> Jeg har kørt en repair disc permissions fordi jeg håber at den gør at
>> han ikke kan ændre noget i systemet. Jeg syntes det er svært at danne
>> sig et overblik over hvad han kan se/læse og helst ville jeg have det
>> sådan at han ikke kan bevæge sig længere ned (eller op) i systemet end
>> hans egen hjemmemappe. Hvordan gøres dette? (Sådan at han ikke engang
>> kan komme ind i /Users og se mine logins)... Dvs: Han skal *kun* kunne
>> bevæge sig inde i sit eget "home-directory"...
>
>
> Du kan ikke laase ham inde i et chroot hvis han skal kunne arbejde med
> vaerktoejer installeret paa maskinen - i hvert fald ikke uden at du kan
> duplikere hele udviklingsmiljoe inde i brugerens chroot.

Ok. Det indser jeg nu. Men kan man så afskære ham fra mange biblioteker,
uden at ændre permissions (så jeg ikke glemmer at sætte dem tilbage)?

> Han kan laese alle filer, med undtagelse af visse systemfiler med
> foelsomme oplysninger i (f.eks. password filen). Hvis der er filer du
> ikke oensker han skal tilgaa, skal du blot fjerne r bitten, og paa
> directories fjerne xr bittene.

Jeg har det problem, at min harddisk er fyldt op med alt muligt skrammel
så jeg mener at det er en uoverkommelig opgave at kigge det hele
igennem. Og hvis jeg fjerner/ændrer nogen permissions er jeg bange for
at glemme hvad jeg har lavet så systemet måske ikke længere fungerer
korrekt... Det skal jeg måske ikke være så bange for eller hvordan? Jeg
har selvfølgelig et (indbygget i os x) "repair permissions"-værktøj, men
jeg er ikke engang klar over hvordan det ved hvilke permissions filerne
skal have og hvor godt det er.

> Du kan benytte shellens 'restricted' mode til noget af det du oensker,
> men det er ikke en perfekt beskyttelse og det kraever en god forstaaelse
> at saette forsvarligt op.

Hvor kan jeg læse mere om det?

> Jeg vil anbefale at du laeser mere om UNIX hvis du vil opnaa det du
> beskriver - eller lade vaere med at give ham adgang.

Har du nogen kildehenvisninger? Alle unix er forskellige og ligeså er
det med os x, så det er vel forståeligt for dig, at jeg spørger. På min
Mandrake 9 som jeg tidligere har kørt (og som var ustabilt pga.
driver-problemer), var jeg ikke så bange for at ændre permissions. Det
virkede alligevel ikke ordentligt, så derfor kunne jeg ændre alt det jeg
gad. På min mac os x kører alting nu tip-top og der ligger så ufatteligt
mange timers installering på HD´en, at jeg ikke orker at begå en fejl
som kræver geninstallering fordi jeg ikke kan udrede fejlen (lettere på
Mandrake og pc-linux, IMO).


Med venlig hilsen / Best regards
Martin Jørgensen

--
---------------------------------------------------------------------------
Home of Martin Jørgensen - http://www.martinjoergensen.dk

Alex Holst (04-11-2004)
Kommentar
Fra : Alex Holst


Dato : 04-11-04 12:17

Martin Jørgensen wrote:
> Alex Holst wrote:
[..]

Du er heldig. NSA har netop offenliggjort deres MacOS X Security Guide:

http://www.nsa.gov/snac/os/applemac/osx_client_final_v.1.pdf


--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.mongers.org

OSS/FAQ for dk.edb.sikkerhed: http://sikkerhed-faq.dk

Martin Jørgensen (04-11-2004)
Kommentar
Fra : Martin Jørgensen


Dato : 04-11-04 23:07

Alex Holst wrote:

> Martin Jørgensen wrote:
>
>> Alex Holst wrote:
>
> [..]
>
> Du er heldig. NSA har netop offenliggjort deres MacOS X Security Guide:
>
> http://www.nsa.gov/snac/os/applemac/osx_client_final_v.1.pdf

Takker. Det kigger jeg lidt på.


Med venlig hilsen / Best regards
Martin Jørgensen

--
---------------------------------------------------------------------------
Home of Martin Jørgensen - http://www.martinjoergensen.dk

Michael Knudsen (03-11-2004)
Kommentar
Fra : Michael Knudsen


Dato : 03-11-04 22:25



Martin Jørgensen (04-11-2004)
Kommentar
Fra : Martin Jørgensen


Dato : 04-11-04 23:05

Michael Knudsen wrote:

> On Wed, 3 Nov 2004, Martin Jørgensen wrote:
-snip-

>> Hvordan giver jeg ham minimale privilegier? Jeg har gjort det i
>> opsætningen under "System Preferences" hvor jeg tilføjede ham som
>> bruger på pc´en (i den grafiske skal), men jeg tror kun det virker når
>> han logger ind grafisk på min computer... Hvilket jeg ikke engang ved
>> om/hvordan han kan med ssh... Jeg gætter på at han nu alligevel ikke kan.
>
>
> Lad vaere med at give ham e.g. sudo-adgang, og soerg for, at han kun er
> i gruppe med sig selv. Jeg ved ikke, om der er nogle fancy ting i OSX,
> der giver mulighed for mere finkornede privilegier end traditionel unix
> goer, saa det maa du selv finde ud af og naegte ham.

Jep, takker mange gange... Jeg sørger for at han er i gruppe med sig
selv. Jeg tror ikke der er nogen fancy ting i os x. Som standard har han
vist heller ikke sudo adgang, så det giver ingen problemer.

> Han kan godt koere X-programmer, med mindre du slaar X11-forwarding fra
> og blokerer for alt andet trafik end ssh:
>
> http://mongers.org/ssh

Tusind tak for linket Interessant læsning, selvom jeg har set en del
af det før.
-snip-

> Det forhindrer godt nok alle brugere i at vise indholdet af /Users, men
> det maa du goere op med dig selv:
>
> # chmod o-r /Users

Ok, det vil jeg overveje at gøre... Havde det også selv i tankerne og
jeg tror egentligt ikke det ændrer noget for systemets drift.

-snip-

>> Så enkelt er det. Det er der vel ikke spor underligt i?
>
>
> Du skal overveje, om du skal laegge mere arbejde i at forbedre tingene,
> end du skal i at restaurere dit system fra en backup, hvis han
> oedelaegger noget.

Derfor kunne jeg f.eks. godt tænke mig at at han ikke kunne pille ved
sin $HISTFILE, så jeg kan kigge lidt på hvad han laver... *Det* må da
kunne lade sig gøre? Evt. med et script så jeg får en kopi af filen, der
lægges et andet sted uden at han kan se det?


Med venlig hilsen / Best regards
Martin Jørgensen

--
---------------------------------------------------------------------------
Home of Martin Jørgensen - http://www.martinjoergensen.dk

Kasper Dupont (06-11-2004)
Kommentar
Fra : Kasper Dupont


Dato : 06-11-04 23:14

Michael Knudsen wrote:
>
> On Wed, 3 Nov 2004, Martin Jørgensen wrote:
> >> Ja, men han kan blot slette den, inden han logger ud, eller han kan bede
> >> sin shell undlade at logge kommandoer.
> >
> > Hvordan gør man egentligt det?
>
> Det afhaenger af din shell. I pdksh:
>
> $ rm -f $HISTFILE
> $ unset HISTFILE
> $ echo 'unset HISTFILE' >> .profile

Eller man nøjes bare med at skrive "unset HISTFILE"
i de sessioner hvor man gør ting, man ikke vil have
logget. Så bliver det meget sværere at opdage, at
der er kommandoer, som ikke er blevet skrevet i
history filen.

--
Kasper Dupont

Martin Jørgensen (07-11-2004)
Kommentar
Fra : Martin Jørgensen


Dato : 07-11-04 11:43

Kasper Dupont wrote:
> Michael Knudsen wrote:
>
>>On Wed, 3 Nov 2004, Martin Jørgensen wrote:
>>
>>>>Ja, men han kan blot slette den, inden han logger ud, eller han kan bede
>>>>sin shell undlade at logge kommandoer.
>>>
>>>Hvordan gør man egentligt det?
>>
>>Det afhaenger af din shell. I pdksh:
>>
>> $ rm -f $HISTFILE
>> $ unset HISTFILE
>> $ echo 'unset HISTFILE' >> .profile
>
>
> Eller man nøjes bare med at skrive "unset HISTFILE"
> i de sessioner hvor man gør ting, man ikke vil have
> logget. Så bliver det meget sværere at opdage, at
> der er kommandoer, som ikke er blevet skrevet i
> history filen.

Ok, men hvordan "modvirker" man dette? Jeg kunne f.eks. godt tænke mig
at "remote"-useren´s $HISTFILE blev gemt i en anden brugers (min egen)
hjemmemappe... Dette kan sikkert ikke lade sig gøre, idet remote-useren
ikke har adgang til min mappe... Medmindre man kan lave et script med
noget sudo, måske???

Det må sku´ da kunne lade sig gøre på en eller anden måde, sådan at man
ikke bare kan skrive "unset HISTFILE" og så kan jeg ikke se hvad der sker?


Med venlig hilsen / Best regards
Martin Jørgensen

--
---------------------------------------------------------------------------
Home of Martin Jørgensen - http://www.martinjoergensen.dk

Kasper Dupont (07-11-2004)
Kommentar
Fra : Kasper Dupont


Dato : 07-11-04 20:27

Martin Jørgensen wrote:
>
> Kasper Dupont wrote:
> >
> > Eller man nøjes bare med at skrive "unset HISTFILE"
> > i de sessioner hvor man gør ting, man ikke vil have
> > logget. Så bliver det meget sværere at opdage, at
> > der er kommandoer, som ikke er blevet skrevet i
> > history filen.
>
> Ok, men hvordan "modvirker" man dette?

Lad være med at stole på brugerens shell og i det hele
taget noget som helst, der kører som den pågældende
bruger.

Måske kunne en modificeret udgave af script kommandoen
bruges, men hvis den kører som den pågældende bruger
kan du heller ikke stole på den.

Så egentlig ville den bedste løsning være at indbygge
noget af script funktionaliteten i sshd. Det skal man
selvfølgelig ikke prøve på, med mindre man ved, hvad
man gør. Ændrer man i sshd kunne man nemt introducere
langt større sikkerhedshuller.

Man kunne overveje at lade brugeren først logge ind
under et uid som har en shell, der foretager logning
og derefter kalder et suid program for at skifte til
den endelige bruger. Men så vidt jeg kan gennemskue
skal man enten lægge dette suid program på et readonly
filsystem for at brugeren ikke kan ændre det, eller
involvere root permissions et sted i systemet.

Under alle omstændigheder bør man passe på med at
involvere root permissions, for det vil gøre
konsekvenserne af en fejl langt større.

--
Kasper Dupont

Jesper Louis Anderse~ (07-11-2004)
Kommentar
Fra : Jesper Louis Anderse~


Dato : 07-11-04 21:51

Kasper Dupont <kasperd@daimi.au.dk> wrote:

> M?ske kunne en modificeret udgave af script kommandoen
> bruges, men hvis den k?rer som den p?g?ldende bruger
> kan du heller ikke stole p? den.

eller satse paa at OSX har en kommando svarende til
FreeBSDs watch(8).

> S? egentlig ville den bedste l?sning v?re at indbygge
> noget af script funktionaliteten i sshd. Det skal man
> selvf?lgelig ikke pr?ve p?, med mindre man ved, hvad
> man g?r. ?ndrer man i sshd kunne man nemt introducere
> langt st?rre sikkerhedshuller.

Nej.

--
< Keltus> .. now back to reading my /. and compiling my \
l33t gentoo linux which makes it 5000% faster than \
your lame not-even-a-real-OS computer. Uptime: 20000 days, 4 hours


Søg
Reklame
Statistik
Spørgsmål : 177551
Tips : 31968
Nyheder : 719565
Indlæg : 6408825
Brugere : 218887

Månedens bedste
Årets bedste
Sidste års bedste