RSBAC Grsec Selinux ProPolice and Pax
cendres at videotron.ca
Sun Jan 18 05:35:44 PST 2004
On January 18, 2004 07:45 am, Archaic wrote:
> On Sun, Jan 18, 2004 at 04:45:43AM -0500, Robert Connolly wrote:
> > Its unfortunete for us that they decided to patch on redhat packages, but
> > I'm pretty sure they decided to do that for what they thought was best
> > for the community.
> They did what best suited their opinion. Mandrake did the same with
> their version. They even say that much of their stuff is ripped from the
> Fedora patches and modified to their taste. IOW, unless we want to be
> using distro-specific tools, the patches will apparently need rewritten
> and I have no idea how deep the Redhat integration is.
>From what I'm seeing its all trivial. Nothing needs to be rewritten, just
moved around or unconfigured.
> > Redhat has one of the larger user groups, which would bring more
> > Selinux testers and developers. If they patched on GNU software then
> > redhat would need to adapt their patches, making Redhat less likely to
> > add or use Selinux. Aswell anyone but LFS would need to modify Selinux
> > patches if they were patched for vanilla GNU software, making them
> > less standardized, less testable, etc.
> I'm confused... are you arguing for switching to redhat stuff to make
> the patches apply?
Of course not. I just see how selinux would justify using redhat as a base
system. I have no intention of adding any unnessesary features.
> > Selinux can control access of a daemon in chroot better than Grsec.
> They both use MAC and RBAC, so what's different? What specifically can
> GRSec not do? Is the problem because of the daemon being chrooted?
If you have several daemons in the same chroot you can't control letting 2
daemons/users share a file without letting the others. Same goes for network
access (Unless with unix permissions and iptables, but thats not what we're
comparing here). Selinux has a more robust policy language.
> > Setup properly there is no need for services chroot at all on an
> > Selinux system.
> That is a hard pill to swallow as any wall can be torn down. I don't
> like placing all my eggs in one basket. I think services should be
> chrooted to add another layer of security regardless of any other
Like how propolice aborts libsafe's example exploits, libsafe may be obsolete,
but it can be used anyway. On an selinux system, chroot may be obsolete, but
it can be used anyway.
More information about the hlfs-dev