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…