Russell Coker wrote: > On Mon, 31 Aug 2009, Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote: > >> 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. >> > > Of course we potentially have the same issue when changing a boolean, and when > loading a new policy on a running system. In a realistic scenario, if you > make a change that allows a process context to write to a public data store > while at the same time denying read access to secret data then you also need > to purge the contents of any files that the process may open for read/write. > > Similar problems can also occur using Unix permissions and certain > combinations of chmod with setuid/setgid bits. Of course most potential > cases of triggering this issue with Unix permissions are extremely contrived > and wouldn't be a likely attack scenario. The best example I can think of > with Unix permissions is access to sound devices. If a system is configured > to add the "audio" supplementary group to a user's session when they login at > the console then they can keep a detached process running to maintain access > to the audio devices (and anything else permitted to that group). > 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. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
