MAC kernel option

[Robert Watson]

On Sun, 18 Sep 2005, Christian S.J. Peron wrote:

> On Sun, Sep 18, 2005 at 01:21:17PM +0100, Robert Watson wrote:
>>
>> For the time being, I think leaving it off by default is the right thing
>> to do.  There are a few performance issues we'll want to consider
>> carefully:
>>
>> (1) Right now, we automatically allocate label storage for four policies
>>     on most system objects if MAC is compiled in.  This isn't a huge
>>     amount of memory (4 pointers plus one flags field), and it is zone
>>     allocated, but this is still a non-trivial overhead.  We don't do this
>>     for mbufs unless requested by an active policy, but it's still
>>      measurable.
>
> How about we introduce MPC_LOADTIME_FLAG_USELABELS which we can use for 
> MAC policies which require the use of labels. This way we conditionally 
> allocate label storage only if a policy which requires them is loaded.

The problem is that "going back later and allocating labels" is a complex 
activity subject to race conditions and various other nasties.

On the other hand, most of our policy modules neatly fall out into two 
categories:

- Policies that don't use labels at all, and can be loaded and unloaded at
   run-time.  I.e., mac_bsdextended, mac_seeotheruids, etc.

- Policies that use labels all over the place, and can only be loaded at
   boot.  I.e., mac_biba, mac_mls, sebsd.

The only policy I've written that tries to use labels with a run-time load 
is mac_partition, which knows that if it sees a '0' in the label slot that 
this means an un-partitioned process.  Do you use vnode labels (etc) for 
mac_chkexec to cache EA data, or just direct EA access?

Robert N M Watson
To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message