Na tento seriál je ještě trochu brzy, ale já jsem ze všech těch nových vlastností, které půjdou do Fedory 20, opravdu nadšený.
Poznámka: Článek původně vyšel v blogu Dana Walshe jako New Security Feature in Fedora 20 Part 1: Setroubleshoot - Journald integration.
Před časem na sebe byla kolegyně Máirín Duffy pyšná kvůli tomu, jak si poradila s problémem s SELinuxem. Měla podobný problém jako řada lidí, kteří se s SELinuxem potýkají. Vytvořila nějaký obsah pro svůj webový server, přesunula ho do adresáře /var/www, zkusila se na věc podívat ve svém prohlížeči a dostala zprávu podobnou té následující:
Když se podívala do /var/log/httpd/error_log, viděla hlášku, jako je tato:
# tail /var/log/httpd/error_log [Fri Aug 02 08:05:43.347080 2013] [core:error] [pid 10556] (13)Permission denied: [client ::1:38045] AH00132: file permissions deny server access: /var/www/html/index.html
Místo aby myslela, že je problém s příznaky Ownership nebo Permission, vzpomněla si na SELinux a usoudila, že by mohl být problém se značkami. Takže spustila:
# restorecon -R -v /var/www restorecon reset /var/www/html/index.html context unconfined_u:object_r:user_home_t:s0->unconfined_u:object_r:httpd_sys_content_t:s0
Kdyby pokračovala ve zkoumání, našla by na dalších místech, kde se ukládají logy, následující. V souboru /var/log/audit/audit.log
jádro zanechalo AVC hlášku podobnou této:
# ausearch -m avc -ts recent -i
type=PATH msg=audit(08/02/2013 08:05:43.346:1197) : item=0 name=/var/www/html/index.html inode=3145858 dev=08:03 mode=file,644 ouid=root ogid=root rdev=00:00 obj=unconfined_u:object_r:user_home_t:s0
type=CWD msg=audit(08/02/2013 08:05:43.346:1197) : cwd=/
type=SYSCALL msg=audit(08/02/2013 08:05:43.346:1197) : arch=x86_64 syscall=open success=no exit=-13(Permission denied) a0=0x7f476595da40 a1=O_RDONLY|O_CLOEXEC a2=0x0 a3=0x7fffe27e11b0 items=1 ppid=10552 pid=10556 auid=unset uid=apache gid=apache euid=apache suid=apache fsuid=apache egid=apache sgid=apache fsgid=apache ses=unset tty=(none) comm=httpd exe=/usr/sbin/httpd subj=system_u:system_r:httpd_t:s0 key=(null)
type=AVC msg=audit(08/02/2013 08:05:43.346:1197) : avc: denied { read } for pid=10556 comm=httpd name=index.html dev="sda3" ino=3145858 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file
SETroubleshoot tu zprávu dostal a hlásil ve /var/log/messages
:
# grep setroubleshoot /var/log/messages Aug 2 08:01:46 redsox setroubleshoot: SELinux is preventing /usr/sbin/httpd from read access on the file /var/www/html/index.html. For complete SELinux messages. run sealert -l fd6b9022-1ced-4065-905a-8f0e884f9915
Kdyby nakonec spustila tento příkaz sealert, který je uvedený v logu, zjistila by, že setroubleshoot zapsal svoji analýzu do /var/lib/setroubleshoot/setroubleshoot_database.xml
.
# sealert -l fd6b9022-1ced-4065-905a-8f0e884f9915 SELinux is preventing /usr/sbin/httpd from read access on the file /var/www/html/index.html. ***** Plugin restorecon (92.2 confidence) suggests ************************* If you want to fix the label. /var/www/html/index.html default label should be httpd_sys_content_t. Then you can run restorecon. Do # /sbin/restorecon -v /var/www/html/index.html ...
Je prima, že Máirín svůj problém vyřešila tak rychle, ale jak vidíte, systém zanechal malé nápovědy všude kolem, aby jí pomohl. A kdo říká, že je SELinux složitý?!
Ok, Dane, k věci?
Pokud jste sledovali konferenci Fedora-devel, víte, že probíhala velká debata o tom, jestli syslog (rsyslog) povolit ve výchozí instalaci. Záměrem je konsolidovat logování do journald, o čemž jsem mluvil v předchozím blogu. A nástrojům pro analýzu logů říct, aby spoléhaly na data z journald, místo aby procházely /var/log/messages
.
Integrace SETroubleshot s journald
Ve Fedora 18 nebo 19 jsme začali ukládat data z setroubleshoot do žurnálu. Potíž je v tom, setroubleshoot reportoval o procesu httpd, ale journald/systemd to nemohl vědět. Požádal jsem tým journald, aby přidal mechanismus, pomocí kterého by oprávněná aplikace mohla určit Process ID (PID), ke kterému se zpráva logu váže. Systemd/journald tuto vlastnost přidal ve verzi systemd-206-1 a já příslušnou funkci přidal do setroubleshoot-3.2.11-1.fc20.x86_64.
Takže teď by Máirín stačilo zkontrolovat stav služby httpd a viděla by následující zprávu:
# systemctl status httpd httpd.service - The Apache HTTP Server Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled) Active: active (running) since Fri 2013-08-02 08:01:35 EDT; 30min ago Main PID: 10552 (httpd) Status: "Total requests: 4; Current requests/sec: 0; Current traffic: 0 B/sec" CGroup: /system.slice/httpd.service ├─10552 /usr/sbin/httpd -DFOREGROUND ├─10553 /usr/libexec/nss_pcache 196611 off /etc/httpd/alias ├─10554 /usr/sbin/httpd -DFOREGROUND ├─10555 /usr/sbin/httpd -DFOREGROUND ├─10556 /usr/sbin/httpd -DFOREGROUND ├─10557 /usr/sbin/httpd -DFOREGROUND ├─10558 /usr/sbin/httpd -DFOREGROUND └─10569 /usr/sbin/httpd -DFOREGROUND Aug 02 08:01:35 redsox.boston.devel.redhat.com systemd[1]: Started The Apache HTTP Server. Aug 02 08:01:46 redsox.boston.devel.redhat.com python[10564]: SELinux is preventing /usr/sbin/httpd from read access on the file /va...html. ***** Plugin restorecon (
A s pomocí příkazu journalctl
by viděla celou analýzu:
# journalctl -r -o verbose -u httpd.service -- Logs begin at Tue 2013-04-09 15:19:05 EDT, end at Fri 2013-08-02 08:32:35 EDT. -- Fri 2013-08-02 08:05:45 EDT [s=3087834a63d74580811c9e1088ac7fdf;i=1195d;b=71667fa0d7074a3f8bdf1c0da22fe234;m=22b877728;t=4e2f5c7552cb6;x=908 _UID=0 _GID=0 _BOOT_ID=71667fa0d7074a3f8bdf1c0da22fe234 _MACHINE_ID=8835be49c83449d3b4581853df82eafa _HOSTNAME=redsox.boston.devel.redhat.com _TRANSPORT=journal _CAP_EFFECTIVE=3fffffffff _SYSTEMD_CGROUP=/system.slice/dbus.service _SYSTEMD_UNIT=dbus.service _EXE=/usr/bin/python2.7 _COMM=setroubleshootd _CMDLINE=/usr/bin/python -Es /usr/sbin/setroubleshootd -f _SELINUX_CONTEXT=system_u:system_r:setroubleshootd_t:s0-s0:c0.c1023 MESSAGE=SELinux is preventing /usr/sbin/httpd from read access on the file /var/www/html/index.html. ***** Plugin restorecon (92.2 confidence) suggests ************************* If you want to fix the label. /var/www/html/index.html default label should be httpd_sys_content_t. Then you can run restorecon. Do # /sbin/restorecon -v /var/www/html/index.html ***** Plugin catchall_boolean (7.83 confidence) suggests ******************* If you want to allow httpd to read user content Then you must tell SELinux about this by enabling the 'httpd_read_user_content' boolean. You can read 'user_selinux' man page for more details. Do setsebool -P httpd_read_user_content 1 ***** Plugin catchall (1.41 confidence) suggests *************************** If you believe that httpd should be allowed read access on the index.html file 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 httpd /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp CODE_FILE=/usr/lib64/python2.7/site-packages/setroubleshoot/server.py CODE_LINE=196 CODE_FUNC=report_problem SYSLOG_IDENTIFIER=python OBJECT_UID=48 OBJECT_GID=48 OBJECT_COMM=httpd OBJECT_EXE=/usr/sbin/httpd
Prima, ne?
Všechny informace jsou nyní sjednoceny do jedné sady nástrojů a když začnou administrátoři používat systemct status foobar
, dostanou důležité informace o SELinuxu v hlavním logu, takže bude snazší SELinux používat a více lidí ho pak nechá zapnutý.
Mimochodem, tohle bude fungovat i v Red Hat Enterprise 7.
Do budoucna
S týmem systemd/journald chci dál pracovat, aby systemctl status
poskytoval více informací, takže by byla celá zpráva na jedné obrazovce a odpadla by potřeba dalšího kroku. Už tak je to však velký krok kupředu z hlediska použitelnosti.
V nadcházejících verzích Fedory bych se chtěl úplně zbavit databáze setroubleshoot a používat jako informační databázi jen journald.
A stále chci tlačit jaderný tým, aby zvážil Friendly EPERM.
14. 8. 2013 at 14:44
Jo, vsechno to nacpeme do systemd. A uz si nekdo zkusil pustit journald na systemu, ktery bezi nekolik tydnu a podivat se na konec logu? Me prijde, ze to nikdo nezkusil…
14. 8. 2013 at 14:53
Kouknul jsem do bugzilly – https://bugzilla.redhat.com/show_bug.cgi?id=867841 tak uz na to je -r a -be – lepsi nez nic, akorat budu muset prestat pouzivat tail…