---

Hej

Jeg har lavet et klient-program, "krypto", som kan kryptere/dekryptere noget
tekst. Til krypteringen bruges en nøgle, som hentes fra en central server en
gang i døgnet i forbindelse med en kryptering, og gemmes lokalt på
computeren.

Programmet kan køres direkte fra kommandoprompten, men vil som regel blive
brugt fra f.eks. en PHP webside med popen()-kommandoen.


Mit spørgsmål er, hvor diverse filer skal placeres i filsystemet, og hvilke
rettigheder de skal tildeles for at sikre det bedst muligt.
I øjeblikket er filerne placeret således:
/etc/krypto/krypto.conf (skal kunne læses fra og skrives til af
programmet - konfiguration og nøgle der udskiftes hver dag)
/var/www/cgi-bin/kryptoprogram (kan eksekveres af apache/PHP)
/var/log/krypto/kryptolog (skal kunne skrives til af programmet ved
fejl)

Konfigurationsfilen skal helst ikke kunne læses af alle der har adgang til
serveren, men kun af programmet.


Hvor plejer man at placere sådan et program og hvad bør man tænke på ifm.
sikkerhed?

/Carsten

---

Carsten <carstensm@hotmail.com> wrote:
> Jeg har lavet et klient-program, "krypto", som kan kryptere/dekryptere
> noget tekst.

Jeg er villig til at vaedde store maengder penge paa, at du har begaaet
adskellige fjollede fejl (du har allerede beskrevet et par af dem i dit
indlaeg) i dit kryptoprogram, som goer at din kryptering er let at
bryde.

Jeg anbefaler, at du i stedet bruger et vaerktoej udviklet med
korrekthed og sikkerhed for oeje.

Derefter boer du maaske tage hele designet af loesningen op til
genovervejelse. Hvis du fortaeller os hvad du vil opnaa, kan det vaere
vi kan pege dig i en bedre retning end den du er paa vej ad nu.

--
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

---

Hej Alex

Tak for dit hurtige svar, som jeg dog ikke fik så meget ud af. Men det er
nok min egen skyld fordi jeg ikke har forklaret nok om programmet.

> Jeg er villig til at vaedde store maengder penge paa, at du har begaaet
> adskellige fjollede fejl (du har allerede beskrevet et par af dem i dit
> indlaeg) i dit kryptoprogram, som goer at din kryptering er let at
> bryde.

Kan du nævne et par af mine fejl - bare til at starte med.

> Jeg anbefaler, at du i stedet bruger et vaerktoej udviklet med
> korrekthed og sikkerhed for oeje.

Programmet gør mere end at kryptere/dekryptere. Desuden skal det kunne
installeres på alle mulige Linux-maskiner - og gerne uden at bruge 3. parts
værktøjer. Programmet henter krypteringsnøglen fra en central server via
https en gang i døgnet.

> Derefter boer du maaske tage hele designet af loesningen op til
> genovervejelse. Hvis du fortaeller os hvad du vil opnaa, kan det vaere
> vi kan pege dig i en bedre retning end den du er paa vej ad nu.

Jeg tager gerne det hele op til genovervejelse.
Jeg vil opnå at sende krypteret data over http i en form/query. Modtageren
af dataene har samme krypteringsnøgle, og kan således dekryptere data.

Men uanset hvordan (eller hvor godt) programmet fungerer, så er spørgsmålet
stadig:
1. Hvor bør jeg placere den faste konfigurationsfil?
2. Hvor bør jeg placere krypteringsnøglen?
3. Hvilke tilladelser skal filerne/folderne have for at programmet kan
bruges f.eks. via PHP/Apache?

Ellers må du/I gerne forklare hvorfor spørgsmålene ikke er relevante...

/Carsten

---

Carsten <carstensm@hotmail.com> wrote:
> Jeg tager gerne det hele op til genovervejelse.
> Jeg vil opn? at sende krypteret data over http i en form/query.

Hvorfor kan du ikke bruge https til at aflevere dataene naar du kan
hente din krypteringsnoegle via https? Brug baade server og klient
certifikater.

--
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

---

> > Jeg tager gerne det hele op til genovervejelse.
> > Jeg vil opn? at sende krypteret data over http i en form/query.
>
> Hvorfor kan du ikke bruge https til at aflevere dataene naar du kan
> hente din krypteringsnoegle via https? Brug baade server og klient
> certifikater.

Har ikke megen forstand på klient certifikater - er de gratis og nemme at
håndtere for almindelige brugere?

Et problem kan evt. være at kun nøgle-serveren har ssl certifikat. Hvis
serveren derfor vil sende data til klienten i en query, så kan det ikke være
ssl-krypteret. Det er altså kun når klienten opretter forbindelsen, at der
kan bruges https.

Desuden kan der være flere klienter(=websites) på den samme maskine, som
alle skal have forskellige krypteringsnøgler (eller klient-certifikater,
hvis det er aktuelt i dette scenarie)


/Carsten

---

Carsten wrote:
>
> Men uanset hvordan (eller hvor godt) programmet fungerer, så er spørgsmålet
> stadig:
> 1. Hvor bør jeg placere den faste konfigurationsfil?

/etc

> 2. Hvor bør jeg placere krypteringsnøglen?

Nok /var/cache eller /var/lib

> 3. Hvilke tilladelser skal filerne/folderne have for at programmet kan
> bruges f.eks. via PHP/Apache?

Apache kører typisk med et seperat brugerid der f.eks.
kunne være navngivet apache. Men bemærk, at alle filer,
der kan læses af denne bruger kan læses af flere end
man umiddelbart ville tro. Selv hvis de ligger udenfor
webroden, har et specielt efternavn eller er beskyttet
med en .htaccess fil, kan det læses af andre brugere
på systemet ved blot at oprette et symlink i deres
eget public_html directory.

Og kan et program kaldes fra php, så kan det muligvis
også kaldes på andre måder, eller fra andre php scripts
end man havde forestillet sig.

Hvis du finder brug for setuid eller setgid executables,
så skal du være ekstremt omhyggelig. At lade webserveren
køre som en bruger og lade en executable være setuid til
en anden bruger, som kun anvendes til det ene formål,
burde være mere sikkert end at lade apache brugeren have
direkte læseadgang til relevante filer.

Der er et par detaljer man bør være opmærksom på. Kan
programmet kaldes af andre end apache brugeren vil fejl
i setuid programmet være alvorligere. Man kan evt. lade
programmet kun være executable for en gruppe som apache
brugeren har rettigheder som.

Bemærk at hvis der er alvorlige fejl i setuid programmet
kan man måske opnå denne brugers rettigheder og derved
få mulighed for at overskrive programfilen. Man kan evt.
nøjes med setgid.

Desværre kan man ikke anvende gruppe ID til begge
formål. Jeg kender ikke nogen genial løsning, som
opfylder begge kriterier. Det bedste jeg kan foreslå er,
at køre setgid og lade programmet selv checke om det
køres af en bruger med passende rettigheder. Dette
check skal udføres som det allerførste inden programmet
kigger på nogen form for input (stdin/parametre/environment).

>
> Ellers må du/I gerne forklare hvorfor spørgsmålene ikke er relevante...

Jeg synes ikke du har uddybet dine krav godt nok til at
jeg kan gennemskue, om der er nogle problemer med dit
design. Jeg kan heller ikke gennemskue om setuid/setgid
overhovedet ville være en del af løsningen.

--
Kasper Dupont -- der bruger for meget tid paa usenet.
#define _(_)_"rdk"/* This is my real email address */
char _[]=_("kaspe")_("brics");_[7]='@';_[13]='.';puts(_);

---

Kasper Dupont skrev:

> Apache kører typisk med et seperat brugerid der f.eks. kunne være
> navngivet apache. Men bemærk, at alle filer, der kan læses af denne
> bruger kan læses af flere end man umiddelbart ville tro. Selv hvis
> de ligger udenfor webroden, har et specielt efternavn eller er
> beskyttet med en .htaccess fil, kan det læses af andre brugere på
> systemet ved blot at oprette et symlink i deres eget public_html
> directory.

Det kommer helt an på opsætningen af Apache. Man behøver ikke at slå
"FollowSymlinks" til i Apaches opsætning.

Jacob
--
"The universe isn't for the likes of me to understand. I only work here."