SECURITY
Access to objects is controlled via the system security routines.
These routines operate on security attributes. Security attributes apply to an object and control
who has access to that object.
- oz_knl_secattr_fromname - extracts security attributes from an object's name string
- oz_sys_secattr_str2bin - convert a security attributes string to binary form
- oz_sys_secattr_bin2str - convert a security attributes binary buffer to string
- oz_knl_secattr_validate - validate security attributes binary buffer
- oz_knl_secattr_create - create security attributes object from binary buffer
- oz_knl_secattr_increfc - increment/decrement security attributes object reference count
- oz_knl_secattr_getsize - get size of binary buffer for a security attributes object
- oz_knl_secattr_getbuff - get address of binary buffer for a security attributes object
Security attribute strings have the form <id>=<acc>+<acc>+...,<id>=<acc>+<acc>+..., where
<id> is an identifier number (you make up for uniqueness), and <acc> is a type of access to be
granted to that identifier number (like look, read and write).
These routines operate on security keys. Security keys apply to an thread and control what the thread
can access.
- oz_sys_seckeys_str2bin - convert a security keys string to binary form
- oz_sys_seckeys_bin2str - convert a security keys binary buffer to string
- oz_knl_seckeys_create - create security keys object from binary buffer
- oz_knl_seckeys_increfc - increment/decrement security keys object reference count
- oz_knl_seckeys_getsize - get size of binary buffer for a security keys object
- oz_knl_seckeys_getbuff - get address of binary buffer for a security keys object
- oz_knl_seckeys_differ - tell if two security keys objects are different
Security keys strings are just a comma separated list of identifier numbers.
These routines apply a set of keys to a set of attributes:
- oz_knl_security_getsecaccmsk - get mask of accesses allowed to an object by a set of keys
- oz_knl_security_check - see if a particular set of accesses is allowed to an object by a set of keys
Now the design of these routines is such that they are the only ones that know about the contents of those
strings, binary buffers and the objects themselves. So you could re-write just these routines if you wanted
to have a simple uid/gid scheme instead of this more general acl paradigm.
All objects directly accessible to user mode have security attributes to control who can access them.
- disk files
- device units
- i/o channels
- event flags
- images
- logical names and tables
- processes
- sections
- threads
- jobs
- users (the in-memory control block)
Threads have these additional security related structures:
- default create security attributes - when a thread creates an object,
the object gets these security attributes unless otherwise specified
- security keys - these determine what the thread can access
User blocks have this additional security related structure:
- Authorized security keys - a thread can only select either this entire
set or a subset when changing its keys, it cannot give a thread more than
what is listed here
When a user logs in, the oz_util_logon.oz image is activated as part of the system
process (it runs with full access to anything). It reads the user's username and
password, then gets the user's security keys and attributes from the password file.
Then it creates the user block with the security attributes and saves a copy of the
security keys there too (as the authorized keys). Finally, it creates a job and
spawn a process under that user block to run the cli, giving it the security keys,
security attributes, and default creation security attributes from the password
file.
A thread can change its (or any thread it has write access to) security keys, but it
can't give it more than what is in the calling thread's user block's authorized keys.
A thread can change any security keys (of an object it has write access to) to anything
it wants, it is just not advisable to change them to something that prohibits it from
writing that object in the future, but it is possible this may be desirable in some
situations.
By default, objects are created by the calling thread's default creation security
attributes. If other attributes are desired, some objects have a routine to directly
change the attributes. Most objects can also have their security attributes specified
by placing (security_attributes) on the end of their name. Objects that
support this are:
- disk files
- event flags
- logical names and tables
- processes
- threads
- jobs
When the object is created, the (security_attributes) is stripped off the end
of the name and parsed, then the object is created with the specified attributes. The
(security_attributes) string does not become part of the object's name. So for
example, you could tell the system to create file common.log(5=look+read+write,6=look+read+write),
and the file would be named just common.log, and threads with either key 5 or 6
(or both) would be able to look at, read and write that file.