Security

allow_core_dumps = boolean

no

Core dumps are a bad thing. This value should only be set to yes if a problem with the server is being debugged.

allow_vulnerable_openssl = boolean

no

Allows the server to start with versions of OpenSSL known to have critical vulnerabilities.

This check is based on the version number reported by libssl and may not reflect patches applied to libssl by distribution maintainers.

chroot = filename

/path/to/chroot/directory

The directory where the server does chroot.

The chroot process is done very early in the course of starting the server. After the chroot process has been performed, the server switches to the user configuration item listed in this document (which MUST be specified). If group is specified, the server switches to that group, too. Any other groups listed for the specified user in /etc/group are also added as part of this process.

The current working directory (chdir / cd) is left outside of the chroot process until all of the modules have been initialized. This allows the raddb directory to be left outside of the chroot process. Once the modules have been initialized, the server does a chdir to ${logdir}. Proceeding in this manner means that it should be impossible to break out of the chroot.

To avoid any security issues related to this use of chdir, simply ensure that the raddb directory is inside of the chroot and run cd raddb BEFORE starting the server.

If the server is statically linked, then the only files that have to exist in the chroot are ${run_dir} and ${logdir}. If you do the "cd raddb" as discussed above, then the "raddb" directory has to be inside of the chroot directory, too.

group = string

radius

Radiusd is run as the number of this group.

If commented out, the server will run as the group that started it. In order to change to a different group, the server MUST be started as root (or have root privileges).

It is STRONGLY recommended that the server be run with as few permissions as possible. That is, if shadow passwords are not being used, then the group items below should be set to radius.

NOTE that some kernels refuse to setgid(group) when the value of (unsigned)group is above 60000; don’t use group nobody on these systems!

On systems with shadow passwords, group = shadow might need to be set for the server to be able to read the shadow password file. If users can be authenticated while in debug mode, but not while in daemon mode, then it may be that the debugging mode server is running as a user that can read the shadow info and that the user listed below cannot.

The server will also try to use initgroups to read /etc/groups. It will join all groups where user is a member. This can allow for some finer-grained access controls.

max_attributes = integer

200

The maximum number of attributes permitted in a RADIUS packet. Packets that have MORE than this number of attributes in them will be dropped.

If this number is set too low, then no RADIUS packets will be accepted.

If this number is set too high, then an attacker may be able to send a small number of packets that will cause the server to use all available memory on the machine.

Setting this number to 0 means "allow any number of attributes".

reject_delay = integer

1

When sending an Access-Reject, a delay of a few seconds may occur. This delay may help slow down a DoS attack. The delay also helps to slow down any potential use of brute-force to crack a user’s password.

Setting this number to 0 means "send rejects immediately"

If this number is set higher than cleanup_delay, then the rejects will be sent at cleanup_delay time, when the request is deleted from the internal cache of requests.

Useful ranges: 1 to 5

status_server = boolean

yes

Whether or not the server will respond to Status-Server requests.

When sent a Status-Server message, the server responds with an Access-Accept or Accounting-Response packet.

This is mainly useful for administrators who want to "ping" the server without adding test users or creating fake accounting packets.

It’s also useful when an NAS marks a RADIUS server "dead". The NAS can periodically "ping" the server with a Status-Server packet. If the server responds, it must be alive, and the NAS can start using it for real requests.

See also raddb/sites-available/status

user = string

radius

Radiusd is run as the name of this user.

If commented out, the server will run as the user that started it. In order to change to a different user, the server MUST be started as root (or have root privileges).

It is STRONGLY recommended that the server be run with as few permissions as possible. That is, if shadow passwords are not being used, then the user items below should be set to radius.

NOTE that some kernels refuse to setgid(group) when the value of (unsigned)group is above 60000; don’t use group nobody on these systems!

On systems with shadow passwords, group = shadow might need to be set for the server to be able to read the shadow password file. If users can be authenticated while in debug mode, but not while in daemon mode, then it may be that the debugging mode server is running as a user that can read the shadow info and that the user listed below cannot.

The server will also try to use initgroups to read /etc/groups. It will join all groups where user is a member. This can allow for some finer-grained access controls.