Rainer Orth wrote: > 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>
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. > > 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. > > 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. >> 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. > >> 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. > >> 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. Okay, happy to. > >> 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. > > 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. -- blu "Mark my words, nanotechnology is going to be huge!" ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom
