Bug 480140 - ntpd not allowed to read symlinked keys and shared memory
ntpd not allowed to read symlinked keys and shared memory
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: Miroslav Grepl
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-15 06:30 EST by Miroslav Lichvar
Modified: 2009-11-18 05:48 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-11-18 05:48:15 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Miroslav Lichvar 2009-01-15 06:30:00 EST
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 };
Comment 1 Daniel Walsh 2009-01-15 10:30:14 EST
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?
Comment 2 Daniel Walsh 2009-01-15 10:31:19 EST
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 };
Comment 3 Miroslav Lichvar 2009-01-15 11:55:42 EST
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.
Comment 4 Daniel Walsh 2009-01-15 13:33:14 EST
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?
Comment 5 Miroslav Lichvar 2009-01-15 14:06:28 EST
They are communicating only through shm and they both try to create the segments at start, so normally the order doesn't matter.
Comment 6 Daniel Walsh 2009-01-15 15:35:02 EST
So in one case ntp creates the shared memory, and since gpsd is an unconfined process it can write to it?
Comment 7 Miroslav Lichvar 2009-01-15 16:02:35 EST
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.
Comment 8 Daniel Walsh 2009-03-02 21:23:17 EST
Miroslav Grepl, do you think you could write some policy for gpsd?

Too many Miroslavs.  :^)
Comment 9 Miroslav Grepl 2009-03-16 13:42:23 EDT
Fixed in selinux-policy-3.5.13-49.fc10
Comment 10 Bug Zapper 2009-11-18 05:45:42 EST
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

Note You need to log in before you can comment on or make changes to this bug.