Re: Attempts at security (was Re: Draft spec for new dpkg "triggers" feature)
Am Samstag 03 Februar 2007 02:21 schrieb Russell Coker:
> On Saturday 03 February 2007 05:17, Hendrik Sattler
> <debian@hendrik-sattler.de> wrote:
> > And everybody gets the SE Linux overhead if he wants or not?
>
> It's disabled by default, unlike in Fedora and Red Hat Enterprise Linux
> where it's on by default. I believe that the latest release of SUSE has
> AppArmor on by default.
RedHat has a long history of strange decisions.
> > The current
> > system does not give you perfect security but neither does adding SE
> > Linux. Instead, you probably get annoying permission problems.
>
> This is why every Windows user uses the administrator account for
> everything.
No, this is caused by other system design flaws and some bad software
companies. Some learned and improved (Nero) and some didn't (Epson).
But Microsoft probably had reason why they hide the file system ACL settings
by default (hint: complexity).
> > > You want features such as exec-shield, well you don't get them -
> > > because of other people with the same attitude as you.
> >
> > Please differ between things that are pretty much automatic (even when
> > not only using debian packages) and things that you need some days to
> > setup correctly (if you ever manage to do so).
> > And always think about the problems that you introduce with such things
> > (and almost all you named have such).
>
> You claim that almost all the examples I gave have problems. Please
> explain the problems that you believe to be in exec-shield, PIE, and
> poly-instantiated directories. Make sure that they are real examples not
> "a program might have some problem" claims.
PIE:
http://www.linuxfromscratch.org/hlfs/view/unstable/uclibc/chapter02/pie.html
Does X already work with it? Mplayer is also name there and thus probably xine
(using these win32-DLLs), too? How about things like Mono?
Exec-shield is related to it, AFAIK.
Since this is selective for every application, it is good. But everything that
increases restrictions of whatever kind will hit a project that cannot handle
this restriction. Not naming those in the same spot as advertising it does
not really help...
But you are right, most users and even programmers will never notice...
For the poly-instantiated views to directories, I am not sure that this is
thought to its end, yet. The main usage will probably be /tmp but there are
already solutions for secure temp file creation. Although it can integrate
with SE Linux, it does not require it.
Users may get confused why they do not see the same directory contents
althought the path is the same.
HS
Reply to: