Setting up a system to use security types

QNX SDP8.0QNX OS System Security GuideAPIConfiguration

Before you can generate or apply a security policy, you need to specify a type for each process in your system.

The following abbreviated startup script is for QNX OS on a VMWare virtual machine and is similar to one used by many BSPs. It is the first thing that runs in a system, executed directly by the OS kernel and process manager (procnto) acting as a rudimentary shell:

  [+script] startup-script = {
    
  slogger2
  waitfor /dev/slog
  
  # Some common servers
  pipe
  random
  waitfor /dev/random
  
  devb-eide blk cache=64M,auto=partition,vnode=2000,ncache=2000,noatime,commit=low
  waitfor /dev/hd0
  
  . . .
  
  reopen /dev/con1
  
  ksh /proc/boot/start-system
  display_msg "---> Starting shell"
  [+session] ksh -l &
  }

To create a system that supports a security policy, you need to start every process that is still active when startup is complete with the name of a type. Currently, this type determines which abilities the process has and where in the path space it can attach itself. The simplest way to start a process with a type is to use on with the -T option. Alternatively, you can use SLM, which recognizes types.

The following startup script rewrites the example with a meaningful type name for each service. You can use any name you like, but policies are easier to work with if the name is based on the name of the associated service. Because each service has unique security requirements, you should have a different type for each service. In addition, this example uses -U and -u to start each service with a different user ID:

[+script] startup-script = {
 
    # Push the security policy
    secpolpush
 
    on -T slogger2_t slogger2 -U 20
    waitfor /dev/slog
 
    # Some common servers
    on -u 21 -T pipe_t pipe
    on -u 22 -T random_t random
    waitfor /dev/random
 
    on -T devb_t -u 23 devb-eide 
        lk cache=64M,auto=partition,vnode=2000,ncache=2000,noatime,commit=low
    waitfor /dev/hd0
 
    . . .
 
    ksh /proc/boot/start-system
    echo "---> Starting shell"
    on -d -t /dev/con1 -T console_t ksh -l
 
    reopen /dev/con1
}

This revised script includes the following changes:

It runs services with a non-root user ID in two different ways. For pipe, random, and devb, it starts the service with its intended user. For slogger2, it starts the service as root and then specifies a user for the process to switch to later.

You can use user names instead of numeric user IDs, but make sure that the user names are present in /etc/password.
Note:
Some processes drop privileges by calling secpol_transition_type(). Start these processes with their user ID (using on with -u), instead of starting them as root and switching them later by passing an appropriate option. (When you generate a policy, this behavior is indicated by the creation of a type_run_t type.)
If a process does not transition type, but accepts an option to change user ID, start it as root but specify options that switch the ID later.
For a process that does not transition type and can’t change its user ID, start it as non-root.
To identify processes that switch types using secpol_transition_type(), run the following command after you start your system:
```
pidin -f a_n
```

It changes how it provides a shell on the console. In most cases, BSPs use the following command to provide a shell:
```
[+session] ksh -l &
```
The revised script uses the following command, which has a similar effect but runs the shell as its own type, console_t:
```
on -d -t /dev/con1 -T console_t ksh -l
```

It switches the system from one operating according to pre-QNX Neutrino 7.0 rules to one that supports and enforces security policies using the following command:
```
secpolpush
```

Although these changes do all the basic work necessary to start a system using a security policy, because there is no security policy, if you try to boot you get a series of errors. For the initial steps for adding a security policy, see Booting the system for the first time.

Page updated: March 05, 2025