From: dsugar@tresys.com (David Sugar) Date: Tue, 2 Jan 2018 21:44:46 +0000 Subject: [refpolicy] [PATCH 1/1] Add interface for ntp_dbus_chat In-Reply-To: <20171226113058.GA356@julius.enp8s0.d30> References: <20171220154037.GA25507@julius.enp8s0.d30> <85fe7bc8-b8cf-217d-bbed-cbf78c75857c@ieee.org> <20171226113058.GA356@julius.enp8s0.d30> Message-ID: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com > -----Original Message----- > From: refpolicy-bounces at oss.tresys.com [mailto:refpolicy- > bounces at oss.tresys.com] On Behalf Of Dominick Grift via refpolicy > Sent: Tuesday, December 26, 2017 6:31 AM > To: refpolicy at oss.tresys.com > Subject: Re: [refpolicy] [PATCH 1/1] Add interface for ntp_dbus_chat > > On Tue, Dec 26, 2017 at 05:24:26AM -0500, Chris PeBenito via refpolicy > wrote: > > On 12/20/2017 01:28 PM, David Sugar via refpolicy wrote: > > > > > > > > >> -----Original Message----- > > >> From: David Sugar > > >> Sent: Wednesday, December 20, 2017 1:10 PM > > >> To: refpolicy at oss.tresys.com > > >> Subject: RE: [refpolicy] [PATCH 1/1] Add interface for > > >> ntp_dbus_chat > > >> > > >>> -----Original Message----- > > >>> From: refpolicy-bounces at oss.tresys.com [mailto:refpolicy- > > >>> bounces at oss.tresys.com] On Behalf Of Dominick Grift via refpolicy > > >>> Sent: Wednesday, December 20, 2017 10:41 AM > > >>> To: refpolicy at oss.tresys.com > > >>> Subject: Re: [refpolicy] [PATCH 1/1] Add interface for > > >>> ntp_dbus_chat > > >>> > > >>> On Tue, Dec 19, 2017 at 09:01:35PM +0000, David Sugar via > > >>> refpolicy > > >>> wrote: > > >>>> I'm seeing dbus send_msg denials when using timedatectl. This > > >>>> adds > > >>> interface to allow the communication. > > >>>> > > >>>> type=USER_AVC msg=audit(1513693376.372:155): pid=667 uid=81 > > >>> auid=4294967295 ses=4294967295 > > >>> subj=system_u:system_r:system_dbusd_t:s0- > > >>> s0:c0.c1023 msg='avc: denied { send_msg } for msgtype=method_call > > >>> interface=org.freedesktop.timedate1 member=SetNTP > > >>> dest=org.freedesktop.timedate1 spid=1037 tpid=1038 > > >>> scontext=staff_u:sysadm_r:applyconfig_t:s0-s0:c0.c1023 > > >>> tcontext=system_u:system_r:ntpd_t:s0 tclass=dbus > > >>> exe="/usr/bin/dbus- daemon" sauid=81 hostname=? addr=? terminal=?' > > >>> > > >>> Ideally systemd-timedated shouldnt be associated with the ntpd_t > > >>> domain in the first place, but i guess that ship has sailed > > >>> > > >> > > >> Yes, it appears that systemd-timedated is labeled ntpd_exec_t in > ntp.fc. > > >> It probably could be changed, I don't know how many ntp files > > >> systemd- timedated is actually accessing. Or how much a change > > >> like that would break. It is my understanding that > > >> systemd-timedated does a subset of the ntpd features. At some > level it makes sense. > > >> > > > > > > And looking more closely I am seeing some denials when starting > systemd-timedated (unrelated to the dbus stuff). Maybe it is worth > exploring moving away from this domain for this process. Do we know the > history of the change to label systemd-timedaed as ntpd_exec_t and if > moving it will cause major problems for someone? > > > > The change was made back in April, submittted by Rusell Coker. A look > > of the diff since then indicates rules added for systemd-time* is > > almost entirely enclosed in the init_systemd blocks. It would be easy > > to reverse course on this decision, though it's unclear to me if it's > > warranted. > > I would argue that there may be a case to run timesyncd in ntpd_t as > timesync implements the client functionality of ntp servers. Meaning > that they are pretty similar in terms of permissions except for binding > sockets to ports, also its pretty unlikely that one has a ntp server > running if one has timesync running (because that implies that the user > only needs the client bits) > > timedate(d) is a different story in my vieuw though. This thing uses > dbus, is used to enable an ntp client implementation such as timesync or > timedatex. Eventhough it does need some time related permissions, its > pretty different > > on top of that it seems that there are scenarios where one may end up > both timedated as well as ntp server processes running on the same > system, unlike timesyncd and both ntp server processes (i suppose) > Looking at our overall approach it looks like chronyd might be more what we want to use for our current usecase. I am going to change my efforts and try chronyd rather than systemd-timedated. At this point this patch can be ignored. I have some patches for chronyd that I will submit (in the not too distant future) once I'm sure chronyd is doing what we want. > > > > -- > > Chris PeBenito > > _______________________________________________ > > refpolicy mailing list > > refpolicy at oss.tresys.com > > http://oss.tresys.com/mailman/listinfo/refpolicy > > -- > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 > Dominick Grift