Brian Utterback writes:
> >> 3.3 Services and the /etc Directory
> > [...]
> >> Does the service manifests method context grant rights above that
> >> of the noaccess user and basic privilege set?
> >> [ ] Yes - ARC review required
> >> [x] No
> >
> > This is wrong: the ntp.xml file in the case materials has
> >
> > <method_context>
> > <method_credential
> > user='root'
> > group='root'
> >
> > privileges='proc_fork,proc_exec,net_privaddr,proc_lock_memory,sys_time'
> > />
> > </method_context>
>
> Okay. Fair enough. It should have been Yes. But this is more
> restrictive than the current implementation, since xntpd currently
> runs as root with all privs.
True enough, but probably only because nobody did the necessary analysis to
restrict the privilege set.
> > Since ntp is a network facing service, I suggest to handle this
> > differently: don't use root here, but a special ntp user and group. I
> > don't think daemon can be used since the ntpd potentially needs to read
> > ntp keying material in /etc/inet (or whereever ntp.conf says) which must
> > not be readable by other daemon processes and needs to write to ntp.drift
> > and ntpstats in /var/ntp. root (as suggested here) has read and write
> > access to too many files, so I strongly prefer the special uid/gid instead.
> >
> > If /var/ntp needs to be writable by ntp:ntp after the upgrade, this needs
> > to handled there.
>
> While I am not adverse to having an ntp user and group, I have
> discussed this with a few people off and on, and there doesn't seem to
> be a consensus as to whether or not it is worth it. It will definitely
> make administration more difficult, because of the requirements placed
> on the key files. Also, in discussion with Nico just now, we agreed to
> have the pid for ntp written to /var/run, which will be more
> complicated if the daemon runs as anything other than root or daemon.
> Having a ntp user will definitely break the reading of existing keyfiles.
Right, but given that ntpd is a network facing daemon which needs to be
able to read and write files, I'd opt to make it as secure as
possible, which means not running as root if at all possible (which it is:
I tried this back in 2006 when I made a first cut at an SMF service for
ntp4). Since the pid file is not really necessary at in the presence of
SMF, I'd either omit it completely or have it in /var/ntp which needs to be
writable by the ntpd daemon user (ntp in my proposal) anyway. I think it
is important to get this right at first shot: forcing users to deal with
two migrations (xntpd -> ntpd both run as root and later ntpd run as root
-> ntpd run as ntp:ntp) should be avoided. I don't think we really are in
a hurry to integrate as quickly as possible.
> > I'm not sure how to best handle the privilege set: use
> > basic,!file_link_any,!proc_info,!proc_session,... or just list the
> > necessary privileges? That may be a code review issue, though.
> >
> > One should even consider those privileges which are only needed at startup,
> > but this is something to pursue within the NTP project, not in this ARC
> > case.
> >
>
> Correct. I would prefer to deal with restricting the privs and making
> NTP priv aware as a follow-on project in concert with the NTP
> community. It is clear that the privs in the proposed NTPv4 are an
> improvement on the current xntpd service. I would like to take this
> one step at a time.
Agreed: this is certainly only a refinement (and probably not an issue for
PSARC anyway since the daemon needs to start off with the larger privilege
set).
> >> 3.4 Security
> >> 3.4.1 Secure By Default
> > [...]
> >> Are inbound network communications denied by default?
> >> [x] Yes
> >> [ ] No - ARC review required
> >> [ ] N/A
> >
> > This is only true if the ntp service is completely disabled.
>
> That was my interpretation, i.e. that this attribute was met by the
> fact that the service is off by default.
Ok. Maybe we can get a clarification from the authors of the FOSS checklist?
> >> Are passwords stored within the file system for the component?
> >> [x] Yes
> >> [ ] No - continue to next section (section 3.4.6)
> >>
> >> If yes are the permissions on the file such to protect exposing the
> >> password(s)?
> >> [x] Yes
> >> [ ] No - ARC review required
> >> The passwords are stored in the /etc/inet/ntp.keys file, which is not
> >> delivered. This
> >> file is administrator created. The passwords in question authenticate
> >> NTP servers and
> >> clients to one another and not individual users. It is up to the
> >> administrator to
> >> set permissions appropriately when the file is created.
> >
> > I think we should provide some guidelines for that, especially if ntpd is
> > run as ntp:ntp.
>
> Perhaps. Again, this is no worse than the current implementation, and
> I think it is much better. The docs are all delivered in
> /usr/share/doc/ntp.
Fine. ntp4 is certainly a strict improvement over xntp, but if we can
improve the Solaris integration at integration, we should.
> >> 4.2 Imported Interfaces
> >> Interface Name Classification Comments
> >> ----------------------------------- -----------
> >> --------------------------
> > [...]
> >> ntp_adjtime,ntp_gettime syscalls Project Private
> >
> > Seems unlikely given that there are ntp_adjtime(2) and ntp_gettime(2) man
> > pages available. I don't know which case introduced them, and the man
> > pages don's state interface stability.
>
> True. The original implementation was done by Jan Brittenson, and he
> stated to me that he intended these interfaces to be project private.
> I also expressed a bit of dismay. But I am not changing them anyway.
> On the other hand, I know of no other consumers than NTP.
Probably not, but we should check this. Perhaps you can dig up the
original PSARC case which proposed those? This might become important in
the future if the nanokernel code is ported to Solaris: such a port would
break interface compatiblity, and would be much easier if they really were
Project Private.
> > I don't see this in the FOSS checklist, but perhaps the use of RBAC
> > authorizations should be explicitly part of this case. The ntp.xml
> > manifest currently has
> >
> > <property_group name='general' type='framework'>
> > <!-- to start stop ntpd -->
> > <propval name='action_authorization' type='astring'
> > value='solaris.system.date' />
> > </property_group>
> >
> > Perhaps we need separate authorizations for changing service properties
> > compared to starting and stopping the service?
>
> I am not sure that I see an advantage.
My take here is that it should be possible for an operator to stop and
restart the ntp service without being able to reconfigure it at the same
time. /etc/security/auth_attr regularly has separate solaris.smf.manage.*
and solaris.smf.value.* authorizations. I think it would be wise to follow
this lead. In fact, the `Service Management Facility (SMF) usage' policy
http://www.opensolaris.org/os/community/arc/policies/SMF-policy/
states
Guidance For Delivery of SMF Services
[...]
* Services must provide service related RBAC authorizations, as
appropriate, by providing service specific values for the action_authorization,
modify_authorization, value_authorization, and read_authorization of property
groups. See smf_security(5).
These authorizations must follow the form of "solaris.smf.{manage,
modify, value, read}.service" respectively. These authorizations must be
delivered into an appropriate Rights profile, either new or existing.
Note that I won't be able to follow up on any replies since I'll be away
until Monday.
Rainer
-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University
