Re: Attempts at security
On Saturday 03 February 2007 22:37, Hendrik Sattler
<debian@hendrik-sattler.de> wrote:
> Am Freitag 02 Februar 2007 21:14 schrieb Reinhard Tartler:
> > Hendrik Sattler <debian@hendrik-sattler.de> writes:
> > > And everybody gets the SE Linux overhead if he wants or not?
> >
> > Which overhead does SE Linux impose to you?
>
> Take a look at the extra paths in the LSM that the kernel runs for many
> system calls. There is no selective choice in what to turn on, except the
> rules that you specify later down that road.
> ALthough capabilities also use the LSM (which sucks, btw), the are pretty
> simple (this is _not_ a comparison to SE Linux).
It would be interesting to do some benchmarks and compare the overhead of a
LSM kernel booted without SE Linux enabled to some of the other overheads we
have.
One that springs to mind is CONFIG_HIGHMEM4G, it seems only useful if you have
more than 896M of RAM. Therefore it seems that all P3 desktop machines with
the i686 kernel package from etch will receive no benefit from it (I am not
aware of any P3 desktop machine that supports more than 512M of RAM).
Another is the fact that all Debian kernels for i686 and similar CPUs are
compiled with SMP enabled even though the vast majority of such machines are
not SMP. Until the most recent developments in CPUs implementing the AMD64
ISA SMP on the desktop was extremely rare (and desktops outnumber servers by
a significant margin).
While an occasional branch statement that is not taken may impose a tiny
overhead, it's nothing compared to having a sub-optimal memory arrangement or
having extra locks for SMP.
This is not to criticise those choices of the kernel team. Having a smaller
number of kernels makes the entire build and support process easier - which
benefits all of us in many non-obvious ways.
Anyway, if the overhead of SE Linux in the kernel is something you consider to
be a problem then there are many bigger problems that you will have with the
Debian kernel packages (or probably any kernel image from a binary
distribution). Best to just compile your own kernel.
> > > The current system does not give you perfect security but neither does
> > > adding SE Linux. Instead, you probably get annoying permission
> > > problems.
> > > Name a few guys that really likes to use this on a private machine and
> > > some real-life improvements that it brings. Hint: "increased security"
> > > is not an argument.
> >
> > I consider "increased security" a very valid argument. The DAC security
> > model is quite outdated now and doesn't really match real world security
> > concerns most workstations are experiencing today!
>
> "Real world security concerns"? Please describe your "real world" and
> compare to the other existant "real world"s.
Do you have any specific objections to Reinhard's statement? Making
ad-hominem attacks on someone else's grasp of reality doesn't help the
discussion.
Do you even know what DAC is and what it's failings are?
> > > Not being able to change the cause to the better doesn't mean to
> > > introduce a mess to control the result. And I really hope that Debian
> > > never considers installing+enabling selinux by default.
> >
> > IIRC, debian/etch already does already install selinux today without you
> > even noticing it.
>
> It is not enabled by default. That is the other point: you get that selinux
> integration if you want or not.
Apart from those branch instructions in the kernel image what specific things
do you object to?
--
russell@coker.com.au
http://etbe.blogspot.com/ My Blog
http://www.coker.com.au/sponsorship.html Sponsoring Free Software development
Reply to: