Trusted Solaris Developer's Guide

Releasing an Application

You submit a fully tested and debugged application to the system administrator for application integration. The application can be submitted as a CDE action or software package. If the application uses privilege, the system administrator evaluates (or has someone else evaluate) the application source code and security information you supply with the CDE action or software package to verify the use of privilege does not compromise system security.

Notify the system administrator of new auditing events, audit classes, or X Window System properties your application uses because he or she will need to put them into the correct files. See Chapter 8, Application Auditing and Chapter 14, Trusted X Window System for more information.

Creating a CDE Action

A CDE action is launched from the work space by a user or role and inherits the privileges assigned to it in that user's or role's profile. A CDE action is a set of instructions that work like application macros or programming interfaces to automate desktop tasks such as running applications and opening data files. In the Trusted Solaris environment, applications are started from the work space as CDE actions. How to create a CDE action is fully described in the Common Desktop Environment: Advanced User's and System Administrator's Guide, Part Number: 802-1575-10. SunSoft, a Sun Microsystems, Inc. business, produces the guide.


Note -

When you create a CDE action, always create an f.action rather than an f.exec. An f.exec executes the program as root with all privileges.


The system administrator puts the CDE action into the appropriate profiles and assigns inheritable privileges (if any) to the CDE action. The executable files associated with the CDE action need allowed privileges if the program inherits privileges and might or might not need forced privileges. You should list the inheritable, forced, and allowed, privileges the program uses (if any), indicate the labels at which the application is intended to run, and supply any effective user or group IDs required. The system administrator assigns forced and allowed privileges to the executable file, and assigns inheritable privileges, label ranges, and effective user and group IDs to the CDE action in the profile.

Creating a Software Package

The System V Release 4 application binary interface (ABI) specifies a software distribution model called software packaging that you use to package software for integration by the system administrator. All software distributed using the ABI model is guaranteed to install on all ABI-compliant systems.

When you create the software package, you supply security attribute information in the optional tsolinfo(4) file (described below), which is used in the package installation procedure. This file is optional because default security attributes are assigned during package installation in the event no security attribute information is provided with the package.

Package Files

A package consists of package objects (the files to be installed) and control files (files that control how, when, where, and if the package is installed). Information about packages already installed on the system is stored in the software installation database in /var/sadm/install/contents.

The Solaris operating environment provides the following commands for creating and installing ABI-compliant software packages.

pkginfo(1)

Display software package information. 

pkgparam(1)

Display package parameter values. 

pkgask(1M)

Create a request script. 

installf(1M)

Add an entry to the software installation database. 

removef(1M)

Remove an entry from the software installation database. 

To create a package, you set up the following files:

pkgmk(1) uses pkginfo(4) and prototype(4) to construct a software package. The optional scripts customize the installation and remove packages.

MAC Security Attributes

The tsolinfo(4) file contains entries associated with package objects that require special security attributes. If a package object does not have any tsolinfo entries associated with it, it is assigned a default set of security attributes derived from the file system where the package is finally installed. This file can contain one or more entries per package object in the following format, where all fields in the format are required for each entry.

attribute_name object_name attribute_value

Here is a list of possible attribute names, what they mean, and how to specify them.

Attribute Name 

Description 

Attribute Value 

forced_privs 

Package object forced privileges  

Comma-separated list of privileges. 

allowed_privs 

Package object allowed privileges  

Comma-separated list of privileges. 

public 

Package object is public.  

No attribute value. 

mld 

Package object is a multilevel directory 

No attribute value 

The following example tsolinfo(4) file entries specify security attributes for the sendmail(1M) package objects.

Attribute Name 

Package Object Name 

Attribute value 

mld

var/spool.mail

 

mld

var/mail

 

mld

var/tmp

 

allowed_privs

usr/lib/sendmail

all

forced_privs

usr/lib/sendmail

file_mac_write

label

etc/security/tsol

[admin_high]

Description

Edit Existing Package

To find and edit an existing package, search the software installation database with the grep(1) command. The information returned includes the package name.


% cat /var/sadm/install/contents | grep /usr/lib/object

Once you have the package name, you can find the package definition for that package and edit the tsolinfo(4) file. If no tsolinfo file exists, create one. If you create a tsolinfo file, add it to the prototype file so the pkgmk(1) command can find the tsolinfo file.

Add New Package

To add a new package, refer to the Application Packaging Developer's Guide for the Solaris operating environment for detailed information on creating packages. This section summarizes the concepts and steps.

The following Solaris commands are for creating new software packages.

pkginfo(1)

Display software package information. 

pkgparam(1)

Display package parameter values. 

pkgmk(1)

Create a software package. 

pkgproto(1)

Generate a prototype file for input to pkgmk(1).

pkgtrans(1)

Transfer and/or translate a package. 

The following figure shows the files that you are responsible for creating, the role of the pkgmk(1) command, and the resulting directory structure or package.

Figure A-1 Add New Package

Graphic

Create Required files

  1. Create a pkginfo(4) file using the man page.

  2. Create a prototype(4) file using the man page.

    Use the pkgproto(1) command to generate a prototype(4) file template.

Create Optional Files and Scripts

  1. Create the tsolinfo(4) file using the man page.

    Make sure tsolinfo is listed in the prototype file so that the pkgmk(1) command can find the tsolinfo file.

  2. Create optional package information files as needed.

  3. Create optional packaging scripts as needed.

Create the Package

  1. Run the pkgmk(1) command.

  2. Save the package to storage media

  3. Give the storage media to the system administrator for installation.

Prototype File

You can create a prototype file with any editor. There must be one entry for every package component. The following is a sample prototype file that contains an entry for the tsolinfo file. The tsolinfo file is preceded by the letter i to indicate an information file. The letter f indicates a standard executable or data file. Refer to the prototype(4) man page for more information.

# Package "prototype" file for the bbp device driver.
# Bidirectional Parallel Port Driver for SBus Printer Card.
#
i pkginfo
i request
i copyright
i postinstall
i tsolinfo
f none bbp.kmod 0444 root sys
f none bbp_make_node 0555 root sys
f none bbp_remove_node 0555 root sys