Messages in this thread | | | Subject | Re: LSM: Basic module stacking infrastructure for security-next-Acked | From | Tetsuo Handa <> | Date | Sun, 17 May 2015 12:53:55 +0900 |
| |
Casey Schaufler wrote: > > I would like to propose revival of security_task_alloc()/security_task_free() > > hooks. I have several single function modules which want to use these hooks. > > > > 4 years ago, I wrote > > http://osdn.jp/projects/akari/scm/svn/blobs/head/branches/uuid4.c > > which is targeted for restricting qemu processes managed via libvirtd process > > with operations in case bugs like VENOM: QEMU vulnerability (CVE-2015-3456) > > are discovered, without making system administrators' heads explode by > > enforcing SELinux. When isolating processes, use of per "struct task_struct" > > blob saves a lot of unnecessary duplication of per "struct cred" blob. > > > > Another module which want to use security_task_alloc()/security_task_free() > > is kportreserve, which does not need to distinguish users but wants to cache > > current thread's executable path. In general, my LSM modules try to distinguish > > not users but processes. Therefore, per "struct task_struct" blob is convenient > > for me. > > > > I could not afford proposing this kind of single function modules for mainline > > at that time. But now, if we wish to accept this kind of modules, I can update > > them and propose for mainline. (If we wish to keep this kind of modules away in > > order to avoid getting security/ directory bloated, I'm OK with only exporting > > security_hook_heads; I'll continue managing as out-of-tree LSM kernel modules.) > > > > If security_task_alloc()/security_task_free() come back (and optionally > > "void *security" in "struct task_struct" also comes back), we can run > > {SELinux,Smack,AppArmor}+TOMOYO now, for what TOMOYO is designed to use as > > security blob is "struct task_struct"->security than "struct cred"->security. > > > > Can I again propose security_task_alloc()/security_task_free() hooks for > > these single function modules and TOMOYO? > > Although I agree with you that it makes more sense to hang task data > off of the task structure than off of the cred structure I don't like > the notion of having both. I wasn't heavily involved in the cred split > (and was not then and not now a fan of it) and missed the discussion > about why the security blob is included in the cred. But, that's where > it ended up. I would have no objection to moving the blob from the cred > to the task, although I expect there are reasons for it to remain > where it is.
My understanding is that "struct cred" was introduced in order to allow switching all user-related attributes atomically, and "struct cred"->security was introduced because it was one of user-related attributes which should be switched among with other user-related attributes. Also, subjective / objective creds distinction was introduced in order to allow overriding these user-related attributes without affecting inter-process operations.
> > For now at least, I propose that we leave the security blob in the cred.
We can't move "struct cred"->security back to "struct task_struct"->security because SELinux wants to switch all user-related attributes atomically. But TOMOYO can't utilize "struct cred"->security well because it is not allowed to modify "struct cred"->security when TOMOYO wants to use it as per "struct task_struct" attributes.
Yama uses security_task_free() but does not need security_task_alloc() because Yama does not need to inherit per "struct task_struct" entry to fork()ed process. But TOMOYO needs security_task_alloc() to inherit it. Even without reviving "struct task_struct"->security , TOMOYO can manage like Yama's "struct ptrace_relation" if security_task_alloc() is available.
> I will be proposing mechanisms for dealing with that pesky "void *security" > shortly. During the time I've been working on stacking I've identified > a veritable plethora of ways to address the issue. I am putting together > a menu of options and a set of arguments to help guide an open debate on > which suits the current state and direction of the kernel best.
| |