dynamic security-context transition avoidance

David Collier-Brown davec-b at rogers.com
Tue Nov 2 14:03:10 GMT 2004


On Mon, Nov 01, 2004 at 10:23:10AM -0600, Darrel Goeddel wrote:
>> We are looking at a well-defined (via the policy) set of 
>> available type transitions.  Note that you can also specify a one-way 
>> dynamic transition as well (type1_t can dynamically transition to type2_t, 
>> but type2_t has no dynamic transitions available).  This will allow a 
>> daemon process to initialize itself with one set of access rights (bind 
>> ports, read conf files, etc.), and then lock itself into a domain with less 
>> access rights for the duration of its execution.  

Luke Kenneth Casson Leighton <lkcl at lkcl.net> wrote:
| in smbd's case, however, that would be detrimental: the flexibility 
| of being able to transition back again [to type2_t] is actually a
| necessity. it might even be convenient to go through a "third" type:
|
| type1_t: access to samba configuration files [only!] seteuid: 0
| type2_t: access to user files [only!] seteuid: NNNN
| type3_t: access to pretty much nothing (except that needed for cleanup
|          operations)

    Contrarily, one could have the samba config
file (or database) access read-only, and access
to log-files write-only in both the initial
(type1_t) and the user (type2_t) security context.

    This is what is usually done with mandatory access
controls (MAC) in a B2 environment, with the explicit
intention that the application running in the
security context ("compartment") will have exactly
the minimum privilege to do it's work, and no more.
This avoids multiple changes of security context,
and thus the overheads of changing. or fork/execing.

    In non-secure environments, the appropriate file
descriptors for conf files and logs can be opened, 
then passed across exec to a less-privileged child.  
That's a common way of approximating least
privilege when using C2 Unix. 

    And of course, in utterly insecure Unix, one opens
all the appropriate files and then calls 
setuid(unprivileged user), putting all the security
in the source code, as is done now (;-))

    The first two approaches might be sufficient for Samba's
needs, although Samba may be implicitly assuming the third.

--dave (former B2 Multics person) c-b
-- 
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
davecb at spamcop.net           |                      -- Mark Twain


More information about the samba-technical mailing list