Re: Stacking - anyone care how to report module id's?

crispinat_private

David Wagner wrote:

>Greg KH  wrote:
>  
>
>>Then lets deal with that problem when those modules crawl out into the
>>light.
>>    
>>
>Is it going to be any easier to change the interface later?
>It seems like if we're going to change the interface, now is the time.
>(Of course, it seems to be an open question whether there is any
>need to change the interface.)
>
Exactly: if there is going to be a need to change the interface, and we 
know about it now, then changing it now instead of later saves a lot of 
effort and confusion. So lets discuss it on its merrits, instead of 
shoving it aside just 'cause the train hasn't hit us yet :)

Greg makes an interesting point on performance. While I believe that 
most modules will be stacked with something like Capabilities and/or 
OWLSM, the likely case is going to be that only one of those modules 
(the big policy engine) is going to use sys_security(). Furthermore, the 
total number of modules stacked into a kernel is likely to also be small 
(single digit). The amount of time the Stacker module spends polling is 
going to be fairly small.

On the other hand, it is this kind of thinking that gave the Linux 
kernel a scheduler that linearly scanned the process ready list, and had 
to be upgraded when Linux went into the big time. It is also this 
polling business that I am calling "ugly". IMHO, this kind of polling is 
only called for if the results of the poll are going to change between 
one scan and the next (e.g. polling the ready status of I/O hardware).

Greg is correct that there is no code that uses this feature, but that's 
tautological: there is no such code because the feature doesn't exist. 
Imagining that scenario is not hard. Suppose that OWLSM grows more 
policies (I have a student considering adding the "no ptrace for root" 
policy to OWLSM). Suppose that the list of "cute" policies that OWLSM 
grows so large that people want the ability to turn some of them off. 
Now suppose that you want to do this at run-time, i.e. when running this 
application (e.g. Courier mail server) disable that policy (e.g. 
hard-link following). Now we have OWLSM wanting to use sys_security, and 
share it with the SELinux/LIDS/SubDomain big-ass policy engine.

Now we have a situation where using the facility is not just plausible, 
but IMHO probable.

I can see the advantages of this interface change pretty clearly. Talk 
to me about costs. Does it confound something in the kernel 
implementation? Does it cause some other interface weirdness (e.g. 
Stacker really *does* need to poll the modules dynamically)?

Crispin

-- 
Crispin Cowan, Ph.D.
Chief Scientist, WireX                      http://wirex.com/~crispin/
Security Hardened Linux Distribution:       http://immunix.org
Available for purchase: http://wirex.com/Products/Immunix/purchase.html

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module