new stacker module

From: Serge E. Hallyn (hallyn@private)
Date: Sun Nov 16 2003 - 19:45:14 PST

  • Next message: Chris Wright: "Re: new stacker module"

    At http://www.cs.wm.edu/~hallyn/stacker.patch is a patch against the
    current lsm-2.5 bk tree to implement a new stacker module.  I started
    with David Wheeler's module (thanks :), and updated it to work with the
    2.6 hooks and use sysfs.  Beyond that, I left several features for
    later.  In particular, I'm not dealing with module unloading yet.
    
    The main extension is the ability to stack more than one module needing
    access to kernel security objects.  However it requires a bit of
    cooperation from the stacked modules to do so.  Here's how it works:
    
    insmod stacker_plug.ko
    insmod another module (say dirjail.ko)
    
    dirjail will call mod_reg_security, and get back a return value >= 0.
    This value is it's index into a void ** array allocated by stacker for
    each security object.  (The number of void*'s allocated is 3 by default,
    and can is specified as a max_num_modules module parameter to stacker)
    There seems to be no elegant way to have stacker simply be able to
    allocate this array before any module will use it, so stacker exports a
    set of functions for allocating the security fields.
    
    void ** stacker_alloc_bprm_sec(struct linux_binprm *bprm);
    void ** stacker_alloc_sb_sec(struct super_block *sb);
    void ** stacker_alloc_inode_sec(struct inode *inode);
    void ** stacker_alloc_file_sec(struct file *file);
    void ** stacker_alloc_task_sec(struct task_struct *p);
    void ** stacker_alloc_req_sec(struct open_request *req);
    void ** stacker_alloc_skb_sec(struct sk_buff *skb);
    void ** stacker_alloc_msg_sec(struct msg_msg *msg);
    void ** stacker_alloc_msgqueue_sec(struct msg_queue *msq);
    
    On all the 'free' calls (ie security_ops->skb_free_security),
    stacker calls all the stacked modules' skb_free_security functions,
    then kfree's the actual skb->security field (if not null).
    
    Of course you can use this any way you want.  The way I use it
    is to define two macros, get_security and set_security.
    
    #define get_security(st,p,sectype) ( \
    	p->sectype ? \
    		((void **)p->sectype)[my_index] \
    			: \
    		stacker_alloc_##st##_sec(p)[my_index] \
    )
    
    #define set_security(st,p,sectype,data) ( \
    	p->sectype ? \
    		(((void **)p->sectype)[my_index] = data) \
    			: \
    		(stacker_alloc_##st##_sec(p)[my_index] = data) \
    )
    
    where:
    st = {inode,sb,file,task,bprm,req,skb,msg,msgqueue}
    p = variable name
    sectype = {i_security,s_security,f_security,security}
    data = whatever you want to store.
    
    I've used this to stack dirjail and dte *1, both of which use task
    and inode security fields, and a stacktest module which just
    mucked with the task->security field.
    
    Comments welcome.
    
    -serge
    
    
    *1 Using the dte and dirjail in this patch file, as the bk version of
    dte is still for a previous version of stacker.
    



    This archive was generated by hypermail 2b30 : Sun Nov 16 2003 - 19:46:12 PST