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

gregat_private

On Mon, Aug 26, 2002 at 09:41:43AM -0700, Crispin Cowan wrote:
> 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 :)

No, please don't overengineer.

> 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.

Ok, that's not even relevant to this argument.  When people realized
that the current scheduler had problems, based on larger loads, and
bigger boxes, they fixed it.  

> 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).

I don't understand why you are calling this "polling".  Every module is
allowed to make it's own decision, that's not polling.  Polling is the
terminolgy for accessing hardware (vs. interrupts), and as NAPI has
proven, polling is much better in some high-load situations :)

> 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. 

No, write the code to _need_ this, then come back and ask for the
feature.  Again, don't overengineer.

> 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. 

The policies for OWLSM are already able to be turned on and off at
config time.

> 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.

But LIDS does not use sys_security, and SELinux does an end-run around
it anyway.  SubDomain has not been released, so I can't comment on that.

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

But what kind of speed is needed for the call to disable a specific
option for a specific program.  Once at startup for that program.
Again, don't try to optimize something that you haven't even measured :)

thanks,

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