Re: How to attach some config info permanently to a object?

From: Chris Wright (chrisat_private)
Date: Fri Jan 24 2003 - 00:57:48 PST

  • Next message: Stephen D. Smalley: "[patch] Sync lsm-2.5 with patches for mainline 2.5"

    * ¶«·½ ó»ÎÄ (phanixat_private) wrote:
    > 
    > Hi!
    > 
    >  I'm working on a MEC(Mandatory Execution Control) module based on
    >  the LSM infrastructure of linux-2.4.19.
    
    Great, looks like you are making nice progress.
    
    >  First, it reads its config file, parse it, extract legal 
    
    You should really do the config file reading and parsing in userspace.
    Then send the processed data to the kernel.  You can use a proc entry,
    a character device, or make your own small ram based filesystem.  The
    last way is the most flexible.
    
    >  conf_list_head-->|(first conf info node)|    |(second conf info node)|
    >                   |Name:/bin/bash        |    |Name:/bin/tcsh         |
    >                   |Logic:list_deny       |    |Logic:list_allow       |
    >                   |binlist:/bin/ping     |    |binlist:/bin/ls        |
    
    If your lists can dynamically change, other than the first load, make sure
    you properly protect list traversal with a lock.
    
    >  Then it tries to attach proper mec config info to every process:
    
    You can lazy update each process as you need to check permission.
    See SELinux's use of task_precondition as an example.
    
    >  lock_kernel();
    >  for_each_task(taskp)
    >    set_task_mec_info(taskp);
    >  unlock_kernel();
    
    you should read_lock(&tasklist_lock) to get protected access to
    tasklist.
    
    >  Here set_task_mec_info() first tries to get the process's full pathname
    >  (for example: /usr/sbin/httpd)
    >  (Currently, I have trouble doing this. Chris told me to use the code
    >   of proc_exe_link. I think that the code of proc_exe_link is just what I 
    > need.
    
    I hadn't realized mmput() is not exported.  This lookup is a last resort
    in my opinion.  The preferred way to label tasks is during fork and
    exec, with the task_* hooks and the binprm_* hooks.  For the case where
    the task was created before the module was initialized, I would
    recommend a lazy update like SELinux does.
    
    >   I tried but when make module_install, depmod said :Unresolved symbol : 
    > mmput .
    
    This function is not exported to modules. As Jan-Erik mentioned, you'd
    need to export the symbol yourself.  Or otherwise convince yourself that
    you always have a valid refcounted task->mm object, and don't refcount.
    You should still grab the mmap_sem for the vma list.
    
    >  Here is the problem:
    >  *** What if any other module uses task's void *security pointer and set it 
    > to 
    >      some other value?( Do I realy need to maintain a hashlist of pid and 
    > confinfo
    >      in the module? )
    
    As mentioned before.  Your module can control whether other LSM modules
    can load.  The register_security() call will only succeed for the first
    security module.  If that is your module, it can be sure not to accept
    mod_reg_security() requests for any module effectively eliminating any
    other security modules from being loaded.
    
    >  *** In a module based on LSM, how to attach some config info permanently 
    > to an
    >      object(for example, from the point a task is forked until it exits)? 
    >      alloc_security() and free_security() seems useless here.
    >  *** In fact, I don't know when do we need to use alloc_securit(),
    >      then set_security(), then free_security().Can anyone give me a 
    > scenario?
    
    During fork you have the opporunity to allocate space needed for the
    security ID that you will attach to it.  The ID is commonly copied from
    the task's parent.  Later, during execve() for example, you can get the
    new executable name from bprm->file->f_dentry/f_vfsmount pair in
    bprm_set_security and assign the new ID.  When the task exits, and its
    parent cleans up, the space allocated for the task's security ID can be
    freed.
    
    cheers,
    -chris
    -- 
    Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net
    _______________________________________________
    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 : Fri Jan 24 2003 - 00:59:25 PST