[ntp:hackers] NTP Development Snapshot 4.2.5p208 Released

Brian Utterback brian.utterback at sun.com
Sun Aug 30 18:15:13 UTC 2009



Dave Hart wrote:
> On Sun, Aug 30, 2009 at 4:45 PM, Brian Utterback wrote:
>> Overwriting the existing file is something that is highly dangerous and
>> probably ought not to be allowed at all and to make it so simple to do by
>> mistake is just not a good design.
> 
> For some people, overwriting the existing configuration file is the
> only option that's interesting, as they would like to delegate ntpd
> administration to someone who does not have any other access to the
> host to replace files manually.  Without a shorthand for the startup
> configuration file path, someone intending to replace it but without
> access to the host would have to know or guess the startup
> configuration filename.

Reasonable. But the ability to overwrite the file should be opt-in, 
and the option must be something more than a single character.
> 
>> There are two things to consider that make this doubly dangerous. One, ntpq
>> remembers your key entries after they are entered. Two, saveconfig does not
>> validate its flags.
> 
> If you have an idea for better validation of arguments, please share.

Well, the obvious one is to not allow more arguments on the line.

> 
>> So, if you are in a ntpq session and have already
>> entered the proper key, it will not ask you again when you run saveconfig.
>> And if you happen to type
>>
>> "saveconfig . /conffile"
>>
>> instead of
>>
>> "saveconfig ./conffile"
>>
>> then you have just overwritten the origiunal ntp.conf file.
> 
> I am not sure why you'd be trying to write to ntpd's current directory
> rather than a specified path.  Assuming there's a good reason, why
> would you include "./" when leaving it off is equivalent?  We could
> discourage this habit by rejecting saveconfig arguments beginning with
> "." aside from "." alone.

How would the user that is unfamiliar know that ./ is not needed? Many 
people just type ./ out of habit when they mean the current directory. 
If you have to have a token that means "the current config file", then 
  it shouldn't include a character that is legal part of a path.

Furthermore, I notice that while  ntpd will not overwrite existing 
files, it returns that the write succeeded. This doesn't sound wise, 
since the remote admin may think that the current config is written 
somewhere when it isn't.

The ability to create a file owned by root at any path is not safe. 
This feature needs more work.



> 
>> If you simply have to have this feature, I would prefer that there was an
>> "enable confoverwrite" option that could not be changed remotely and
>> defaults to disabled.
> 
> I don't have to have this feature.  I was thinking of Steve's
> delegated ntpd administrator case and "." seemed a logical invalid
> filename to use for the purpose.  I chafe at the concept of
> special-case disabling of remote management of any configuration file
> knob.  If we did have an "enable confoverwrite" or "enable
> saveconfigoverwrite" knob to prevent overwriting the startup file or
> any file, respectively, and it defaulted to off, why shouldn't the
> operator be permitted to decide to enable it at runtime?  If you don't
> want remote management, don't configure authentication to enable it,
> or use "restrict ... nomodify".

Because modifying the persistent state of the service is a whole 
different thing than allowing administrative access. Not to mention 
the possibility of privilege elevation becomes a whole lot more likely 
with the ability to write a file like that.

> 
>> During testing, I also noticed that the config file that saveconfig saves
>> does not include "includefile" directives. This makes it even worse, since
>> the resulting config file is not functionally equivalent to the existing
>> file.
> 
> But does it include the directives pulled from included files?  If so,
> it's working as designed.  It is not supposed to spit out the
> identical text that was fed in, but it is supposed to spit out a
> functional equivalent.

Oh, I understand that, but it eliminates a whole class of possible 
delegated administrative solutions. For instance, allowing a dhcp 
agent to write to a file with a list of servers it got from dhcp is a 
lot easier if it doesn't have to worry about all the other commands 
that might be in there. And removing also.

The point about the include is that being able to overwrite the config 
file is a whole lot less safe if you can't guarantee that the file is 
functionally equivalent when you are done.

> 
> Cheers,
> Dave Hart

-- 
blu

It's bad civic hygiene to build technologies that could someday be
used to facilitate a police state. - Bruce Schneier
----------------------------------------------------------------------
Brian Utterback - Solaris RPE, Sun Microsystems, Inc.
Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom


More information about the hackers mailing list