ディレクトリ構造で:
/www/live/website1/app/
/www/live/website1/files/
/www/live/website1/logs/
Apacheが少なくとも次のアクセスを必要とする場合:
app: read-only access, but read-write is fine (files already chmod 0644)
files: read-write access
logs: read-write access
次の2つのルールが設定されている場合:
/usr/sbin/semanage fcontext -a -t httpd_sys_content_t "/www/live/.*/.*";
/usr/sbin/semanage fcontext -a -t httpd_log_t "/www/live/.*/logs(/.*)?";
/sbin/restorecon -vr "/www";
どちらが適用され、正常に動作しているようです...しかし、LogRotateは満足していません。
LogRotate構成は現在次のとおりです。
/www/live/*/logs/*access_log /www/live/*/logs/*access_log_443 {
weekly
rotate 52
missingok
notifempty
nodateext
sharedscripts
postrotate
/usr/sbin/apachectl graceful > /dev/null
endscript
}
ただし、これはSELinuxによってブロックされているようで、/www/live
フォルダー(下の例では262146)に関連するiノードをヒットしようとすると、audit.logにエントリが表示されます.../www/live /内のフォルダ。
type=AVC msg=audit(1396579563.324:316060): avc: denied { read } for pid=12336 comm="logrotate" name="live" dev=dm-0 ino=262146 scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:default_t:s0 tclass=dir
type=SYSCALL msg=audit(1396579563.324:316060): Arch=c000003e syscall=2 success=no exit=-13 a0=7fff2cef68b0 a1=90800 a2=7fff2cef6b5a a3=8 items=0 ppid=12334 pid=12336 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=35531 comm="logrotate" exe="/usr/sbin/logrotate" subj=system_u:system_r:logrotate_t:s0-s0:c0.c1023 key=(null)
それで、この親ディレクトリをどのコンテキストに設定する必要がありますか?
/usr/sbin/semanage fcontext -a -t default_t "/www(/.*)";
私が知っているところではdefault_t
は機能せず、var_t
...も機能しません。また、参考までに、これらのフォルダーはすでにchmod 0755であるため、何が見えるかは気にしません。
そしてボーナスポイントについて...プログラムが持っている許可の完全なリストを見る簡単な方法はありますか? LogRotateがhttpd_log_t
およびvar_log_t
にアクセスできる必要があることを知っています。
面倒なのは、LogRotateを手動で実行すると、これらの制限をバイパスしているように見えることです。これは、(cronを介して実行する場合とは異なり)ユーザーのアクセス許可を継承すると想定しているためです。
これが正しい答えかどうかはまだ確認されていません...
/usr/sbin/semanage fcontext -a -t sysfs_t "/www(/.*)";
/usr/sbin/semanage fcontext -a -t httpd_sys_content_t "/www/live/.*/.*";
/usr/sbin/semanage fcontext -a -t httpd_log_t "/www/live/.*/logs(/.*)?";
/sbin/restorecon -vr "/www";
そこではsysfs_t
が重要です。
LogRotateで使用できるドメインを見つけることができます。
sesearch -s logrotate_t -SA
「dir」の「読み取り」(「開く」だけではない)パーミッションをクイック検索する:
sesearch -s logrotate_t -SA -c dir -p read | sort
次に、リストをスキャンすると、sysfs_t
が最適です。
私が見つけた問題は、/usr/sbin/logrotate
を自分で実行すると、ルートアカウントコンテキストを継承することです。
id -Z
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
そのため、「制限なし」のアクセス(つまり、フルアクセス)が自動的に取得されます。テストするために、次のコードを使用すると、完全ではありませんが、一種の作業が行われることがわかりました。
sandbox /usr/sbin/logrotate -d /etc/logrotate.conf
newrole
とruncon
についても知りました。どちらも、RedHat/CentOSシステムに個別にインストールする必要があります。
yum install policycoreutils-newrole
newrole -r system_r -t logrotate_t
runcon -r system_r -t logrotate_t /usr/sbin/logrotate -d /etc/logrotate.conf
しかし、これらの両方が私に許可拒否エラーを与えていました(おそらく移行が許可されていないため):
http://wiki.gentoo.org/wiki/SELinux/Tutorials/How_does_a_process_get_into_a_certain_context
他に便利だと思ったもの:
yum install setools-console
seinfo -usystem_u -x
seinfo -rsystem_r -x
seinfo -tlogrotate_t -x
seinfo -tsysfs_t -x
システムで作成したルールのリストを確認するには:
cat /etc/selinux/targeted/contexts/files/file_contexts.local
SELinuxの詳細については、次の17のチュートリアルが非常に役立ちました。
http://wiki.gentoo.org/wiki/SELinux/Tutorials
個人的に私はこれらすべてのプログラムに非常に一貫性がないことを発見し、ほとんどの人がデフォルトでSELinuxを無効にするだけの理由を理解できます...
seinfo
とnewrole
を取得するには、追加のパッケージをインストールする必要がありますaudit.log
ファイルはタイムスタンプを使用するため、代わりにausearch -m avc --start today
を試してください。matchpathcon
)。audit2allow
の出力(または操作)が明白であるとは言いません。全体として非常に強力なシステムであるように思われるので、これは残念です。