9. Authorizations and Privileges

Version 0.5, 2009-Feb-13

In order to understand the design of security in NWAM, we need to first understand the overall architecture of NWAM.

In the current NWAM design, we break the code into five functional parts:

netcfgd is the daemon which controls the repository where we save all our network configurations. nwamcfg, the GUI, and nwamd will send request to netcfgd to access the repository via the library, libnwam. nwamd is the policy engine, which will receive system events, configure the network, and read network configuration. The GUI and nwamcfg are configuration tools that can be used to view and modify network configuration. They will also refresh the nwam service to apply new configuration when needed.

With some understanding of the overall architecture of NWAM, we can discuss the security design of each part one by one.

9.1 NWAM-related Authorizations and Profiles

The NWAM Phase 0.5 ( PSARC 2008/482) project introduced the solaris.network.autoconf authorization. This project will provide more granularity for this authorization by introducing:

These authorizations will be registered in auth_attr(4).

NWAM Phase 0.5 also introduced a profile, "Network Autoconf", which was assigned the solaris.network.autoconf authorization. This profile is assigned to the "Console User" and "Network Management" profiles in prof_attr(4). The "Network Autoconf" profile will be updated to include all three of these new authorizations; any profiles which include the "Network Autoconf" profile will therefore continue to have equivalent authorizations.

9.2 nwamcfg and the GUI

The NWAM GUI will have three components, which will not be privileged. They will be granted authorizations, depending on how they are launched and what they need to do. The three components are:

9.3 netcfgd

We will create uid 'netcfg' for this daemon to run as; we will also create group 'netadm', which will include both netcfg and dladm. Additionally, the permissions of /etc/dladm/secobj.conf will be changed to 660. Thus, without special authorizations or privileges, netcfgd will be able to create security objects. Note that the file permissions come into play because we will be using libdladm to create secure objects, rather than pfexec'ing the dladm command. Exec attributes exist such that appropriately authorized users actually run the dladm command as user dladm, and thus have permission to modify /etc/dladm/secobj.conf, which currently has permissions 600 and is owned by user dladm.

netcfgd will check for the following authorizations when it receives requests via libnwam (so, it needs proc_audit privilege for auditing):

9.4 nwamd

We will create uid 'netadm' for this daemon to run as. Uid 'netadm' also belongs to the group 'netadm' we created for netcfgd. User netadm will be assigned the "Network Management" profile, which contains most of, if not all, the authorizations and privileges needed to apply network configurations.

There may be some authorizations and/or privileges missing from this profile; missing auths will be added to the "Network Management" profile as needed during implementation.

nwamd will check for the solaris.network.autoconf.refresh authorization when it receives request to reload and reapply configuration from repository. So, it needs proc_audit privilege for auditing.

Finally, any user-provided scripts which are run by nwamd will be pfexec'd.

Revision History

Revision Date Changes
0.1 2008-Apr-15 initial draft, plus minor text edits
0.2 2008-Apr-25 modify uid/gid for netcfgd and nwamd
0.3 2008-Apr-30 update GUI info and Console User description based on Darren's feedback; add some explanation regarding file ownership
0.4 2008-Oct-01 tweak auth details to take into account phase 0.5 changes
0.5 2009-Feb-13 Design review feedback; more implementation changes