[Devel] Re: [PATCH 2/5] cr: checkpoint the active LSM and add RESTART_KEEP_LSM flag

[Serge E. Hallyn]

Quoting Casey Schaufler (casey at schaufler-ca.com):
> Serge E. Hallyn wrote:
> > Quoting Casey Schaufler (casey at schaufler-ca.com):
...
> > What exactly would refusing the restart prevent?
> >
> > You already have the passwords in the checkpoint file, so you're
> > not protecting those.
> >   
> 
> 
> I seem to be having some trouble presenting my point. It's not about
> the passwords. It's not about the firewall configuration. It's not
> even really about the SELinux policy. It's about the total security
> configuration of the system. This is a problem with checkpoint/restart
> in general and there isn't much we can do about reassigning user id
> and other bad things that can happen.
> 
> If the admin decides that an action is acceptable because the SELinux
> policy prevents some other action it had better be the case that a
> process was never allowed to perform that "other action". If you allow
> restart across policy changes you can't be sure that the process has
> not performed such an "other action". Processes are not stateless.

No, but again there are only 3 kinds of state that I can think of
that are relevant at restart:

	1. calculations which were made before ckpt and after
	   restart.  For instance,  maybe before the policy change
	   the task could read key a but not key b.  After it could
	   read key b but not a.  With both keys, it can rule the
	   world.
	   In this case c/r changes nothing, bc the user could get
	   the same info using ptrace.

	2. system-wide changes which the task could do with the
	   old policy, while it could do different once after.
	   Doing both changes it can rule the world.
	   Again, c/r changes nothing, bc the user could simply
	   run the program twice to make both changes.
	
	3. resources (file descriptions, whatever) which the task
	   could create before the policy change but not after.
	   Every resource will be re-opened at sys_restart()
	   using the credentials of the caller.
	   This isn't perfect.  It means that if the program
	   started out privileged to open some file and then
	   dropped privilege, then the program either will fail
	   to restart, or will have to be restarted with extra
	   privilege.  And there's a decent chance that the
	   sys_restart() caller will have more privs than the
	   program anyway.  But that is why I feel pretty strongly
	   that it's up to the caller, in userspace, to worry about
	   it and do policy checks if need be.

I am more worried about a user taking a checkpoint image and
editing it, then pursuading a more privileged user to restart it
for him.  "see, the source was trustworthy and needed privs to
start.  can you restart it for me?"

The only thing to do about that is to eventually do TPM signing
of checkpoint images.

> > The program was running under xyz_t, which on the old system was
> > allowed to make some change the fw configuration, but is not under
> > the new.  Then after restart, it will be labeled as xyz_t, and
> > won't be allowed to make the change.
> >
> > When a program running as abc_t calls sys_restart() do restart
> > the task under xyz_t, then
> > 	1. everything which is re-created for the task will
> > 	   need to be allowed (under current policy) to
> > 	   abc_t.
> > 	2. abc_t will need to be allowed process_t:restore to
> > 	   xyz_t.
> >
> > What exactly can the abc_t task do if allowed to restart,
> > which it couldn't otherwise do?
> 
> That's the point. It does not have to do the bad thing, it has
> already been done. The cat is out of the bag. The process now has
> state that it couldn't get under the new policy.

Again I claim that any state it couldn't get under the new policy,
either it could get using ptrace anyway (i.e. a key), or it can't
re-create the state because the new policy will prevent it.

>  The new policy
> allows the process to do something that it could not had it
> started under the new policy.

And it still is re-starting under the new policy, though again
(I keep stressing bc this worries me more) the authorization
checks are done against the credentials at sys_restart(), not
the checkpointed credentials.

...

> > Then I would argue the user (who has authorization to restart this
> > beast and therefore is hopefully not malicious) should have compared
> > policies before doing sys_restart...
> >   
> 
> I'm a firm believer in malicious users. That, and users who are
> sufficiently stupid to be indistinguishable from malicious users.
> That, and users who are sufficiently clever to do the same things
> that a malicious user would do in order to do something that looks
> like a really good idea, but that is not.

So do you think that adding a policy version check in the kernel
at restart would help this?

Do you think providing a recipe for userspace to do the policy
checks would help?  Along with a security_may_restart() hook
so that LSM policy can force restart to go through a helper
that does these checks, if it wants to enforce that?

-serge
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers