On Jan 22, 2008 1:04 PM, Simo Sorce <ssorce@xxxxxxxxxx> wrote: > > > On Tue, 2008-01-22 at 13:01 -0500, Yaakov Nemoy wrote: > > On Jan 22, 2008 12:16 PM, Jeff Spaleta <jspaleta@xxxxxxxxx> wrote: > > > Selinux when interacting with any chroot-like apparatus is still a > > > problem. Perhaps its time to take stock of all the packages that rely > > > on chroot-like behavior which are similarly affected by selinux, so > > > that a common technical solution can be found and applied. > > > > +1 > > > > This is just a bug between SELinux and any chrooting program. It is > > not a reason to fetch torches and pitchforks or to complain that > > SELinux sucks, or any of that nonsense. Fixing the interaction between > > SELinux and chroot is one of those things that can only get better the > > more real world usage SELinux sees. > > It seem to me that SELinux can provide for the same (or better) > "features" of chroot without actually requiring a chrooted environment. > So shouldn't we simply provide targeted policies and not use chroot for > known services ? Chroot provides a bunch of other 'features' (actually lack thereof) that SELinux on its own can't provide itself. SELinux can block a program from accessing certain files, or doing certain things on the machine, which is great for security. SELinux would have a harder time telling a program that a certain file doesn't exist, such as in a mock chroot. Furthermore, the chroot could be used to provide a more dynamic environment that is dissimilar to the host environment, such as using mock to build many different kinds of packages in a 'clean room'. The SELinux policy for that would have to be incredibly flexible. I don't think it's a sane idea. (I could be wrong.) I think what you really want is SELinux to be in some ways chroot aware, so that it can handle a policy within a policy, something that would let you chroot a policy into SELinux. You'd probably want a meta-chroot-policy as well, to define who or what can or cannot use chroot. It might even make doing certain things like running mock or revisor easier to implement so that they don't neet root access, or if they do, they are better confined. Honestly, I wish i knew more about writing policies to suggest what a better solution could be tough. -Yaakov -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
