Hiding GUC variables from non-superusers
Pursuant to prior discussion, I have added a flag to guc.c that marks
certain GUC variables as not to be shown to non-superusers. For the
moment it's just set on variables related to the server's filesystem
layout, such as the recently added data_directory and config_file
variables. But now that we have it, I am wondering if it shouldn't
be set on other potentially security-related variables. For instance,
knowing exactly what logging the DBA is doing or not doing might be of
assistance to a blackhat user. On the other hand, it's a bit pointless
to block viewing of any USERLIMIT variables, since the user can discover
by experimentation what their settings are; and most of the
logging-level variables are USERLIMIT. (Maybe that whole concept is a
bad idea and should be rethought. Why exactly should a non-privileged
user be able to adjust logging level either up or down? Cranking it out
to the max could be seen as a crude form of DOS attack...)
Right now what I have marked are
config_file
data_directory
dynamic_library_path
external_pid_file
hba_file
ident_file
krb_server_keyfile
log_directory
log_filename
preload_libraries
unix_socket_directory
I am strongly tempted to mark "archive_command" as well. Unless we want
to revisit the USERLIMIT idea, there's not anything else I see that
looks worth marking.
Comments, opinions?
regards, tom lane
On Fri, 2004-10-22 at 21:09, Tom Lane wrote:
Pursuant to prior discussion, I have added a flag to guc.c that marks
certain GUC variables as not to be shown to non-superusers. For the
moment it's just set on variables related to the server's filesystem
layout, such as the recently added data_directory and config_file
variables. But now that we have it, I am wondering if it shouldn't
be set on other potentially security-related variables. For instance,
knowing exactly what logging the DBA is doing or not doing might be of
assistance to a blackhat user. On the other hand, it's a bit pointless
to block viewing of any USERLIMIT variables, since the user can discover
by experimentation what their settings are; and most of the
logging-level variables are USERLIMIT. (Maybe that whole concept is a
bad idea and should be rethought. Why exactly should a non-privileged
user be able to adjust logging level either up or down? Cranking it out
to the max could be seen as a crude form of DOS attack...)
Complete agreement. Anything that can't be set should be invisible.
Setting logging high or even checking that logging is set high could be
the precursor to a DoS attack via repeated accesses.
Looking at memory sizes might be a way to spot small, poorly setup
systems.
I am strongly tempted to mark "archive_command" as well. Unless we want
to revisit the USERLIMIT idea, there's not anything else I see that
looks worth marking.
Yes, definitely archive_command should be.
I'd still prefer a master GUC for archive_mode = on, which would be user
visible. ......I'll wear you down ....we've got years yet, ;-)
--
Best Regards, Simon Riggs