Re: [developers-l] Re: [debian-devel] Re: security enhanced debian branch?
On Fri, 19 Dec 2003 23:03, peter@devbox.adamantix.org (Peter Busser) wrote:
> has disadvantages and no advantages. LSM only provides one quarter of the
> kernel hooks that RSBAC provides. Therefore the choice is either:
> Castrating RSBAC or not to use LSM. Castrating RSBAC would be really bad,
> so there is not much choice but not to use LSM hooks. Amon posted his view
> on LSM on the RSBAC website[1]. The author of gr-security, Brad Spender,
> has posted a similar view on LSM[2].
The third option that was open to Amon Ott was to work with the LSM developers
to get hooks for all the necessary interfaces. If he had done so then he
would have all non-network hooks he desired in LSM now.
The network hooks are an issue that is being worked on now. If RSBAC used LSM
where possible and it's own hooks otherwise the end result would still have
been better than it is now. It would mean that the RSBAC would conflict with
less other kernel patches.
The LSM kernel patches (which I've been maintaining in Debian for some time)
conflict with a huge number of other kernel patches. This is painful for
code maintenance and a serious disadvantage for users (having to compromise
on which kernel patches they can apply). As LSM is in 2.6 the options
available to users are much better, they can expect that all kernel patches
for 2.6.x kernels will work with SE Linux without any modifications!
If you use RSBAC then you can expect that any complex or invasive kernel patch
will not apply. Some file system kernel patches have been so invasive, XFS
was in it's early days and Reiser4 will probably be so invasive when it's
released (this is not a criticism of either file system, XFS needed some
kernel support that was not in the default kernel and patched everything that
was necessary to provide it, Reiser4 will also add lots of new features and
if Hans achieved half his goals it will have some serious kernel changes).
Finally having LSM in 2.6 means that the interface is stable and we won't have
the pain of forward-porting the patch to new kernels. It seems that almost
no kernel patches are released for new kernels in a timely manner. The users
want them much faster than the upstream provides them, so someone has to do
the forward port. I am very glad that I don't have to do this for 2.6, it
saves me a day's work for every new kernel that's released.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
Reply to: