On Fri, 2006-09-15 at 15:23 -0400, Rosalie Hiebel wrote: > Thanks very much for the explanation of how the context of instance > directories is computed. Once I added the proper type_member rule, > it was working as you described.
Ok, good. > I want an application which runs at various MLS levels to see only > the instance whose MLS level matches the process's MLS level; I > thought polyinstantiation by context would easily provide this. If the application is security-aware and knows what level it is operating in, it could just directly manage and access the proper per-level instance directories. No need to have it transparently created and mounted in that situation. Now, if the main application itself is security-aware, but you want it to launch sub-applications that are untrusted and security-unaware, then the main application could very well use pam_namespace to set up the namespace in the child process prior to exec'ing the sub-application in the desired level. That would provide transparency to the sub-applications as well as providing stronger isolation than doing everything in the main application. > We > also would occasionally like certain processes to be able to see all > instances of it at or below the MLS level of the process. Is this > possible with polyinstantiation? (Would the user being in the list > of excluded uids be required?) I think there are different options here, e.g.: - put the user in the exclusion list to avoid creating a separate namespace altogether, or - directly access the instance directories if they live outside of the polyinstantiated directory (as per namespace.conf), or - unmount any bind mounts from the current namespace in order to see the instance directories if they live within the polyinstantiated directory. Or just create the process outside of anything that uses pam_namespace. -- Stephen Smalley National Security Agency -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
