All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Serge E. Hallyn" <serue@us.ibm.com>
To: Casey Schaufler <casey@schaufler-ca.com>
Cc: Oren Laadan <orenl@cs.columbia.edu>,
	Linux Containers <containers@lists.osdl.org>,
	David Howells <dhowells@redhat.com>,
	Alexey Dobriyan <adobriyan@gmail.com>,
	linux-security-module@vger.kernel.org
Subject: Re: [PATCH 0/8] a start to credentials c/r
Date: Wed, 27 May 2009 13:24:32 -0500	[thread overview]
Message-ID: <20090527182432.GE780@us.ibm.com> (raw)
In-Reply-To: <4A1D6449.4020906@schaufler-ca.com>

Quoting Casey Schaufler (casey@schaufler-ca.com):
> Serge E. Hallyn wrote:
> > Quoting Casey Schaufler (casey@schaufler-ca.com):
...
> > Uh, so yes, bsaed on info in the file as well  :)  Except
> > of course the LSM would just be fed the checkpointed context
> > and the checkpoint file context (and can deduce current's context).
> >   
> 
> And SELinux can do whatever calculations it likes based on the
> three contexts and the loaded policy.  Are you at all concerned
> about the possibility that the policy may have changed? I can
> envision scenarios in which it would be impossible for a process
> to gain a particular context under current policy, but that a
> checkpointed process may have stored away.

Good point.  But on the other hand, if the program were running
the whole time, instead of being checkpointed and restarted, then
the running program wouldn't be relabeled when the policy changed,
right?  Now if the domain becomes invalid, then presumably the
restart would fail.  But if the (source_domain,entry_type)->new_domain
set changes from (root_t,x_entry_t)->x_t to (root_t,x_entry_t)->y_t,
a task running as x_t won't be relabeled to y_t.  So I don't thnk
restarting a task which is checkpointed as x_t, under the x_t
domain, is wrong.

> >>>  and one which determines
> >>> the task->cred->security filed based upon any of:
> >>> 	1. current_security() of the task calling sys_restart()
> >>> 	2. the task->cred->security checkpointed in the ckpt file
> >>> 	3. the ->security of the checkpoint file
> >>>   
> >>>       
> >> For Smack the correct behavior would be:
> >>
> >>     1. for sys_restart() callers without CAP_MAC_ADMIN
> >>     2. for sys_restart() callers with CAP_MAC_ADMIN
> >>     3. never
> >>     
> >
> > That makes sense, and is basically analagous (if I'm thinking
> > right) to how I'm doing capabilities.
> >
> > So the first (authorization hook) for smack would just always
> > return TRUE?
> >   
> 
> I suggest that it needs to check for a valid Smack label. Even though
> they're just text strings they do have limitations, including size
> (> 0 < 24) and character set. A call to smk_import() is the right
> way to do it, as it also makes sure the label is in the internal list.
> If smk_import() returns NULL something's amiss.

Ok, thanks.

-serge

      reply	other threads:[~2009-05-27 18:24 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-26 17:32 [PATCH 0/8] a start to credentials c/r Serge E. Hallyn
2009-05-26 17:33 ` [PATCH 1/8] cr: break out new_user_ns() Serge E. Hallyn
2009-05-26 17:33 ` [PATCH 2/8] cr: split core function out of some set*{u,g}id functions Serge E. Hallyn
2009-05-26 17:33 ` [PATCH 3/8] cr: capabilities: define checkpoint and restore fns Serge E. Hallyn
2009-05-26 17:33 ` [PATCH 4/8] groups: move code to kernel/groups.c Serge E. Hallyn
2009-05-26 17:33 ` [PATCH 5/8] groups: allow compilation on s390x Serge E. Hallyn
2009-05-26 23:17   ` Serge E. Hallyn
     [not found] ` <20090526173242.GA13757-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-05-26 17:33   ` [PATCH 6/8] cr: checkpoint and restore task credentials Serge E. Hallyn
2009-05-27 18:36     ` Alexey Dobriyan
2009-05-28 14:01       ` Serge E. Hallyn
2009-05-28 14:36         ` Alexey Dobriyan
2009-05-26 17:34 ` [PATCH 7/8] cr: restore file->f_cred Serge E. Hallyn
2009-05-26 17:34 ` [PATCH 8/8] user namespaces: debug refcounts Serge E. Hallyn
2009-05-27  3:05 ` [PATCH 0/8] a start to credentials c/r Casey Schaufler
2009-05-27 12:37   ` Serge E. Hallyn
2009-05-27 16:03     ` Casey Schaufler
2009-05-27 18:24       ` Serge E. Hallyn [this message]

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=20090527182432.GE780@us.ibm.com \
    --to=serue@us.ibm.com \
    --cc=adobriyan@gmail.com \
    --cc=casey@schaufler-ca.com \
    --cc=containers@lists.osdl.org \
    --cc=dhowells@redhat.com \
    --cc=linux-security-module@vger.kernel.org \
    --cc=orenl@cs.columbia.edu \
    /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: link
Be 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.