Prev |  | Next

## 20. I want to keep the drivers and upsd in their own security domains. How can this be accomplished?

Using a few role accounts and a common group, you can limit access to resources such as the serial port(s) leading to the UPS hardware.

This is just an example. Change the values to suit your systems.

- Create a user called nutdev and another called nutsrv. Put them both in a group called nut.
- Change the owner of any serial ports that will be used to nutdev, and set the mode to 0600. Then change the ownership of your state directory (usually /var/state/ups) to nutdev.nut.

For my development system this yields the following /dev entries:

    0 crw-------   1 nutdev   tty        4,  64 Sep  3 17:11 /dev/ttyS0
    0 crw-------   1 nutdev   tty        4,  65 Sep  3 17:11 /dev/ttyS1

- Switch to root, then start the drivers:

      # upsdrvctl -u nutdev start

- The listing for /var/state/ups then looks like this:

      4 drwxrwx---   2 nutdev   nut          4096 Aug 20 18:37 .
      4 drwxr-xr-x   4 root     root         4096 May 14 21:20 ..
      4 srw-rw----   1 nutdev   nut             0 Sep  3 17:10 apcsmart-ups1
      4 srw-rw----   1 nutdev   nut             0 Sep  3 17:10 blazer_ser-ups2

You may have to remove old socket or state files first if you are changing to this security scheme from an older version. The drivers will create new files with the right owners and modes.

Note that `/var/state/ups` is group writable since `upsd` will place the `upsd.pid` file here by default.

You may have to change the groups of `upsd.conf` and `upsd.users` to make them readable to the NUT `upsd` program. These files should not be owned nor writable by `nutsrv`, since someone could compromise the daemon and change the config files. Instead, put `nutsrv` in a group (`nut` in this example), then make the files owned by `root.nut`, with POSIX bits mode `0640`.

Once the config files are ready, start upsd:

    :; upsd -u nutsrv

Check your syslog to be sure everything’s happy, then be sure to update your startup scripts so it uses this procedure on your next boot.

If you like this, you’ll probably also find the chroot(2) process to be useful and interesting. See security.txt for more details.

Prev |  | Next
| Home |