From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Serge E. Hallyn" Subject: Re: [PATCH 3/5] cr: add generic LSM c/r support Date: Sun, 30 Aug 2009 08:58:00 -0500 Message-ID: <20090830135800.GC14699@hallyn.com> References: <20090828210041.GA27878@us.ibm.com> <20090828210417.GC28048@us.ibm.com> <4A98AEDE.1000105@schaufler-ca.com> <20090829224147.GA12549@hallyn.com> <4A99BC58.9040205@schaufler-ca.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <4A99BC58.9040205@schaufler-ca.com> Sender: linux-security-module-owner@vger.kernel.org To: Casey Schaufler Cc: "Serge E. Hallyn" , Oren Laadan , Linux Containers , linux-security-module@vger.kernel.org, SELinux , "Eric W. Biederman" , Stephen Smalley , James Morris , David Howells , Alexey Dobriyan List-Id: containers.vger.kernel.org Quoting Casey Schaufler (casey@schaufler-ca.com): > Serge E. Hallyn wrote: > > Quoting Casey Schaufler (casey@schaufler-ca.com): > >> But each can be expressed as a context, can't it? > >> > > > > A set of contexts (root_u:root_r:root_t:::system_u:system_r\ > > :system_t::...). > > > > There would be a problem if it were stored as a more > > structured type, and if the ->restore handler wanted to > > re-create an actual task_security_struct, ipc_security_struct, > > etc. So the last paragraph in the patch intro was just trying to > > explain why the intermediate layer, storing a generic string on > > the c/r object hash, needs to be there. The thing that is > > not possible is to place the actual void *security or a struct > > task_security_struct on the objhash. > > > > Right. Now why do you need a set of contexts? Because for SELinux, for instance, when checkpointing a security context for a task, we want to checkpoint the actual context, the fscreate context, the sockcreate context, keycreate context, and the task create (exec_create) context. > > ... > > > > > >>> + /* str will be alloc'ed for us by the LSM. We will free it when > >>> + * we clear out our hashtable */ > >>> > >>> > >> Why do you think that you need a copy? Sure, SELinux always gives you > >> a copy, but Smack keeps "contexts" around and making a copy is not only > >> unnecessary, but wasteful. If you free the "context" with the appropriate > >> call (security_release_secctx) you will get the "free allocated memory" > >> behavior desired by SELinux and the "do nothing" behavior of Smack. For > >> free, assuming that you also fix your Smack hook so that it works in the > >> way Smack deems "Correct". > >> > > > > Hmm, that should be doable. Mind you these are not the same as > > secctx's returned by secid_to_secctx. > > Now why is that? If they are different things, what are they? > > What is the difference between a secctx and a context? > I got a bit confused because the word "context" has been > used to refer to the thing represented by a secctx for a > long time. I know, I know, I should come up with a better name. But while an selinux context would be root_u:root_r:root_t the blob I have to checkpoint for a task would perhaps be root_u:root_r:root_t:::null:::null::null:::user_u:serge_r:serge_t:::null thanks, -serge From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from msux-gh1-uea02.nsa.gov (msux-gh1-uea02.nsa.gov [63.239.67.2]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id n7UDe28H007555 for ; Sun, 30 Aug 2009 09:40:02 -0400 Received: from hrndva-omtalb.mail.rr.com (localhost [127.0.0.1]) by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id n7UDfGWJ001767 for ; Sun, 30 Aug 2009 13:41:16 GMT Date: Sun, 30 Aug 2009 08:58:00 -0500 From: "Serge E. Hallyn" To: Casey Schaufler Cc: "Serge E. Hallyn" , Oren Laadan , Linux Containers , linux-security-module@vger.kernel.org, SELinux , "Eric W. Biederman" , Stephen Smalley , James Morris , David Howells , Alexey Dobriyan Subject: Re: [PATCH 3/5] cr: add generic LSM c/r support Message-ID: <20090830135800.GC14699@hallyn.com> References: <20090828210041.GA27878@us.ibm.com> <20090828210417.GC28048@us.ibm.com> <4A98AEDE.1000105@schaufler-ca.com> <20090829224147.GA12549@hallyn.com> <4A99BC58.9040205@schaufler-ca.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <4A99BC58.9040205@schaufler-ca.com> Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov Quoting Casey Schaufler (casey@schaufler-ca.com): > Serge E. Hallyn wrote: > > Quoting Casey Schaufler (casey@schaufler-ca.com): > >> But each can be expressed as a context, can't it? > >> > > > > A set of contexts (root_u:root_r:root_t:::system_u:system_r\ > > :system_t::...). > > > > There would be a problem if it were stored as a more > > structured type, and if the ->restore handler wanted to > > re-create an actual task_security_struct, ipc_security_struct, > > etc. So the last paragraph in the patch intro was just trying to > > explain why the intermediate layer, storing a generic string on > > the c/r object hash, needs to be there. The thing that is > > not possible is to place the actual void *security or a struct > > task_security_struct on the objhash. > > > > Right. Now why do you need a set of contexts? Because for SELinux, for instance, when checkpointing a security context for a task, we want to checkpoint the actual context, the fscreate context, the sockcreate context, keycreate context, and the task create (exec_create) context. > > ... > > > > > >>> + /* str will be alloc'ed for us by the LSM. We will free it when > >>> + * we clear out our hashtable */ > >>> > >>> > >> Why do you think that you need a copy? Sure, SELinux always gives you > >> a copy, but Smack keeps "contexts" around and making a copy is not only > >> unnecessary, but wasteful. If you free the "context" with the appropriate > >> call (security_release_secctx) you will get the "free allocated memory" > >> behavior desired by SELinux and the "do nothing" behavior of Smack. For > >> free, assuming that you also fix your Smack hook so that it works in the > >> way Smack deems "Correct". > >> > > > > Hmm, that should be doable. Mind you these are not the same as > > secctx's returned by secid_to_secctx. > > Now why is that? If they are different things, what are they? > > What is the difference between a secctx and a context? > I got a bit confused because the word "context" has been > used to refer to the thing represented by a secctx for a > long time. I know, I know, I should come up with a better name. But while an selinux context would be root_u:root_r:root_t the blob I have to checkpoint for a task would perhaps be root_u:root_r:root_t:::null:::null::null:::user_u:serge_r:serge_t:::null thanks, -serge -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.