[Devel] Re: [PATCH 0/8] a start to credentials c/r

Serge E. Hallyn serue at us.ibm.com
Wed May 27 11:24:32 PDT 2009


Quoting Casey Schaufler (casey at schaufler-ca.com):
> Serge E. Hallyn wrote:
> > Quoting Casey Schaufler (casey at 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
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers




More information about the Devel mailing list