Design scope of a security policy module

From: Henrę Țór Baldursson (henry@f-prot.com)
Date: Mon Nov 04 2002 - 07:22:22 PST

  • Next message: Greg KH: "Re: Design scope of a security policy module"

    	Hello.
    
    	I work for an antivirus company, and we're contemplating using your API
    to do on-access scanning of files on a filesystem. Which is what we
    already do in the Windows environments.
    	I'm not here to debate licensing issues. I'm here rather to investigate
    how extensive the framework is. What the design scope of a security
    policy module should be. For example with regards to access control to
    files, more specifically where the access control verdict depends on the
    content of files, it seems logical to me for the framework to cache
    verdicts in order to reduce resource usage and increase responsiveness
    of the system.
    	When an access control policy, whose only factor is content, is applied
    to a file. That policy should not need to be applied to said file until
    its content changes, or a reasonable amount of time has passed. And I,
    personally, feel that this functionality belongs in the framework rather
    than in something called a "security policy module". 1) Because caching
    verdicts has nothing to do with security, it has to do with reducing
    latency in the framework's design. 2) Because this would prevent people
    from excessively redesigning the wheel and causing code obesity.
    	My questions are: Has/Should this functionality be implemented in the
    framework rather than in security policy modules? What are your opinions
    on the matter?
    
    Best regards,
    Henry.
    
    -- 
    Henrę Țór Baldursson, Linux Developer
    FRISK Software International
    http://www.f-prot.com
    http://aves.f-prot.com
    
    
    
    

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



    This archive was generated by hypermail 2b30 : Mon Nov 04 2002 - 07:23:51 PST