Я установил vsftpd на своем сервере Fedora 12 и хотел бы иметь следующую конфигурацию. Каждый пользователь должен иметь доступ к:
Для этого я сначала настроил vsftpd для chroot каждого пользователя в его домашний каталог. Затем я создал /web/USER с правильными разрешениями и использовал mount --bind /web/USER /home/USER/Web чтобы пользователь мог иметь доступ к /web/USER через /home/USER/Web.
Я также включил логическое значение SELinux ftp_home_dir так что vsftpd разрешено писать в домашние каталоги пользователей.
Это работает очень хорошо, за исключением того, что когда пользователь пытается загрузить или переименовать файл в /home/USER/Web, SELinux запрещает это, потому что изменения также должны быть внесены в /web/USER, и SELinux не дает vsftpd разрешения на запись чего-либо в этот каталог.
Я знаю, что могу решить проблему, включив логическое значение SELinux allow_ftpd_full_access, или ftpd_disable_trans. Я также пытался использовать audit2allow для генерации политики, но он генерирует политику, которая дает ftpd доступ на запись к каталогам типа public_content_t; это эквивалентно включению allow_ftpd_full_access, если я правильно понял.
Я хотел бы знать, можно ли настроить SELinux, чтобы разрешить FTP-доступ для записи в конкретный каталог. /web/USER и его содержимое, вместо полного отключения элементов управления FTP SELinux.
# semanage fcontext -a -t public_content_rw_t "/myftp/pub(/.*)?"
Обязательно укажите (/.*)? в конце имени каталога.
Я также пытался использовать audit2allow для генерации политики, но он генерирует политику, которая предоставляет ftpd доступ на запись к каталогам типа public_content_t; это эквивалентно включению allow_ftpd_full_access, если я правильно понял
По сути, да; поскольку SELinux позволяет каталогам / файлам, помеченным public_content_t для разделения между различными службами. Однако дальнейший контроль доступа осуществляется за счет использования sebooleans (или sebool, точнее).
Предоставление «полного доступа ftpd» не означает предоставления ему прав делать / читать / писать, что и где он хочет. SELinux имеет определенные политики для служб в вашей системе; смысл, ftpd разрешено читать файлы, если контекст файла каталога (fcontext) является public_content_t. SELinux предоставляет права записи на ftp-сервер, если fcontext каталога public_content_rw_t; другим службам, таким как samba, apache и т. д., должны быть разрешены разрешения на запись в эти каталоги через логические значения, в соответствии с соответствующими Документация RedHat. Если ваша «локальная политика» предоставляет ftpd доступ на запись в каталогах с меткой public_content_t, это существенно снижает уровень безопасности. Поэтому я предлагаю пометить каталог знаком public_content_rw_t context и удаление созданной вами локальной политики.
Для получения дополнительной информации и подробностей см. Страницы вики SELinux.
Попробуй это:
setsebool -P allow_ftpd_full_access on
Если виноват SELinux, стоит обратить внимание на несколько логических значений SELinux.
Лучшее начало: getsebool -a | grep ftp
Вы увидите что-то вроде
allow_ftpd_anon_write -> off allow_ftpd_full_access -> on allow_ftpd_use_cifs -> off allow_ftpd_use_nfs -> off ftp_home_dir -> on ftpd_connect_db -> off httpd_enable_ftp_server -> off twrite_server -> off_twrite
Не все из них относятся к vsftpd, например> httpd_enable_ftp_server предназначен для Apache, на котором запущен FTP, а tftp_anon_write - для> tftpd. Я бы начал с:
setsebool -P allow_ftpd_full_access для setsebool -P ftp_home_dir для
Источник: https://www.centos.org/forums/viewtopic.php?t=8129
Давайте обобщим известную информацию в лучший ответ. Вы уже указали решение, используя определенные логические значения selinux или разрешая доступ на запись в любые каталоги с public_content_t которые оба неоптимальны для вас.
Вам нужно обеспечить что каталоги имеют правильный контекст selinux. У вас есть пути / home / $ USER / Web и / web / $ USER, первый используется для монтирования второго через --bind вариант.
Первая идея, которая приходит мне в голову, - попробовать без mount --bind. Думаю, это сработает для доступа к FTP для вашего первого тестирования, и, возможно, вы уже это пробовали. Вам необходимо проверить, доступны ли теперь эти файлы через HTTP. Если нет, это означает, что ваш Apache Userdir не работает и должен быть исправлен, прежде чем играть с mount --bind. Вероятно, вы хотите, чтобы эти каталоги были в / web из-за внешнего хранилища, верно?
Я предполагаю, что единственная проблема здесь в том, что каталог / web / $ USER настроен не так, как если бы он работал автоматически для / home / $ USER / Web. Вы можете создать другой каталог, например / home / $ USER / Test, и сравнить результаты ls -lZ на них. Вы бы ясно заметили разницу.
Ты можешь использовать chcon чтобы изменить контекст, а затем проверить, что происходит. Это инструмент низкого уровня, и это не систематическое решение, но оно помогает быстро тестировать вещи. Вы также можете здесь немного поработать черной магией и просто бежать restorecon в / home / $ USER / Web, и я считаю, что он правильно установит контекст.
Окончательным решением было бы использовать semanage fcontext чтобы изменить базу данных пути, чтобы использовать правильный контекст также для / web, а также для любого / web / $ USER и особенно иметь контекст / home / $ USER / Web тот же самый как для / web / $ USER как mount --bind это немного самой черной магии.
После изменения базы данных пути не забудьте запустить restorecon -r /web на, и было бы неплохо также проверить, что restorecone -r /home это не нарушает. Также проверьте, созданы ли новые каталоги / web / $ USER с правильным контекстом или restorecon необходимо. Если вас не устраивает ситуация, вы можете настроить restorecond чтобы отслеживать эти каталоги и немедленно исправлять контекст, но это должно быть крайней мерой.
Всегда помните, что сам selinux не знает базу данных путей, но работает исключительно с контекстами безопасности соответствующих файлов.
У меня сейчас нет дистрибутива с поддержкой selinux, иначе я бы дал вам больше примеров командной строки, и решение было бы более точным. При необходимости я могу исправить это позже с помощью виртуальной системы centos / fedora. Теперь я вижу, что вопрос довольно старый. Меня обманул недостаточный ответ, но надеюсь, что это еще кому-то поможет.