Hide Forgot
SELinux is preventing /usr/bin/python from 'getattr' accesses on the file /etc/localtime. ***** Plugin restorecon (99.5 confidence) suggests ************************* If you want to fix the label. /etc/localtime default label should be locale_t. Then you can run restorecon. Do # /sbin/restorecon -v /etc/localtime ***** Plugin catchall (1.49 confidence) suggests *************************** If you believe that python should be allowed getattr access on the localtime 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 SetroubleshootF /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:setroubleshoot_fixit_t:s0-s0:c0. c1023 Target Context system_u:object_r:etc_runtime_t:s0 Target Objects /etc/localtime [ file ] Source SetroubleshootF Source Path /usr/bin/python Port <Неизвестно> Host (removed) Source RPM Packages python-2.7-8.fc14.1 Target RPM Packages glibc-2.13-1 Policy RPM selinux-policy-3.9.7-31.fc14 Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name (removed) Platform Linux (removed) 2.6.35.11-83.fc14.x86_64 #1 SMP Mon Feb 7 07:06:44 UTC 2011 x86_64 x86_64 Alert Count 1 First Seen Вск 06 Мар 2011 11:12:18 Last Seen Вск 06 Мар 2011 11:12:18 Local ID b0e87718-a7bc-4026-9614-72dffac1c1c9 Raw Audit Messages type=AVC msg=audit(1299399138.596:74): avc: denied { getattr } for pid=13062 comm="SetroubleshootF" path="/etc/localtime" dev=sda2 ino=1180039 scontext=system_u:system_r:setroubleshoot_fixit_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_runtime_t:s0 tclass=file type=SYSCALL msg=audit(1299399138.596:74): arch=x86_64 syscall=fstat success=yes exit=0 a0=9 a1=7fff4e82fe90 a2=7fff4e82fe90 a3=2 items=0 ppid=13061 pid=13062 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=SetroubleshootF exe=/usr/bin/python subj=system_u:system_r:setroubleshoot_fixit_t:s0-s0:c0.c1023 key=(null) Hash: SetroubleshootF,setroubleshoot_fixit_t,etc_runtime_t,file,getattr audit2allow #============= setroubleshoot_fixit_t ============== allow setroubleshoot_fixit_t etc_runtime_t:file getattr; audit2allow -R #============= setroubleshoot_fixit_t ============== allow setroubleshoot_fixit_t etc_runtime_t:file getattr;
Please execute restorecon -R -v /etc/localtime and reopen if this happens again. ***** Plugin restorecon (99.5 confidence) suggests ************************* If you want to fix the label. /etc/localtime default label should be locale_t. Then you can run restorecon. Do # /sbin/restorecon -v /etc/localtime
Was this a fresh install from a livecd?
No, It was netinstall some month ago. I've restored content and switch SELinux to enforcing mode -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Miroslav, of course when the fix causes another AVC... It can get frustrating. Something in an update, or started by dbus on in an init script changed the /etc/localtime while running as initrc_t which caused it to be mislabeled. But we have no idea what.
this happens again. date cannot access localtime SELinux is preventing /bin/date from read access on the file /etc/localtime. ***** Plugin restorecon (99.5 confidence) suggests ************************* If you want to fix the label. /etc/localtime default label should be locale_t. Then you can run restorecon. Do # /sbin/restorecon -v /etc/localtime ***** Plugin catchall (1.49 confidence) suggests *************************** If you believe that date should be allowed read access on the localtime 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 date /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Исходный контекст unconfined_u:system_r:mysqld_safe_t:s0 Целевой контекст system_u:object_r:etc_runtime_t:s0 Целевые объекты /etc/localtime [ file ] Источник date Путь к источнику /bin/date Порт <Неизвестно> Узел f14.zhukoff.net Исходные пакеты RPM coreutils-8.5-7.fc14 Целевые пакеты RPM glibc-2.13-1 RPM политики selinux-policy-3.9.7-31.fc14 SELinux активен True Тип политики targeted Принудительный режим Permissive Имя узла f14.zhukoff.net Платформа Linux f14.zhukoff.net 2.6.35.11-83.fc14.x86_64 #1 SMP Mon Feb 7 07:06:44 UTC 2011 x86_64 x86_64 Счётчик уведомлений 9 Первый замеченный Срд 02 Мар 2011 23:38:58 Последний замеченный Вск 13 Мар 2011 10:08:19 Локальный ID 36cc448b-52ca-49f0-8324-f33bbe40c265 Необработанные сообщения аудита type=AVC msg=audit(1300000099.293:43425): avc: denied { read } for pid=5108 comm="date" name="localtime" dev=sda2 ino=1180032 scontext=unconfined_u:system_r:mysqld_safe_t:s0 tcontext=system_u:object_r:etc_runtime_t:s0 tclass=file type=AVC msg=audit(1300000099.293:43425): avc: denied { open } for pid=5108 comm="date" name="localtime" dev=sda2 ino=1180032 scontext=unconfined_u:system_r:mysqld_safe_t:s0 tcontext=system_u:object_r:etc_runtime_t:s0 tclass=file type=SYSCALL msg=audit(1300000099.293:43425): arch=x86_64 syscall=open success=yes exit=ESRCH a0=3170b5cd39 a1=0 a2=1b6 a3=2 items=0 ppid=5054 pid=5108 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm=date exe=/bin/date subj=unconfined_u:system_r:mysqld_safe_t:s0 key=(null) Hash: date,mysqld_safe_t,etc_runtime_t,file,read audit2allow #============= mysqld_safe_t ============== allow mysqld_safe_t etc_runtime_t:file { read open }; audit2allow -R #============= mysqld_safe_t ============== allow mysqld_safe_t etc_runtime_t:file { read open }; -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
It looks like a dbus service is culprit. But could you try to do # grep -r localtime /etc/init.d/
I would also look as ps -eZ | grep initrc_t grep locale /usr/libexec/ -R | wc -l 104 We need to have an idea of what process is modifying the localtime grep localtime `grep Exec /usr/share/dbus-1/system-services/* | cut -f 2 -d"=" | cut -d" " -f 1 | sort -u` Might give you an indicator of a dbus service that could be mucking around with it. Then we could make sure we have SELinux labels for each.
$ grep -r localtime /etc/init.d/ /etc/init.d/avahi-daemon: if [ -s /etc/localtime ]; then /etc/init.d/avahi-daemon: cp -fp /etc/localtime /etc/avahi/etc >/dev/null 2>&1 $ ps -eZ | grep initrc_t system_u:system_r:initrc_t:s0 2040 ? 00:00:33 tunnel system_u:system_r:initrc_t:s0 7389 ? 00:00:00 sleep $ sudo grep locale /usr/libexec/ -R | wc -l 85 -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Pavel can you think of any app that you have run that could have changed the localtime ?
Only KDE applet I think. I've check "Set date and time automatically" -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Ngo, is the KDE Applet modifying the /etc/localtime, if so, how does it do it? via dbus?
The dateandtime KCM (KDE Configuration Module, i.e. System Settings module): https://projects.kde.org/projects/kde/kdebase/kde-workspace/repository/revisions/master/show/kcontrol/dateandtime does indeed touch /etc/localtime, and it uses KAuth, which indeed uses D-Bus activation for the privilege escalation (and PolicyKit for verifying authorization). In case that's useful, the executable being activated is /usr/libexec/kde4/kcmdatetimehelper and the D-Bus service name is org.kde.kcontrol.kcmclock (with User=root).
So, can you use the above information to make this work in the SELinux policy? Is there anything we can or should do in kdebase-workspace (which doesn't involve rewriting the whole way KAuth works)?
Oh, and if this helps, this is the code used by the D-Bus-activated helper to set the timezone: https://projects.kde.org/projects/kde/kdebase/kde-workspace/repository/revisions/master/entry/kcontrol/dateandtime/helper.cpp#L166
(In reply to comment #13) > So, can you use the above information to make this work in the SELinux policy? > Is there anything we can or should do in kdebase-workspace (which doesn't > involve rewriting the whole way KAuth works)? We need to add a policy for /usr/libexec/kde4/kcmdatetimehelper
Well and it looks like a new policy will be needed also for others -rwxr-xr-x. root root system_u:object_r:bin_t:s0 /usr/libexec/kde4/backlighthelper -rwxr-xr-x. root root system_u:object_r:bin_t:s0 /usr/libexec/kde4/fontinst_helper -rwxr-xr-x. root root system_u:object_r:bin_t:s0 /usr/libexec/kde4/kcmkdmhelper -rwxr-xr-x. root root system_u:object_r:bin_t:s0 /usr/libexec/kde4/kcmremotewidgetshelper -rwxr-xr-x. root root system_u:object_r:bin_t:s0 /usr/libexec/kde4/ksysguardprocesslist_helper
I am trying to treat kcmdatetimehelper with gnomeclock_t policy and it works with some changes pretty good. Pavel, good catch.
Yes I would combine them when possible. I will happy to get rid of this avc, happens quite often.
Fixed in selinux-policy-3.9.7-34.fc14