Säkerhetsrisker med två inloggningar till samma GID?

Största säkerhetsrisken här är nog att du har filer som ägs av www-data. www-data skall inte äga filer då dessa blir tillgängliga vid en exploit av servern.

Jag skulle nog föredra att skapa en grupp för användarna som skall editera filerna och göra filer/kataloger i webträdet skrivbara för den gruppen samt göra användarna till medlemmar i gruppen. Alternativt, skapa en användare som äger filerna och låt dem använda sudo för att arbeta med filerna men det kan bli lite knepigt om de skall ladda upp filer etc.

Har alltså båda användarna unika UID men samma primary group? Det är inga som helst problem.Jag kan förklara hur jag brukar göra:

Låt båda användarna ha sina egna grupper som primary group. Skapa en mapp i webb roten som heter tex www.example.com, Skapa en grupp som heter exemple och ändra rättigheterna på mappen www.example.com till 770 och så den ägs av användare www-data och gruppen example. Lägg till www-data, användare y och användare x i gruppen example som completery group. Så långt borde alla ha skriv och läs rättigheter till den mappen

Sedan sätter du sticky bit på den mappen och ser till så att användarna har 007 som umask, sätts i /etc/profile i debian. Då kan alla ändra varandras filer också. Och alla filer som skapas där kommer automatisk att tillhöra gruppen example, som då alla användare är medlem. Skulle det bli problem så att någon fil får en chmod på tex 700 så ska det gå att ändra av vem som helst eftersom mappen www.example.com har alla i gruppen example skrivrättigheter till.

Det är så jag brukar göra. Jag vet inte om det finns bättre lösningar?. Jag har aldrig riktigt förståt hur det är tänkt att man ska organizera sånt här i linux

Menar du SGID? Sticky ändrar beteendet för en katalog såtillvida att endast root eller filens ägare kan radera/döpa om filen till skillnad från vem som helst med skrivrättigheter till katalogen vilket är det normala.

Jag skulle kanske ha skrivit att katalogen skulle SGID:as, jag tenderar att förutsätta att folk vet sånt.

Ja det har du helt rätt id. Jag brukar blanda ihop det där. SGID ska den vara. Då kommer allt som skapas i mappen tilhöra den grup som mappen tillhör.

Exempel:

#whoami
Xuser
# ls -la
drwxr-xr-x 16 example example 4096 2007-11-28 11:52 www.example.com
#chmod g+s www.example.com
#touch ./www.example.com/test
#ls -la ./www.example.com/test
drwxr-xr-x 16 Xuser example 4096 2007-11-28 11:52 www.example.com

Jag tror inte det här fungerar om man använder kommandot mv. Då får man nog ange några magiska växlar eller efterhandsjustera rättigheterna

Sen har du rätt i att det är dumt att låta www-data äga www.example.com.. Kommer någon åt web-server så är det mångdubbelt enklare att göra något elakt. Det gäller ju specielt ifall man använder(har aktiverat) php eller cgi.

Men då vet jag faktiskt inte riktigt hur man gör med rättigheterna för att fixa. Man kan ju såklart ändra ägaren till någon dummy, men då måste ju apache ändå kuna läsa. Och som jag förstår det är den enda möjligheten då att sätta 775? och låta apache vara "everyone" Det fungerar ju inte att lägga till den i example gruppen, för den kommer ju ha skrivrättuigheter. Men då kommer ju problemet att man kanske inte vill att att alla som kan läsa /var/www ska kunna läsa /var/www/www.example.com.. har jag missat någon smidigare lösning?

Nu hoppas jag ni förstår. Jag känner att det blev lite luddigt:)

Mitt direkta svar blir något i stil med att du inte skall ha potentiellt fientliga användarkonton på en webserver. Dock kan jag förstå att inte alla kan kosta på sig en dedikerad webserver.

Som jag sade i mitt första inlägg är sudo (eller liknande program) en möjlighet. Då kan du göra www-data till medlem i gruppen och ha filerna chmod 0640. De användare som skall jobba med filerna får då byta EUID med sudo så att de får skrivrättigheter.

Andra möjligheter är extended attributes för mer granulära ACLs eller ett komplett MAC-system som t.ex. SELinux.

De enda rimliga alternativet borde då alltså bli ACL eller SElinux, sudo kommer bara vara kompitabelt med en terminal. En ftp server eller webDAV osv är ju inte kompitabelt med det. Att låta bli att ha osäkra användarkonton fungerar ju bara ibland, dessutom är ju *nix designad för att vara ett multianvändarsystem, så man vill ju kunna ha många användare utan att dom kan störa varandra. I trådskaparens fall tror jag inte att han borde bry sej om det. Det är nog överskurs. Beroende på hur mycket tid han vill lägga ner då förstås

Iaf. Det här är en av dom saker jag inte gillar med *nix. Jag skulle vilja enkelt kunna sätta rättigheter för hur många grupper jag vill, Inte "Ägare, Grupp, Alla" designen. Den enda sak som stör mej mer än det är att de glömt bort att bygga ett rättighetsystem för nätverket. root < 1024, everyone >1024 är ett riktig vek och ofullständig design. Jag väntar på när något större OS vågar släppa lite på POSIX standarderna och utveckla lite för att få ett säkrare och mer funktionabelt system..

För att inte det här skall hamna alltför långt från ämnet...

Nyrostad - Nej, ditt påhitt innebär i sig inget större säkerhetsproblem. Hur mycket jobb du vill lägga ner på att eliminera de andra riskerna är upp till din bedömning av vad som är "säkert nog".

millepromille - Att ett system är ett multianvändarsystem innebär inte att det är riskfritt att låta vilka användare eller tjänster som helst köra på samma maskin. Utan att avse att starta något flamewar så måste jag ju påpeka att Windows NT och framåt implementerar ett mycket kompetent ACL-system, döm själv hur det hjälpt säkerheten. Säkerhetens största fiende är komplexitet och även om mer avancerade system som MAC/MLS (t.ex. SELinux) kan åstadkomma mycket säkra system så är kunskapen och arbetsinsatsen som krävs mycket stor. Och en bra säkerhetslösning är en som du kan förstå och sköta.
Man kan bygga mycket säkra system med en traditionell UNIX, men det kräver att man begränsar vissa aspekter av systemet (ur "användarvänlig" synvinkel). Som jag sade kan jag förstå att den som bara vill köra en liten server hemma tycker att det är obekvämt. Dock bottnar det enligt min mening i en farlig missuppfattning, nämligen den att man kan anpassa säkerheten till arbetssättet.

Men som sagt, nu börjar jag komma alltför långt från ämnet...