From: Casey Schaufler <casey@schaufler-ca.com> To: "Serge E. Hallyn" <serge@hallyn.com> Cc: "Serge E. Hallyn" <serue@us.ibm.com>, Oren Laadan <orenl@cs.columbia.edu>, Linux Containers <containers@lists.osdl.org>, linux-security-module@vger.kernel.org, SELinux <selinux@tycho.nsa.gov>, "Eric W. Biederman" <ebiederm@xmission.com>, Stephen Smalley <sds@epoch.ncsc.mil>, James Morris <jmorris@namei.org>, David Howells <dhowells@redhat.com>, Alexey Dobriyan <adobriyan@gmail.com>, Casey Schaufler <casey@schaufler-ca.com> Subject: Re: [PATCH 3/5] cr: add generic LSM c/r support Date: Sat, 29 Aug 2009 16:40:08 -0700 [thread overview] Message-ID: <4A99BC58.9040205@schaufler-ca.com> (raw) In-Reply-To: <20090829224147.GA12549@hallyn.com> Serge E. Hallyn wrote: > Quoting Casey Schaufler (casey@schaufler-ca.com): > >> Serge E. Hallyn wrote: >> > ... > >>> Briefly, all security fields must be exported by the LSM as a simple >>> null-terminated string. They are checkpointed through the >>> security_checkpoint_obj() helper, because we must pass it an extra >>> sectype field. Splitting SECURITY_OBJ_SEC into one type per object >>> type would not work because, in Smack, one void* security is used for >>> all object types. >>> >> I do not understand why the Smack behavior is a limitation here. >> > > Well it's not the Smack behavior, it's the combination of Smack's > and SELinux's behavior :) > OK. That's what I thought. > In the end what I have here is probably best anyway - what is > stored in the object hash is not a security struct as known > by any LSM, but a generic object label. So at > object_hash_types[CKPT_OBJ_SEC]->restore(), we don't re-create > an actual security struct, but just a string which is later > used by security_xyztype_restore() to create an actual label. > That's completely reasonable and in keeping with the Smack mindset. Of course, it's easiest if the string is the actual label. Smack wins! > >>> But we must pass the sectype field because in >>> SELinux a different type of structure is stashed in each object type. >>> >> 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? > ... > > >>> + /* 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. > Though selinux_release_secctx > is implemented as a simple kfree, so it would 'just work.' I'm > not sure if it's better to just re-use it, or introduce a new > security_release_context() that does the same thing... > > thanks, > -serge > > >
WARNING: multiple messages have this Message-ID (diff)
From: Casey Schaufler <casey@schaufler-ca.com> To: "Serge E. Hallyn" <serge@hallyn.com> Cc: "Serge E. Hallyn" <serue@us.ibm.com>, Oren Laadan <orenl@cs.columbia.edu>, Linux Containers <containers@lists.osdl.org>, linux-security-module@vger.kernel.org, SELinux <selinux@tycho.nsa.gov>, "Eric W. Biederman" <ebiederm@xmission.com>, Stephen Smalley <sds@epoch.ncsc.mil>, James Morris <jmorris@namei.org>, David Howells <dhowells@redhat.com>, Alexey Dobriyan <adobriyan@gmail.com>, Casey Schaufler <casey@schaufler-ca.com> Subject: Re: [PATCH 3/5] cr: add generic LSM c/r support Date: Sat, 29 Aug 2009 16:40:08 -0700 [thread overview] Message-ID: <4A99BC58.9040205@schaufler-ca.com> (raw) In-Reply-To: <20090829224147.GA12549@hallyn.com> Serge E. Hallyn wrote: > Quoting Casey Schaufler (casey@schaufler-ca.com): > >> Serge E. Hallyn wrote: >> > ... > >>> Briefly, all security fields must be exported by the LSM as a simple >>> null-terminated string. They are checkpointed through the >>> security_checkpoint_obj() helper, because we must pass it an extra >>> sectype field. Splitting SECURITY_OBJ_SEC into one type per object >>> type would not work because, in Smack, one void* security is used for >>> all object types. >>> >> I do not understand why the Smack behavior is a limitation here. >> > > Well it's not the Smack behavior, it's the combination of Smack's > and SELinux's behavior :) > OK. That's what I thought. > In the end what I have here is probably best anyway - what is > stored in the object hash is not a security struct as known > by any LSM, but a generic object label. So at > object_hash_types[CKPT_OBJ_SEC]->restore(), we don't re-create > an actual security struct, but just a string which is later > used by security_xyztype_restore() to create an actual label. > That's completely reasonable and in keeping with the Smack mindset. Of course, it's easiest if the string is the actual label. Smack wins! > >>> But we must pass the sectype field because in >>> SELinux a different type of structure is stashed in each object type. >>> >> 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? > ... > > >>> + /* 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. > Though selinux_release_secctx > is implemented as a simple kfree, so it would 'just work.' I'm > not sure if it's better to just re-use it, or introduce a new > security_release_context() that does the same thing... > > 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.
next prev parent reply other threads:[~2009-08-29 23:40 UTC|newest] Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top 2009-08-28 21:00 [PATCH 1/5] cr: define ckpt_debug if CONFIG_CHECKPOINT=n Serge E. Hallyn 2009-08-28 21:02 ` [PATCH 2/5] cr: checkpoint the active LSM and add RESTART_KEEP_LSM flag Serge E. Hallyn 2009-08-28 21:02 ` Serge E. Hallyn 2009-08-28 21:03 ` [PATCH 1/1] mktree: accept the lsm_name field in header and add -k flag Serge E. Hallyn 2009-08-28 21:03 ` Serge E. Hallyn 2009-08-29 4:43 ` [PATCH 2/5] cr: checkpoint the active LSM and add RESTART_KEEP_LSM flag Casey Schaufler 2009-08-29 4:43 ` Casey Schaufler 2009-08-29 22:59 ` Serge E. Hallyn 2009-08-29 22:59 ` Serge E. Hallyn 2009-08-30 0:03 ` Casey Schaufler 2009-08-30 0:03 ` Casey Schaufler 2009-08-30 13:48 ` Serge E. Hallyn 2009-08-30 13:48 ` Serge E. Hallyn 2009-08-30 18:58 ` Casey Schaufler 2009-08-30 18:58 ` Casey Schaufler 2009-08-30 20:24 ` Serge E. Hallyn 2009-08-30 20:24 ` Serge E. Hallyn 2009-08-30 21:43 ` Casey Schaufler 2009-08-30 21:43 ` Casey Schaufler 2009-08-31 13:22 ` Serge E. Hallyn 2009-08-31 13:22 ` Serge E. Hallyn 2009-08-31 13:36 ` Serge E. Hallyn 2009-08-31 13:36 ` Serge E. Hallyn 2009-09-01 5:51 ` Casey Schaufler 2009-09-01 5:51 ` Casey Schaufler [not found] ` <4A9ACBD4.4020804-iSGtlc1asvQWG2LlvL+J4A@public.gmane.org> 2009-09-01 12:29 ` Russell Coker 2009-09-01 12:29 ` Russell Coker 2009-09-02 16:36 ` Casey Schaufler 2009-09-02 16:36 ` Casey Schaufler 2009-09-02 18:55 ` Shaya Potter 2009-09-02 22:27 ` Casey Schaufler 2009-09-02 22:27 ` Casey Schaufler 2009-08-28 21:04 ` [PATCH 3/5] cr: add generic LSM c/r support Serge E. Hallyn 2009-08-28 21:04 ` Serge E. Hallyn 2009-08-29 4:30 ` Casey Schaufler 2009-08-29 4:30 ` Casey Schaufler 2009-08-29 22:41 ` Serge E. Hallyn 2009-08-29 22:41 ` Serge E. Hallyn 2009-08-29 23:40 ` Casey Schaufler [this message] 2009-08-29 23:40 ` Casey Schaufler 2009-08-30 13:58 ` Serge E. Hallyn 2009-08-30 13:58 ` Serge E. Hallyn 2009-08-30 19:03 ` Casey Schaufler 2009-08-30 19:03 ` Casey Schaufler 2009-08-30 20:26 ` Serge E. Hallyn 2009-08-30 20:26 ` Serge E. Hallyn [not found] ` <4A9ACD0A.9050004-iSGtlc1asvQWG2LlvL+J4A@public.gmane.org> 2009-08-31 12:45 ` Stephen Smalley 2009-08-31 12:45 ` Stephen Smalley 2009-09-01 5:49 ` Casey Schaufler 2009-09-01 5:49 ` Casey Schaufler 2009-09-04 13:38 ` Serge E. Hallyn 2009-09-04 13:38 ` Serge E. Hallyn 2009-08-28 21:04 ` [PATCH 4/5] cr: add smack support to lsm c/r Serge E. Hallyn 2009-08-28 21:04 ` Serge E. Hallyn 2009-08-28 21:05 ` [PATCH 5/5] cr: add selinux support Serge E. Hallyn 2009-08-28 21:05 ` Serge E. Hallyn
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=4A99BC58.9040205@schaufler-ca.com \ --to=casey@schaufler-ca.com \ --cc=adobriyan@gmail.com \ --cc=containers@lists.osdl.org \ --cc=dhowells@redhat.com \ --cc=ebiederm@xmission.com \ --cc=jmorris@namei.org \ --cc=linux-security-module@vger.kernel.org \ --cc=orenl@cs.columbia.edu \ --cc=sds@epoch.ncsc.mil \ --cc=selinux@tycho.nsa.gov \ --cc=serge@hallyn.com \ --cc=serue@us.ibm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.