There was some discussion on the users list with a suggestion by Phil to implement something similar to the Samba project's panic action. That's now been done # panic_action: Command to execute on server fault. # # WARNING: DO NOT SET A PANIC ACTION ON PRODUCTION SERVERS WHICH DOES # WARNING: NOT IMMEDIATELY RETURN. DOING SO MAY PREVENT YOUR SERVER # WARNING: FROM RESTARTING. # # Sets a command which will be executed if the server receives a fatal, # non user generated signal, i.e. SIGSEGV, SIGBUS, SIGABRT or SIGFPE. # # This can be used to start an interactive debugging session so # that information regarding the current state of the server can # be acquired. # # The following string substitutions are available: # - %e The currently executing program e.g. /sbin/radiusd # - %p The PID of the currently executing program e.g. 12345 # # Standard ${} substitutions are also allowed. # # An example panic action for opening an interactive session in GDB would be: #panic_action = "gdb %e %p" # # An example panic action for opening an automated session in GDB would be: #panic_action = "gdb -silent -x ${raddbdir}/panic.gdb %e %p > ${logdir}/gdb.log 2>&1" So getting full backtraces out of the server should now be as simple as uncommenting that bottom panic_action line. With the automated session it should be safe to run on production servers, and will provide useful information about transient faults. Also added support for panic_action to the unittest program, so if any of the unittests fail with a segv you'll get a full GDB backtrace automatically. https://travis-ci.org/FreeRADIUS/freeradius-server/jobs/17651987#L2043 Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On 26 Jan 2014, at 17:27, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
There was some discussion on the users list with a suggestion by Phil to implement something similar to the Samba project's panic action.
That's now been done
# panic_action: Command to execute on server fault. # # WARNING: DO NOT SET A PANIC ACTION ON PRODUCTION SERVERS WHICH DOES # WARNING: NOT IMMEDIATELY RETURN. DOING SO MAY PREVENT YOUR SERVER # WARNING: FROM RESTARTING. # # Sets a command which will be executed if the server receives a fatal, # non user generated signal, i.e. SIGSEGV, SIGBUS, SIGABRT or SIGFPE. # # This can be used to start an interactive debugging session so # that information regarding the current state of the server can # be acquired. # # The following string substitutions are available: # - %e The currently executing program e.g. /sbin/radiusd # - %p The PID of the currently executing program e.g. 12345 # # Standard ${} substitutions are also allowed. # # An example panic action for opening an interactive session in GDB would be: #panic_action = "gdb %e %p" # # An example panic action for opening an automated session in GDB would be: #panic_action = "gdb -silent -x ${raddbdir}/panic.gdb %e %p > ${logdir}/gdb.log 2>&1"
So getting full backtraces out of the server should now be as simple as uncommenting that bottom panic_action line.
With the automated session it should be safe to run on production servers, and will provide useful information about transient faults.
Also added support for panic_action to the unittest program, so if any of the unittests fail with a segv you'll get a full GDB backtrace automatically.
Hm, can anyone see any obvious security issues with having the utilities and server check environmental variables for a PANIC_ACTION? It allows you to be exceptionally lazy... you could just set it in ~/.profile and an interactive debugger session would pop up any time a utility or daemon crashed. Just seems like one of those possibly insecure exploitable things... Maybe only enable it #ifndef NDEBUG then it's off for official releases? and for radiusd only if it was running in foreground mode? Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Arran Cudbard-Bell wrote:
Hm, can anyone see any obvious security issues with having the utilities and server check environmental variables for a PANIC_ACTION?
No. If it's running as a service, the environment is already sanitized. If someone can become root and run radiusd, well... they can edit anything.
It allows you to be exceptionally lazy... you could just set it in ~/.profile and an interactive debugger session would pop up any time a utility or daemon crashed.
That's very useful.
Just seems like one of those possibly insecure exploitable things... Maybe only enable it #ifndef NDEBUG then it's off for official releases? and for radiusd only if it was running in foreground mode?
It's useful in daemon mode too. Just use NDEBUG. Alan DeKok.
participants (2)
-
Alan DeKok -
Arran Cudbard-Bell