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). PS Do we really need so many on the CC list? I removed a few entries of people who are on the SE Linux list. -- russell@xxxxxxxxxxxx http://etbe.coker.com.au/ My Main Blog http://doc.coker.com.au/ My Documents Blog -- 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.
