At today's PSARC I mentioned that OSS would need to deal with
device allocation. After the meeting I chatted a little with
Margot. I thought it would be useful to record the "requirements"
here. And an (my) interpretation of how they apply to this case.
(There are likely also virtualization -- i.e., zone and SunRay requirments
that are independent of device allocation and just related to DAC and
authorization.)
There are a few security requirements that Solaris needs to
fulfill that today only come through the device allocation framework.
IMO, it would be better if they all happened without the need for device
allocation. Some background first. Device allocation has been around
since SunOS 3.5e/4.0 days as a way to fulfill criteria for SunOS/Solaris
evaluations as define in Trusted Computer System Evaluation Criteria (TCSEC,
Orange Book) and all of the successors to todays Common Criteria version 3.
Fulfilling the criteria is in general a good security practice and really
"should" be done everywhere.
The criteria include:
Object Reuse
Discretionary Access Control - DAC
Audit
Authorization
(and for labeled systems such as Solaris Trusted Extensions - TX)
Object Labeling
Object reuse is provided for most objects without resorting to
allocate. For removal media and some things normally provided in
logindevperm, object reuse is provided by allocate. The object reuse
criteria state that before an object (memory, process, disk free space, ...)
is given to a process, it may not have any contents from any previous use.
For things like audio, traditionally state has either been left in the kernel
or the device itself that is there for the next user to access. allocate
provides a "device clean" routine that is run at appropriate times to
reset the state to a default. See $SRC/cmd/allocate/audio_clean.c.
Relative to the OSS project, if last close were to reset the state
to defaults, allocate audio_clean would not be needed.
Discretionary access control criteria state that (in POSIX terms)
only the owner of an object should determine who can access it and in what
way. For file system objects this is done with the POSIX owner/group and
pbits. For system owned devices, some should be given exclusive
ownership/access to the "workstation owner" logged in user. These devices
are handled through logindevperm.
Audit criteria state that when a user accesses something that
user's access should be auditable. This in general is provided for under
the covers by the Solaris Audit subsystem (when configured by the admin).
Since allocate disables logindevperm, it also audits when things under
its control are allocated to and deallocated from a user.
Authorization criteria state that only authorized users may
do certain things. Authorizations come in two forms: implicit and
explicit. A user is implicitly authorized to use a system by having
a user name and password. A user is implicitly authorized to read a
file, base on its owner/group/pbits. With Solaris RBAC certain users
are granted explicit authorization to do certain tasks. allocate extends
those explicit authorizations to which objects under its control a user
may access. In some ways, it might be useful to extend explicit authorization
to logindevperm devices. I've filed RFE 6621332 "consider defining
authorizations for logindevperm items and enforcing them a login time" to
capture that. Tamarack today is authorization driven for the things it
controls. Tamarack also audits when it grants a user access to something
it controls.
Object labeling criteria state that every object in the system
must have a "security" label. In TX this label is generally implicit
for all but removable and print media. There, it is defined by some visual
marking on the media.
My interpretation on how this applies to this case is: we wouldn't
need to allocate audio (for non-TX Solaris) if on last close the state was
reset and if logindevperm enforced authorizations (and possibly audited).
Aside -- Perhaps it's a good time to move logindevperm processing into
pam_open_session and pam_close_session ;-).
In the TX case, allocate would still be needed to provide a way that audio
were available at whatever label the authorized user wished to use it.
Implicitly labeling audio at login time would not meet customer requirements.
Note that there is also a general customer requirement that not every
user have access to audio. When the SS1s first shipped with a microphone,
certain (government) customers required that the microphone port be physically
disabled before they be deployed to users.
HTH,
Gary..
