Brian Utterback <brian.utterback at sun.com> writes:
I'm sorry for chiming in so late (even after the case was closed), but I've
been terribly busy all week.
There are a couple of issues I noticed when we founded the ntp project back
in 2006 and that I'd like to see addressed by this case:
> 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>
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.
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.
> 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.
> 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.
> 4.0 Interfaces
> (see
> http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/ for
> details)
> 4.1 Exported Interfaces
>
> Interface Name Classification Comments
> --------------------------- -------------------
> ---------------------------
> SUNWntpr Uncomitted Root package
> SUNWntpu Uncomitted /usr package
> /etc/inet/ntp.conf Uncomitted Configuration file
> /usr/lib/inet/ntpd Uncomitted NTP daemon
> /usr/lib/inet/ntp-wait Project Private
> /usr/sbin/ntpdate Volatile
> /usr/sbin/ntptrace Volatile
> /usr/sbin/ntpq Uncomitted
> /usr/sbin/ntpdc Volatile
> /usr/sbin/ntp-keygen Uncomitted Crypto key gen utility.
> /usr/sbin/ntptime Volatile Kernel NTP state utility.
> /usr/share/doc/ntp Uncommitted Location for html docs
> /usr/share/doc/ntp/* Volatile Contents of HTML docs.
I think the FMRI should be listed here as well.
> 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.
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?
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University
