Description of problem: When symlinks are used in /etc/ntp/crypto directory, ntpd is not allowed to read the keys. This is a common practice supported by ntp-keygen tool. Another problem is with the SHM driver which uses a shared memory segment to exchange data with another process providing a reference clock. Version-Release number of selected component (if applicable): selinux-policy-3.5.13-38.fc10.noarch Additional info: type=AVC msg=audit(1232012982.634:11832): avc: denied { ipc_owner } for pid=28153 comm="ntpd" capability=15 scontext=unconfined_u:system_r:ntpd_t:s0 tcontext=unconfined_u:system_r:ntpd_t:s0 tclass=capability type=AVC msg=audit(1232012982.634:11832): avc: denied { unix_read unix_write } for pid=28153 comm="ntpd" key=1314148400 scontext=unconfined_u:system_r:ntpd_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=shm type=AVC msg=audit(1232012982.634:11832): avc: denied { associate } for pid=28153 comm="ntpd" key=1314148400 scontext=unconfined_u:system_r:ntpd_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=shm type=AVC msg=audit(1232012982.634:11833): avc: denied { read write } for pid=28153 comm="ntpd" key=1314148400 scontext=unconfined_u:system_r:ntpd_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=shm type=AVC msg=audit(1232012982.634:11833): avc: denied { read write } for pid=28153 comm="ntpd" path=2F535953563465353435303330202864656C6574656429 dev=tmpfs ino=104103939 scontext=unconfined_u:system_r:ntpd_t:s0 tcontext=unconfined_u:object_r:user_tmpfs_t:s0 tclass=file type=AVC msg=audit(1232012982.636:11834): avc: denied { read } for pid=28153 comm="ntpd" name="ntpkey_host_localhost" dev=sda1 ino=1924562 scontext=unconfined_u:system_r:ntpd_t:s0 tcontext=unconfined_u:object_r:ntpd_key_t:s0 tclass=lnk_file audit2allow is suggesting: #============= ntpd_t ============== allow ntpd_t ntpd_key_t:lnk_file read; allow ntpd_t self:capability ipc_owner; allow ntpd_t unconfined_t:shm { unix_read read write unix_write associate }; allow ntpd_t user_tmpfs_t:file { read write };
Seems the reference clock is running as unconfined_t which is probably not correct and is just he way it is currently setup. When you run the system via init scripts what are the AVC's you are seeing?
Miroslav, these seem fine to add. allow ntpd_t ntpd_key_t:lnk_file read; allow ntpd_t self:capability ipc_owner; These are wrong, since they indicate ntpd trying to talk to a process started by a user. allow ntpd_t unconfined_t:shm { unix_read read write unix_write associate }; allow ntpd_t user_tmpfs_t:file { read write };
After removing the segments with ipcrm and starting ntpd before gpsd, I'm getting only the lnk_file denial. When ntpd is started after gpsd, there are also: allow ntpd_t initrc_t:shm { unix_read read write unix_write associate }; allow ntpd_t self:capability ipc_owner; I think it's ok to require ntpd to be started first.
I think it would be best to write some policy for gpsd. Does gpsd use some other mechanism to communicate with gpsd? Or are they not communicating if the gpsd is not running first?
They are communicating only through shm and they both try to create the segments at start, so normally the order doesn't matter.
So in one case ntp creates the shared memory, and since gpsd is an unconfined process it can write to it?
Yes, that's how I think it works. If gpsd creates the segment, ntpd will just get permission denied when shmget() is called and complain to syslog.
Miroslav Grepl, do you think you could write some policy for gpsd? Too many Miroslavs. :^)
Fixed in selinux-policy-3.5.13-49.fc10
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping