* ¶«·½ ó»ÎÄ (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