Casey Schaufler wrote: > > Checkpoint/restart has traditionally been interesting in the > mainframe and supercomputer space. These environments have very > different security profiles from a user desktop. No one at the > [.......] National Supercomputer Centre cares if you can save > your rogue game as soon as you pick up the Amulet of Yendor and > restart it if you get killed on the way up. These environments > are concerned with leaking data between the groups that have > funded the facility, which is why they are very often customers > of advanced access control technologies. I don't know that I see > a really good security story for C/R in the desktop space, and > as Russell points out, there are plenty of opportunities to > exploit the feature. This is of course well outside the scope of > what goes on within an LSM, where the specific issues are more > or less contained. #1 I think you are shortsighted on this, there are many desktop scenarios where c/r has benefits. Think linux terminal services, where one has a large amount of backend machines and doesn't want to kill a user's session due to having to reboot a machine, or to do load balancing. #2 I think all this discussion is making things more complicated than it needs to be. There should be a simple policy decision. Q. Would we allow this "user" (of the restart mechanism) to create a container and be root to it. If the answer is yes, then any restart (even with a maliciously modified checkpoint file) should be allowed to proceed, as no differences between that and what it could do anyways. If the answer is no, then any restart should not be allowed to proceed. why? I imagine restart working something like this a) create new container for restarted processes b) restore processes c) apply container LSM policy d) let processes run why in this order, for the reasoning given before that permissions can change. This can actually be an issue with just a single user if you try to restore as that single user i.e. touch a open(a) chmod 000 a and now try to restart, so shows the reliance on "root" in the context of the new container. its also possible to argue that if one does security model changes such as this, restart should fail, and therfore could switch by b/c above. now getting back to the why. what are the 2 primary attacks that have been mentioned 1) total host security policy 2) maliciously created checkpoint files for #2, if we apply the policy decision I stated above, we shouldn't care about malicious checkpoint files (beyond their ability to trigger kernel bugs), as there's no fundamental difference between what a malicious user could do with a constructed checkpoint file and what our policy decision is based on (being root to the container). for #1, why should this manner? if host policy (say re network connections?) would prevent some sort of functionality, this should cause restart to error out with a security permission error. restart shouldn't ignore host policy in this case. Though I would add, this shouldn't really matter re file system, as each containers fs should be isolated, and if they are shared and have different rules on different machines, I believe you have a much bigger fundamental security problem. This then makes restart just an issue of how LSM policies can actually operate with multiple different containers that should be treated as fully independent machines running on a single host and with possibly different security requirements for each container, but not a checkpoint/restart issue in specific. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
