secpol

Updated: April 19, 2023

Manage the compiled security policy file

Syntax:

secpol [-cdnpqQv] [-i compiled_policy] [-t type] [-a ability] [-f filter]

Runs on:

QNX Neutrino

Options:

-a ability
The ability to use in conjunction with the -f option.
-c
Displays detailed information for each blob in the compiled security policy file. Lists the information for all types. To reduce the information to specific items of interest, use the -f option instead.
-d
Displays the blob list, including the offset for blob data, the amount of data in bytes, the blob type, and the blob name.
-f filter
Dumps blob contents, based on filters. You can filter based on the filter type as well as a type name (use the -t option) or an ability name (use the -a option). You can abbreviate filter names to their first three characters. The filter types are:
  • ability to show data that grants or denies access to the indicated ability
  • all to show all output (equivalent to -c option)
  • capability to show capabilities granted to the indicated type
  • channel to show path space attachments that yield a channel of indicated type
  • connect to show connections the type can make or can be made to that type
  • default to show types that are granted default abilities
  • dynamic to show use of dynamic abilities
  • noinherit to show abilities that are not inherited
  • nonroot to show ability data that affects abilities granted to non-root
  • reference to show all references to indicated type
  • root to show ability data that affects abilities granted to root only
  • settype to show ability data that allows the indicated type to be set
  • unlock to show abilities that are unlocked
-i compiled_policy
The full path to the compiled_policy file. Use this option to specify a non-default path to an additional security file.

Because the security policy file that secures a system may be referenced by multiple components even after it is pushed to procnto, it must be located at /proc/boot/secpol.bin.

-n
Display the type identifiers by their numbers instead of their names.
-p
QNX recommends that you use secpolpush instead of this option.

The -p option pushes the compiled security policy to the microkernel for enforcement. Picks up the security policy compiled as /proc/boot/secpol.bin, unless the -i option overrides it with a different file name.

-q
Quiets the output, if there are no errors.
-Q
Queries the current policy indentifier, which is a 32-bit number. If a policy has been pushed to procmgr, the id of the policy can be queried. If the id has the most significant bit set, the policy is immutable. Otherwise, the policy can be changed.
-t type
Convert the type to id or vice versa. Combine the -t option with the -f option for filtering.
-v
Validate blobs. Use with the -p option to ensure only valid policies are pushed to procmgr. Output from secpol -v lists the blob names and their validity unless suppressed with -q. The secpol utility exits with a status of 1 if a validation error is encountered or 0 if the file is valid.

Description:

The secpol utility is a target-based utility for manipulating binary policy files. Use it to view the contents of a compiled security policy (such as the rules for each type), validate a policy after you have compiled it, and to push the compiled policy into effect.

Note: The PROCMGR_AID_MAC_POLICY ability is required to push the policy.

Without a policy in effect, all type identifiers are zero and processes with the PATHSPACE procmgr ability can attach channels anywhere in the path space. With the policy in effect, processes can only attach in a limited set of locations. Pushing the security policy triggers policy enforcement. It should be one of the first things that you do when you startup your system.

Note: The IFS startup script runs when you boot the board. It is an ideal place for a series of on -T statements. For more information about these statements, refer to the on utility in the Utilities Reference.

Start up resource managers after your push the policy.

See the Security Developers Guide for more information about:
  • how to design a security policy and automate its creation using secpolgenerate
  • the grammar that is used in the uncompiled, text version of the security policy file (generated or manual)
  • how to compile a security policy with the secpolcompile utility
  • best practices for security integration

Example:

This example shows how to use the secpol utility to validate the policy:
secpol -v

This example shows how to push a compiled security policy from /proc/boot/secpol.bin to the microkernel:

secpol -p

Filtering examples, based on a specific policy:

The secpol utility includes a set of filters for viewing contents of a compiled security policy file. Use the -f option to specify a filter by name. These filtering examples are based on the following policy:
attribute priv_port;
ability iofunc/dup;
ability network/bind/privport;
type procnto;
type io_pkt_t, priv_port;
type qconn_t;
type sshd_t;
type fs_nfs3_t, priv_port;
type user_1_t;
type user_2_t;
type root_t;
allow io_pkt_t self : ability {
      nonroot able_create mem_phys:0- priority:255 qnet interrupt:18 iofunc/dup
};
allow_attach io_pkt_t {
         /dev/socket/...
         /dev/crypto     
};
allow priv_port self : ability {
      network/bind/privport
};
allow sshd_t self : ability {
      settypeid:user_1_t,user_2_t
      gain_priv:channel_connect
};
allow sshd_t self : ability {
      fork
      unlock
      noinherit
};
allow sshd_t self : ability {
      spawn
      noinherit
};
allow root_t self : ability {
      default_priv
      -mem_phys
};
allow_attach qconn_t / io_pkt_t;
allow { root_t user_1_t } io_pkt_t:channel connect;
allow user_1_t  io_pkt_t:channel net_connect;
Examples for each type of filter follow, including specific commands and the results of the filtering.
ability
The ability filter displays data that determines if types would be given a named ability, for example, pathspace:
secpol -f ability -a pathspace
The results of the filter indicate that three types have, or potentially have, the pathspace ability. The types io_pkt_t and qconn_t have gained it as a result of allow_attach rules while root_t has it for root only by virtue of having been given default_priv.
SECPOL_BLOB_ABILITIES
io_pkt_t  crc:160665c4
    PATHSPACE allow root non-root inherit lock
qconn_t  crc:8977b760
    PATHSPACE allow root non-root inherit lock
root_t  crc:98da6509
    EOL
capability
The capability filter indicates a specified type's abilities, the paths it can attach channels or create links to and the channels it can connect to over QNET. The following example filters on the user1_t type:
secpol -f capability -t user_1_t
The command yields the following filtered information:
SECPOL_BLOB_ABILITIES
user_1_t  crc:55ffe65b
    SPAWN allow root non-root inherit lock
    FORK allow root non-root inherit lock
    PROT_EXEC allow root non-root inherit lock
    PGRP allow root non-root inherit lock
    MAP_FIXED allow root non-root inherit lock
    RCONSTRAINT allow root non-root inherit lock
    PUBLIC_CHANNEL allow root non-root inherit lock
    RUNSTATE_BURST allow root non-root inherit lock
    XTHREAD_THREADCTL allow root non-root inherit lock
    PROT_WRITE_AND_EXEC allow root non-root inherit lock
    CHANNEL_CONNECT allow root non-root inherit lock subrange 2-2 (io_pkt_t)
    EOL deny root non-root inherit lock
-------------------------------------------------
SECPOL_BLOB_PMA_RULES
-------------------------------------------------
SECPOL_BLOB_QNET
user_1_t can connect to:
    io_pkt_t
channel
Use the channel filter to identify data that allows a channel of a particular type to be created. For example, use the following command to determine how a channel of type io_pkt_t can appear:
secpol -f channel -t io_pkt_t
The command yields the following filtered information, indicating that this channel type can either come from a process of type io_pkt_t attaching to /dev/crypto or anywhere under /dev/socket, or it can result in a process of type qconn_t attaching a channel to / and having its type changed to io_pkt_t:
SECPOL_BLOB_PMA_RULES
allow_attach io_pkt_t /dev/socket/...;
allow_attach io_pkt_t /dev/crypto;
allow_attach qconn_t / io_pkt_t;
connect
Use the connect filter to determine which types are able to connect to a channel of a given type such as io_pkt_t:
secpol -f connect -t io_pkt_t
The command yields the following filtered information, indicating that types user_1_t and root_t can make local connections to a channel of type io_pkt_t, while an incoming QNET connection of type user_1_t can also make a connection.:
SECPOL_BLOB_ABILITIES
user_1_t  crc:55ffe65b
    CHANNEL_CONNECT allow root non-root inherit lock subrange 2-2 (io_pkt_t)
root_t  crc:98da6509
    CHANNEL_CONNECT allow root non-root inherit lock subrange 2-2 (io_pkt_t)
-------------------------------------------------
SECPOL_BLOB_QNET
user_1_t can connect to:
    io_pkt_t
default
Use the default filter to see types that have been granted default abilities to some extent. This means that the abilities are not fully specified by the security policy but depend (for static abilities) on whether procnto gives the ability to root or non-root or (for dynamic abilities) on the parameters passed to a call to procmgr_ability_create.
secpol -f default
In this case, there is only a single type that has been granted default abilities. Although root_t could gain additional abilities through use of default_priv in the policy, it doesn't mean it will necessarily get all of them. In this case, the policy indicates that root_t should get default abilities with the exception of mem_phys:
SECPOL_BLOB_ABILITIES
root_t  crc:98da6509
    EOL
For more information, filter based on the mem_phys ability to see that it is denied:
secpol -f ability -a mem_phys
The command yields the following filtered information:
SECPOL_BLOB_ABILITIES
io_pkt_t  crc:160665c4
    MEM_PHYS allow root non-root inherit lock subrange 0-18446744073709551615
root_t  crc:ba473fd4
    MEM_PHYS deny root non-root inherit lock
dynamic
Use the dynamic filtering option to view abilities created by calling procmgr_ability_create:
secpol -f dynamic
The command yields the following filtered information:
SECPOL_BLOB_ABILITIES
io_pkt_t  crc:160665c4
    iofunc/dup allow root non-root inherit lock
    network/bind/privport deny non-root
    network/bind/privport allow root inherit lock
fs_nfs3_t  crc:7531f7d4
    network/bind/privport deny non-root
    network/bind/privport allow root inherit lock
noinherit
The noinherit filter shows abilities that are not inherited. By default, policies generated by secpolcompile assign abilities that are in turn inherited by child processes. Having abilities not inherited can be better in some cases since it can allow privileged abilities to be dropped when spawning a child. However, it will also cause abilities to become unlocked and if the ability was subject to a subrange, the child process might gain privilege as a result. By using the noinherit filter, you can determine types that might bear scrutiny, for example:
secpol -f noinherit
In this case root_t also shows up as having non-inherited abilities due to its use of default_priv since abilities are by default not-inherited:
SECPOL_BLOB_ABILITIES
sshd_t  crc:f8833bdb
    SPAWN allow root non-root no-inherit lock
    FORK allow root non-root no-inherit
root_t  crc:ba473fd4
    EOL
unlock
The unlock filter shows abilities that could be changed by the process because they are not locked.
secpol -f unlock
The command yields the following filtered information:
SECPOL_BLOB_ABILITIES
sshd_t  crc:f8833bdb
    FORK allow root non-root no-inherit
root_t  crc:b5407a43
    EOL 
nonroot
The nonroot filter shows all abilities that are granted to types when their effective uid is anything other than 0.
secpol -f nonroot 
The command yields the following filtered information:
SECPOL_BLOB_ABILITIES
io_pkt_t  crc:160665c4
    PATHSPACE allow root non-root inherit lock
    MEM_PHYS allow root non-root inherit lock subrange 0-18446744073709551615
    SPAWN allow root non-root inherit lock
    FORK allow root non-root inherit lock
    PROT_EXEC allow root non-root inherit lock
    QNET allow root non-root inherit lock
    INTERRUPT allow root non-root inherit lock subrange 18-18
    PRIORITY allow root non-root inherit lock subrange 255-255
    PGRP allow root non-root inherit lock
    MAP_FIXED allow root non-root inherit lock
    RCONSTRAINT allow root non-root inherit lock
    PUBLIC_CHANNEL allow root non-root inherit lock
    ABLE_CREATE allow root non-root inherit lock
    RUNSTATE_BURST allow root non-root inherit lock
    XTHREAD_THREADCTL allow root non-root inherit lock
    PROT_WRITE_AND_EXEC allow root non-root inherit lock
    iofunc/dup allow root non-root inherit lock
    network/bind/privport deny non-root
    EOL deny root non-root inherit lock
qconn_t  crc:8977b760
    PATHSPACE allow root non-root inherit lock
    SPAWN allow root non-root inherit lock
    FORK allow root non-root inherit lock
    PROT_EXEC allow root non-root inherit lock
    . . .
root
The root filter shows all abilities that are granted to types when their effective uid is 0.
secpol -f root
The command yields the following filtered information:
SECPOL_BLOB_ABILITIES
io_pkt_t  crc:160665c4
    network/bind/privport allow root inherit lock
sshd_t  crc:f8833bdb
    SETTYPEID allow root inherit lock subrange 6-7 (user_1_t,user_2_t)
fs_nfs3_t  crc:7531f7d4
    network/bind/privport allow root inherit lock
settype
The settype filter shows types that can spawn processes with a given type or can set their own type to that type by calling secpol_transition_type(). For example, use the following command to determine who can switch type to user_1_t:
secpol -f settype -t user_1_t
The command yields the following filtered information:
SECPOL_BLOB_ABILITIES
sshd_t  crc:f8833bdb
    SETTYPEID allow root inherit lock subrange 6-7 (user_1_t,user_2_t) 
reference
This example of the reference filter shows all data associated with the io_pkt_t type, including abilities associated with the type, paths the type can connect to, and other types that can connect to channels of the specified type.
secpol -f reference -t io_pkt_t
The command yields the following filtered information:
SECPOL_BLOB_TYPE_MAP
io_pkt_t = 2
-------------------------------------------------
SECPOL_BLOB_ABILITIES
io_pkt_t  crc:160665c4
    PATHSPACE allow root non-root inherit lock
    MEM_PHYS allow root non-root inherit lock subrange 0-18446744073709551615
    SPAWN allow root non-root inherit lock
    FORK allow root non-root inherit lock
    PROT_EXEC allow root non-root inherit lock
    QNET allow root non-root inherit lock
    INTERRUPT allow root non-root inherit lock subrange 18-18
    PRIORITY allow root non-root inherit lock subrange 255-255
    PGRP allow root non-root inherit lock
    MAP_FIXED allow root non-root inherit lock
    RCONSTRAINT allow root non-root inherit lock
    PUBLIC_CHANNEL allow root non-root inherit lock
    ABLE_CREATE allow root non-root inherit lock
    RUNSTATE_BURST allow root non-root inherit lock
    XTHREAD_THREADCTL allow root non-root inherit lock
    PROT_WRITE_AND_EXEC allow root non-root inherit lock
    iofunc/dup allow root non-root inherit lock
    network/bind/privport deny non-root
    network/bind/privport allow root inherit lock
    EOL deny root non-root inherit lock
user_1_t  crc:55ffe65b
    CHANNEL_CONNECT allow root non-root inherit lock subrange 2-2 (io_pkt_t)
root_t  crc:b5407a43
    CHANNEL_CONNECT allow root non-root inherit lock subrange 2-2 (io_pkt_t)
-------------------------------------------------
SECPOL_BLOB_PMA_RULES
allow_attach io_pkt_t /dev/socket/...;
allow_attach io_pkt_t /dev/crypto;
allow_attach qconn_t / io_pkt_t;
-------------------------------------------------
SECPOL_BLOB_QNET
user_1_t can connect to:
    io_pkt_t