Linux, Apache en rechten

[Jazzy]

Ik heb een vrij kale CentOS 6.2 machine waar ik Apache op heb geïnstalleerd. Nu weet ik alleen niet wat de beste manier is om hier permissies op te zetten. Ik lees wel allerlei voorbeelden maar als niet-Linux man kan ik niet goed overzien wat een praktische optie is. Ik begrijp hoe rechten toegekend worden voor de eigenaar, groep en anderen maar niet hoe je dat in de praktijk toepast.

Wat ik heb/weet:
- documentroot is /www
- bestanden in /www, /www/images en /www/files
- een gebruiker met de naam henk (adduser henk)
- een groep met de naam www (groupadd www)
- Henk is lid gemaakt van www (usermod -a -G www henk)
- Apache draait onder user apache/groep apache

Wat ik wil:
- sitebestanden onder /www moeten uiteraard zichtbaar worden voor anonieme gebruikers
- persmissies toepassen met de groep www
- gebruiker Henk moet kunnen schrijven in /www en onderliggende directories

Op welke manier kan ik nu het beste permissies toekennen aan mijn www-groep? En waarom zo?

[Hero of Time]

Ownership:

chown -R henk:www /www

Rechten:

find /www -type f -exec chmod 644 {} \;
find /www -type d -exec chmod 755 {} \;

Wat bovenstaande doet is de eigenaar naar gebruiker Henk en groep www zetten, daarna elk bestand in /www lees en schrijf rechten voor de gebruiker, lees voor groep en anderen. Mappen krijgen lees, wijzig en uitvoer rechten voor gebruiker, lees en uitvoer voor groep en anderen. Waarom uitvoer rechten? Omdat je anders de map niet in mag .

Vraag mij wel af, waarom wil je ieder ander lees rechten geven op die mappen en bestanden? Wat is precies je doel? Want als het alleen websites moet serveren, zonder dat mensen er via ftp of ssh op mag, kan je de 'overige' alle rechten ontnemen. Apache serveert alles en het kan 't lezen, dus je bezoekers op de website ook.

Lees je verders even in de hele rechtenstructuur van Linux en er zijn zat guides voor het beveiligen van je webserver. Beetje inzet hier kan geen kwaad, wat je wilt is al op duizenden sites uitgelegd.

[psyBSD]

Als je alle leden van de www groep schrijfrechten wil geven, kun je het volgende doen:

find /www -type d -exec chmod 2775 {} \;
find /www -type f -exec chmod 664 {} \;

Moet je voor het mooie wel apache lid maken van een andere (niet-www) groep. Voor de veiligheid.

Edit:
2775 zet het SET_GID bit op de folder, hierdoor worden alle bestanden en mappen hieronder automatisch van de 'www' groep, met de bijbehorende rechten.

[ Voor 22% gewijzigd door psyBSD op 16-02-2012 09:20 ]

[igmar]

Gebruik een ACL.. Over dit onderwerp zijn echt al tig topic geweest, met allemaal dezelfde strekking.

[Jazzy]

Dank mannen, dat zijn tips waar ik wat mee kan. Ik weet dat er heel veel over geschreven is maar ik zoek echt even de toepassing in de praktijk. Als Windows-man heb ik hier totaal geen gevoel mee en heb ik liever dag iemand echt even mee denkt en uitleg kan geven.

Ik had er niet aan gedacht dat henk en apache eigenlijk de enige users zijn. Aangezien Others dan helemaal geen rechten nodig hebben kan ik (2)775 en 664 vervangen door 770 en 660?

In prinicpe lijkt dit te werken zo, behalve dat henk via FTP nog alleen maar kan lezen, niet schrijven. Weet niet of het een rechten probleem is, SElinux instelling of een probleem met mijn configuratie.

iptables:

code:

# Firewall configuration written by system-config-firewall
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 21 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT

In iptables-config:

code:

IPTABLES_MODULES="ip_conntrack_ftp"

In /etc/vsftpd/vsftpd.conf:

code:

write_enable=YES
userlist_enable=YES
tcp_wrappers=YES

Door ip_conntrack_ftp zou het niet nodig zijn om passive ftp te configureren. Maar toch werkt het niet:

code:

ftp web01
Verbonden met web01.putten.local.
220 Welcome to Jetze's FTP service.
Gebruiker (web01.putten.local:(none)): henk
331 Please specify the password.
Wachtwoord:
230 Login successful.
ftp> cd /www/www.blaat.net
250 Directory successfully changed.
ftp> mkdir test123
550 Create directory operation failed.
ftp> ls
200 PORT command successful. Consider using PASV.
150 Here comes the directory listing.
test
226 Directory send OK.
ftp: 6 bytes ontvangen in 0,00 seconden 6000,00 kB/s.
ftp>

Heb de rechten nu twee keer gecontroleerd en via SSH kan henk alles doen wat nodig is, bestanden aanmaken en verwijderen. Via FTP lukt het dus niet, recten probleem of configuratie?

[Jazzy]

igmar schreef op donderdag 16 februari 2012 @ 10:37:
Gebruik een ACL.. Over dit onderwerp zijn echt al tig topic geweest, met allemaal dezelfde strekking.

Een specifiek topic in gedachten wat aansluit bij mijn vragen?

[DAzN]

Bekijk of ftp wel is wat je wilt. Als je vanaf een OS werkt dat ssh ondersteunt (*nix, OSX) dan kun je een webserver / website veel eenvoudiger beheren via openssh. scp en sftp zijn veiliger dan het ftp-protocol en ook nog eens eenvoudiger in gebruik. Helemaal als je ook nog eens met sleutels werkt in plaats van met wachtwoorden.

[igmar]

Jazzy schreef op donderdag 16 februari 2012 @ 10:44:
[...]
Een specifiek topic in gedachten wat aansluit bij mijn vragen?

Nee, niet echt. Maar ACL's zijn redelijk normaal deze dagen. De manual van setfacl wijst zichzelf wel, let alleen op het verschil tussen een ACL en een default ACL. Die laatste is van toepassing op *directories* en geld vervolgens voor bestanden en directies die daarna aangemaakt worden.

Als je verdere uitleg zoekt : Shoot, dan kan ik je wel de goede richting op sturen.

[borft]

onder windows kan je ook prima sftp gebruiken met bv filezilla, dit werkt gewoon via ssh, en dan hoef je dus geen extra service te configureren. Ik persoonlijk zou nooi ftp over plain itnernet gebruiken, tenzij het anonymous is, want het is echt heel onveilig.

ow ja, een tip voor je firewall: shorewall

[ Voor 8% gewijzigd door borft op 16-02-2012 14:28 ]

[Jazzy]

Prima suggestie. Maar deze server beheer ik alleen van een ander intern werkstation, versleuteling heeft dus niet de hoogste prioriteit. Als het over het internet moest dan had ik inderdaad voor sftp gekozen.

borft schreef op donderdag 16 februari 2012 @ 14:28:ow ja, een tip voor je firewall: shorewall

Ik wil niet eigenwijs overkomen maar waarom moet ik een andere firewall kiezen? Ik heb juist gekozen voor een minimale setup en wil het zo simpel mogelijk houden. Als ik dan een tool gebruik die de onderliggende configuratie voor me doet, dan lijkt het wel makkelijker maar ik wil graag begrijpen wat ik doe.

[ Voor 55% gewijzigd door Jazzy op 16-02-2012 14:53 ]

[Jazzy]

Het lijkt inderdaad SELinux te zijn, in /var/audit/audit.log zie ik:

code:

type=AVC msg=audit(1329403911.560:109): avc:  denied  { write } for  pid=1448 comm="vsftpd" name="images" dev=dm-0 ino=1048678 scontext=unconfined_u:system_r:ftpd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:default_t:s0 tclass=dir

Verder nog een keer geprobeerd met SELinux uit en dan werkt het prima, SELinux aan en het werkt niet. Weet iemand welke rol ik precies aan moet zetten om schrijven via ftp in /www toe te staan?

[Jazzy]

Okay, voor iemand die een keer in een vergelijkbare situatie komt... SELinux is een extra laag van beveliging bovenop het standaard permissiemodel. Helaas blokeert het een heel aantal zaken die je met een default installatie zou verwachten dat ze werken.

SELinux logt in /var/log/audit/audit.log maar geeft weinig concrete informatie om het probleem op te lossen. Je kunt het log laten analyseren door sealert en wel asl volgt:

code:

yum install setroubleshoot
sealert -a /var/log/audit/audit.log
of:
sealert -a /var/log/audit/audit.log > /pad/naar/logbestand.txt

Het rapport is verrassend leesbaar. Het stukje wat voor mij relevant was:

SELinux is preventing /usr/sbin/vsftpd from write access on the directory images.

***** Plugin catchall_boolean (57.6 confidence) suggests *******************

If you want to allow ftp servers to login to local users and read/write all files on the system, governed by DAC.
Then you must tell SELinux about this by enabling the 'allow_ftpd_full_access' boolean.
Do
setsebool -P allow_ftpd_full_access 1

***** Plugin catchall_labels (36.2 confidence) suggests ********************

If you want to allow vsftpd to have write access on the images directory
Then you need to change the label on images
Do
# semanage fcontext -a -t FILE_TYPE 'images'
where FILE_TYPE is one of the following: ftpd_tmpfs_t, var_run_t, var_log_t, xferlog_t, ftpd_var_run_t, pcscd_var_run_t, var_lock_t, tmp_t, ftpd_tmp_t, tmpfs_t, user_home_type, root_t, public_content_rw_t, krb5_host_rcache_t, tmp_t, user_home_dir_t, nfs_t.
Then execute:
restorecon -v 'images'


***** Plugin catchall (7.64 confidence) suggests ***************************

If you believe that vsftpd should be allowed write access on the images directory by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep vsftpd /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp