[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: selinux breaks revisor

On Jan 22, 2008 1:04 PM, Simo Sorce <ssorce redhat com> wrote:
> On Tue, 2008-01-22 at 13:01 -0500, Yaakov Nemoy wrote:
> > On Jan 22, 2008 12:16 PM, Jeff Spaleta <jspaleta gmail com> 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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]