[Devel] Re: [PATCH 09/10] cr: restore LSM credentials
Serge E. Hallyn
serue at us.ibm.com
Wed Jun 10 07:59:12 PDT 2009
Quoting Stephen Smalley (sds at tycho.nsa.gov):
> On Tue, 2009-06-09 at 20:46 -0500, Serge E. Hallyn wrote:
> > Checkpoint and restore task and ipc struct ->security info.
> > (files->f_security yet to be done).
> >
> > LSM contexts (a string representation of obj->security) are
> > checkpointed as shared objects before any object referencing
> > it. The object's checkpoint header struct has a reference
> > (h->sec_ref) to the shared object. A NULL ->security is indicated
> > by h->sec_ref = -1.
> >
> > At checkpoint time, for each obj->security to be checkpointed,
> > the LSM will be asked (once) to convert it to a string, in memory
> > which the checkpoint subsystem will kfree. At restart time,
> > the LSM will first return some meaningful token given the
> > checkpointed string. That token will be passed to per-object-type
> > restore functions (task_restore_context(), shm_restore_security(),
> > etc) where the LSM can determine based on the object type, the
> > caller, and the token, whether to allow the object restore, and
> > what value to actually assign to ->security. In smack, the
> > token is the actual imported label. In SELinux, it is a temporary
> > pointer to the sid which the checkpointed context referred to.
Thanks for taking a look.
> Possibly I misunderstand, but it appears that you have a single
> security_context_to_str() hook that tries to take an arbitrary
Yikes, you're right. And I remember telling myself that wouldn't
work - then apparently I ran into the next problem and forgot.
> ->security pointer for any object type. I don't believe that is safe,
> as each object type may have its own security structure.
Absolutely. Which begs the question why it was working for me :)
> There are already LSM hooks to obtain secids for objects (task, ipc,
> inode, sock), and to convert between secid and secctx strings for use by
> the audit subsystem and networking subsystem. Why can't you just use
> those hooks for getting the secids and then converting them to secctx
> strings later?
I had taken a look at the *_secid() hooks, and think I misunderstood
them. Using those makes sense; I'll make that change.
> > In smack, the checkpointed labels are used for both tasks and
> > ipc objects so long as the task calling sys_restart() has
> > CAP_MAC_ADMIN. Otherwise, if the checkpointed label is different
> > from current_security(), -EPERM is returned.
> >
> > The basics of SELinux support are there (enough to demonstrate working
> > c/r with SELinux enforcing), but there will need to be new object
> > permissions for restore, so the precise nature of those needs to be
> > discussed. For instance, do we want to define process:restore
> > and ipc_msg_msg:restore, in which case
> > allow root_t user_t:process restore
> > would mean that root_t may restart a task and label it user_t?
>
> I think so, yes.
Ok, I'll define those in the next set.
thanks,
-serge
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
More information about the Devel
mailing list