From: "Serge E. Hallyn" <serue@us.ibm.com>
To: James Morris <jmorris@namei.org>
Cc: Linux Containers <containers@lists.osdl.org>,
linux-security-module@vger.kernel.org,
SELinux <selinux@tycho.nsa.gov>,
Stephen Smalley <sds@epoch.ncsc.mil>,
Alexey Dobriyan <adobriyan@gmail.com>,
Casey Schaufler <casey@schaufler-ca.com>,
Andrew Morgan <morgan@kernel.org>
Subject: Re: [PATCH 1/1] cr: lsm: restore LSM contexts for ipc objects
Date: Mon, 22 Jun 2009 11:25:24 -0500 [thread overview]
Message-ID: <20090622162524.GA926@us.ibm.com> (raw)
In-Reply-To: <alpine.LRH.2.00.0906221537190.19585@tundra.namei.org>
Quoting James Morris (jmorris@namei.org):
> On Fri, 19 Jun 2009, Serge E. Hallyn wrote:
>
> > Here is the next version of the patch implementing checkpoint
> > and restore of LSM contexts. This is just handling IPC objects
> > as a proof of concept. But actually, looking ahead and both
> > files and tasks, I see that selinux stores several sids in the
> > security structs. For instance, for tasks there is the current
> > sid, exec sid, create sid, keycreate_sid, and sockcreate_sid.
> > So I guess I'll have to ask the LSM for how many secids it wants
> > to checkpoint, then checkpoint an array of contexts?
> >
>
> Can you please explain exactly what checkpoint/restart is?
Take a container or (it is still subject to debate whether to allow
this) any process tree, freeze it, record the state of the tasks,
all objects they own, and the filesystem. The result is a checkpoint
image file for later use. Unfreeze, and either continue running or
kill. Later, restart from the checkpoint image, which will create
a new container containing all of the needed objects (IPC semaphores,
open files, sockets, etc) and restart all tasks exactly where they
left off.
While it seems very likely that in the end (when it hits upstream)
we will require privilege to use restart at all, we are doing our
best to design it so that it is safe for unprivileged users. That
means that every object creation must be contingent on the authorization
of the task calling sys_restart(). After all, it is a trivial matter
to call sys_checkpoint() on your own vim process, edit the checkpoint
file to change the filename to /etc/passwd and the process uid to 0,
and then call sys_restart() on the result.
Since we don't want to talk about any 'trusted' user in SELinux at
all, the same mindset required to support unprivileged restart for the
DAC perms very much applies to c/r of SELinux state.
I'll add an explanation to the next version of the patch.
thanks,
-serge
WARNING: multiple messages have this Message-ID (diff)
From: "Serge E. Hallyn" <serue@us.ibm.com>
To: James Morris <jmorris@namei.org>
Cc: Linux Containers <containers@lists.osdl.org>,
linux-security-module@vger.kernel.org,
SELinux <selinux@tycho.nsa.gov>,
Stephen Smalley <sds@epoch.ncsc.mil>,
Alexey Dobriyan <adobriyan@gmail.com>,
Casey Schaufler <casey@schaufler-ca.com>,
Andrew Morgan <morgan@kernel.org>
Subject: Re: [PATCH 1/1] cr: lsm: restore LSM contexts for ipc objects
Date: Mon, 22 Jun 2009 11:25:24 -0500 [thread overview]
Message-ID: <20090622162524.GA926@us.ibm.com> (raw)
In-Reply-To: <alpine.LRH.2.00.0906221537190.19585@tundra.namei.org>
Quoting James Morris (jmorris@namei.org):
> On Fri, 19 Jun 2009, Serge E. Hallyn wrote:
>
> > Here is the next version of the patch implementing checkpoint
> > and restore of LSM contexts. This is just handling IPC objects
> > as a proof of concept. But actually, looking ahead and both
> > files and tasks, I see that selinux stores several sids in the
> > security structs. For instance, for tasks there is the current
> > sid, exec sid, create sid, keycreate_sid, and sockcreate_sid.
> > So I guess I'll have to ask the LSM for how many secids it wants
> > to checkpoint, then checkpoint an array of contexts?
> >
>
> Can you please explain exactly what checkpoint/restart is?
Take a container or (it is still subject to debate whether to allow
this) any process tree, freeze it, record the state of the tasks,
all objects they own, and the filesystem. The result is a checkpoint
image file for later use. Unfreeze, and either continue running or
kill. Later, restart from the checkpoint image, which will create
a new container containing all of the needed objects (IPC semaphores,
open files, sockets, etc) and restart all tasks exactly where they
left off.
While it seems very likely that in the end (when it hits upstream)
we will require privilege to use restart at all, we are doing our
best to design it so that it is safe for unprivileged users. That
means that every object creation must be contingent on the authorization
of the task calling sys_restart(). After all, it is a trivial matter
to call sys_checkpoint() on your own vim process, edit the checkpoint
file to change the filename to /etc/passwd and the process uid to 0,
and then call sys_restart() on the result.
Since we don't want to talk about any 'trusted' user in SELinux at
all, the same mindset required to support unprivileged restart for the
DAC perms very much applies to c/r of SELinux state.
I'll add an explanation to the next version of the patch.
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-06-22 16:25 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-20 1:32 [PATCH 1/1] cr: lsm: restore LSM contexts for ipc objects Serge E. Hallyn
2009-06-20 1:32 ` Serge E. Hallyn
2009-06-22 5:37 ` James Morris
2009-06-22 5:37 ` James Morris
2009-06-22 16:25 ` Serge E. Hallyn [this message]
2009-06-22 16:25 ` Serge E. Hallyn
[not found] ` <20090620013216.GA4435-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-06-22 14:47 ` Stephen Smalley
2009-06-22 14:47 ` Stephen Smalley
2009-06-22 17:50 ` Serge E. Hallyn
2009-06-22 17:50 ` Serge E. Hallyn
2009-06-22 18:23 ` Stephen Smalley
2009-06-22 18:23 ` Stephen Smalley
2009-06-23 3:10 ` Casey Schaufler
2009-06-23 3:10 ` Casey Schaufler
2009-06-23 17:55 ` Stephen Smalley
2009-06-23 17:55 ` Stephen Smalley
2009-06-23 18:18 ` Serge E. Hallyn
2009-06-23 18:18 ` Serge E. Hallyn
2009-06-23 19:57 ` Serge E. Hallyn
2009-06-23 19:57 ` Serge E. Hallyn
2009-06-24 13:10 ` Stephen Smalley
2009-06-24 13:10 ` Stephen Smalley
2009-06-24 22:07 ` Serge E. Hallyn
2009-06-24 22:07 ` Serge E. Hallyn
2009-06-25 12:34 ` Stephen Smalley
2009-06-25 12:34 ` Stephen Smalley
2009-06-25 12:59 ` Serge E. Hallyn
2009-06-25 12:59 ` Serge E. Hallyn
2009-06-25 14:06 ` Stephen Smalley
2009-06-25 14:06 ` Stephen Smalley
2009-06-25 4:21 ` Oren Laadan
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=20090622162524.GA926@us.ibm.com \
--to=serue@us.ibm.com \
--cc=adobriyan@gmail.com \
--cc=casey@schaufler-ca.com \
--cc=containers@lists.osdl.org \
--cc=jmorris@namei.org \
--cc=linux-security-module@vger.kernel.org \
--cc=morgan@kernel.org \
--cc=sds@epoch.ncsc.mil \
--cc=selinux@tycho.nsa.gov \
/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.