Privilege Control

Updated: April 19, 2023

Like other components that run on QNX Neutrino, the privileged operations required by io-sock and networking components are protected by process manager abilities. These abilities are configured either directly by the components themselves, or, preferably, via security policies that are defined by the system integrator.

For a list of these abilities, see Abilities in the “Privilege control” section of the System Security Guide.

For an overview of process manager abilities, see:

After io-sock is up and running, you can use a sysctl command to have io-sock drop the extra privileges it needed during startup and have it run with a reduced set of privileges for normal operation.

Dropping privileges for systems with a security policy

For systems that use security policies, you should run io-sock as a non-root user and then, after it has fully started, set qnx.sec.transition. (For io-pkt, this command was qnx.kern.secpol.) The io-sock manager continues to run with the same uid it was started with, but switches to a different security type, most likely one with fewer privileges. For example:

sysctl qnx.sec.transition=1

The sysctl design requires you to pass in a non-zero value; passing in 1 is recommended because future releases could assign specific meanings to other parameter values.

Dropping privileges for systems without a security policy

If your system does not use security policies, you should run io-sock as root and then use qnx.sec.droproot to have it switch to the specified user. For example:

sysctl qnx.sec.droproot=value

where value specifies a user, one or more groups, or both, using one of the following formats:

The default is 99:99,120. In the second format, the primary group is the one specified for user_name in /etc/passwd.

(For io-pkt, this command switched io-pkt to a user that was specified when it was started.)

Abilities for networking operations

In addition to general abilities, io-sock sets up and uses the following abilities to govern specific networking operations:

Value Description
network/privport Controls the ability to bind a privileged port (low port number)
network/rawsocket Controls the ability to open a raw socket that uses Internet protocol family definitions provided by netinet/in.h; required by utilities such as ping
network/reuseport Controls the ability to connect to a socket on the same port as another connection created by another user and to which the IP_BINDMULTI or SO_REUSEPORT socket options are applied
network/ipsec Controls who can administer IPsec
network/admin Controls the abilities that are not provided by another ability, but a networking component generally requires (e.g., create and bring up interfaces, set the socket manager state via sysctl); required by utilities such as dhclient

For a system that has a security policy, you incorporate additional abilities by adding them to the policy, a task that you can automate using secpolgenerate.

For systems that don't use security policies, you cannot use qnx.sec.droproot to specify additional abilities to retain if your networking driver needs them (the io-pkt implementation of qnx.sec.droproot allows this). Instead, you can specify any extra abilities when you start io-sock. For example:

on -A nonroot,allow,interrupt io-sock -d em

For more information, see the entry for on in the Utility Reference.

Controlling access to packet filtering

Access to packet filtering (PF) and Berkeley Packet Filter (BPF) is controlled via filesystem ACLs on the /dev/pf and /dev/bpf devices. For more information, see “Access Control Lists (ACLs)” in the QNX Neutrino User's Guide.