OpenBSD php/MySQL till chrootat Apache?

PHP är bara att installera, det fungerar fint direkt.

MySQL är lite pillande med men inga större problem.
Detta kräver dock att /var/www ligger på samma partition som /var, annars fungerar inte hårdlänken...
I /etc/rc.local:

# MySQLd
if [ -x /usr/local/libexec/mysqld ]; then

    /usr/bin/install -d -o _mysql -g _mysql /var/run/mysql
    echo -n " mysqld"; /usr/local/libexec/mysqld &

    for i in 1 2 3 4 5 6; do
        if [ -S /var/run/mysql/mysql.sock ]; then
            break
        else
            sleep 1
            echo -n "."
        fi
    done
    
    # Apache chroot
    /bin/mkdir -p /var/www/var/run/mysql
    sleep 2
    /bin/ln -f /var/run/mysql/mysql.sock /var/www/var/run/mysql/mysql.sock
fi

Du kan behöva ändra sökvägen till mysql.sock i php.ini.

Jag använder verktyg som loggar systemanrop från angiven process så att man kan se vilka filer och bibliotek som behövs om man gör det manuellt.

Chroot är ett säkerhets-hack tycker jag, ingen långsiktig lösning. Det är en del att tänka på för att förhindra att någon tar sig ut.

• inga suid-root binärer

• inte köra något som root i chroot

• root bör äga alla filer och de skall inte vara skrivbara av någon annan

• inte köra någon process utanför som körs av samma användare som servern

• inte erbjuda något skal i chroot:et

• inte tillåta exekvering av binärer i kataloger där uppladdat material hamnar (annars finns det möjlighet att ladda upp kompilatorer, skal och alla de verktyg som kan tänkas behövas om man skall bryta sig ur)

• etc etc

Verklig separation är den rätta vägen och jag hoppas att Xen (och hårdvaran) utvecklas så att man kan konsolidera servrar utan risk för att domäner sniffar PCI-bussar och liknande elakheter. Amd har ju IOMMU och det är ju ett steg i rätt riktning...

Om du är _riktigt_ paranoid kan du köra:

• använda en hårdvaru-platform som har stöd för separering av data och kod i stacken (sidvis), exempel alpha eller amd64

• Apache med minimalt antal moduler

• chroot

• PF som bara tillåter anslutningar till port 80 (stoppa all trafik ut som inte är svar på en förfrågan)

• systrace

• securelevel 2, dock verkar OpenBSD skita i securelevels. NetBSD's securelevel 2 förhindrar t ex att man monterar om endast läsbara diskar till läs- och skrivbara, även om man är root

• endast läsbara diskar (du får skapa skrivbara partitioner för loggar och uppladdat material)

• använder noexec, nodev, nosuid etc på skrivbara områden

• tar bort allt onödigt på servern, framförallt suid- och sgid-binärer som inte används, du kan ta bort dessa bitar också om du vill ha kvar programmen

• och självklart uppdaterar mjukvaran regelbundet

• använda mod_security och/eller snort

• endast tillåta inloggning lokalt (vilket du måste göra ändå om du använder securelevels eftersom man måste gå ner i singleuser för att kunna montera om diskarna vid uppdateringar)

Kanske inte den mest smidiga lösningen ur underhållssynpunkt men några steg mot en säkrare server...

Lite mer om skillnaden mellan OpenBSD's och NetBSD's implementation, mer specifikt ett säkerhetshål som upptäckts i OpenBSD's variant. Securelevels kom till för att förhindra/förminska möjligheterna för en cracker som fått root att skada maskinen.

Källa http://www.securityfocus.com/columnists/380

Har man möjlighet så kan securelevels 2 vara användbart (förutsatt att man kör NetBSD). Har man fysisk tillgång till maskinen så ser jag inga nackdelar med att använda det...

ldd fungerar men ktruss och ktrace är bättre (jag antar att OpenBSD har något liknande).

Det där är egentligen inget avancerat shellskript och jag kan beskriva lite vad det gör (det finns dessutom ett antal varianter av det vilka kan hittas i guider om man söker på exempelvis "openbsd apache chroot mysql".

Först kollas det så att mysqld existerar (ingen mening att försöka starta det annars ), därefter skapas katalogen /var/run/mysql med _mysql:_mysql som ägare, sedan startas mysqld.

Därefter så kollar vi i sex sekunder om /var/run/mysql/mysql.sock skapats (för varje sekund skrivs en punkt ut). När det är klart skapas katalogen /var/www/var/run/mysql och väntar i två sekunder på att det innan ska bli klart. Sedan skapar vi en hårdlänk från /var/run/mysql/mysql.sock till /var/www/var/run/mysql/mysql.sock (skriver över den om den redan existerar).

Tänk på att när man pratar om / i ett chroot jail så pratar man om katalogen som man chrootas i (/var/www i det här fallet), så om man skriver /etc/fil.conf i en konfigurationsfil som körs efter chrootningen så kommer programmet att leta i /var/www/etc/fil.conf, likaså är det därför som PHP:s moduler installeras i /var/www/lib/php/modules.

EDIT: För den delen så behöver man faktiskt inte göra såhär, man kan lika gärna strunta i att utnyttja UNIX-socketen och använda sig av TCP-sockets istället (använda 127.0.0.1 istället för localhost i PHP-skripts). Man slipper då hårdlänka in mysql.sock i chroot jailet.

Ok, det kanske låter som om jag inte gillar OpenBSD, men det gör jag (eller vissa delar av det iaf).

Jag vet att det kräver root-behörigheter och det är det som är hela poängen. Det finns betydligt bättre verktyg (systrace) men hela iden med securelevels är att förhindra root från att göra vissa saker under drift. Som du säger så är det inget totalförsvar mot attacker, men kan potentiellt minska skadorna av dessa.

Om du läste beskrivningen av problemet kan man montera filsystem ovanpå ett existerande och modifiera valfria filer, även de som har immutable-flaggor satta genom att skapa en ny fil ovanpå den gamla. Om detta är en del av spec:en kanske det inte ska kallas säkerhetshål, det hamnar nog under problem med designen. Securelevels på OpenBSD ger en falsk känsla av trygghet och borde därmed inte användas, modifieras för att förhindra montering av filsystem eller tas bort helt.

Och det är nog smidigast att kommunicera över localhost, men lite långsammare skulle jag tro än än domän-socket.

Lägg de där raderna i /etc/rc.local så körs MySQL igång vid startup.

Om man använder 127.0.0.1 istället för localhost så kommunicerar man med servern via nätverket (TCP-sockets) istället för via filsystemet (UNIX-sockets) och därmed spelar chrooten ingen roll, eftersom att vi inte pratar med MySQL via filsystemet som är chrootat.

Men som sagt, det där är knappast struligt så det finns ingen direkt anledning att strunta i det.

localhost är hostnamnet för 127.0.0.1.

Så localhost är samma sak som att skriva ip-adressen 127.0.0.1

Jodå, titta i /etc/hosts så ser du en rad liknande denna:

127.0.0.1       localhost.localdomain   localhost

Du kan ju också prova att ping'a localhost:

$ ping localhost
PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.183 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.079 ms
64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.078 ms
 
--- localhost ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2020ms
rtt min/avg/max/mdev = 0.078/0.113/0.183/0.050 ms
$

Fungerar på samma sätt på alla OS som använder TCP/IP.

Där är vi helt överrens, det faligaste är att man tror att det finns någon magisk switch man kan slå på så är allt frid och fröjd, ta exemplet brandväggar.

Angående localhost vs. 127.0.0.1, ja det är samma sak, men MySQL-libet tolkar dem olika.

(jag sa aldrig att localhost och 127.0.0.1 skiljde sig åt i systemet, remember? )