> -----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?
> > >
> > > ---
> > > ntp.if | 28 ++++++++++++++++++++++------
> > > 1 file changed, 22 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/ntp.if b/ntp.if
> > > index 00c7620..a6fe5b7 100644
> > > --- a/ntp.if
> > > +++ b/ntp.if
> > > @@ -177,6 +177,27 @@ interface(`ntp_rw_shm',`
> > > fs_search_tmpfs($1)
> > > ')
> > >
> > > +########################################
> > > +## <summary>
> > > +## Send and receive messages from
> > > +## ntp over dbus.
> > > +## </summary>
> > > +## <param name="domain">
> > > +## <summary>
> > > +## Domain allowed access.
> > > +## </summary>
> > > +## </param>
> > > +#
> > > +interface(`ntp_dbus_chat',`
> > > + gen_require(`
> > > + type ntpd_t;
> > > + class dbus send_msg;
> > > + ')
> > > +
> > > + allow $1 ntpd_t:dbus send_msg;
> > > + allow ntpd_t $1:dbus send_msg;
> > > +')
> > > +
> > > ########################################
> > > ## <summary>
> > > ## All of the rules required to
> > > @@ -225,11 +246,6 @@ interface(`ntp_admin',`
> > > ntp_run($1, $2)
> > >
> > > ifdef(`init_systemd',`
> > > - gen_require(`
> > > - class dbus send_msg;
> > > - ')
> > > -
> > > - allow $1 ntpd_t:dbus send_msg;
> > > - allow ntpd_t $1:dbus send_msg;
> > > + ntp_dbus_chat($1)
> > > ')
> > > ')
> > > --
> > > 2.14.3
> >
> > > _______________________________________________
> > > 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
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.
--
Chris PeBenito
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)
>
> --
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20171226/34a6ee92/attachment.bin
> -----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