Stephen Smalley wrote: > On Thu, 2008-10-30 at 13:16 +0900, KaiGai Kohei wrote: > >> Hi, >> >> I got a question on the secure os users mailing-list in Japan. >> He said that he is interested in sVirt patches but not good at the way >> to apply the security policy of SELinux on userspace object manager, so >> it makes him hesitate to comment for the patches. >> >> We know great manpages are provided yet, but a structured documentation >> to implement SELinux aware userspace object managers is not well known. >> It is not unclear whether it should be included within README, or not. >> >> However, an official guidance for developers should be considered. >> >> Any comment? >> > > The intent was that these papers would serve as such a reference, > although they don't necessarily go into the level of detail an > implementer might want and the interfaces have of course changed over > time: > http://www.nsa.gov/selinux/papers/gconf07-abs.cfm > http://www.nsa.gov/selinux/papers/xorg07-abs.cfm > http://www.nsa.gov/selinux/papers/radac07-abs.cfm > > I started work on such a paper last year but it fell by the wayside. Here's a summary of it: How to Write a Userspace Object Manager 1. Decide what classes and permissions your object manager will be enforcing control over. These could already exist in policy, or if your object manager provides its own service a new set of classes and permissions will be needed. This is a difficult step because trade-offs can be made: two "different" actions on an object could be represented by different security classes for the two objects, different permissions on the same object type, or different types on the same object with the same permission. Choose a set of object classses and permissions and be prepared for changes as you go. 2. Figure out how your objects will be labeled. Who are the subjects? What type transitions will be made to label each object? Will some objects be lableled directly (not through a type transition)? Are some objects lableled by name? Will some objects be polyinstantiated? Each object needs to be labeled, so there either needs to be space inside the object to store the label (via some opaque security field or user data field) or the SELinux code will need to store and manage labels itself. 3. Hook the SELinux code into the object manager so that it will gain control when: a) The program starts up, so the AVC can be initialized. You'll need to set selinux callbacks with selinux_set_callback(3), establish a mapping from names to numbers for your security classes and permissions with selinux_set_mapping(3), initialize the AVC with avc_open(3) and a label handle with selabel_open(3) if you're using the file contexts or a similar string-to-name mapping, look up the "unlabeled" context with security_get_initial_context(3), and anything else that needs to be done to get the userspace object manager set up and running. b) Objects are created and destroyed, so the object can be labeled properly. There are compute_create() and compute_member() functions that mirror the kernel interfaces and which work on both SID's -- avc_compute_create(3), avc_compute_member(3) or security context strings directly -- security_compute_create(3), security_compute_member(3). A name lookup can be performed with selabel_lookup(3). SID's (security_id_t pointers) are reference counted and need to be managed with sidput() and sidget() to prevent memory leaks. c) Security decisions are made, so the policy can be queried. avc_compute_create(3) and security_compute_av(3) are the key functions here. 4. Figure out how the SELinux code will be configured. If you have a mapping from names to contexts this can be either kept in a configuration file or a new backend for it could be added to libselinux. There are various ancillary options such as permissive mode, and handle_unknown behavior which can be configured in the userspace AVC; this could be exposed to the user through conf file options or command line parameters. -- Eamon Walsh <ewalsh@xxxxxxxxxxxxx> National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
